2021年7月28日(水) 6:05 Christian Huitema <[email protected]>: > 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
