Re: [Lurk] [TLS] TLS 1.2 and sha256

Hubert Kario <hkario@redhat.com> Wed, 13 June 2018 13:21 UTC

Return-Path: <hkario@redhat.com>
X-Original-To: lurk@ietfa.amsl.com
Delivered-To: lurk@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6540B130E22; Wed, 13 Jun 2018 06:21:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 hMDS7JS6R-0E; Wed, 13 Jun 2018 06:21:23 -0700 (PDT)
Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2F42130E1F; Wed, 13 Jun 2018 06:21:22 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.rdu2.redhat.com [10.11.54.5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C5AB6818BAED; Wed, 13 Jun 2018 13:21:21 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (unknown [10.43.21.250]) by smtp.corp.redhat.com (Postfix) with ESMTP id DF8D97C57; Wed, 13 Jun 2018 13:21:20 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Cc: David Benjamin <davidben@chromium.org>, Daniel Migault <daniel.migault@ericsson.com>, LURK BoF <lurk@ietf.org>
Date: Wed, 13 Jun 2018 15:21:15 +0200
Message-ID: <2502786.FB2IomL8uD@pintsize.usersys.redhat.com>
In-Reply-To: <CAF8qwaCFEwz_D5PtSAYKifvisKbGK6yVJma=7uSDd=UOWkG=gw@mail.gmail.com>
References: <CADZyTknFe8Da948kOJRZcPkKkwnaVQUOseMfyZa_A4TckuY3gw@mail.gmail.com> <CAF8qwaCFEwz_D5PtSAYKifvisKbGK6yVJma=7uSDd=UOWkG=gw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3048220.dCRxH3muN7"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.11.54.5
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Wed, 13 Jun 2018 13:21:21 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.8]); Wed, 13 Jun 2018 13:21:21 +0000 (UTC) for IP:'10.11.54.5' DOMAIN:'int-mx05.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:''
Archived-At: <https://mailarchive.ietf.org/arch/msg/lurk/TJ4Yw1CHHdwdCb21mjzyicLPRaE>
Subject: Re: [Lurk] [TLS] TLS 1.2 and sha256
X-BeenThere: lurk@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Limited Use of Remote Keys <lurk.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lurk>, <mailto:lurk-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lurk/>
List-Post: <mailto:lurk@ietf.org>
List-Help: <mailto:lurk-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lurk>, <mailto:lurk-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jun 2018 13:21:26 -0000

On Monday, 11 June 2018 23:52:55 CEST David Benjamin wrote:
> In both TLS 1.2 and TLS 1.3, SHA-256 isn't hardcoded per se. It's a
> function of the cipher suite you negotiate (and also, separately, the
> signature algorithm you negotiate). That said, in practice, both are pretty
> solidly dependent on SHA-256. Most options involve it. AES-128-GCM and
> ChaCha20-Poly1305 are currently paired with SHA-256 while only AES-256-GCM
> is paired with SHA-384.
> 
> We could certainly define new cipher suites for either of TLS 1.2 and TLS
> 1.3 as needed. But defining a new cipher suite for TLS 1.2 doesn't
> magically deploy it for all existing TLS 1.2 servers. Those servers must
> deploy new code, at which point updating your TLS library to include it
> would also pull in TLS 1.3 anyway (or whatever the latest TLS version is by
> then).

except that introduction of a new ciphersuite is far less intrusive change 
that a completely new protocol like TLS 1.3

API/ABI compatibility is also a factor, where the behaviour with session 
resumption, client certificate based authentication and PSK handling is 
different between TLS 1.2 and TLS 1.3

> So I think there will likely be no point in bothering with TLS 1.2
> allocations at that point. More options means more combinatorial complexity
> for implementations, which means more our rather limited collective
> resources in this space get even more thinly spread.

ciphersuites are usually defined by their settings, where addition of a new 
ciphersuite, which uses already implemented PRF, cipher and key exchange 
requires only addition of new entry in an array, not complete reworking of 
parts of the codebase...

> David
> 
> On Mon, Jun 11, 2018 at 5:25 PM Daniel Migault <daniel.migault@ericsson.com>;
> wrote:
> > Hi,
> > 
> > TLS 1.2 uses sha256 as the prf hash function. When sha256 will not be
> > considered secured, I am wondering if we can reasonably envision
> > deprecating sha256 for TLS 1.2 or if TLS 1.2 will at that time be
> > deprecated in favor of TLS 1.X X>= 3 ?
> > 
> > In other words, I am wondering how much we can assume TLS 1.2 is
> > associated to sha256.
> > 
> > Yours,
> > Daniel
> > 
> > 
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls


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