Re: [TLS] PR#449

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 <ekr@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
>