Subject: [TLS] PRF digest function for ChaCha20-Poly1305 cipher suites

From: Brian Smith <[email-masked]>
Date: Fri, 18 Dec 2015 11:29:05 -1000

Hi,

The recent renaming of the ChaCha20-Poly1305 cipher suites brought
something to my attention that I hadn't thought about before. It seems like
it might be better to use HKDF-SHA512 instead of HKDF-SHA512, and then
rename the ChaCha20-Poly1305 cipher suites to _SHA512. Or, use SHA-384.

It seems like ChaCha20-Poly1305 is likely to be implemented along with
Ed26619 and x25519. Ed25519 already has a hard requirement of SHA-512; see
[1].

Also, existing TLS cipher suites with 256-bit keys, the
TLS_*_AES_256_GCM_SHA384
cipher suites, use SHA-384 as the PRF digest; see [2]. Note that SHA-384 is
SHA-512 with a different IV, truncated to 384 bits.

I've heard that Apple's HomeKit protocol also uses HKDF-SHA512 (With
Ed25519 and x25519).

Ed25519, x25519, ChaCha20-Poly1305, and HomeKit (I've heard) are all
designed for ease of safe, fast, implementation on devices with limited
resources. In particular, such devices might prefer to have a larger and
faster implementation of SHA512 but a smaller and slower SHA-256, and/or
forgo SHA-256 completely. Or, they might have a hardware implementation of
SHA-512 instead of a the more-common-today hardware implementation of
SHA-256.

Thus, it is far from obvious that SHA-256 is the best choice for these
cipher suites.

WDYT?

[1] https://tools.ietf.org/html/draft-josefsson-eddsa-ed25519-02#section-5
[2] https://tools.ietf.org/html/rfc5289#section-3.2.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Brian Smith <[email-masked]>
Date: Fri, 18 Dec 2015 11:43:44 -1000

On Fri, Dec 18, 2015 at 11:29 AM, Brian Smith <[email-masked]> wrote:

> something to my attention that I hadn't thought about before. It seems
> like it might be better to use HKDF-SHA512 instead of HKDF-SHA512, and
>

That is, it seems it would be better to use HKDF-SHA512 instead of
**HKDF-SHA256**.

Cheers,
Brian

---

From: Adam Langley <[email-masked]>
Date: Sun, 20 Dec 2015 12:54:26 -0800

On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith <[email-masked]> wrote:
>> it might be better to use HKDF-SHA512 instead of HKDF-SHA512, and
>
>

I assume that you mean for TLS 1.3 since you mention HKDF? I updated
the draft recently because David Benjamin noted that the names didn't
include the PRF (which they should these days) and that OpenSSL, at
least, used SHA-256, so might as well make the spec match reality.

So, the current code points are probably SHA-256 now. I don't object
to adding more if people want SHA-384 too. Although, since the hash
function is only used in key derivation with these cipher suites, I'm
not sure that a slower, software implementation of SHA-256 would be a
big problem.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: Brian Smith <[email-masked]>
Date: Sun, 20 Dec 2015 15:13:20 -1000

Adam Langley <[email-masked]> wrote:

> I assume that you mean for TLS 1.3 since you mention HKDF?

No, I mean for all versions of TLS.

> I updated

The version of OpenSSL that implements these cipher suites is not released
yet. They updated that  implementation just 9 days ago, so it seems pretty
malleable still.

> function is only used in key derivation with these cipher suites,

I don't think it would be a good idea to add more code points to negotiate
SHA-512 in the PRF while still leaving code points for negotiating SHA-256
in the PRF. It should be one or the other.

> I'm

It just seems really unfortunate to mandate SHA-512 for Ed25519 and then
mandate SHA-256 for ChaCha20-Poly1305 in TLS. Mandating the same algorithm
for both seems like a better idea.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Dec 2015 17:41:32 -0800

> No, I mean for all versions of TLS.

Do you mean using SHA-512 in the TLS 1.2 PRF? Or something else?

> for both seems like a better idea.

Can you explain what resource you're trying to conserve here?

The MTI cipher suites for TLS 1.2 and 1.3 require SHA-256 and
All the AES-GCM ciphers already require SHA-256 or SHA-384, so it
seems like the vast majority of implementations are going to require at
least one of these algorithms in any case.

-Ekr

---

From: Brian Smith <[email-masked]>
Date: Sun, 20 Dec 2015 15:50:01 -1000

> Do you mean using SHA-512 in the TLS 1.2 PRF? Or something else?

Yes, for TLS 1.2 and TLS 1.3.

> least one of these algorithms in any case.

Nobody should pay attention to what the MTI cipher suite for TLS 1.2 is,
because it's obsolete; in fact, one would be making a huge mistake to
deploy it now if one's application didn't have legacy backward
compatibility concerns. And, we should change the MTI cipher suite for TLS
1.3 to the ChaCha20-Poly1305 ones, because they solve a lot of problems.
For example, they remove any question of any need to implement rekeying,
they avoid the weird IV construction hacks that are necessary for 128-bit
cipher suites like AES-GCM, and they can be implemented efficiently in a
safe way, unlike AES-GCM.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 20 Dec 2015 18:09:19 -0800

> Yes, for TLS 1.2 and TLS 1.3.

Sorry, I'm still confused TLS 1.2 uses a specific PRF. TLS 1.3 uses HKDF.
Are you suggesting TLS 1.2 use the TLS 1.2 PRF with SHA-512 and that
TLS 1.2 use SHA-512 with HKDF, or something different?

> safe way, unlike AES-GCM.

This seems like a separate question.

SHA-256-using cipher suites are widely deployed and not going away any time
soon,
so what resource are you trying to conserve here?

-Ekr

---

From: Brian Smith <[email-masked]>
Date: Mon, 21 Dec 2015 14:54:23 -1000

> TLS 1.2 use SHA-512 with HKDF, or something different?

I mean that TLS 1.2 should use SHA-512 with the TLS 1.2 PRF and that TLS
1.3 should use SHA-512 with HKDF.

> This seems like a separate question.

You are the one that brought the MTI stuff into this, not me.

> SHA-256-using cipher suites are widely deployed and not going away any
> time soon, so what resource are you trying to conserve here?
>

I'm trying to minimize the number of algorithms (amount of code) necessary
to implement ChaCha20-Poly1305 using x25519 for key agreement and Ed25519
for signatures. The different between needing or not needing SHA-256
matters most for very small computers (AVR and Cortex-M0), but doesn't
really matter much for larger computers where SHA-256 has an advantage.

In particular, since there seems to be a notable amount of hardware that is
or will soon be released that optimized for
ChaCha20-Poly1305+x25519+Ed25519, because of Apple HomeKit, it would be
nice to take advantage of that for TLS.

Besides that, the inconsistency regarding why these new
256-bit-encryption-key cipher suites are currently defined to use SHA-256
in the PRF whereas all the existing 256-bit-encryption-key cipher suites
use SHA-384 seems strange. Even if an application wants to use AES-GCM
cipher suites, it would be able to avoid needing SHA-256 if it implemented
the AES256-GCM cipher suites instead of AES128-GCM.

Cheers,
Brian
-- 
https://briansmith.org/

---

From: Hubert Kario <[email-masked]>
Date: Tue, 22 Dec 2015 13:53:22 +0100

On Monday 21 December 2015 14:54:23 Brian Smith wrote:
> > Sorry, I'm still confused TLS 1.2 uses a specific PRF. TLS 1.3 uses
> > HKDF. Are you suggesting TLS 1.2 use the TLS 1.2 PRF with SHA-512
> > and that TLS 1.2 use SHA-512 with HKDF, or something different?
> 
> I mean that TLS 1.2 should use SHA-512 with the TLS 1.2 PRF and that
> TLS 1.3 should use SHA-512 with HKDF.
> 
> > Nobody should pay attention to what the MTI cipher suite for TLS 1.2
> > is,> 
> >> compatibility concerns. And, we should change the MTI cipher suite
> >> for TLS 1.3 to the ChaCha20-Poly1305 ones, because they solve a
> >> lot of problems. For example, they remove any question of any need
> >> to implement rekeying, they avoid the weird IV construction hacks
> >> that are necessary for 128-bit cipher suites like AES-GCM, and
> >> they can be implemented efficiently in a safe way, unlike AES-GCM.
> > 
> > SHA-256-using cipher suites are widely deployed and not going away
> > any time soon, so what resource are you trying to conserve here?
> I'm trying to minimize the number of algorithms (amount of code)
> necessary to implement ChaCha20-Poly1305 using x25519 for key
> agreement and Ed25519 for signatures. The different between needing
> or not needing SHA-256 matters most for very small computers (AVR and
> Cortex-M0), but doesn't really matter much for larger computers where
> SHA-256 has an advantage.
> 
> In particular, since there seems to be a notable amount of hardware
> that is or will soon be released that optimized for
> ChaCha20-Poly1305+x25519+Ed25519, because of Apple HomeKit, it would
> be nice to take advantage of that for TLS.
> 
> 256-bit-encryption-key cipher suites are currently defined to use
> SHA-256 in the PRF whereas all the existing 256-bit-encryption-key
> cipher suites use SHA-384 seems strange. Even if an application wants
> to use AES-GCM cipher suites, it would be able to avoid needing
> SHA-256 if it implemented the AES256-GCM cipher suites instead of
> AES128-GCM.

I'm not convinced about SHA-512, but yes, they probably should use 
SHA-384 at the very least. And given that the algorithm for SHA-384 and 
SHA-512 is essentially the same, using just different IVs, that should 
be usable for highly restricted hardware, wouldn't it?

I would be against SHA-512 as that would be the very first cipher that 
uses SHA-512 PRF in TLS1.2, making its addition/implementation much more 
invasive to the underlying library, OTOH, we have multiple ciphers which 
use SHA-384 PRF. I think I just need to remind the delay after which NSS 
added support for SHA-384 compared to introduction to AES-128-GCM TLS 
ciphers...
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 24 Dec 2015 05:36:39 -0500 (EST)

----- Original Message -----
> added support for SHA-384 compared to introduction to AES-128-GCM TLS

I agree. SHA384 also aligns it with the AES-256-GCM ciphers. I believe an
implementation mixing chacha20 with AES is a much more common scenario than
the one described by Brian.

regards,
Nikos