Subject: [TLS] Proposal to deprecate sha1 and md5 for digital signatures in TLS 1.2

From: Loganaden Velvindron <[email-masked]>
Date: Thu, 9 May 2019 18:10:48 +0400

Hi all,

Following the recent thread on TLS 1.0 and TLS 1.1 deprecation, we
came up with a proposal to deprecate md5 and sha1 for digital
signatures in the TLS 1.2 spec.

Please find the draft at this url:
https://tools.ietf.org/html/draft-lvelvindron-tls-md5-sha1-deprecate-03

We look forward to your feedback.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 09 May 2019 21:46:44 -0400

It might pay to spend more time on explaining what you are trying to do.

The goal appears to be to remove a dependency on signature schemes that include these weaker hash functions.  But the introduction just says that the functions are bad.

You should be very clear about what effect this has on the use of SHA-1 in HMAC for record protection.  It looks like you don't intend to deprecate that.  Say that.

The change to the enum is silly.  Overall, I think that the updates to 5246 are unnecessary.  Concentrate on 7525.

The 7525 text starts with "When using RSA", so it could be read to not apply to ECDSA.  That would be a mistake.  I recommend splitting the paragraph into talking about the group size (the first sentence) and a separate paragraph on hash functions used as part of the signing process. 

As part of that, this probably needs to be a MUST: "Clients SHOULD indicate to servers that they request SHA-256, by using the "Signature Algorithms" extension defined in TLS 1.2."

And then I think we should publish something.  Like David, I'm acutely aware of the compatibility hazard that this presents, but it's no less worth doing.

On Fri, May 10, 2019, at 00:12, Loganaden Velvindron wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Loganaden Velvindron <[email-masked]>
Date: Tue, 14 May 2019 10:34:38 +0400

[comments in-line]

On Fri, May 10, 2019 at 5:47 AM Martin Thomson <[email-masked]> wrote:

> The goal appears to be to remove a dependency on signature schemes that
> include these weaker hash functions.  But the introduction just says that
> the functions are bad.
>
> We've updated the draft.

> You should be very clear about what effect this has on the use of SHA-1 in
> HMAC for record protection.  It looks like you don't intend to deprecate
> that.  Say that.
>
> Added.

> The change to the enum is silly.  Overall, I think that the updates to
> 5246 are unnecessary.  Concentrate on 7525.
>
> Removed change to enum.

> The 7525 text starts with "When using RSA", so it could be read to not
> apply to ECDSA.  That would be a mistake.  I recommend splitting the
> paragraph into talking about the group size (the first sentence) and a
> separate paragraph on hash functions used as part of the signing process.
>
> This change was also incorporated.

> As part of that, this probably needs to be a MUST: "Clients SHOULD
> indicate to servers that they request SHA-256, by using the "Signature
> Algorithms" extension defined in TLS 1.2."
>
> And then I think we should publish something.  Like David, I'm acutely
> aware of the compatibility hazard that this presents, but it's no less
> worth doing.
>
> We also agree with you.
Latest draft is here:
https://www.ietf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.txt

---

From: Hubert Kario <[email-masked]>
Date: Tue, 14 May 2019 13:24:35 +0200

> https://www.ietf.org/id/draft-lvelvindron-tls-md5-sha1-deprecate-04.txt

why did you drop SHA-1 from Section 4 and 5?

the note about SHA-1 in HMAC applies to ciphersuites, to state explicitly that 
ciphersuites like TLS_DHE_RSA_WITH_AES_128_CBC_SHA are _not_ deprecated by it

SKE and CV don't use HMAC

-- 
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: Daniel Migault <[email-masked]>
Date: Tue, 14 May 2019 14:09:36 -0400

Hi,

Please find some comments.

Yours,
Daniel

Introduction

I would suggest a reference to rfc6194 for sha1 digest as well as for
hmac-sha1.

I believe more text in the introduction may be needed to expose how the
document impacts TLS 1.2.

Typically, the impacted structure is HashAlgorithm, This structure is used
by SignatureAndHashAlgorithm which defines the Signature Algorithms
extension and is included in messages such as CertificateRequest  In
addition a number of messages rely on this extension (, ServerKeyExchange,
CertificateVerify) and they will be impacted by the current document.

Updating the HashAlgorithm registry was caught in the previous version by
updating the enum. While this is not the standard procedure to deprecate a
registry entry, I believe the intention was there. I would rather suggest
to do that in the IANA section..

section 2:

I am wondering whether SHOULD NOT could be replaced by  MUST NOT. On the
one hand, deprecation should be smooth, but on the other hand I am reading
that rfc6194 and rfc6151 already started the deprecation. I would rather
favour MUST NOT.

Maybe we need to also indicate that MD5 or SHA-1 are ignored by the
receiver.

section 3:

The title section maybe should be Certificate Request (without 's').
Similarly to the previous section I would suggest MUST NOT and specifying
how the client would behave upon receiving MD5 or SHA-1 as hash.

I believe SHA-1 has been dropped in section 4 and 5.

section 6:

The current rfc5246 rely on default sha-1 and md5. To ease interoperability
I am wondering if we strongly recommend to provide the signature algorithm
extension in addition to the default sha256.

section 7:

The new text is missing a capital letter: s/severs/Servers.

Unless i am missing something, I would limit the update to the scope of the
draft and leave the sentence discussing the group unchanged. .

In the following paragraph and s/MUST not/MUST NOT/.

I believe the IANA section is missing:

TLS HashAlgorithm should have the values

1 md5 Y [RFCTBD]
2 sha1 Y [RFCTBD]

Yours,
Daniel

On Tue, May 14, 2019 at 7:25 AM Hubert Kario <[email-masked]> wrote:

> Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech
> Republic_______________________________________________
> TLS mailing list
> [email-masked]

---

From: Loganaden Velvindron <[email-masked]>
Date: Tue, 14 May 2019 22:16:17 +0400

On Tue, May 14, 2019 at 3:24 PM Hubert Kario <[email-masked]> wrote:

> It was done following this comment from David Cooper.
"
[..] While they may be subject to collision attacks, SHA-1 is still
considered secure in cases in which collision resistance is not required,
and I do not believe that collision resistance is required when SHA-1 is
used to create the "signatures" in the ServerKeyExchange and
CertificateVerify messages.
"

--

---

From: Hubert Kario <[email-masked]>
Date: Tue, 14 May 2019 20:26:01 +0200

> Maybe we need to also indicate that MD5 or SHA-1 are ignored by the

that was the intention behind my suggestion for SHOULD NOT - i.e. the server 
MUST be able to handle ClientHello that does advertise them, but in practice 
ignore them based on required handling for SKE and CV
 
> how the client would behave upon receiving MD5 or SHA-1 as hash.

same as above
 
> extension in addition to the default sha256.

no, sha-1 is the default in case the extension is omitted, but then we also 
specify that if the extension is omitted now, the negotiation MUST fail
the recommendation for sha256 is that it in practice has to be included in the 
extension as some servers use the extension to select server certificate, so 
omitting sha256 there will cause the connection to fail

this is also partially the reason for a SHOULD NOT instead of MUST NOT for 
section 2 and 3 – I do not know how those servers handle interaction between 
SHA-1 missing in the extension and root CA (self-signed certificate) being 
signed by SHA-1

---

From: Hubert Kario <[email-masked]>
Date: Tue, 14 May 2019 20:57:18 +0200

> CertificateVerify messages.

SLOTH paper disagrees on that as far as CertificateVerify message is concerned

SP 800-52 rev-2 does not provide much in terms of justification why SLOTH 
paper would be wrong and allows for SHA-1 signatures only in TLS 1.0 and TLS 
1.1, it does not explicitly state that SHA-1 signatures in TLS 1.2 are 
allowed...
-- 
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: Daniel Migault <[email-masked]>
Date: Tue, 14 May 2019 15:13:13 -0400

> ignore them based on required handling for SKE and CV
got it, then the text needs to be explicit in each case we should not hide
ourselves behind a vague SHOULD.

> Works for me. I believe the reasoning worth being mentioning. In addition,
the section update of 5246 coudl also emphasis changes are not limited to
the NEW text.

> I had the same question ;-) and of course not the response.  I believe
that we should clarify this and document the choice for MUST/SHOULD.

---

From: Loganaden Velvindron <[email-masked]>
Date: Wed, 29 May 2019 23:51:24 +0400

> 1.1, it does not explicitly state that SHA-1 signatures in TLS 1.2 are

Hello All,

We've updated the document based on the feedback we've got:

We've re-added deprecating sha-1 in ServerKeyExchange and CertificateVerify:
https://tools.ietf.org/html/draft-lvelvindron-tls-md5-sha1-deprecate-05

--