One comment below. -- -Todd Short // tsh...@akamai.com<mailto:tsh...@akamai.com> // "One if by land, two if by sea, three if by the Internet."
On Sep 13, 2017, at 10:53 AM, Matt Caswell <fr...@baggins.org<mailto:fr...@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. In this case, the client must have previously connected to the server, so it knows what parameters the server supports, and should only use those, preventing an HRR from being generated. If the client were to send a ClientHello with unsupported server parameters and early data, I would consider this a client error, and an alert should be generated. Should a stateless server silently drop any records that it doesn't understand? 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? Thanks Matt _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
