On Thursday, 9 February 2017 22:17:33 CET Eric Rescorla 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:
Isn't the whole CH2 supposed to be deterministically created from CH1 and HRR? So you should be able (as the server) to recreate the CH1 given the hash (or better yet, keyed HMAC) of the CH1 fairly easily? Bonus point: you automatically reject technically malformed CH2 messages (ones with more changes than prescribed) as you won't be able to create a CH1 that creates the matching HMAC. I do not think that stateless HRR is special enough to mess around with message transcript hash... -- 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
