Re: [TLS] Application layer interactions and API guidance

[Watson Ladd <[e-mail]>]

On Sat, Oct 8, 2016 at 10:32 AM, David Benjamin <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>> 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
>>> > <[e-mail]>
>>> > 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
>>> > > > <[e-mail]> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.