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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
