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