Session ticket renewal regarding RFC 5077 TLS session resumption

[Maxim Dounin]

Hello!

On Thu, Oct 29, 2020 at 10:23:33PM +0100, Robert Naundorf wrote:

> I have a question on TLS session resumption with client-side session
> tickets and its implementation in nginx.
> 
> RFC 5077, section 3.3, paragraph 2 reads:
> If the server successfully verifies the client's ticket, then it MAY renew
> the ticket by including a NewSessionTicket handshake message after the
> ServerHello in the abbreviated handshake. The client should start using the
> new ticket as soon as possible ...
> 
> Which seems very reasonable to me. That way the session could continue
> without the need of a costly full handshake. It could continue virtually
> forever, as long as the client resumes the session within the time window
> configured by ssl_session_timeout.

This is not how session timeouts work.  Session timeout means that 
parties have to re-check if the other side still have access to 
the certificate presented and its private key, certificates 
haven't been revoked and so on.  That is, once session timeout 
expires, there should be a full handshake.

In RFC 5077, relevant section is 5.6. Ticket Lifetime
(https://tools.ietf.org/html/rfc5077#section-5.6):

   The TLS server controls the lifetime of the ticket.  Servers
   determine the acceptable lifetime based on the operational and
   security requirements of the environments in which they are deployed.
   The ticket lifetime may be longer than the 24-hour lifetime
   recommended in [RFC4346].  TLS clients may be given a hint of the
   lifetime of the ticket.  Since the lifetime of a ticket may be
   unspecified, a client has its own local policy that determines when
   it discards tickets.

It refers to RFC 4346, which further explains where 24-hour limit 
comes from (https://tools.ietf.org/html/rfc4346#appendix-F.1.4):

   Sessions cannot be resumed unless both the client and server agree.
   If either party suspects that the session may have been compromised,
   or that certificates may have expired or been revoked, it should
   force a full handshake.  An upper limit of 24 hours is suggested for
   session ID lifetimes, since an attacker who obtains a master_secret
   may be able to impersonate the compromised party until the
   corresponding session ID is retired.  Applications that may be run in
   relatively insecure environments should not write session IDs to
   stable storage.

Renewing tickets is not about avoiding full handshakes, but rather 
about returing an updated ticket to the client - for example, to 
update the key used to encrypt tickets.

-- 
Maxim Dounin
http://mdounin.ru/