[TLS] (no subject)

[Eric Rescorla <[e-mail]>]

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.