Re: [TLS] (no subject)

[Eric Rescorla <[e-mail]>]

Based on people's seeming mild preference for option #1, I have produced:
https://github.com/tlswg/tls13-spec/pull/901

I'll merge this tomorrow absent some loud screaming.

-Ekr


On Thu, Feb 9, 2017 at 1:17 PM, Eric Rescorla <[e-mail]> wrote:

> 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.
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>