Re: [TLS] TLSv1.3 Cookies

[Matt Caswell <[e-mail]>]

On 13 September 2017 at 16:12, Eric Rescorla <[e-mail]> wrote:
> On Wed, Sep 13, 2017 at 7:53 AM, Matt Caswell <[e-mail]> 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.

Right - well that's the case right now - I guess we don't know how
this feature might be used for in the future?

So in case (3) should this be documented somewhere - either in the
TLSv1.3 spec or the QUIC spec? Perhaps the TLSv1.3 spec should just
state that protocols using the cookie feature should specify how
early_data is to be handled - and then leave it up to QUIC/DTLS to
define the behaviour in each of their cases.

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

Ok - that makes sense. Perhaps this is worth a note somewhere (not
sure where it would fit).

Matt