To add to that, in out-of-order transports, whether a message was sent over 0-RTT or not may not even be very well-defined. If QUIC originally sent data over 0-RTT but had to retransmit it after the full connection parameters are available, I believe it will use those.
Even in an in-order transport, imagine if I have a very long replayable request in HTTP/2 (maybe it's a PUT and comes with a request body, or maybe it has too many headers). I start sending that one over 0-RTT. While I'm in the middle of sending that, I get back a ServerHello (w/ early_data) through Finished. I either need to complete the handshake and switch to 1-RTT mid-request or wait for the long request to complete before finishing the handshake or sending any non-replayable ones, though they may be higher priority. (They probably are if they don't come with as giant of response bodies...) The former is by far the more attractive option. Or perhaps I hit max_early_data_size ( https://github.com/tlswg/tls13-spec/pull/674) and thus can't send more 0-RTT data anyway. In HTTP/2 you have the additional amusement that, due to HPACK, your 0-RTT data probably has an effect on the 1-RTT data even if requests are all or nothing. I don't think we can make the receiver aware of the 0-RTT / 1-RTT boundary sanely. In my mind, the decision whether to send something 0-RTT or wait until 1-RTT is primarily the sender's business. If the sender wanted to, it could make the data replayable anyway by just replaying it. On the receiver's side, yeah, you concatenate the streams. That's why the server must decline 0-RTT if any negotiated parameter (ALPN, etc.) changes. David On Sat, Oct 8, 2016 at 1:14 PM Nick Harper <nhar...@google.com> wrote: In my proposed 0-RTT Token Binding draft ( https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-01), the signature is the same in 0-RTT data as in 1-RTT data, assuming the server didn't reject early data. The thought here is that a client's write API might look like "please send this data, and I'm fine with it being sent 0-RTT", so the Token Binding code doesn't have to know if its message was sent before or after handshake completion. If early data is rejected, then the application data has to change, but this isn't something limited to Token Binding. A server cold reject early data and also change ALPN from what the client expected, requiring the client to send different data. I think it's fine from an API perspective for data sent 0-RTT to also be sent 1-RTT so long as early data is accepted. On Saturday, October 8, 2016, Ilari Liusvaara <ilariliusva...@welho.com> wrote: 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls