Subject: [TLS] TLS 1.2 and sha256

From: Daniel Migault <[email-masked]>
Date: Mon, 11 Jun 2018 17:25:13 -0400

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

---

From: David Benjamin <[email-masked]>
Date: Mon, 11 Jun 2018 17:52:55 -0400

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

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.

David

On Mon, Jun 11, 2018 at 5:25 PM Daniel Migault <[email-masked]>
wrote:

> In other words, I am wondering how much we can assume TLS 1.2 is
> associated to sha256.
>
> Yours,
> Daniel
>
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Colm MacCárthaigh <[email-masked]>
Date: Mon, 11 Jun 2018 15:36:53 -0700

Just to add to this excellent answer  ... there is the signature on the
certificates used, which is independent of the cipher suite that you
negotiate but also commonly uses SHA256. Truly moving from SHA256 would
require CAs, Browsers, etc to adopt something new there too.

On Mon, Jun 11, 2018 at 2:52 PM, David Benjamin <[email-masked]>
wrote:

> On Mon, Jun 11, 2018 at 5:25 PM Daniel Migault <
> [email-masked]> wrote:
>
>> Hi,
>>

-- 
Colm

---

From: Hubert Kario <[email-masked]>
Date: Wed, 13 Jun 2018 15:21:15 +0200

> would also pull in TLS 1.3 anyway (or whatever the latest TLS version is by

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

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

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