RE: [EXTERNAL] Going STEK-less with QUIC?

[Andrei Popov <[e-mail]>]

> 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.

This is only a problem if the client and server negotiate psk_ke mode, rather than psk_dhe_ke, correct?

Cheers,

Andrei

-----Original Message-----
From: QUIC <[e-mail]> On Behalf Of Christian Huitema
Sent: Tuesday, July 27, 2021 2:02 PM
To: IETF QUIC WG <[e-mail]>
Subject: [EXTERNAL] Going STEK-less with QUIC?

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