Subject: [TLS] WGLC for draft-ietf-tls-md5-sha1-deprecate

From: Sean Turner <[email-masked]>
Date: Fri, 22 Nov 2019 06:41:36 +0800

All,

This is the working group last call for the "Deprecating MD5 and SHA-1 signature hashes in TLS 1.2" draft available https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/.  Please review the document and send your comments to the list by 2359 UTC on 13 December 2019.

Note the the GH repo for this draft can be found at:
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate

Cheers,

Joe, Chris, and Sean

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 22 Nov 2019 00:34:13 +0000

>    This is the working group last call for the "Deprecating MD5 and SHA-1 signature hashes in TLS 1.2" draft available https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/.  Please r…
  
I just re-read this.  Looks good. Perhaps a sentence of rationale in section 2 and 3 explaining why its SHOULD NOT and not MUST NOT would help explain things to some?

---

From: David Benjamin <[email-masked]>
Date: Fri, 22 Nov 2019 10:25:24 +0800

On Fri, Nov 22, 2019 at 8:35 AM Salz, Rich <[email-masked]> wrote:

> >    This is the working group last call for the "Deprecating MD5 and
> SHA-1 signature hashes in TLS 1.2" draft available
> https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/.
> Please review the document and send your comments to the list by 2359 UTC
> on 13 December 2019.
>
> I just re-read this.  Looks good. Perhaps a sentence of rationale in
> section 2 and 3 explaining why its SHOULD NOT and not MUST NOT would help
> explain things to some?
>

To that end, the combination of client advice in sections 2 and 4 is a bit
odd. Section 2 uses SHOULD NOT include MD5 and SHA-1, but section 4 says
the client MUST NOT accept the MD5 SHA-1, even if it included it. Why would
the client include it in that case? It seems the two should either both be
MUST NOT or both be SHOULD NOT.

I think client-sent alerts in section 4 are also wrong. handshake_failure
means the sender was unable to negotiate parameters, and
insufficient_security is a variant of handshake_failure. This is the client
reacting to the server sending something inconsistent with the ClientHello,
so it should be illegal_parameter. In the context of ServerKeyExchange
signatures, handshake_failure or insufficient_security would be sent by the
*server* if the *client* only advertised MD5 and SHA-1.

(In principle the client rules in section 4 are redundant with the text in
section 2. It's just a restatement of negotiation requirements: your
advertisement to the peer should match how you react to the peer's
selection. But it's nice to write it explicitly and the document is not
very long.)

Some additional nitpicks:
This document mostly writes "SHA-1", but the introduction has an instance
of "SHA1".
Section 2 should probably have a "the" before the first occurrence of
"signature_algorithms extension".
Section 4 includes both server behavior and the client restatement of
negotiation requirements above, but section 5 does not include the
corresponding server restatement of negotiation requirements.

Otherwise, the document looks good to me.

---

From: Hubert Kario <[email-masked]>
Date: Fri, 22 Nov 2019 20:18:47 +0100

On Friday, 22 November 2019 03:25:24 CET, David Benjamin wrote:
>>> ...
>> I just re-read this.  Looks good. Perhaps a sentence of rationale in ...
>

because it also influences certificate selection, and getting a certificate
signed with SHA-1 isn't an automatically disqualifying property?
(it may be an intermediate CA that's not used, it may be an explicitly 
trusted
certificate, etc.)

> *server* if the *client* only advertised MD5 and SHA-1.

well, it depends if the SHA-1 was advertised by client or not

if it was advertised (because of certificates, see above), then
handshake_failure is correct; if it wasn't advertised but the
signature_algorithms were included, then yes, client should abort with
illegal_parameter

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Hubert Kario <[email-masked]>
Date: Fri, 22 Nov 2019 20:29:55 +0100

On Thursday, 21 November 2019 23:41:36 CET, Sean Turner wrote:
> All,
>
> This is the working group last call for the "Deprecating MD5 
> and SHA-1 signature hashes in TLS 1.2" draft available 
>  Please review the document and send your comments to the list 
> by 2359 UTC on 13 December 2019.
>

Proposed two PRs to fix the two minor things raised on the ML:
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/2
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/3

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 23 Nov 2019 15:40:05 +0200

> (it may be an intermediate CA that's not used, it may be an explicitly

If you don't want SHA-1 exchange signatures, you darn sure do not want
actual SHA-1 certificates that are not trust anchors anyway. And because
TLS 1.2 does not have separate lists for exchange signatures and
certificate signatures, the client needs to withdraw advertisment for
both in order to not send a misleading offer.

And I expect that in practice, not sending SHA-1 in
signature_algorithms would cause very little breakage on top of what
is already broken due to using SHA-1 exchange signatures.

So I think both should be MUST NOT.

-Ilari

---

From: Karthik Bhargavan <[email-masked]>
Date: Sat, 23 Nov 2019 17:32:36 +0100

This is a bit of a shameless plug, but I think it is important to cite papers that show that the use of weak hash functions for TLS signatures is actually exploitable.

As far as I know, the last round of deprecating MD5 in TLS signatures was triggered by the SLOTH attack:

https://www.mitls.org/pages/attacks/SLOTH

The associated paper explains how weak hash functions can allow an attacker to break protocols like TLS, SSH, etc.

https://www.mitls.org/downloads/transcript-collisions.pdf

This probably deserves to be added to the references of this draft.

@inproceedings{BhargavanL16,
  author    = {Karthikeyan Bhargavan and Gaetan Leurent},
  title     = {Transcript Collision Attacks: Breaking Authentication in TLS, IKE, and SSH},
  booktitle = {Proceedings of the {ISOC} Network and Distributed System Security Symposium ({NDSS} '16)},
  month     = {Feb},
  year      = {2016},
  url       = {
http://www.mitls.org/downloads/transcript-collisions.pdf
}
}

Best regards,
Karthik

> On 23 Nov 2019, at 14:40, Ilari Liusvaara <[email-masked]> wrote:
> 
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: David Benjamin <[email-masked]>
Date: Sun, 24 Nov 2019 11:27:26 -0500

> both in order to not send a misleading offer.

Right, I had a longer discussion of the certificate-but-not-TLS case but
omitted it. :-) Basically what Ilari said. In particular, I believe older
versions of Schannel will, despite being able to sign SHA-256,
preferentially sign SHA-1 if the client offers it. This is inconvenient
when it comes to predicting breakage but is perfectly consistent with the
client's offer. When I last looked at this a few years ago, this accounted
for a nontrivial portion of SHA-1-negotiating servers on the web, so
rejecting SHA-1 while still advertising it is probably not the best
strategy.

Fortunately, we've already distrusted SHA-1 X.509 signatures on the web, so
hopefully that will simplify things. There is a risk that some servers'
trust anchors' (otherwise irrelevant) signatures are SHA-1 and they are
trying to match it against the signature algorithms list, but I expect the
SHA-1-preferring servers to be the deciding concern. Issues with
trust-anchor-checking servers can likely be worked around by configuring
the server to not send the trust anchor, which is desirable anyway.

(All of this may not apply to non-web deployments, of course.)