Re: [TLS] Signature Algorithms

"Mehner, Carl" <> Tue, 17 March 2015 18:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 63ED01A884D for <>; Tue, 17 Mar 2015 11:10:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GielSNZY3qNr for <>; Tue, 17 Mar 2015 11:10:28 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 542911A8824 for <>; Tue, 17 Mar 2015 11:10:28 -0700 (PDT)
Received: from pps.filterd ( []) by (8.14.7/8.14.7) with SMTP id t2HI9Bg5022186; Tue, 17 Mar 2015 13:10:26 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=201408; bh=/Y7sih26YQju/hsLNaZTrpJh2JrNG/Y+s9OAKjVVnT0=; b=fd8zcGLBBn6X9B5Tmo//cffL3HZXX3x9tRd2R8KOYCJBcMGWWo/H36F67VfcKeqO9LuI 1PmzFHzatyb5jD1TOOXkBJFqHCxCiMeDQXoJUin+fK/nrgROxF0ALPmjbwX4UFHNkimZ gFrbX/ri+v6xR5N+LDjJ9DVZsqP/PbVql9QrQcydyFFn51jvNlrw0mfkKMbZlszYSQYt P9eBbkuvBhcjNj3ax/CugAL0e+g7+04aU5xdgyhzhBHeIAJDNyKoTNsCXziQWRYYRJ8I xRcODQ4GRua7DgnWH5X2UWXbO+HDuvtcf+9qlMHwAT0dQe7MWEukISoL6JQ2krl5sTaB gA==
Received: from ( []) by with ESMTP id 1t36bawu1v-1; Tue, 17 Mar 2015 13:10:26 -0500
Received: from ([]) by ([]) with mapi id 14.03.0158.001; Tue, 17 Mar 2015 13:10:25 -0500
From: "Mehner, Carl" <>
To: Eric Rescorla <>, Dave Garrett <>
Thread-Topic: [TLS] Signature Algorithms
Thread-Index: AQHQYN2keZkvConmFEatyoGpqnKTLw==
Date: Tue, 17 Mar 2015 18:10:25 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-c2processedorg: b8bcc573-fb52-4e08-924e-ca559c360d81
Content-Type: multipart/alternative; boundary="_000_19075EB00EA7FE49AFF87E5818D673D411463AF8PRODEXMB01Weagl_"
MIME-Version: 1.0
X-Proofpoint-Direction: FromExch
X-Proofpoint-Direction: Internet
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.13.68, 1.0.33, 0.0.0000 definitions=2015-03-17_04:2015-03-17,2015-03-17,1970-01-01 signatures=0
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Signature Algorithms
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Mar 2015 18:10:31 -0000

I’m not arguing for TLS 1.3 to drop support for SHA-1 (that’s up to the client configurer), I’m arguing for the TLS signature algorithms extension to not specify the signature of a root. This same argument applies for MD5 roots with long term SHA-1 end-entity certs.

If we want to drop MD5 EE-certs by removing MD5 from the signature algorithms, and you want to keep your long term SHA-1 EE-cert that has a chain which is capped by an MD5 root, you would not be able to send that root in the certificate_list as the document is written today. The text I suggested allows you to still send the root.

If the client provided a "signature_algorithms" extension, then all

   certificates provided by the server, except for the self-signed

   root CA certificate, MUST be signed by a hash/signature algorithm

   pair that appears in that extension.

From: Eric Rescorla []
Sent: Tuesday, March 17, 2015 1:00 PM
To: Dave Garrett
Cc:; Mehner, Carl
Subject: EXTERNAL: Re: [TLS] Signature Algorithms

On Tue, Mar 17, 2015 at 10:41 AM, Dave Garrett <<>> wrote:

On Saturday, March 14, 2015 11:40:38 pm Mehner, Carl wrote:
> As we move into a world that lacks trusted SHA-1 signatures, a change in the text would be necessary in order for clients that drop SHA-1 from the supported hash algorithms to continue to connect to servers that send a certificate_list that includes roots signed with SHA-1.

What's the viability of having TLS 1.3 drop support for SHA-1 for end-entity certificates? (not root or intermediary, yet)

I would not be in favor of this. Many people have certificates with very long lifetimes

and this would effectively mean that people could not drop in TLS 1.3 for 1.2 on

their servers, which would be bad.


   This would of course be in addition to dropping all support for MD5, which I think is pretty much a given at this point.

   If it were to be new policy right this second, that wouldn't be great, but by the time TLS 1.3 is ready for widespread adoption I think that's a reasonable expectation. Latest survey shows the SHA-1 to SHA-2 ratio at about 2:3 and improving steadily. SHA-2 will probably be used in the majority within a couple months or so.