Re: [TLS] PR ¤468: Cookie for hrr

[Eric Rescorla <[e-mail]>]

On Sun, May 22, 2016 at 1:48 PM, Ilari Liusvaara <[e-mail]>
wrote:

> On Sun, May 22, 2016 at 12:50:38PM -0700, Eric Rescorla wrote:
> > On Sun, May 22, 2016 at 12:33 PM, Ilari Liusvaara <
> [e-mail]>
> > 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 <
> > > [e-mail]>
> > > > 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).
>

They're gone!

-Ekr


>
>
> -Ilari
>