Re: [TLS] Unifying tickets and sessions

[Brian Smith <[e-mail]>]

Rich,

I think your suggestion is a very good idea. In particular, note that
session tickets could be encrypted during the handshake, but
ServerHello.session_id
cannot. This is valuable because it allows for a level of unlinkability
between the initial connection for a session and a resumption of that
session. If the server rotates tickets for a session on every connection
(resumption or otherwise), this unlinkability would be maintained against
all connections for a session. This seems like a valuable privacy feature.

On Mon, Oct 20, 2014 at 1:11 PM, Salz, Rich <[e-mail]> wrote:

> For 1.3 we bring in the extension definitions from 5077. For the wire
> format, it doesn't matter if the information is a session identifier (a
> short string, referring to state maintained on the server) or a ticket (the
> actual crypto state, stored on the client). Perhaps to be general, we call
> it session token.
>

I suggest, to minimize changes from RFC 5077, and to minimize confusion,
that we continue to call it a session ticket.

A TLS 1.3 client MUST send an empty session_id field. It may send a ticket
> extension. If the server is willing to accept the crypto state, it sends a
> "1" in the returned session_id field, otherwise it sends an empty
> session_id. This is the only use of session_id in TLS 1.3.
>

This change from RFC5077 is not necessary. You just make this change
instead:

-  If a server is planning on issuing a session ticket to a client that
-  does not present one, it SHOULD include an empty Session ID in the
-  ServerHello.  If the server rejects the ticket and falls back to the
-  full handshake then it may include a non-empty Session ID to indicate
-  its support for stateful session resumption.  If the client receives
-  a session ticket from the server, then it discards any Session ID
-  that was sent in the ServerHello.

-

-  When presenting a ticket, the client MAY generate and include a
-  Session ID in the TLS ClientHello.  If the server accepts the ticket
-  and the Session ID is not empty, then it MUST respond with the same
-  Session ID present in the ClientHello.  This allows the client to
-  easily differentiate when the server is resuming a session from when
-  it is falling back to a full handshake.  Since the client generates a
-  Session ID, the server MUST NOT rely upon the Session ID having a
-  particular value when validating the ticket.  If a ticket is
-  presented by the client, the server MUST NOT attempt to use the
-  Session ID in the ClientHello for stateful session resumption.

-  Alternatively, the client MAY include an empty Session ID in the

-  ClientHello.  In this case, the client ignores the Session ID sent in

-  the ServerHello and determines if the server is resuming a session by

+  The client MUST always include an empty Session ID in the ClientHello.

+  The server MUST always include an empty Session ID in the ServerHello.

+  The client determines if the server is resuming a session by

the subsequent handshake messages.


This is a smaller change for implementations and leaks less
information in the plaintext part of the handshake. In particular, on
top of this change, you could in theory make it so that the full
handshake and the resumption handshake look the same on the wire
(modulo leaking the distinction via timing). As I said before [2], I
think that is worth trying to accomplish, both for maximizing interop
as well as improving privacy.


Cheers,

Brian

[1] https://tools.ietf.org/html/rfc5077#section-3.4
[2] http://www.ietf.org/mail-archive/web/tls/current/msg10903.html