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

[Christian Huitema <[e-mail]>]

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