Negotiating psk_dhe_ke does mitigate some of the issues, but not all.
For example, using DHE does not mitigate the secrecy issues with 0RTT.
Another related issue is ensuring that tickets are used exactly once for
0RTT. That's a lot easier if the resumption server is the same as the
initial server. Then for QUIC there is also the issue of clients
remembering negotiated transport parameters from the initial session and
reusing them in 0RTT, which breaks if the resumption server does not use
the same parameters as the initial server.
-- Christian Huitema
On 7/27/2021 2:22 PM, Andrei Popov wrote:
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 <[email protected]> On Behalf Of Christian Huitema
Sent: Tuesday, July 27, 2021 2:02 PM
To: IETF QUIC WG <[email protected]>
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
