Re: Going STEK-less with QUIC?

[Kazuho Oku <[e-mail]>]

2021年7月28日(水) 6:05 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?
>

I'm not sure if we'd be interested in deploying this sort of stuff, due to
the following two reasons:

* Most if not all of large-scale HTTP deployments use STEK for
TLS-over-TCP. Therefore, even if we address the issue on the QUIC side, the
low bar remains as-is on the TCP side.
* By allowing clients to "stick" to reusing the same server across multiple
connections, we are creating a new DoS attack vector that allows attackers
to target a particular host behind a load balancer. While we can implement
mitigations, that is an additional complexity.

That said, if we are to pursue this, I wonder if it would be better to
solve the issue entirely on the load-balancer & server side rather than
making a protocol change to QUIC.

To give an example, I think the same result can be achieved in practice by
designing a format of NEW_TOKEN tokens that is to be shared by the load
balancer and the server. That token would contain the server-id. When the
load balancer receives an Initial packet conveying such a token, it can
parse the server-id contained in that token, and forward the packet to the
specified backend.


> -- Christian Huitema
>
>
>

-- 
Kazuho Oku