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! 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
