Subject: [TLS] (no subject)

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Feb 2017 13:17:33 -0800

Hi folks,

We need to close on an issue about the size of the
state in the HelloRetryRequest. Because we continue the transcript
after HRR, if you want a stateless HRR the server needs to incorporate
the hash state into the cookie. However, this has two issues:

1. The "API" for conventional hashes isn't designed to be checkpointed
   at arbitrary points (though PKCS#11 at least does have support
   for this.)
2. The state is bigger than you would like b/c you need to store both
   the compression function and the "remainder" of bytes that don't
   fit in [0]

Opinions differ about how severe all this is, but it's certainly
unaesthetic, and it would be nice if the state that was stored in
the HRR cookie was just a hash output. There seem to be three
major approaches for this (aside from "do nothing").

1. Special case HRR and say that the transcript is either

   CH || SH ....   (no HRR)

     or

   Hash(CH1) || HRR || CH ... (HRR)  [1]

2. Pre-hash the messages, so that the handshake hash
   becomes:

   Handshake_hash_N = Hash(Hash(msg_1) || Hash(msg_2)
                           ... Hash(msg_N))

3. Recursively hash, so that the handshake hash becomes:

   Handshake_hash_N= Hash(Handshake_hash_N-1 || msg_N)

[As Antoine Delignat-Lavaud points out, this is basically making
a new Merkle-Damgard hash with H as the compression function.]

I've posted PR#876, which implements version #2, but we could do any one of
the three.
and they all have the same state size. The argument for #1 seems to be
that it's the minimal change, and also the minimal overhead, and the
argument against is that it's non-uniform because CH1 is treated
differently.  We might imagine making it seem more uniform by also
hashing HRR but that doesn't make the code any simpler. Versions #2
and #3 both are more uniform but also more complicated changes.

The arguments for #2 versus #3 are that #3 is somewhat faster
(consider the case where you have a short message to add, #2 always
needs to run the compression function twice whereas #3 can run it
once). However, with #3 it is possible to take a hash for an unknown
transcript and create a new hash that matches that unknown transcript
plus an arbitrary suffix.  This is already a property of the M-D
hashes we are using but it's worse here because those hashes add
padding and length at the end before finalizing, so an extension
wouldn't generally reflect a valid handshake transcript, whereas in
this case you get to append a valid message, because the padding is
added with every finalization stage. I don't know of any reason
why this would be a security issue, but I don't have any proof it's
not, either.

I'd like to get the WG's thoughts on how to resolve this issue over the next
week or so so we can close this out.

-Ekr

[0] The worst-case overhead for SHA-256 is > 64 bytes and for SHA-512
it’s > 128 bytes. The average is half that.

[1] We actually need to do something to make it injective, because
H(CH1) might look like a handshake message, but that should be easy.

---

From: Kyle Nekritz <[email-masked]>
Date: Wed, 15 Feb 2017 21:58:28 +0000

I have a small preference for option 1. I think in a way #2 and #3 require a special case as well for the PSK binder transcript. Unless we consider the truncated ClientHello and the rest of the ClientHello separate messages, the handshake hash will have to move backwards after computation of the binders (removing ClientHello[truncated] and adding the full ClientHello). Allowing the hash to solely move forward allows for a bit simpler implementation.

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Thursday, February 9, 2017 4:18 PM
To: [email-masked]
Subject: [TLS] (no subject)

Hi folks,

   CH || SH ....   (no HRR)

     or

I've posted PR#876, which implements version #2, but we could do any one of the three.

-Ekr

---

From: Dr Stephen Henson <[email-masked]>
Date: Thu, 23 Feb 2017 16:08:40 +0000

>    the compression function and the "remainder" of bytes that don't

Does the handling of Post-Handshake authentication pose a similar issue? That is
the need to keep the hash context of the handshake and then append additional
data to generate or check the CertificateVerify message?

Steve.
-- 
Dr Stephen N. Henson.
Core developer of the   OpenSSL project: http://www.openssl.org/
Freelance consultant see: http://www.drh-consultancy.co.uk/
Email: [email-masked], PGP key: via homepage.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 23 Feb 2017 08:16:16 -0800

> data to generate or check the CertificateVerify message?

It's a slight inconvenience, but not a real issue because you don't need to
send the state over the wire. So you just need a forkable hash
implementation, which you needed anyway because of the way the rest of the
hashing works.

-Ekr