Tighten TLS1.2 Session Ticket lifetimes

[maddeleine]

Security issue notifications

If you discover a potential security issue in s2n we ask that you notify
AWS Security via our vulnerability reporting page. Please do not create a public github issue.

Problem:

A s2n-tls server currently sends a new session ticket in a resumed handshake if the STEK used to encrypt the ticket is in decrypt-only mode. This is in the original resumption RFC, however it seems like a bad idea in general, because it allows the original session to live longer. I recommend removing the code that creates a new session ticket in a resumed handshake.
See:
https://datatracker.ietf.org/doc/html/rfc5077#section-3.1

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.

Recommended Solution:

Stop sending session tickets in resumed handshakes in TLS1.2.
Note that we technically could remove some handshakes from our state machine with this change, although that would not be required.