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

[Nick Harper <[e-mail]>]

On Tue, Feb 28, 2017 at 10:46 AM, Andrei Popov <[e-mail]>
wrote:

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

The attacker needs more than just the TLS "Early Secret". The attacker
needs the resumption PSK (effectively the Early Secret), but also the
ClientHello used for a 0-RTT connection and the Sec-Token-Binding header
sent on that 0-RTT connection. The attacker can then replay the stolen
bound token from that connection with the Sec-Token-Binding header on a new
connection that uses the same ClientHello, and an attacker-chosen HTTP
request. This replay is possible for as long as the server will accept that
specific ClientHello (which can be shorter than how long that server will
accept that resumption PSK, because the ClientHello includes the ticket age
when sending early data, and section 4.2.7 of tls13 says that the server
MUST validate that the ticket age is in a small tolerance of the time since
it was issued). I believe this is covered in section 6.2 of
https://tools.ietf.org/html/draft-ietf-tokbind-tls13-0rtt-00, and would be
happy to expand on that section to make things clearer. This is all in
addition to a network attacker being able to replay a 0-RTT request without
changing it.

This replay of a Sec-Token-Binding header for a 0-RTT request exists
regardless of when the client switches from the 0-RTT exporter to the
normal exporter (assuming that the server will accept the combination of
0-RTT + TB at all).

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

The server chooses whether or not to accept early data before it reads that
early data. This is the fact that I use to conclude that the server will
accept in early data any request. The server certainly could terminate the
handshake at any stage, but then it doesn't matter how we would do Token
Binding on that connection, because the connection is no more. TLS 1.3
doesn't provide any mechanism for a server to say "I don't like that that
request was sent in early data, please send it again now that the handshake
is complete", and I'm not aware of any application layer specs (e.g. HTTP)
that have such a mechanism. That's how I reached the conclusion that the
server won't reject some requests sent in early data.

>
>
> Cheers,
>
>
>
> Andrei
>
>
>