Re: [TLS] TLSv1.3 Cookies

On Wed, Sep 13, 2017 at 7:53 AM, Matt Caswell <frodo@baggins.org> wrote:

> I am looking at trying to implement the TLSv1.3 stateless cookie
> mechanism (in order to be able to support QUIC stateless retries).
>
> I am not clear how cookies are supposed to interact with early_data.
> Consider the scenario where a server is operating statelessly. Because
> there is no state each ClientHello looks like the first one it ever
> saw. The server only knows that a particular ClientHello is actually a
> ClientHello2 following an HRR because of the state held in the cookie.
>
> What happens when a client attempts to send early data to such a
> server? The server will process the ClientHello and determine that
> there is no cookie, sends back an HRR and then forgets all of its
> state and waits for the next ClientHello. However what it actually
> gets next is early_data. It does not know that that early data
> followed an earlier ClientHello (because it is stateless) so it does
> not know to skip the records. It just looks like illegal records so,
> presumably, it will respond with an alert.
>

It seems like there are three cases here:

1. TLS over TCP -- you won't do this statelessly, and so you can know to
dump
early data.
2. DTLS -- you can be stateless, but you don't terminate connections on
decrypt
error, so you just discard the packets as you would any other bogus packet.
3. QUIC -- the data looks like an unknown connection (you have dumped the
conn_id)
so you silently discard.

> I am also unclear what protects against cookies being replayed. If an
> attacker wishes to perform an amplification attack on a particular IP
> it awaits a legitimate ClientHello with a cookie coming from that IP
> and records it. It then replays that ClientHello with cookie to the
> server many times. The cookie looks valid to the server and it
> responds with its ServerHello, full Certificate chain etc back to the
> original IP. What have I missed here?
>

Yes. Cookies aren't generally intended to stop that kind of amplification,
they're just designed to prevent blind attacks on IPs you're not on-path
for. Note that QUIC has an additional defense here of requiring that
that ClientInitial be a certain minimum size. Note that if you are on-path
you can still get a lot of amplification even with TCP at the cost of
sending SYN, ACK, ClientHello...

-Ekr

> Thanks
>
> Matt
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>