Re: [TLS] Unifying tickets and sessions

["Richard Fussenegger, BSc" <[e-mail]>]

Nice to see this merge and I directly +1 the token wording.

How about **MUST NOT** for more than 24 hours for the encryption key and 
**MUST NOT** for more than 3 x 24 hours for decryption keys? That should 
account for all possibilities and one can use three keys to achieve it 
that rotate at the same intervals.

The RFC should clarify that the negotiated cipher **MUST** be honored 
when encrypting the state that will be sent to the client. [1]

Regards
Richard

[1] https://media.blackhat.com/us-13/US-13-Daigniere-TLS-Secrets-WP.pdf

On 10/20/2014 10:11 PM, Salz, Rich wrote:
> 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.
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls