This change has a non-obvious consequence for server implementation complexity. I don't have an especially good alternate proposal though.
Putting ticket_age in EncryptedExtensions means there are two ways a server may reject 0-RTT. It might reject ClientHello because the ticket is invalid (or if ALPN doesn't match the client and server's new preferences, etc.), or it might reject at EncryptedExtensions because the ticket_age is bad. But rejecting at the second point requires going back to the ClientHello and re-negotiating parameters, etc., as in a full handshake. This is a fairly involved part of the handshake and adding a state machine transition (TLS stacks often look like asynchronous state machines driven by handshake messages) in the middle of it invites a lot of bugs. Options I see: 1. Leave it as-is and implementations just deal with it. The simplest way out would be to buffer and defer processing the ClientHello until after EncryptedExtensions (or lack thereof) is known. Note this is a little subtle because you may not have a ticket to decrypt EncryptedExtensions. 2. A bad ticket_age is a fatal error, not a 0-RTT reject. This requires that the server timeout be fairly generous to avoid the slowest RTT anyone might care about. Roughly match the timeout for the client's second leg. But if the client's clock changes between getting the ticket and trying 0-RTT, we'd punish them with connection error rather than a full handshake. That seems poor. 3. Smuggle an encrypted ticket_age inside the ClientHello. This means avoids the complex framing, but now we need some ad-hoc encryption inside an extension. It needn't be very complicated, but it's a wart. (Silliest option is NewSessionTicket contains 4 random bytes or you derive something from the resumption secret and XOR it into the data since this is something we were otherwise okay with sending in the clear anyway. It's just about avoiding a vague correlator when tickets are only used once. Or we could do something less silly and more heavyweight like actually run the record layer.) I'm not thrilled about #2 or #3 and getting #1 right isn't impossible, but it would be nice to avoid these sorts of sharp edges if we can. David On Wed, May 11, 2016 at 7:38 AM Eric Rescorla <e...@rtfm.com> wrote: > https://github.com/tlswg/tls13-spec/pull/449 > > In Buenos Aires, we agreed to add EncryptedExtensions from the client > in 0-RTT to carry the ticket age/elapsed_time. I have written this up in > the PR above. Comments welcome. > > Target Merge date: Friday. > > -Ekr > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls