Re: [TLS] [Last-Call] Last Call: <draft-ietf-tls-md5-sha1-deprecate-04.txt> (Deprecating MD5 and SHA-1 signature hashes in TLS 1.2) to Proposed Standard

[Donald Eastlake <[e-mail]>]

Hi,

On Thu, Oct 15, 2020 at 5:56 AM Martin Rex <[e-mail]> wrote:
>
> The IESG <[e-mail]> wrote:
> >
> > The IESG has received a request from the Transport Layer Security WG (tls) to
> > consider the following document: - 'Deprecating MD5 and SHA-1 signature
> > hashes in TLS 1.2'
> >
> >   <draft-ietf-tls-md5-sha1-deprecate-04.txt> as Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and solicits final
> > comments on this action. Please send substantive comments to the
> > [e-mail] mailing lists by 2020-10-28. Exceptionally, comments may
> > be sent to [e-mail] instead. In either case, please retain the beginning
> > of the Subject line to allow automated sorting.
>
>...
>
> Section 6 of the current draft says:
>
>    6.  Updates to RFC5246
>
>    [RFC5246], The Transport Layer Security (TLS) Protocol Version 1.2,
>    suggests that implementations can assume support for MD5 and SHA-1 by
>    their peer.  This update changes the suggestion to assume support for
>    SHA-256 instead, due to MD5 and SHA-1 being deprecated.
>
>    In Section 7.4.1.4.1: the text should be revised from:
>
>    OLD:
>
>    "Note: this is a change from TLS 1.1 where there are no explicit
>    rules, but as a practical matter one can assume that the peer
>    supports MD5 and SHA- 1."

It probably should be clarified but I think this text is just trying
to say that with TLS 1.1 you could assume support of MD5 and SHA-1.

>    NEW:
>
>    "Note: This is a change from TLS 1.1 where there are no explicit
>    rules, but as a practical matter one can assume that the peer
>    supports SHA-256."

How about
    "Note: this is a change from TLS 1.1 where there are no explicit
    rules, but as a practical matter one could have assumed that the peer
    supports MD5 and SHA- 1."
or, to be even more explicit
    "Note: this is a change from TLS 1.1 where there are no explicit
    rules, but as a practical matter with TLS 1.1 one could have
assumed that the peer
    supports MD5 and SHA- 1."

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

> and therefore the behaviour in section 2 about the "Signature Algorithms"
> extension ought to say:
>
>    2.  Signature Algorithms
>
>    Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
>    extension.  If a client does not send a signature_algorithms
>    extension, then the server MUST use (sha256,rsa) for
>    digitally_signed on the ServerKeyExchange handshake message for
>    TLS cipher suites using RSA authentication, and the server MUST use
>    (sha256,ecdsa) for TLS cipher suites using ECDSA authentication.
>
>    The server behaviour ought to be consistent for both, receipt of an
>    extension-less SSLv3+ ClientHello handshake message, and for a
>    backwards-compatible SSL VERSION 2 CLIENT-HELLO (which can not convey
>    any TLS extensions) as described in Appendix-E.2 of rfc5246,
>    and as permitted in bullet 2 in section 3 of RFC6176.
>
>
>
> As desribed in RFC6151, collision attacks on MD5 were appearing in
> publications already in 2004, 2005, 2006 & 2007, the TLSv1.2 spec
> rfc5246 should have never *NEWLY* added support for (md5,rsa) in
> TLSv1.2 digitally_signed.
>
> Similarily, since the sunset date for SHA1-signatures had been
> announced by NIST *before* TLSv1.2 (rfc5246) was published,
> TLSv1.2 (rfc5246) should have never *NEWLY* added support for
> (sha1,rsa) in TLSv1.2 digitally_signed, but have used (sha256,rsa)
> from the beginning.  sha256 has been required for the TLSv1.2 PRF
> and for HMAC-SHA256 of several cipher suites anyway, so there
> was no excuse for not using sha256 in TLSv1.2 digitally_signed
> in the first place.
>
>
> -Martin
>
> --
> last-call mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/last-call