<div dir="ltr"><div><div><div>Hi Aaron, hi Pepi , <br><br>thank you very much for your comments.<br><a href="http://dualec.org/DualECTLS.pdf"></a></div>I tried to answer to both mails with this mail. I marked Pepi's answer with 'P>'.<br>
<br></div>Kind regards<br></div>Torsten<br><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2014-04-04 2:37 GMT+02:00 Aaron Zauner <span dir="ltr"><<a href="mailto:azet@azet.org" target="_blank">azet@azet.org</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Torsten,<br>
<br>
First off: Why wouldn't the OWASP project simply refer to other projects<br>
concerning cryptography recommendations (ENISA, bettercrypto [...])?<br>
This might spare you hours of valuable time.<br></blockquote><div>In my project there, we'd like to include the most important best practices to mitigate the OWASP Top 10. These Examples in our Wiki are used as an appetizer for the Links (within and outside OWASP). Up to now, we run for this to support JAVA and PHP developers. Up to now we started it in German. You have done a great job on <a href="http://bettercrypto.org">bettercrypto.org</a>, so you are naturally included as Link ;-)<br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Torsten Gigler wrote:<br>
> I'd like to contribute this policy for ciphers to the discussion:<br>
> * Highest Priority for Ciphers that support 'Forward Secrecy'<br></blockquote><div>P> ONLY ciphers that support PFS, non-pfs compatibility fallback only for TLS 1.0.<br></div><div>P><br></div><div>P> In addition: I propose to change the cipher string to disable TLS_RSA_WITH_AES_(128|256)_CBC_SHA (0x2f|0x35) for TLS > 1.0. > It is our “legacy fallback cipher” and shouldn't be used in TLS 1.1 or TLS 1.2 in favor of PFS ciphers.<br>
</div><div>This would be fine. Do you know how to configure this with e.g. Apache? <br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> * Favor DHE over ECDHE (with a hint to check the performance)<br>
ACK.<br></blockquote><div>P> With proper TLS session tickets the impact of DHE is minimal even on slow devices like “smart” phones. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * Favor GCM over CBC regardless of the cipher size<br>
ACK. CBC mode in TLS <1.1 will be vulnerable to the BEAST attack.<br>
<br></blockquote><div>Is it still an issue? (<a href="https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat">https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat</a>)<br>
What do you suggest for this for TLS<1.1, I think RC4 does perhaps more worse than good (+ same question as above, how to limit cipher to be used only for old protocols?)<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> * Priorize the ciphers by the sizes of the Cipher and the MAC<br>
How do you prioritize those? The MAC has to fit the security of the<br>
symmetric algorithm in question.<br></blockquote><div>You priorize them by the order of the Cipher String, which defines the order, if the 'server order' is set.<br></div><div>In this case the<b> server selects</b> one of ciphers a<b> client offers</b> in the Client-Hello. So you can control on server side the cipher that will be used when a type of browser connects (if the user does not suppress some ciphers ;-) )<br>
</div><div>E.g. (for the cipher string discussed in this thread): TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b) will be used by Opera and Safari, TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) will be mainly used by Chrome and Firefox;<br>
<a href="https://www.ssllabs.com/ssltest/analyze.html?d=bettercrypto.org&hideResults=on">https://www.ssllabs.com/ssltest/analyze.html?d=bettercrypto.org&hideResults=on</a> (Handshake Simulation for the cipher string of <a href="http://bettercrypto.org">bettercrypto.org</a>)<br>
</div><div>Up to now, I do not understand the order of the <a href="http://bettercrypto.org">bettercrypto.org</a> cipher string (DHE/ECDHE, and GCM/CBC mixed...) .....<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> * Favor RSA over ECDSA<br>
ACK.<br></blockquote><div>P> I'd like to discuss the exclusion of DSA.<br>P> <a href="https://projectbullrun.org/dual-ec/tls.html">https://projectbullrun.org/dual-ec/tls.html</a><br>P> <br>P> When you have bad randomness and reuse a nonce you're leaking your private key. Nadia Heninger called this a “strange property” in “The year in crypto” at 30C3.<br>
P> <a href="http://media.ccc.de/browse/congress/2013/30C3_-_5339_-_en_-_saal_1_-_201312281830_-_the_year_in_crypto_-_nadia_heninger_-_djb_-_tanja_lange.html">http://media.ccc.de/browse/congress/2013/30C3_-_5339_-_en_-_saal_1_-_201312281830_-_the_year_in_crypto_-_nadia_heninger_-_djb_-_tanja_lange.html</a><br>
<br>Do you mean this "The researchers also successfully recovered signature keys from TLS servers that used DSA or ECDSA to sign DH/ECDH public keys."? (from <a href="http://dualec.org/DualECTLS.pdf">http://dualec.org/DualECTLS.pdf</a> / <i><a href="http://www2.futureware.at/~philipp/dualec/On%20the%20Practical%20Exploitability%20of%20Dual%20EC%20in%20TLS%20Implementations.htm">Cache</a>)<br>
</i></div><div><i>=> </i>Yes, it is possible to downgrade or exclude this ciphers even without loosing a Browser or huge downgrades of cipher strength.<i><br></i></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I have recently come to the conclusion that - basically - djb pointed to<br>
and solved most problems 10years before the wider community and<br>
implementors notice them. Of course this is a generalization - and not<br>
always true (TCP SYN cookies) - but it's mostly true. The issue being<br>
that you need more feedback than djb to standardize stuff. :)<br>
<br>
Ed25519 looks really nice. But it's not deployed anywhere near TLS, as<br>
far as I know. See: <a href="https://en.wikipedia.org/wiki/EdDSA" target="_blank">https://en.wikipedia.org/wiki/EdDSA</a><br></blockquote><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
related hint (off topic, I know): DNSSEC DDOS will become a real problem<br>
in the next couple of years. I've talked to Dan Kaminsky on twitter<br>
about the issue. His basic response was "but other protocols suck as<br>
well!". Without starting another flame: this is just naive. Have fun<br>
with a badly designed, hierarchical, "trust" protocol. As such DANE<br>
seems to be doomed as well.<br>
<br>
> * Append the list with Ciphers for legacy browsers and web crawlers<br>
> * Do not use RC4, MD5,... etc<br></blockquote><div>P>Already the case.<br><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> * Ciphers should be usable for DH >= 2000 bits, without blocking latency<br>
> browsers<br></blockquote><div>P> That is a client and implementation problem. Many clients balk at DH params > 1024bits.<br></div><div>Agree. But the server should not use DH-Ciphers used by latency browsers with this issue (=> so I haven't included ciphers like TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x32)'), OK?<br>
<br>>> TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)<br>P> We already agreed to NOT include this one.<br></div><div>This is the only cipher I found that is usable for IE on XP, Win 2003 <br></div><div><br>P> Our
ciphers also explicitly specify cipher's 256bit and 128 bit variants so
one can easily disable the 128bit variants without having to do a lot
of research on how to properly specify a cipher string. (You can just
remove all -128- parts of the string to end up with only 256bit ciphers.
This is intentional.)<br><br>P> Best regards<br>P> Pepi<br><br></div><div>> * Append the list with Ciphers for legacy browsers and web crawlers<br>Our “Cipher A” doesn't respect compatibility with clients at all, especially not legacy ones. Our “Cipher B” is less forward looking and wider compatible. I consider it a bad proposal to give way to broad compatibility in our recommendations. Repeating myself: We're doing betterCRYPTO.org not <a href="http://bettercompatibility.org">bettercompatibility.org</a> or <a href="http://betterperformance.org">betterperformance.org</a>. (Both domains _still_ available.)<br>
</div><div>Well this is always the question between security and usablility, you should know the risk and decide....<br>I do think that is easy to get an A+ at <a href="http://ssllabs.com">ssllabs.com</a>, but you won't be accessible any more by a huge audience.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Conrete this results in this ciphers (grouped according above policy):<br></blockquote><div>Updated:<br><pre>TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x9f)
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x9e)
-------------------------------------------------
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x6b)
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39)
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x67)
=================================================
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
.................................................
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
-------------------------------------------------<br>TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c) => probabely excluded<br>TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) => probabely excluded<br>.................................................<br>
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024) => probabely excluded<br>TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) => probabely excluded
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023) => probabely excluded<br>TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) => probabely excluded<br>=================================================
TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)
TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)
-------------------------------------------------
TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)<br>NN ? => Any alternative for 'TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)' for letency browsers/OS like Win 2003/XP?</pre></div><div>=> openssl ciphers -V EDH+aRSA+AESGCM:EDH+aRSA+AES:DHE-RSA-AES256-SHA:-DHE-RSA-AES128-SHA:EECDH+aRSA+AESGCM:EECDH+aRSA+AES:RSA+AESGCM:RSA+AES+SHA <br>
</div><div>(without DAS, 3DES)<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
><br>
> This could be reached by this cipher string:<br>
> openssl ciphers -V<br>
> EDH+aRSA+AESGCM:EDH+aRSA+AES:DHE-RSA-AES256-SHA:-DHE-RSA-AES128-SHA:EECDH+AESGCM:EECDH+AES:RSA+AESGCM:RSA+AES+SHA:DES-CBC3-SHA<br>
><br>
> Remarks:<br>
> '-DHE-RSA-AES128-SHA':used to be able to use DH >= 2000 bits, without<br>
> blocking latency browsers<br>
> 'DHE-RSA-AES256-SHA': for compatibility reasons for elder versions of<br>
> openssl<br>
I don't really follow there, regarding the "DH >= 2000 bits".<br></blockquote><div> I have excluded DH-ciphers that are used by IE and Java that support only 1024bits (os less). If not the cipher may be choosen by the server and fail on the client later (see also above) <br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><font color="#888888"><br>
<br>
Aaron<br>
<br>
</font></span></blockquote></div><br></div></div></div></div></div>