On Sun, May 22, 2016 at 12:50:38PM -0700, Eric Rescorla wrote: > On Sun, May 22, 2016 at 12:33 PM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > On Sun, May 22, 2016 at 11:30:10AM -0700, Eric Rescorla wrote: > > > On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara < > > ilariliusva...@welho.com> > > > wrote: > > > > > > > Actually, looking at it, I didn't find how EDI context is > > > > determined. And EDI context needs to be fit into cookies because > > > > it isn't retransmitted on 2nd CH. > > > > > > > > > > I don't understand what you're saying here. Here is my claim: > > > > > > 1. The second ClientHello doesn't come with EDI. > > > 2. The Cookie (if used for this) needs to contain the entire hash > > > state, which means it includes the ClientHello w/ EDI transitively. > > > 3. Therefore you can recover the hash state no matter how much > > > the client changes the ClientHello (though we forbid a lot of > > > changes) > > > > > > If I'm wrong here, would definitely like to know. Can you explain? > > > > That would require hash implementation supporting freezing/thawing > > (I have seen only one, and that used MD5), which is even more exotic > > than forking checkpointable hash implementations. > > > > This is a bit of an irritation, I agree. However, it's only required for > stateless implementations, so not your average TLS stack. If you > have a better suggestion, I'd love to have it, thought!
Well, if you didn't have to deal with possibly overly large contexts, you could just reconstruct the 1st ClientHello and HelloRetryRequest. (Reconstruction is even easier without having to worry about cross- handshake cookies). -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
