[TLS] Unifying tickets and sessions

["Salz, Rich" <[e-mail]>]

It's proposed that we unify tickets and sessions at the protocol level.

--------------------------------

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.

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.

The session token may either be an opaque identifier of local server state, or a serialization of the state the server needs, encrypted with some key. General security considerations require that this information not be kept on long-lived media, and that the identifier or encryption key be rotated periodically. These are server-side implementation details.

The session token can be used to tie together multiple transactions with a loss of forward secrecy. Clients can always omit the session token. Servers SHOULD set the lifetime to an appropriate value (and MUST NOT be more than nn hours).  [Where nn is TBD; either 24 or 48.]

"MUST NOT" for more than 24 hours seems to strict. If you rotate keys every 24 hours, session tickets end up being valid for up to 2 * 24 hours (+ fudge) unless you start to reject them while the server still has the key, which seems pointless. Depending on how you set up cron, that could be 49 hours+ in practice due to DST.