Earlier quoted context omitted.
So the encrypted connection used to exchange SNI isn't authenticated? This hides the SNI from passive eavesdroppers but not from an active MITM, no?
Good point. So there is more to it, which I didn't consider before. As I understand [1], the client uses the public key of the key pair used by the SNI to encrypt the SNI value, additionally to any TLS encryption. Only the actual SNI has the private key to decrypt the SNI value. The client must look up the public key in the DNS (I guess at least if it doesn't know the key already, which it could have in the cache). T…
Actually, not necessarily, but first...
> But don't we know "all" the public keys from the certificate transparency logs? Usually a public key is only valid for a limited set of domains, so it would be easy to associate the public key used for encrypting the SNI value with the relevant service
The keys used to encrypt ECH are distinct from keys used to prove identity. So, no only are the CT logs irrelevant (they're logs of the identity information which uses separate keys) but also you would usually choose the same keys for all the names hidden behind some particular server.
Suppose I run big.huge.example a hypothetical CDN. We can use the same public key for clown-porn.example, abortion-rights.example, huge-corp.example, government-stuff.example, even though these services may be entirely segmented internally, we're only using that key to keep the names private from everybody else. As big.huge.example we know whether a client uses clown-porn.example or abortion-rights.example, but an on-path adversary doesn't know that and the key used doesn't help them.
Still back to the encryption problem. We don't actually necessarily need to tell people which key was used. So long as the number of possible keys in use is modest they can guess:
Suppose big.huge actually has four keys in use, maybe two sets of customers on different tiers of product, maybe we're switching keys and there's an overlap period of course - we don't need clients to signal necessarily, we can just decrypt with all four keys, incurring a modest 4x decrypt performance penalty and throwing away the 3 which fail in the ordinary case.