On Sat, Oct 8, 2016 at 10:32 AM, David Benjamin <david...@chromium.org> wrote: > 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.
The problem is with poorly-behaved senders and attackers resending 0-RTT data. Receivers should be able to ensure side-effectfull operations are not carried out by 0-RTT data. Making 0-RTT silent in APIs transforms an interoperability issue into a silent security issue. This is not a good idea. > > 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 > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
