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

[Eric Rescorla <[e-mail]>]

On Sun, May 22, 2016 at 8:59 AM, Ilari Liusvaara <[e-mail]>
wrote:

> On Sun, May 22, 2016 at 07:49:12AM -0700, Eric Rescorla wrote:
> > On Sun, May 22, 2016 at 7:22 AM, Ilari Liusvaara <
> [e-mail]>
> > wrote:
> >
> > > Looking at PR #468:
> > > - It isn't at all obvious how to use it for stateless rejection.
> > > - It is even less obvious how to recover (not causing non-retryable
> > >   fault) from bad cookie (e.g. expired) remembered from previous
> > >   connection.
> > >
> > > There are some tricks for both, but with latter, the 255-byte
> > > cookie space can become quite cramped...
> > >
> >
> > I'll make the space biggeer.
>
> Not having to deal with cross-connection cookies makes things
> easier, but...
>
> 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?



> Also while looking at 0-RTT:
>
> It occured to me how to determine the ciphersuite used for 0-RTT.
> Then it occured to me that the symmetric parts are determined by the
> provisioned context and asymmetric parts don't matter. But I think
> this is quite non-obvious.
>

"All of the parameters for the 0-RTT data (symmetric cipher suite,
ALPN, etc.) MUST be those which were negotiated in the connection
which established the PSK. "

Would be happy to have clarifications.


And clock errors being small outside of gross corrections? Clock
> first-order errors can be pretty large with unsynchronized clocks
> (I have personally seen FO errors on order of 1s per day on some
> bit bad piece of kit), and those would absolutely show up as errors
> in ticket age. And if you have synchronized clock, the zeroth-order
> errors (wrong time) will be small too (can be <10ms). And have fun
> with leap seconds. :-)


Yes. Those people basically won't be able to use 0-RTT.


>
>

> Is the ticket allowed to outlive certificate orginally used in
> provisioning it (possibly indirectly, with ticket being provisoned
> from connection using ticket)?
>

This has never been something TLS has taken a position on.



Also, the extension negotiation matching stuff with 0-RTT talking
> about padding? Padding just plain can't be negotiated. And "negotiated
> in ServerHello"? None of the extensions that can presently be
> negotiated there are any of any interest with 0-RTT. To me the text
> looks really confused.
>

I'll take a look at it, but PRs welcome. Right now I have an open issue
marker,

-Ekr


>
>
> -Ilari
>