Re: [TLS] TLSv1.3 Cookies

[Eric Rescorla <[e-mail]>]

On Wed, Sep 13, 2017 at 8:40 AM, Matt Caswell <[e-mail]> wrote:

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

True...


So in case (3) should this be documented somewhere - either in the
> TLSv1.3 spec or the QUIC spec?


I think it should go in the QUIC spec, because it's QUIC's responsibility
to provide
the transport abstraction to TLS.




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

Generally, I'd prefer to keep this in the other specs, because these are
issues
that arise principally when TLS is embedded in other specs.... If someone
has
a PR, I can take a look, though.


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

I filed:
https://github.com/tlswg/tls13-spec/issues/1079



>
> Matt
>