Hi,
On Thu, Oct 15, 2020 at 5:56 AM Martin Rex <mrex@xxxxxxx> wrote:
>
> The IESG <iesg-secretary@xxxxxxxx> 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
> > last-call@xxxxxxxx mailing lists by 2020-10-28. Exceptionally, comments may
> > be sent to iesg@xxxxxxxx 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 +1-508-333-2270 (cell)
2386 Panoramic Circle, Apopka, FL 32703 USA
d3e3e3@xxxxxxxxx
> 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
> last-call@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/last-call
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
