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

[Nick Harper <[e-mail]>]

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?
>
> 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.

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.

> so if the server receives a HTTP request from the client that is
> semantically
> dependent on some HTTP response from the server, then it knows that the
> client should have switched at this point. However, ISTM that SFIN must
> have appeared prior to the any such application layer message, so requiring
> the client to switch on SFIN would make the switch happen slightly earlier
> and give the server the same guarantees. What's the argument for not
> requiring
> that instead, given that it's tied to the state of the TLS stack rather than
> the
> HTTP stack.
>
> -Ekr