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

[Eric Rescorla <[e-mail]>]

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?



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


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

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