Re: [Unbearable] 0-RTT Token Binding: When to switch exporters?

[Nick Harper <[e-mail]>]

On Mon, Mar 20, 2017 at 4:12 PM, Eric Rescorla <[e-mail]> wrote:
>
>
> On Mon, Mar 20, 2017 at 12:18 PM, Nick Harper <[e-mail]> wrote:
>>
>> On Mon, Mar 20, 2017 at 9:56 AM, Eric Rescorla <[e-mail]> wrote:
>> > I'm not quite sure I understand the reasoning here, so let me try to
>> > walk
>> > through it.
>> >
>> > The HTTP stack tells the TLS stack to initiate a connection and starts
>> > streaming
>> > requests down to the TLS stack. At this point, it can only use the 0-RTT
>> > exporter,
>> > so it has to do that. At some point in this process, the client receives
>> > the
>> > 1-RTT
>> > Finished and can then switch to the 1-RTT exporter, but the serves has
>> > no
>> > way
>> > of knowing at which point that is.
>>
>> As the client's HTTP stack is streaming requests down to the TLS stack
>> (expecting that they be sent as 0-RTT data), a few things could
>> happen:
>> - The TLS stack could have received the server's Finished, so the TLS
>> stack decides to finish the handshake and send all future data
>> streamed from the HTTP stack post-handshake. If the HTTP stack starts
>> preparing the request just before the TLS stack receives the server's
>> Finished, the HTTP stack will generate a Token-Binding header using
>> the 0-RTT exporter, and then stream it to the TLS stack which sends it
>> post-handshake. We could try to assume that the TLS stack will fail
>> any requests to stream data once the handshake is complete and require
>> the HTTP stack to call a different function to send non-0-RTT data.
>> However, this runs into another problem.
>> - The TLS stack can choose how to fragment messages. When the HTTP
>> stack streams a request (which contains a Token-Binding header) to be
>> sent over 0-RTT, the TLS stack could fragment the HTTP request in a
>> way that splits the Token-Binding header between TLS records, and puts
>> half of it in 0-RTT data and the other half in post-handshake
>> application data. (Or, if the "stream early data" function call
>> returns an error if the HTTP stack tries to send 0-RTT data after the
>> handshake is complete, the HTTP stack is now stuck with half of a
>> request sent and a field it needs to change but has already sent half
>> of.)
>> - This split of a Token-Binding header across 0-RTT and non-0-RTT data
>> could also be caused by the TLS stack hitting the max early data size
>> required by the server.
>> - In QUIC, even if the HTTP/QUIC/TLS stack provides some way to
>> guarantee that an HTTP request will end up entirely in 0-RTT data, a
>> packet containing part of the Token-Binding header could get lost
>> until after the TLS handshake is complete, at which point QUIC will
>> retransmit it under the new keys. Given this possibility of
>> retransmission, how is the server to know which exporter to enforce
>> use of?
>
>
> I feel like this text argues for why you need to have a "which exporter was
> used"
> flag, right?

This is more an argument for allowing the client to continue using the
early_exporter_secret for a short time after exchanging Finished
messages. But if the protocol has any point where the client might be
able to use multiple exporters, then it's probably a good idea to have
the "which exporter was used" flag.
>
>
>
>> > In the current rule, the client MUST switch when it sees app data from
>> > the
>> > server,
>>
>> I assume you're referring to paragraph two of section 2.1.1 of
>> draft-ietf-tokbind-tls13-0rtt-01? Now that I re-read that, it does not
>> convey what I meant it to mean. I think what I meant to say is that
>> after a client receives an application-layer response from the server,
>> it must use the exporter_secret for all future token bindings in
>> application messages that are in response to the received
>> application-layer message from the server.
>
>
> Do we really want to allow inversions? E.g., I send request A with the 1-RTT
> token binding and request B afterwards w the 0-RTT token binding? Becase
> this text would allow this.

Probably not. If we can't guarantee that the order in which a client
starts building HTTP requests matches the order they're sent on the
wire, then there's not an obvious way for the server to enforce that
requirement.
>
>
>> Essentially, the problem I'm trying to work around is that there is a
>> non-zero amount of time between the HTTP stack building a request
>> (specifically, the part of that where it builds the Token-Binding
>> header) and the HTTP stack sending that request to the TLS stack. (If
>> the HTTP stack is streaming the request to the TLS stack as the
>> request is being generated, this end time is when the last byte of the
>> HTTP request hits the TLS stack.) During this time, the TLS handshake
>> could have completed. If a client starts building an HTTP request
>> after it has seen application data from the server, then we can
>> guarantee that the client will be able to use the 1-RTT exporter.
>> However, the client could start building an HTTP request before it has
>> seen application data (and before the TLS stack has seen a Finished
>> message from the server), but send that after the client's TLS stack
>> sends its Finished message. This is the case that I want to allow.
>
>
> This does seem reasonable. Note that it's not directly observable by the
> server when you do this one way or the other. Let me think if there's a
> way to write this that relies less on request/response semantics.
>
> Perhaps:
> Any HTTP requests which the client initiates after sending its Finished
> MUST...?
>
> -Ekr
>
Something like that could work. A client initiating a request could
mean putting it on the wire, or starting to build the request, and I'd
like some clarity that it's the latter.

How's this:
All HTTP requests which the client starts processing to send after the
client sends its Finished message MUST use the exporter_secret for
their token bindings.