More accurate TLS1.3 ticket_lifetime

[lrstewart]

Problem:

At the moment, ticket_lifetime is calculated as the minimum of:

• the user-set session lifetime
• the user-set encryption key decryption lifetime
• 1 week

This isn't /exactly/ accurate. Which is fine-- the RFC allows for an inaccurate ticket_lifetime. But if could lead to customers trying to use expired tickets (due to keying material lifetime) or discarding valid tickets (due to encryption key lifetime).

Solution:

A more accurate (but more complicated) ticket_lifetime would be the minimum of:

• the user-set session lifetime
• the remaining total lifetime of the encryption key, aka ((encryption lifetime + decryption lifetime) + intro time) - now
• the remaining keying material lifetime, aka (keying material expiration - now).
• 1 week

This is a little fun bc we'll likely want to make sure that the encryption key used for the calculation is the encryption key we use to encrypt, and that "now" is consistent and equal to the ticket issue time. We should also probably handle the case where the result is 0-- should we still send the ticket?

• Does this change what S2N sends over the wire? No
• Does this change any public APIs? No
• Which versions of TLS will this impact? TLS1.3

Requirements / Acceptance Criteria:

What must a solution address in order to solve the problem? How do we know the solution is complete?

• RFC links: Links to relevant RFC(s)
• Related Issues: Link any relevant issues
• Will the Usage Guide or other documentation need to be updated?
• Testing: How will this change be tested? Call out new integration tests, functional tests, or particularly interesting/important unit tests.
  • Will this change trigger SAW changes? Changes to the state machine, the s2n_handshake_io code that controls state transitions, the DRBG, or the corking/uncorking logic could trigger SAW failures.
  • Should this change be fuzz tested? Will it handle untrusted input? Create a separate issue to track the fuzzing work.

Out of scope:

Is there anything the solution will intentionally NOT address?