On 13 September 2017 at 16:11, Short, Todd <[email protected]> wrote: > One comment below. > -- > -Todd Short > // [email protected] > // "One if by land, two if by sea, three if by the Internet." > > On Sep 13, 2017, at 10: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. > > > 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.
Well, that's not the case with a cookie. The server may choose to request a cookie even though all the rest of the parameters are ok can't it? Also what is acceptable to the server may change over time. The ticket may now be invalid because the configuration has changed etc. A client may also not know what groups are acceptable to a server even though it has a ticket, e.g. in the first handshake client sends an X25519 key_share, server responds with an HRR requesting P-256 and then the handshake continues to completion. The server is not obligated to provide supported_groups in its EE message - and even if it did the client is not obligated to remember it. Therefore it is perfectly valid in the second handshake for the client to send an X25519 key_share again along with early_data. Matt _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
