TLS Encrypted Client Hello (formerly ESNI) Enters Draft Status(tools.ietf.org)
tools.ietf.org
TLS Encrypted Client Hello (formerly ESNI) Enters Draft Status
https://tools.ietf.org/html/draft-ietf-tls-esni-07
28 comments
This makes it sound like following the work of IETF is an idle task, and all required is to subscribe to a mailing list, but neglects to mention this inevitably means following endless overlapping and often redundant discussions on multiple mailing lists, that routinely span bi-annual periods. Nobody has time for that unless their job gives them a direct stake in protocol and architecture work. This describes probably much less than 1% of the people found on HN.
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.
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.
The complaint is more "the title of this link does not reflect anything about how the IETF works or the status of this particular revision of the draft rather".
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.
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.
> 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.
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.
Well.... yeah. If I wanted to be a smartass I would be saying something like "the 00 when it got adopted into the working group is important" though, unlike random changes before wglc.
Many thanks for the info and sorry for the confusion.
Posted 9 days ago: https://news.ycombinator.com/item?id=23430934
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...
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...
As a user, I will continue to favour websites that do not use shared hosting. They do not require SNI.
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.
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.
If each dedicated IP address is associated with a single hostname/certificate, then wouldn't it be relatively straightforward to map connections to a specific IP address back to a known hostname?
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.
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.
Of course. I have seen this argument before. When we say "relatively straightforward" what is this relative to? SNI did not make possible what was previously impossible. It made something that was always possible much easier and more reliable by creating a new method -- sniffing ClientHello.
There is no such thing as "absolute" privacy on the internet, (IMO). There never was and there will never be. HOwever if our threat model is marketers/advertisers, the dichotomy, if we choose to view the issue that way, is "easier/more difficult" (on a mass scale) not "possible/impossible". Is it easier to passively sniff ClientHello from network traffic on a mass scale then to connect to 443 on a massive number of computers (or rely on someone else to do it)? Or is it more difficult? One method generates zero traffic and requires relatively less computing resources. The other method generates an inordinate amount of traffic, enough to trigger complaints from internet provider, and requires more significant resources. Today, we have both methods available. Before SNI, the additional, easier method did not exist.
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.
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.
If we trust DNS to publish the SNI public keys, why don't we trust it for the website certificate in the first place?
You need to look at the threat model. The threat model around eSNI public key substitution is a minor privacy invasion: Eve can see the hostnames you're connecting to. This isn't so bad because your DNS provider can already see the hostnames you're connecting to. Standards like DNS over TLS are being explored to make it harder for other parties to use this type of attack.
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.
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.
Yep, there is a standard for exactly that - it's called DANE - https://en.m.wikipedia.org/wiki/DNS-based_Authentication_of_...
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
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
> If we trust DNS to publish the SNI public keys, why don't we trust it for the website certificate in the first place?
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.
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.
I suppose because the certificate changes more often and it’s more reliable/predictable to change the server cert than DNS? If you ARE rotating the SNI public keys I’m assuming you can easily support multiple active at the same time.
It's way easier to give someone a fake DNS reply than to get a valid SSL certificate, so maybe it's just a matter of risk. Bad DNS exposes where you're going. Bad SSL exposes everything you're doing there.
It really doesn't matter though. You can just use DoH and trust Google / Cloudflare for everything. /s
It really doesn't matter though. You can just use DoH and trust Google / Cloudflare for everything. /s
Im curious, can DoH server set Http cookies on my machine? Is DoT safer in this regard?
The server can Set-Cookie for sure if it wants to but the resolver is not supposed to accept it.
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.
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.
> Most users are probably better off with DoH. It protects transport better.
Thanks. Why it protects transport better?
Thanks. Why it protects transport better?
[deleted]
Ohhhhhhhhhhhhh I wrote my reply assuming you meant DNS-over-TCP not DNS-over-TLS. Duh, sorry. Should have been obvious from context.
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.
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.
DANE is a thing but also, websites can and should work without DNS (IP SAN) and alsk, it gets difficult when you have multiple subdomains and when the certificate is for the http host instead of the domain. But for regular sites, DANE with CT logs makes a lot of sense
It's possible we _could_ - a combination of DNSSEC used to sign records, and TLSA records to provide the linking. In reality, however...
Is getting an bad sni key a terrible risk? What kind of data would it leak?
The owners of the key pair whose public half you are tricked into using get to see the otherwise concealed ClientHello which today includes SNI and ALPN. So e.g. they'd know you wanted to speak HTTP/2 to some.name.example
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.
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.
The certificate will still have to be verified at client-side with the CAs. I know my idea will break the entire TLS flow but I am just talking about the validity of it in the first place.
Was just thinking about that.
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).
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).
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.