
TLS Encrypted Client Hello (formerly ESNI) Enters Draft Status - loyukfai
https://tools.ietf.org/html/draft-ietf-tls-esni-07
======
tialaramex
This is a puzzling submission. On the 1st of June an updated eSNI draft,
draft-ietf-tls-esni-07 was published with a new name reflecting the approach
of encrypting more of the Client Hello rather than just SNI, but "draft
status" isn't a thing, except in the sense that a draft either exists or does
not, and this one exists.

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.

~~~
james412
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.

~~~
brongondwana
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.

~~~
tialaramex
> 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](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.

~~~
brongondwana
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.

------
dweekly
Posted 9 days ago:
[https://news.ycombinator.com/item?id=23430934](https://news.ycombinator.com/item?id=23430934)

BoringSSL ticket for implementation:
[https://bugs.chromium.org/p/boringssl/issues/detail?id=275](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...](https://bugs.chromium.org/p/chromium/issues/detail?id=1091403)

------
opqpo
If we trust DNS to publish the SNI public keys, why don't we trust it for the
website certificate in the first place?

~~~
Polylactic_acid
Is getting an bad sni key a terrible risk? What kind of data would it leak?

~~~
opqpo
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.

~~~
zxcmx
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](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).

------
pwdisswordfish2
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.

~~~
terom
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.

~~~
pwdisswordfish2
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.

