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