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

[Eric Rescorla <[e-mail]>]

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!


Also, SHA-384 states are so big (the state at arbitrary point is 208
> bytes!) that putting one into cookie leaves space VERY cramped (if
> all necressary things fit at all).
>

Good point. I just made the editor's copy have 2^16-1 thought it didn't
make it into draft-13.


> > 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.
>
> I would phrase the thing as what various values are, not what they
> must be (there is no way negotiate those, which is good).
>
> > 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.
>
> Even if ticket timestamp mismatch error has fallback in spec, will it
> actually fallback properly with real-world implementations?
>

I hope so. We plan to test it.



> > 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,
>
> Here is what I think should match (going through all currently known
> values and excetions):
>

Thanks for this. Ill try to work up a PR from the below.

Best,
-Ekr


>
> - Version
> - Ciphersuite Protection+PRF, key exchange in allowed values.
> - What to do with server_name???
> - Status_request presence (but not contents)???
> - Status_request_v2 presence (but not contents)???
> - Signed_certificate_timestamp presence (but not contents)???
> - ALP can not be negotiated by any means.
> - 0-RTT Protection+PRF+ALP can not be negotiated.
>
> (I think status_request and status_request_v2 should mirror whatever
> signed_certificate_timestamp does).
>
> Also, that server_name is just its own kind of mess, where what is
> the proper thing isn't at all obvious.
>
>
> And here is the list of extensions that are allowed to be negotiated
> with 0-RTT (parenthesis denotes extensions where things depend on exact
> handling discussed above).
>
> - (server_name)
> - max_framgment_length
> - (status_request)
> - supported_groups
> - use_srtp
> - heartbeat
> - (status_request_v2)
> - (signed_certificate_timestamp)
> - token_binding [I-D stage]
> - cached_info?
> - key_share
> - pre_shared_key
> - early_data (required for obvious reasons)
>
>
> (Note: application_layer_protocol_negotiation is not on this list,
> very much intentionally, since negotiation of ALP is not possible
> in presence of 0-RTT. Don't even try).
>
>
>
> -Ilari
>