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

[David Benjamin <[e-mail]>]

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.)

David