It makes sense to me that the lifetimes be the same.
Russ
On Feb 23, 2016, at 12:42 PM, Nick Sullivan wrote:
> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
