3 ms·
Just ESNI/ECH is a big deal. I recall one of the main arguments against Encrypted server name indication (ESNI) is that it would only be effective for the gian
by infogulch 1y ago
Just ESNI/ECH is a big deal.
I recall one of the main arguments against Encrypted server name indication (ESNI) is that it would only be effective for the giant https proxy services like Cloudflare, that the idea of IP certs was floated as a solution but dismissed as a pipe dream. With IP address certificates, now every server can participate in ESNI, not just the giants. If it becomes common enough for clients to assume that all web servers have an IP cert and attempt to use ESNI on every connection, it could be a boon for privacy across the internet.
- duskwuff 1y ago> If it becomes common enough for clients to assume that all web servers have an IP cert That's never going to be a safe assumption; private and/or dynamically assigned IP addresses are always going to be a thing.
- Hizonner 1y agoSo is this the flow? 1. Want to connect to https://www.secret.com https://www.secret.com. 2. Resolve using DNS, get 1.2.3.4 3. Connect to 1.2.3.4, validate cert 4. Send ESNI, get separate cert for www.secret.com, validate that ... and the threat you're mitigating is presumably that you don't want to disclose the name "www.secret.com" unless you're convinced you're talking to the legitimate 1.2.3.4, so that some adversary can't spoof the IP traffic to and from 1.2.3.4, and thereby learn who's making connections to www.secret.com. Is that correct? But the DNS resolution step is still unprotected. So, two broad cases: 1. Your adversary can subvert DNS. In this case IP certificates add no value, because they can just point you to 5.6.7.8, and you'll happily disclose "www.secret.com" to them. And you have no other path to communicate any information about what keys to trust. 2. Your adversary cannot subvert DNS. But if you can rely on DNS, then you can use it as a channel for key information; you include a key to encrypt the ESNI for "www.secret.com" in a DNS record. Even if the adversary can spoof the actual IP traffic to and from 1.2.3.4, it won't do any good because it won't have the private key corresponding to that ESNI key in the DNS. And those keys are already standardized. So what adversary is stopped by IP certificates who isn't already stopped by the ESNI key records in the DNS?
- tptacek 1y agoPresumably you're encrypting DNS.
- infogulch 1y agoSure, I agree, the next increment in privacy comes with using DoT/DoH (in fact some browsers require this to use ESNI at all). Probably throw in DNSSEC next. Having IP certs is just one more (small) step in that direction. > you include a key to encrypt the ESNI for "www.secret.com" in a DNS record I've never heard of this, is this a thing that exists today? (edited to remove unnecessary comment)
- gruez 1y ago>I've never heard of this, is this a thing that exists today? Are you arguing against one small step in a series of improvements by using a nonexistent hypothetical as evidence that the small step is unnecessary? see: https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypted_Client_Hello https://en.wikipedia.org/wiki/Server_Name_Indication#Encrypt...
- infogulch 1y agoThanks. > Another Internet Draft incorporates a parameter for transmitting the ECH public keys via HTTPS and SVCB DNS record types, shortening the handshake process.[24][25] [25]: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings | https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/
- tptacek 1y agoDNSSEC is an integrity control, not a privacy control.
- infogulch 1y agogp proposes a scenario where an integrity breach is lifted to a privacy breach, insisting on a strict distinction doesn't seem useful in this context.