On Sun, May 22, 2016 at 07:49:12AM -0700, Eric Rescorla wrote: > On Sun, May 22, 2016 at 7:22 AM, Ilari Liusvaara <ilariliusva...@welho.com> > 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. If it is intended for client to be able to preturb 0-RTT, it can be much smaller. 32 bytes is plenty for random parameter, and then ClientRandom preturbs 0-RTT as well... 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. 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. :-) Is the ticket allowed to outlive certificate orginally used in provisioning it (possibly indirectly, with ticket being provisoned from connection using ticket)? 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. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
