Good afternoon all,

 

The RFC 8446 mentions key schedule, resumption_master_secret and new session
ticket and I am not quite sure if I understand the session resumption
behavior correctly.

 

My understanding is that both the client and server calculate all the
secrets of the key schedule therefore both the client and server know the
value of the resumption_master_secret, therefore both sides calculate,

 

PSK = HKDF-Expand-Label(resumption_master_secret,

                        "resumption", ticket_nonce, Hash.length)

 

and the server sends back to the client the PSK (unencrypted, which acts as
an input into the HKDF-Extract to calculate the 0-RTT encryption key) + new
session ticket (encrypted using the session ticket key). Upon resumption the
PSK is provided as an input into the key schedule together with new ECDHE
parameters to assure forward secrecy of the resumed session + the new
session ticket is sent to the server as a reminder it is a resumed session.

 

If the session ticket is opaque to the client then the client needs to store
session information of the initial session (cipher suite, key exchange,
etc..) + PSK and session ticket and the server needs to store only the
session encryption key to resume session. Correct?

 

My question is what key is encrypting the session ticket (is it a symmetric
key that is generated by the webserver/SSL library for each session? In my
Apache 2.4.39 and openssl 1.1.1b testing the TLS 1.3 resumption works
without specifying the SSLSessionTicketKeyFile directive) and what
information is stored in the ticket (is it cipher suite, key exchange?? The
full key schedule is executed anew for resumed session and new crypto.
material is generated so there is no need for the ticket to contain
master_secret or anything similar like in TLS 1.2, so what exactly does the
ticket contain?).

 

Thank you,

 

Lukáš Geyer

_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls

Reply via email to