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. > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
