3 ms·

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 encry

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). This whole thing is still a draft RFC [2] and currently called encrypted client hello. What I don't get: The client will have to disclose, which public key it used to encrypt the client hello / SNI value. 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. Just look up the public key, read it's SAN or CN, and you pretty much know the SNI value. Or at least the service, which might be good enough. What am I missing? [1] https://blog.cloudflare.com/encrypted-sni https://blog.cloudflare.com/encrypted-sni [2] https://www.ietf.org/archive/id/draft-ietf-tls-esni-15.html https://www.ietf.org/archive/id/draft-ietf-tls-esni-15.html

tialaramex 4y ago
> What I don't get: The client will have to disclose, which public key it used to encrypt the client hello / SNI value 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.

tialaramex 4y ago

> What I don't get: The client will have to disclose, which public key it used to encrypt the client hello / SNI value 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.