Re: [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

mrex@sap.com Thu, 15 October 2020 09:56 UTC

Return-Path: <mrex@sap.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752043A13B6; Thu, 15 Oct 2020 02:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.298
X-Spam-Level:
X-Spam-Status: No, score=-3.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sap.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iu3MYu7LeWVr; Thu, 15 Oct 2020 02:56:14 -0700 (PDT)
Received: from smtpde01.smtp.sap-ag.de (smtpde01.mail.net.sap [155.56.68.170]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9B33A13B7; Thu, 15 Oct 2020 02:56:11 -0700 (PDT)
Received: from esa3.sap.c3s2.iphmx.com (esa3.sap.c3s2.iphmx.com [68.232.159.191]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPSA id 4CBl6J3xSfzyc6; Thu, 15 Oct 2020 11:56:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sap.com; i=@sap.com; q=dns/txt; s=it-20200722; t=1602755769; x=1634291769; h=subject:in-reply-to:references:to:date:cc:reply-to: mime-version:content-transfer-encoding:message-id:from; bh=NO7N5F6qtK7i+4Lkw9T5K70JErM8InyLrnGOIY/JyZA=; b=Lkc6dK1fKHL9qDWsek+TST87CCdnSU3NKp+eEVWhYpWRX/u3OGD5NwK9 24yNFfqNeo8FaitRsm9ZUkHwyh+hVM1bn8776eopOAV4g2mPcE/eRoAWS vufhUVioGvheaedNaUA4FEqQTntOGqnAPVsIEeSA/+2uYB/5jjurIG38c hamjDY25Ra25mcVFbyqkYyjIBJ/sxIfBr1YNLU7Z/rtq0mgJ6AdqAPBEp IEUe6n2lEzX8o94h+BjK7f3NVlb2Au12RkE7434k5dOKyzlpO1ud5Ayhu drAh64pGdAe51zGlbyNSL/pcne8upQKq2fEvgAF2SYpWaITCmNXank3a9 A==;
IronPort-SDR: aFHZZ0GJjFVg0Wa3/g/DFvhHfgwKjp5bZz9lWfjv4x2/Kbxh6NidUqihT1PoNXBYu2XaxywsHy Kl3Jh5lTrbCSSBpTY90UYVL7hO4iLKgFnlmVRziPO8BwerrKGqSzDJXAJML5ECHi/6xNw2tix+ vNEAKTj+YIrhPcc+KmYkGtU+eRxwsLQ9aj/6xU4XZVRfK/U5YK6O5bH53EXPxLBK+54TUYKgcr rnI5UX9NxYk19xKuITa9O6Q84D/1+0W6YLWqWgl5J75Tor0mAUT/tX0I9RvV9teNc0zgEIWiJZ d9S+LnK2x1Ua0YGdE2FGv9xJ
X-Amp-Result: SKIPPED(no attachment in message)
Received: from smtpde02.mail.net.sap (HELO smtpde02.smtp.sap-ag.de) ([155.56.68.140]) by esa3.sap.c3s2.iphmx.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 15 Oct 2020 11:56:09 +0200
Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 4CBl6H5RnJz2q; Thu, 15 Oct 2020 11:56:07 +0200 (CEST)
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mail08.wdf.sap.corp (Postfix) with ESMTPS id 4CBl6F3cMLz30jk; Thu, 15 Oct 2020 11:56:05 +0200 (CEST)
X-purgate-ID: 152705::1602755765-00000327-37410CB8/0/0
X-purgate-size: 3564
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 670E5404C; Thu, 15 Oct 2020 11:56:05 +0200 (CEST)
In-Reply-To: <160270080535.5894.280254092203286109@ietfa.amsl.com>
References: <160270080535.5894.280254092203286109@ietfa.amsl.com>
To: last-call@ietf.org
Date: Thu, 15 Oct 2020 11:56:05 +0200 (CEST)
CC: IETF-Announce <ietf-announce@ietf.org>, rdd@cert.org, tls-chairs@ietf.org, tls@ietf.org, draft-ietf-tls-md5-sha1-deprecate@ietf.org
Reply-To: mrex@sap.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20201015095605.670E5404C@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Iua3ClOgRdD6mKeNNhixmNGbjc8>
Subject: Re: [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
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Oct 2020 09:56:17 -0000

The IESG <iesg-secretary@ietf.org> 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@ietf.org mailing lists by 2020-10-28. Exceptionally, comments may
> be sent to iesg@ietf.org instead. In either case, please retain the beginning
> 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