Change:
including it in the "pre_shared_key" extension in its ClientHello (pre-shared-key-extension) and supplying a suitable PSK cipher suite. <del> %%% Ticket Establishment struct { uint32 ticket_lifetime_hint; opaque </del> <ins> %%% Ticket Establishment struct { uint32 ticket_lifetime; opaque </ins> ticket<0..2^16-1>; } NewSessionTicket; Indicates the lifetime in seconds as a 32-bit unsigned integer in <del> 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. </del> <ins> 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. </ins> The value of the ticket to be used as the PSK identifier. <del> 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. </del> The ticket itself is an opaque label.  It MAY either be a database lookup key or a self-encrypted and self-authenticated value. Section 4 of RFC5077 describes a recommended ticket construction

Discussion:
Change ticketlifetimehint to ticket_lifetime and add stricter requirements.
lgtm Please send an email to EMAIL pointing to the change and making a case for it.
Sent, thanks. , Martin Thomson EMAIL wrote:
Mailing list discussion here: URL
+1
Merging per WG discussion. NAME please send me a PR adding yourself to acknowledgements :) 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: ticketlifetimehint 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 ticketlifetimehint. And for SeverConfigurations: struct { opaque configurationid; uint32 expirationdate; KeyShareEntry statickeyshare; EarlyDataType earlydatatype; ConfigurationExtension extensions; } ServerConfiguration; expirationdate 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 expirationdate. [[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: ticketlifetime 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 ticketlifetime. 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: URL 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