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

Hubert Kario <hkario@redhat.com> Mon, 06 May 2019 11:21 UTC

Return-Path: <hkario@redhat.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 134BB120145 for <tls@ietfa.amsl.com>; Mon, 6 May 2019 04:21:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYeuPW6-9Z2z for <tls@ietfa.amsl.com>; Mon, 6 May 2019 04:21:47 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A546C120058 for <tls@ietf.org>; Mon, 6 May 2019 04:21:47 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id D586659479; Mon, 6 May 2019 11:21:46 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.83]) by smtp.corp.redhat.com (Postfix) with ESMTP id 082B160C47; Mon, 6 May 2019 11:21:45 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Cc: Benjamin Kaduk <bkaduk@akamai.com>, "tls@ietf.org" <tls@ietf.org>, "mrex@sap.com" <mrex@sap.com>
Date: Mon, 06 May 2019 13:21:44 +0200
Message-ID: <16747558.couhpb2nsq@pintsize.usersys.redhat.com>
In-Reply-To: <1556904629782.23087@cs.auckland.ac.nz>
References: <28511b10-8f6a-4394-95a9-5188130f7b58@www.fastmail.com> <20190503172022.GH4464@akamai.com> <1556904629782.23087@cs.auckland.ac.nz>
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 10.5.11.12
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 06 May 2019 11:21:47 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/_cmfm5G7ytkh_hmQP6TPQIfwBxs>
Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"
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: Mon, 06 May 2019 11:21:49 -0000

On Friday, 3 May 2019 19:30:38 CEST Peter Gutmann wrote:
> Benjamin Kaduk <bkaduk@akamai.com> 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
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic