Going STEK-less with QUIC?

[Christian Huitema <[e-mail]>]

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