Draft 11 currently supports both ServerConfiguration and PSK + Session
Ticket for session resumption (0RTT or otherwise). Both mechanisms have the
same properties in terms of forward secrecy: a compromise of the server's
private data (whether PSK, session ticket key, or DH exponent) lets an
attacker retroactively decrypt data from all sessions established with the
PSK or Session Ticket. However, both mechanisms contain different language
around how the lifetimes of the resumption data is managed.
After some discussion with Facebook and others, I'd like to suggest a
change in the wording of the draft to make the Session Ticket lifetime more
closely resemble the lifetime of the ServerConfiguration.
Here is the current language for session ticket lifetimes:
ticket_lifetime_hint
Indicates the lifetime in seconds as a 32-bit unsigned integer in network
byte order from the time of ticket issuance. A value of zero is reserved to
indicate that the lifetime of the ticket is unspecified.
The ticket lifetime hint is informative only. A client SHOULD delete the
ticket and associated state when the time expires. It MAY delete the ticket
earlier based on local policy. A server MAY treat a ticket as valid for a
shorter or longer period of time than what is stated in the
ticket_lifetime_hint.
And for SeverConfigurations:
struct {
opaque configuration_id<1..2^16-1>;
uint32 expiration_date;
KeyShareEntry static_key_share;
EarlyDataType early_data_type;
ConfigurationExtension extensions<0..2^16-1>;
} ServerConfiguration;
expiration_date
The last time when this configuration is expected to be valid (in seconds
since the Unix epoch). Servers MUST NOT use any value more than 604800
seconds (7 days) in the future. Clients MUST NOT cache configurations for
longer than 7 days, regardless of the expiration_date. [[OPEN ISSUE: Is
this the right value? The idea is just to minimize exposure.]]
My proposed change is to change the session ticket lifetime hint to a
strict lifetime along the lines of the ServerConfiguration:
ticket_lifetime
Indicates the lifetime in seconds as a 32-bit unsigned integer in network
byte order from the time of ticket issuance. Servers MUST NOT use any value
more than 604800 seconds (7 days). The value of zero indicates that the
ticket should be discarded immediately. Clients MUST NOT cache session
tickets for longer than 7 days, regardless of the ticket_lifetime. It MAY
delete the ticket earlier based on local policy. A server MAY treat a
ticket as valid for a shorter period of time than what is stated in the
ticket_lifetime.
The full change is on Github as a pull request:
https://github.com/tlswg/tls13-spec/pull/424
Note that this new wording is more strict than that of RFC 5077, which does
not specify a maximum lifetime for session tickets or dictate that the hint
be followed in any way by either client or server.
The introduction of the resumption master secret strengthened the forward
secrecy story in TLS by requiring resumed connections to use new session
keys. The proposed logic strengthens the forward secrecy story of TLS even
further by creating a hard limit on the lifetime of unused resumption
master secrets.
Nick
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
