> On Sep 9, 2021, at 15:40, David Benjamin <david...@chromium.org> wrote: > > On Thu, Sep 9, 2021 at 2:12 PM Sean Turner <s...@sn3rd.com> wrote: > > > On Sep 4, 2021, at 17:45, David Benjamin <david...@chromium.org> wrote: > > > > On Fri, Sep 3, 2021 at 1:24 PM Hubert Kario <hka...@redhat.com> wrote: > > On Friday, 3 September 2021 18:00:12 CEST, internet-dra...@ietf.org wrote: > > > 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 > > > > > 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. > > > > 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 > > Servers SHOULD NOT include MD5 and SHA-1 in CertificateRequest > messages. > > 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. > > 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
