Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

Hubert Kario <> Mon, 06 May 2019 11:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 134BB120145 for <>; Mon, 6 May 2019 04:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xYeuPW6-9Z2z for <>; Mon, 6 May 2019 04:21:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A546C120058 for <>; Mon, 6 May 2019 04:21:47 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D586659479; Mon, 6 May 2019 11:21:46 +0000 (UTC)
Received: from (unknown []) by (Postfix) with ESMTP id 082B160C47; Mon, 6 May 2019 11:21:45 +0000 (UTC)
From: Hubert Kario <>
To: Peter Gutmann <>
Cc: Benjamin Kaduk <>, "" <>, "" <>
Date: Mon, 06 May 2019 13:21:44 +0200
Message-ID: <>
In-Reply-To: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart22571370.Bt9SG6LhGm"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 ( []); Mon, 06 May 2019 11:21:47 +0000 (UTC)
Archived-At: <>
Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 06 May 2019 11:21:49 -0000

On Friday, 3 May 2019 19:30:38 CEST Peter Gutmann wrote:
> Benjamin Kaduk <> writes:
> >I'll make the obligatory note that SHA-2 is fine
> Sure, and that was the really strange thing with TLS 1.2, why not just say
> SHA-2 or better only, rather than adding mechanisms that were much, much
> weaker than its predecessors?  So the simple fix is just to use SHA-2 only
> for TLS 1.2.

I don't know as I wasn't there when that was discussed, but one reason could 
be the same as the problems we are facing now with RSA-PSS in TLS 1.3: 
smartcards and HSMs that are limited to old algorithms.
Also, don't forget that signature_algorithms, at least in theory[1], was 
supposed to also influence server certificate selection, and SHA-1 was used in 
vast majority of certificates in PKI.

> >if someone does change their system, are really going to recommend they go
> >to TLS 1.0 with MD5||SHA1 rather than TLS 1.2 with SHA2?
> That would be one argument for an RFC, MUST SHA-2 only or MUST NOT MD5 and
> SHA-1 in 1.2.  Which is pretty much what TLS-LTS says.  Or at least it takes
> the SHA-2-suites-mandatory path which implies no MD5 or SHA-1, I guess I
> should also add an explicit MUST NOT MD5 and SHA-1.
> Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what the
> original discussion was about, why not also add MUST NOT MD5 and SHA1 in
> TLS 1.2 to the text?

I've already suggested it with the draft authors, the conclusion was that it 
probably should be a separate RFC.

 1 - while in practice one popular implementation actually used it as a 
     "required" list – it would abort connections when the sigalg of the 
     certificate it had wasn't included in the ClientHello
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic