Subject: [TLS] Comments on the TLS 1.3 draft

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Thu, 6 Aug 2015 20:35:03 +0000

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.

-          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"

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!

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 6 Aug 2015 13:40:22 -0700

On Thu, Aug 6, 2015 at 1:35 PM, Scott Fluhrer (sfluhrer) <[email-masked]
> 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.
>
>
>
> -          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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>
>