On Sun, Jan 4, 2026 at 6:02 PM Peter Gutmann <[email protected]> wrote:
> Eric Rescorla <[email protected]> writes: > > >The TLS specification takes no position on when (1) clients should attempt > >resumption and (2) servers should allow it. > > The design however strongly discourages its use. Because of the way TLS > 1.3 > reinvented the whole protocol using extensions, you can't know in advance > whether the server will allow a resumption or not as you do with TLS > classic, > which means you always need to send a pile of guessed keyexes in your > client > hello for when it doesn't, making it the same as a non-resumed client > hello. > In both TLS 1.2 and TLS 1.3, it is not possible for the client to know prior to the connection whether the server will allow a resumption or not at the time you send the ClientHello. In either case, the server can always proceed to a full handshake. So there's not much point to resumption to save effort as it was with TLS > classic, you have to do most of the full-handshake crypto (or take the > hello- > retry hit) either way, and implementing resumption just adds even more > complexity and attack surface. > I don't believe that this is correct either. In TLS 1.3, as with any SIGMA-based protocol, there are two main sources of handshake cryptographic cost: - The key establishment ((EC)DHE, ML-KEM, etc.) - The signature [0] Resumption removes the second of these. Whether it removes the first depends on whether you expect to do resumption with asymmetric key establishment. If you do, then you'll need to compute and send the KeyShares whether or not resumption happens. -Ekr [0] And, in some cases, there is also latency introduced by the size of the certificates.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
