In theory, TLS 1.3 provides strong future secrecy guarantees, but the
handling of session tickets can compromise that. In theory, the session
Ticket could be a simple identifier, used by the server to retrieve the
context of a past session. In practice, many servers encode the relevant
session context data in the session ticket itself, using a Session
Ticket Encryption Key (STEK). For server farms, there is no guarantee
that the resumed session will hit the same server as the initial
session, so in practice all servers in the farm share the STEK. And
then, we have a serious future secrecy issue: if the STEK leaks, the
attackers can decrypt all the sessions that were encrypted with that
STEK, and might also be able to decrypt the initial sessions. In short,
STEKs are convenient but risky.
The load balancing draft defines Connection ID formats that assure that
packets get routed to the right server in a pool. I think that we could
use these connection IDs to ensure that a resumed connection goes back
to the same server as the initial server. The simplest implementation
would be for the client to remember one of the "New connection IDs"
received in the initial session, and use that as Initial Connection ID
in the resumed session. Once we do that, we get options. The server
could for example have a server specific STEK, which reduces the impact
of leaking STEk to just the sessions handled by that server, instead of
all the sessions by servers sharing the STEK. Or, the server could just
remember contexts of past sessions locally, and just place an identifier
of that context in the session ticket, effectively going STEK-less.
Would there be any interest in pursuing that idea?
-- Christian Huitema
