Re: [TLS] TLS 1.3 draft-07 sneak peek

[Dave Garrett <[e-mail]>]

On Tuesday, July 07, 2015 10:34:31 am Ilari Liusvaara wrote:
> On Fri, Jul 03, 2015 at 07:25:04PM -0400, Dave Garrett wrote:
> > On Friday, July 03, 2015 07:13:15 pm Eric Rescorla wrote:
> > > I think we probably need to have WG consensus for the SHA-1 thing.
> > 
> > Yes, that's why I left it out of that changeset. I don't think the
> > topic of what to do in the TLS 1.3 spec with SHA1 has been discussed
> > on this list. (if it has, please point me to the thread if someone
> > can)
> > 
> > The simplest thing would be to have a MUST NOT offer or negotiate
> > in 2017 or later and a NOT RECOMMENDED to use until then. Or, we
> > could go deeper into the weeds and talk about expiration dates.
> > Banning it totally for TLS 1.3+ is also an option, but probably not
> > wanted yet.
> 
> No, the simplest thing would be to ban it entierely:
> - MUST ignore entries with MD5 or SHA1 hash in
>   supported_signature_algorithms, even if those are the only
>   ones (which will cause handshake failure).
> - MUST terminate connection with insufficient_security if MD5 or
>   SHA1 is seen in DigitallySigned.algorithm.
> 
> SHA-1 is known to be seriously broken. That is way more than
> enough reason to completely remove it. Especially from new
> standards.
> 
> If one wants those to also apply to TLS 1.2, plus:
> - MUST send signature_algorithms extension in TLS 1.2+,
>   server MUST terminate connections without it.
> - MUST NOT send MD5 or SHA1 entries in
>   supported_signature_algorithms.

I very much agree that banning it entirely is the ideal route, but there were indications given that we didn't want to do this, unfortunately.

Again I'll state: by the time TLS 1.3 is done and actually being adopted, an assumption of no SHA1 will be even more expected. Servers that are playing chicken with browsers planning on dropping support for them in a matter of months can stick to TLS 1.2.


Dave