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

From: The IESG <[email-masked]>
Date: Wed, 14 Oct 2020 11:40:05 -0700

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
[email-masked] mailing lists by 2020-10-28. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   The MD5 and SHA-1 hashing algorithms are steadily weakening in
   strength and their deprecation process should begin for 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 and RFC 7525.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-md5-sha1-deprecate/

No IPR declarations have been submitted directly on this I-D.

---

From: [email-masked] (Martin Rex)
Date: Thu, 15 Oct 2020 11:56:05 +0200 (CEST)

> of the Subject line to allow automated sorting.

The new, backwards-incompatible and interop-fatal behaviour proposed in
section 2 of the current draft must be changed to reflect the updated
rationale from section 6 of the very same document, and to promote
safe and secure interoperability instead of a needless total interop failure.

Requesting interop failure where instead safe and secure interop can
be easily obtained, as the current draft does, would be in serious
violation of section 6 of RFC 2119 about where an imperative MUST
is not allowed for the given situation.

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

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

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

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 15 Oct 2020 16:03:34 -0400

Hi,

On Thu, Oct 15, 2020 at 5:56 AM Martin Rex <[email-masked]> wrote:
>...

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.

>    rules, but as a practical matter one can assume that the peer

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
 [email-masked]

> --
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

---

From: tom petch <[email-masked]>
Date: Fri, 16 Oct 2020 09:56:34 +0100

I think that the first sentence could be improved.

'The MD5 and SHA-1 hashing algorithms are steadily weakening ...' sounds 
as if they are under attack from electrolytic corrosion or the 
death-watch beatle.

I suggest
NEW
'The MD5 and SHA-1 hashing algorithms are increasingly vulnerable to 
attack and this document deprecates their use in TLS 1.2 digital 
signatures.'

And

/This draft/This document/

Tom Petch

On 14/10/2020 19:40, The IESG wrote:
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 17 Oct 2020 16:31:29 -0700

Hi Martin,

> The new, backwards-incompatible and interop-fatal behaviour proposed in

"Backwards-incompatible" I can see, but "interop-fatal" seems yet to be
proven...

>    (sha256,ecdsa) for TLS cipher suites using ECDSA authentication.

... since your propsal here seems to be resulting in TLS servers
prior-to-this-RFC and TLS servers implementing this RFC using a different
interpretation for what the absence of a "signature_algorithms" extension
means.  That itself, seems like a recipe for interoperability failure,
absent some comprehensive case-by-case analysis showing that it is safe.
I, for one, will not support publication of a document including your
proposed change in the absence of such an analysis.

Furthermore, there is perhaps some awkward interaction between the way this
document refers to the contents of the "signature_algorithms" extensions
and the changes to that extension (and the corresponding IANA registry)
made by RFC 8446.  In the current state of the registry, there is not a
separate 'hash algorithm' field, and instead we must deal with combined
SignatureScheme codepoints.  One might argue that this document should
specifically enumerate the 16-bit SignatureScheme codepoints that are
prohibited.

(The SignatureScheme formulation also allows signature types other than RSA
and ECDSA, of course.)

>    and as permitted in bullet 2 in section 3 of RFC6176.

I note that we prohibited SSLv2-compatible ClientHello for TLS 1.3
implementations.  If we are to assume the current formulation of the draft
where absence of the "signature_algorithms" extension continues to imply
inferred support for SHA-1 and MD5, which are now forbidden, then it is a
natural consequence that the SSLv2-compatible ClientHello cannot
successfully negotiate a handshake, and is de facto forbidden.  I am not
entirely sure why you feel there is a need in the ecosystem to continue to
support the SSLv2-compatible ClientHello; do you, perhaps, know of some
implementation that cannot generate an SSLv3/TLS ClientHello but would
otherwise interoperate (using your formulation where no
"signature_algorithms" means inferred SHA-256 support) with a server that
adheres to this draft's strictures?

> was no excuse for not using sha256 in TLSv1.2 digitally_signed

I've lost count of the number of times that you have mentioned this.
Saying it again is not going to change what RFC 5246 says or help us in
coping with the fallout of what RFC 5246 says.

Thanks,

Ben