Subject: [TLS] I-D Action: draft-ietf-tls-md5-sha1-deprecate-08.txt

From: [email-masked]
Date: Fri, 03 Sep 2021 09:00:12 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

        Title           : Deprecating MD5 and SHA-1 signature hashes in (D)TLS 1.2
        Authors         : Loganaden Velvindron
                          Kathleen Moriarty
                          Alessandro Ghedini
	Filename        : draft-ietf-tls-md5-sha1-deprecate-08.txt
	Pages           : 6
	Date            : 2021-09-03

Abstract:
   The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to
   attack and this document deprecates their use in TLS 1.2 digital
   signatures.  However, this document does not deprecate SHA-1 in HMAC
   for record protection.  This document updates RFC 5246.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-tls-md5-sha1-deprecate-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-md5-sha1-deprecate-08

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Sean Turner <[email-masked]>
Date: Fri, 3 Sep 2021 13:03:16 -0400

Roman,

I believe this one is ready for an IESG telechat. Please let me know if you need any additional changes.

spt

> Begin forwarded message:
> 
> From: [email-masked]
> Subject: I-D Action: draft-ietf-tls-md5-sha1-deprecate-08.txt
> Date: September 3, 2021 at 12:00:12 EDT
> To: <[email-masked]>
> Cc: [email-masked]
> Reply-To: [email-masked], [email-masked]
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Hubert Kario <[email-masked]>
Date: Fri, 03 Sep 2021 19:24:11 +0200

>   Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest
>   messages.

>    Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages.
>   If a server receives a CertificateVerify message with MD5 or SHA-1 it
>   MUST abort the connection with handshake_failure or
>   insufficient_security alert.

As written, this would make already existing implementations not RFC 
compliant
when they are configured to not support SHA-1.

RFC5246 requires the server to abort with illegal_parameter if the
CV included an algorithm that wasn't advertised in CR.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: David Benjamin <[email-masked]>
Date: Sat, 4 Sep 2021 17:45:56 -0400

> CV included an algorithm that wasn't advertised in CR.

Ah, good catch. There's also some odd asymmetry here. Section 4 talks about
a server being unable to *send* a ServerKeyExchange (and uses the correct
alerts). It says nothing about the client *receiving* an invalid (by
ClientHello) ServerKeyExchange which is, as in the case you describe, an
illegal_parameter. Meanwhile, Section 5 talks about the server *receiving*
an invalid (by CertificateRequest) CertificateVerify, and with the wrong
alerts. It says nothing about the client being unable to *send* a
CertificateVerify.

I don't feel very strongly about whether we talk about sending, receiving,
or both, for each of these messages. But we should be consistent and use
the right alerts. (Or we could just talk about preferences and let the
message behavior fall out of that.)

David

---

From: Sean Turner <[email-masked]>
Date: Thu, 9 Sep 2021 14:12:31 -0400

> On Sep 4, 2021, at 17:45, David Benjamin <[email-masked]> wrote:
> 
> Ah, good catch. There's also some odd asymmetry here. Section 4 talks about a server being unable to *send* a ServerKeyExchange (and uses the correct alerts). It says nothing about the client *receiving* an invalid (by ClientHello) ServerKeyExchange which is, as in the case you describe, an illegal_parameter. Meanwhile, Section 5 talks about the server *receiving* an invalid (by CertificateRequest) CertificateVerify, and with the wrong alerts. It says nothing about the client being unable to *send* a CertificateVerify.
> 
> I don't feel very strongly about whether we talk about sending, receiving, or both, for each of these messages. But we should be consistent and use the right alerts. (Or we could just talk about preferences and let the message behavior fall out of that.)

I think what might solve this is the following (I just included all of the text with 2119-language because there isn’t much of it):

2.  Signature Algorithms

   Clients MUST include the signature_algorithms extension.  Clients
   MUST NOT include MD5 and SHA-1 in this extension.

3.  Certificate Request

4.  Server Key Exchange

   Servers MUST NOT include MD5 and SHA-1 in ServerKeyExchange messages.
   If the client receives a ServerKeyExchange message indicating MD5 or
   SHA-1, then it MUST abort the connection with an illegal_parameter
   alert.

5.  Certificate Verify

   Clients MUST NOT include MD5 and SHA-1 in CertificateVerify messages.
   If a server receives a CertificateVerify message with MD5 or SHA-1, then
   it MUST abort the connection with illegal_parameter alert.

---

From: David Benjamin <[email-masked]>
Date: Thu, 9 Sep 2021 15:40:05 -0400

On Thu, Sep 9, 2021 at 2:12 PM Sean Turner <[email-masked]> wrote:

> > Ah, good catch. There's also some odd asymmetry here. Section 4 talks
> about a server being unable to *send* a ServerKeyExchange (and uses the
> correct alerts). It says nothing about the client *receiving* an invalid
> (by ClientHello) ServerKeyExchange which is, as in the case you describe,
> an illegal_parameter. Meanwhile, Section 5 talks about the server
> *receiving* an invalid (by CertificateRequest) CertificateVerify, and with
> the wrong alerts. It says nothing about the client being unable to *send* a
> CertificateVerify.
> >
> > I don't feel very strongly about whether we talk about sending,
> receiving, or both, for each of these messages. But we should be consistent
> and use the right alerts. (Or we could just talk about preferences and let
> the message behavior fall out of that.)
>
> I think what might solve this is the following (I just included all of the
> text with 2119-language because there isn’t much of it):
>
> 2.  Signature Algorithms
>

LGTM with one comment. (Sorry, for all the last-minute comments! I didn't
notice this in my last email. :-( ) It is a little odd that servers
advertising MD5/SHA1 in CertificateRequest is merely a SHOULD NOT, but
rejecting them in CertificateVerify is a MUST NOT. Though that's also
present in the existing text. I forget how we ended up here. Was it to
allow for SHA-1 in the Certificate message?

...I wonder if that's why we ended up with the funny alerts. Because if the
server declines to do the SHOULD NOT, the client isn't doing anything
wrong, protocol-wise, by taking the server up on its offer of SHA-1.

If we want to keep it very simple, we could upgrade section 3 to MUST NOT
and avoid this problem, but I don't know if there was some reason for the
asymmetric expectations here. We could also condition the server rule in
section 5 on having taken the SHOULD NOT in section 3. (Prior to TLS 1.3,
there is no way to say "SHA-1 is okay in Certificate, but not okay in
CertificateVerify/ServerKeyExchange".)

David

---

From: Sean Turner <[email-masked]>
Date: Thu, 9 Sep 2021 21:18:39 -0400

> On Sep 9, 2021, at 15:40, David Benjamin <[email-masked]> wrote:
> 
> LGTM with one comment. (Sorry, for all the last-minute comments! I didn't notice this in my last email. :-( ) It is a little odd that servers advertising MD5/SHA1 in CertificateRequest is merely a SHOULD NOT, but rejecting them in CertificateVerify is a MUST NOT. Though that's also present in the existing text. I forget how we ended up here. Was it to allow for SHA-1 in the Certificate message?
> 
> ...I wonder if that's why we ended up with the funny alerts. Because if the server declines to do the SHOULD NOT, the client isn't doing anything wrong, protocol-wise, by taking the server up on its offer of SHA-1.
> 
> If we want to keep it very simple, we could upgrade section 3 to MUST NOT and avoid this problem, but I don't know if there was some reason for the asymmetric expectations here. We could also condition the server rule in section 5 on having taken the SHOULD NOT in section 3. (Prior to TLS 1.3, there is no way to say "SHA-1 is okay in Certificate, but not okay in CertificateVerify/ServerKeyExchange".)
> 
> David 

A lot of this was born out of the deprecate TLS 1/1.1 RFC that spun this I-D off. I believe this is the thread back in mid-2019:
https://mailarchive.ietf.org/arch/msg/tls/qTlDYpSlSe6Mf2zDV_iqOXO-6xo/

spt