On Thu, Aug 6, 2015 at 1:35 PM, Scott Fluhrer (sfluhrer) <sfluh...@cisco.com > wrote:
> I recently reviewed the most recent TLS 1.3 draft, and I must say that I > am impressed; the protocol appears to be a significant improvement. In > particular, you simplify the protocol significantly, and as we all know, > complexity is the enemy of security. You also drop many of the weak > options, such as RC4 and the export ciphers; that sounds like an excellent > idea. > > > > That said, I do see a few things that puzzle me: > > > > - When dealing with ECDSA signatures, the default hash algorithm > is SHA1, and any other hash function needs to be specified explicitly. > Might I ask why that is? No one has demonstrated a SHA1 collision yet; > however people are creeping closer. If you ask me (which you didn’t, but > I’ll give my opinion anyways), the default should be (at least) SHA-256; > you should allow SHA-1 as a downgrade option only if someone makes a strong > case that they can implement ECDSA and the rest of TLS 1.3, but > implementing SHA-256 is just too hard. Otherwise, it should be discarded > just like the other known weak cryptographical primitives (such as RC4). > > - You also allow the provision of someone using MD5 as the hash > algorithm. Take the above comments about how SHA-1 is not a good idea, and > multiply it by a factor of about 10. I see no justification for allowing > someone to use a known broken hash algorithm. > This is just a transient state. We have patches in progress to remove both of these. - Given the general theme of simplification, I was a bit puzzled > by something; you appear to provide two different solutions to “how do I > quickly reestablish a TLS tunnel”; you have both 0-RTT and session > resumption. While both appear to have minor advantages over the other, I > don’t immediately see any real justification for including the complexity > of both. Now, it might be that I’m catching a draft in the middle, and > that you fully intend to combine them. Alternatively, there might be > strong reasons to have both (and it just doesn’t occur to me). In either of > those two cases, “never mind” > Each of these has some benefit, though I agree that it would be nice to combine them. The big issue is: - For security reasons it's much easier to work with 0-RTT DH exchanges. - For performance reasons it's nice to have resumption. -Ekr > > > However, despite these minor nits, I would end with saying that the > working group has done good work on this draft; I look forward to the end > product. > > > > Thanks! > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
