TLS Encrypted Client Hello (formerly ESNI) Enters Draft Status
tools.ietf.org
tools.ietf.org
This Internet Draft was formally adopted by the TLS working group in 2018.
If you have valuable technical input for this work, or indeed any of TLS, you should subscribe to the TLS working group, familiarise yourself with the culture and pitch in - but there doesn't seem to any particular reason it's more relevant to Hacker News today than last week or next month.
Meanwhile there are few mechanisms to popularize the results of standards groups aside from occasional sexed up vendor blog posts (for example, CloudFlare are great at these). I see no problem with this extra visibility, and find it quite perplexing that someone would have reason to complain about it.
If you're expecting to get any value from this hacker news story, you need to understand enough of how the IETF works to know what meaning this particular draft has as opposed to any of the previous 6 revisions.
Seven, or, depending on how you squint, eight :D
Draft numbering starts from zero: https://tools.ietf.org/html/draft-ietf-tls-esni-00
And also the number resets if (as happened in this case) a draft is adopted by a Working Group and acquires that "ietf" in place of an author's name, so the predecessor to that zero zero draft was ekr's draft-rescorla-tls-esni-00.
BoringSSL ticket for implementation: https://bugs.chromium.org/p/boringssl/issues/detail?id=275
Chromium ticket, blocked on above: https://bugs.chromium.org/p/chromium/issues/detail?id=109140...
ESNI just protects the name of the site you're visiting. It's going to be most useful to reduce the amount of data available to bulk snoopers like ISPs or mass surveillance efforts.
But there are lots of ways traffic analysis can uncover data. They can look at request sizes, timing, IP addresses - and critically, your DNS requests. ESNI is an incremental protection that is not expected to be perfect. Just reduce the amount of "low hanging data" that can easily be plucked from streams.
If an attacker can snoop or hard MITM your DNS they know what site you are visiting anyway.
So under the kind of threat model that makes sense for ESNI to be useful there is no real downside to distributing the keys over DNS.
Actually I just had a look at the RFC and this explanation is redundant because they did it themselves in section 7.1: https://tools.ietf.org/html/draft-ietf-tls-esni-04#page-21
In contrast the existing CA infrastructure is intended to protect the content of the user's communications in basically all malicious networking scenarios: DNS hijacking and MITM in particular. The threats that the existing CA infrastructure are meant to protect you from are quite different.
However, there is no reason I can think of that you couldn't distribute the certificate for say, foo.com (signed by existing CA infra) via DNS instead of sending it in-band. I believe you could make the protocol "work" this way.
But DNS is not such a great protocol for sending big things like long certificate chains (in contrast to more svelte naked keys for ESNI). It would not be as good as sending it in-band and the security would be rather worse (more prone to disruption / poisoning / DoS), with more metadata leaked (eg certificate exchange is part of encrypted handshake in standard TLS).
The main semantic difference I can see is that usually the server chooses what server certificate to present; DNS distribution would be more like the client choosing what server cert to use due to DNS eventual consistency. As a practical concern, servers would have to support all valid certs until expiry or introduce additonal negotiation. Servers would also need to figure out which cert the client actually chose, somehow (either by trial decryption or client signalling). Anyway, not TLS as we know it anymore.
It's subtly (but not fatally) worse along several dimensions and I keep thinking of more ways it's worse as I've continued to edit this comment. Last thought: an attacker could easily force you to use an old (but not yet expired) cert. Again I guess the DNS-CA-TLS franken-protocol would have to work around that with additional mechanism (perhaps something like OCSP stapling).
But on the other hand to have substituted this key for the correct one they presumably already intercepted your DNS query and so they likely already knew you were intending to talk to some.name.example from that query.
It really doesn't matter though. You can just use DoH and trust Google / Cloudflare for everything. /s
From rfc8484: "HTTP cookies SHOULD NOT be accepted by DOH clients unless they are explicitly required by a use case."
You'd have to review your particular resolver implementation to be sure. I suppose one would have to say DoT is safer in this regard, since accepting cookies is not an implementation error you could reasonably make without using an HTTP library.
Most users are probably better off with DoH. It protects transport better. Sadly the problem of finding someone trustworthy to resolve through doesn't go away.
EDIT: ^ This is wrong; DNS-over-TLS is fine.
Thanks. Why it protects transport better?
Yeah DNS-over-TLS is safer in this regard and provides equivalent network-path protection. DoH is kind of a garbage protocol but it's a concession to the fact that a lot of "real" networks are broken and HTTP(s) is the only thing you can rely on being able to transport.
Since DNS-over-HTTPS goes over proxies and uses port 443, it'll "work by default" in a larger variety of networks than DNS-over-TLS.
CloudFlare have made the argument that DoH "blends in" better with regular HTTPS traffic but I don't really buy that when everyone just uses the same few recursive resolvers.
I was quite hopeful it might lead to widespread use of self-signed certs, though with things like LetsEncrypt, it's not really needed any more
The threat model around TLS public key substitution is basically full read/write control over your requests. This represents both a major privacy invasion and exposure of auth secrets like your bank account password. Your DNS provider doesn't already have access to those things.
edit: You could deliver a cert this way, and authenticate the cert out of band e.g. through the CA system. This kind of approach is sound from a security standpoint, but there just isn't a lot of upside. There are fewer moving parts when you just deliver the cert the way we do now.
These are two very different things. The SNI public keys are only used to encrypt the hostname, i.e. the goal here is hostname privacy.
You can't have hostname privacy without trusting the DNS. But it will always be a weak form of privacy, because you have to trust a third party.
So what is happening here is that we say "ok, we can't have perfect hostname privacy, but allowing the DNS server to compromise our privacy is better than allowing it to everyone".
Now if you put the cert there you'd say "we allow the DNS to compromise all of our TLS". You really don't want that.
As multiple people here have said there's a way to put signed certificates into DNS called DANE. But it suffers from the fact that it relies on DNSSEC, which is a complex beast and probably most relevant: Which in the decades it has existed hasn't managed to get any relevant traction.
SNI is an interesting experiment. One could argue it benefits users because it has made it less expensive for websites to provide TLS, and therefore there has been more use of TLS, however at the same time it takes users a step back in terms of privacy. Before SNI, SSL/TLS websites never leaked hostnames. Even a user who is using "encrypted DNS" (not the DNScurve kind) or who is not even using DNS at all (she already has the server IP address) ends up leaking hostnames when she accesses websites requiring SNI. That's all of Cloudflare and many other hosting providers/CDNs. The whole exercise makes it trvially easy to track the usage habits of users by sniffing the plaintext TLS setup traffic. Whatever was gained by using SNI to achieve virtual hosting for TLS must be offset by the amount of user privacy sacraficed.
Not surprising one of the sponsors of this draft is an enormous user of SNI in its hosting business.
ESNI is a noble idea however it is riddled with complexity. As a user concerned about leaking hostnames, nothing beats a good old-fashioned TLS website on a decicated IP addresss. There are still plenty of those around.
You can probably just probe the IP on port 443 and look at the certificate subject to characterize that traffic.
Might work for very obscure sites, but not anything commonly used.
However, to be fair, I think there could be an argument regarding websites now using TLS with SNI because of the cost reduction of shared TLS hosting that previously were only only using TCP. Before they started using TLS, arguably hostnames could be sniffed from HTTP headers. Whether pulling hostnames from HTTP Host headers is easier on a mass scale than sniffing ClientHello packets, and whether anyone would do that for marketing/advertising purposes, is for the reader to decide.