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...@rtfm.com> 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 > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
