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

[Andrei Popov <[e-mail]>]

Hi Nick,


Ø  Instead, I propose that if a server accepts the client's 0-RTT data, then the client uses the 0-RTT exporter for the entirety of the connection, and otherwise the client uses the exporter as already specified in TBPROTO. This still has decent security properties.
My understanding is that an attacker who has a stolen bound token and TLS “Early Secret” (but not the corresponding TB private key), can successfully replay this token, alongside the attacker’s HTTP request, to a server that allows TLS 1.3 0-RTT. This type of replay is possible from multiple machines, for as long as the server is willing to accept 0-RTT connections based on the same TLS “Early Secret”. Is this correct?

And this is of course in addition to a network attacker being able to replay a legitimate client’s request without change (no stealing of tokens or secrets required), unless the server takes extraordinary steps to prevent 0-RTT replay.


Ø  A server accepting early data should accept any request sent in early data. The server can't sniff the early data to reject it if it contains a request it doesn't like (e.g. a POST request), because the early data could contain multiple requests (e.g. in the case of HTTP/2), and the server MUST process the ClientHello and immediately send the ServerHello - it cannot wait to process all of the client's early data.
From the fact that the server sends the ServerHello after processing ClientHello, it does not follow that the server will accept every request sent as early data. The server can very well reject certain requests and/or terminate the handshake at any stage.

Cheers,

Andrei