On 13 September 2017 at 16:12, Eric Rescorla <[email protected]> wrote: > On Wed, Sep 13, 2017 at 7:53 AM, Matt Caswell <[email protected]> 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 _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
