Subject: [TLS] Removing the "hint" from the Session Ticket Lifetime hint

From: Nick Sullivan <[email-masked]>
Date: Tue, 23 Feb 2016 09:42:17 -0800

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 23 Feb 2016 12:43:31 -0600

> strict lifetime along the lines of the ServerConfiguration:

But leave it as a relative time, contrasting the absolute expiration
time of the server configuration -- why not go for full-out parallelism?

-Ben

> 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.
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_pull_424&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=S4CFPnNBaB7swATOHOzQkIlnUwgvBaVelRwg-VJzz-g&s=IsvSLMYBUZf_IWLI_bWWg7vpIQk-qSFCzIvsMw7in_I&e=>

---

From: Subodh Iyengar <[email-masked]>
Date: Tue, 23 Feb 2016 18:46:34 +0000

One other proposal which is related is to make server config have relative time as well instead of absolute time. If we don't make this relative this expiration time might not be practically enforceable due to clock skew.

This enforcement is relevant in situations where compromise of the ephemeral server config key is not the same as compromising the long term private key, for example in a SSL key offloading infrastructure.

I do not think relative time introduces any new threats because the server still needs to prove possession of the private key to make new clients accept a server config. Thus a compromise of a server config key should only affect the initial data of clients who have cached a config modulo relative expiration time.

Subodh Iyengar
________________________________
From: TLS [[email-masked]] on behalf of Benjamin Kaduk [[email-masked]]
Sent: Tuesday, February 23, 2016 10:43 AM
To: Nick Sullivan; [email-masked]
Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint

On 02/23/2016 11:42 AM, Nick Sullivan wrote:
My proposed change is to change the session ticket lifetime hint to a strict lifetime along the lines of the ServerConfiguration:

But leave it as a relative time, contrasting the absolute expiration time of the server configuration -- why not go for full-out parallelism?

-Ben

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_tlswg_tls13-2Dspec_pull_424&d=CwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=sssDLkeEEBWNIXmTsdpw8TZ3tAJx-Job4p1unc7rOhM&m=S4CFPnNBaB7swATOHOzQkIlnUwgvBaVelRwg-VJzz-g&s=IsvSLMYBUZf_IWLI_bWWg7vpIQk-qSFCzIvsMw7in_I&e=>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 23 Feb 2016 10:54:48 -0800

On 23 February 2016 at 10:43, Benjamin Kaduk <[email-masked]> wrote:
> But leave it as a relative time, contrasting the absolute expiration time of
> the server configuration -- why not go for full-out parallelism?

As I have said before, the value of absolute time here is that it
allows for the use of server configuration outside of the context of
the TLS 1.3 handshake.  Given that we are now seriously discussing
removing ServerConfiguration from TLS 1.3, this is probably moot.

---

From: Russ Housley <[email-masked]>
Date: Tue, 23 Feb 2016 15:12:48 -0500

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.
> 
> 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.
> 
> 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.]]
> 
> 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-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 Feb 2016 20:14:46 +0000

Absolute lifetimes seem more robust; e.g., if you find one lying around, you don't have enough context to know if it's still good or not.

We went from relative to absolute times in ACME for this reason.

---

From: [email-masked] (Martin Rex)
Date: Mon, 29 Feb 2016 18:11:02 +0100 (CET)

Salz, Rich wrote:
> Absolute lifetimes seem more robust; e.g., if you find one lying around,
> you don't have enough context to know if it's still good or not.
> 

What should be memorized/stored is absolute time-of-creation.

How long to consider it valid, is a local issue and not necessarily
a constant validity period over time.  When memorizing time-of-creation,
you always know exactly how old something is, no matter whether how
many times the local validity period was changed in the meantime.

-Martin

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 29 Feb 2016 17:15:18 +0000

> What should be memorized/stored is absolute time-of-creation.

If the structure itself includes absolute times, then the memorization is (trivially) simpler.

> How long to consider it valid, is a local issue and not necessarily a constant
> validity period over time. 

True.  Treat it as a hint from the server.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 29 Feb 2016 17:31:09 +0000

> closely resemble the lifetime of the ServerConfiguration.

IMHO the analogy between ServerConfiguration and SessionTicket is
a flawed one.  ServerConfiguration is created by the server
unilaterally, at some time before the client connection and is not
session-specific.  The client has no implicit knowledge of the
ServerConfiguration age.

The situation is completely different with SessionTicket, which is
created as a side-effect of the *current* handshake, and is always
fresh when created.  A SessionTicket lifetime hint that is a relative
time is therefore quite sufficient and avoids clock synchronization
and epoch time wrap-around problems.

-- 
	Viktor.

---

From: Subodh Iyengar <[email-masked]>
Date: Mon, 29 Feb 2016 17:35:52 +0000

There are 2 different issues being discussed here, lifetime of tickets and configs.

It is probably better to revisit the discussion of whether or not to have ServerConfig be relative or absolute after it is decided whether or not the DH 0-RTT handshake will still exist.

The general point I wanted to make is that relative times are practically enforceable by clients.
For ticket_lifetime, which already is relative time, it is desirable to change them from an informative only behavior to being usable by clients, which Nick's pull request does.  Enforcing relative time for things like tls ticket validity time has better security properties for certain use cases like key offloading. Nick's pull request limits the time clients can cache it to 7 days which is reasonable middle ground and clients can decide to delete the ticket earlier.

I +1 the pull request.

Subodh Iyengar
________________________________________
From: TLS [[email-masked]] on behalf of Salz, Rich [[email-masked]]
Sent: Monday, February 29, 2016 9:15 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] Removing the "hint" from the Session Ticket Lifetime hint

_______________________________________________
TLS mailing list
[email-masked]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=CwICAg&c=5VD0RTtNlTh3ycd41b3MUw&r=h3Ju9EBS7mHtwg-wAyN7fQ&m=qqjUPIB9UGopotanCAwZnp0-jzGVYglIQZJF_t3gzPA&s=-sv0ZsIso_1M3gqRtmLNdhvCr50uDuFVHhzZro2d4j8&e=