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

[Sean Turner <[e-mail]>]

> On Sep 4, 2021, at 17:45, David Benjamin <[e-mail]> wrote:
> 
> On Fri, Sep 3, 2021 at 1:24 PM Hubert Kario <[e-mail]> wrote:
> On Friday, 3 September 2021 18:00:12 CEST, [e-mail] 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.