On Fri, Oct 07, 2016 at 03:04:14PM -0700, Eric Rescorla wrote: > On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara <ilariliusva...@welho.com> > wrote: > > > On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote: > > > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara > > > <ilariliusva...@welho.com> wrote: > > > > > > > > Also, it is very likely that 0-RTT would need its own read API, because > > > > it is pretty unlikely that existing API could be safely retrofitted > > > > or even purpose-built unified API be designed that isn't just asking > > > > for security problems via mixing 0-RTT and 1-RTT data. > > > > > > Yes. In particular I think the TLS state machine transitions need to > > > be ordered with respect to the arrival and sending of data. The > > > challenge for a multithreaded program (yes, some programs have > > > multiple threads sending and receiving at once) is making this make > > > sense, or even a single-threaded program where the TLS stack can > > > change state at times not visible to the sending thread. Maybe there > > > is some slop here, like 0-RTT can become 1-RTT on send, but this > > > raises all sorts of problems for receiving. I think we need to require > > > separation in the API. > > > > 0-RTT can't be allowed to become 1-RTT on send (unless it is auto- > > retransmit, which needs to be disableable, as sometimes that just plain > > won't work). > > Can you explain why that is?
E.g. what they are planning to do with 0-RTT Token Binding in HTTP. The client puts in a signature into 0-RTT data. If the server rejects the 0-RTT and the client retransmits, the signature will still be there but is different. Also, if 0-RTT data can silently shift to 1-RTT, it would mean the server-side model would be to concatenate 0-RTT and 1-RTT data, which I thought we already established is quite dangerous. -Ilari _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
