Subject: [TLS] DNS-based Encrypted SNI

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Jul 2018 16:39:14 -0700

Hi folks,

I just submitted:

  https://tools.ietf.org/html/draft-rescorla-tls-esni-00

This draft describes a DNS-based approach to doing encrypted SNI.

Previously, we had thought this wouldn't work because only sites that
were particularly vulnerable would do it, and so the use of ESNI marks
you out. The idea behind this draft is that there are a lot of sites
which are hosted by -- and whose DNS is run by -- a large provider,
and that provider can shift many if not all of its sites to ESNI at
once, thus removing the "standing out" issue and making a DNS-based
approach practical.

I am working on an implementation for NSS/Firefox and I know some
others are working on their own implementations, so hopefully we can
do some interop in Montreal.

This is at a pretty early stage, so comments, questions, defect
reports welcome.

-Ekr

---

From: Paul Wouters <[email-masked]>
Date: Mon, 2 Jul 2018 23:53:19 -0400 (EDT)

> This is at a pretty early stage, so comments, questions, defect

 	This structure is placed in the RRData section of a TXT record as a
 	base64-encoded string.  If this encoding exceeds the 255 octet limit
 	of TXT strings, it must be split across multiple concatenated strings
 	as per Section 3.1.3 of [RFC4408].

It is strongly recommended not to use TXT records. Why not use a new
RRTYPE? Everything these days knows how to serve unknown record types
(see RFC 3597). The only possibly exception is provisioning tools of
small players, but this document starts of saying you basically need
to be on a bulk hosting provider anyway. They can properly provision.

I need to think more about the document to see if there is really not
something simpler or better possible.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Jul 2018 20:57:58 -0700

> to be on a bulk hosting provider anyway. They can properly provision.

See:
https://github.com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906

-Ekr

---

From: "Sniffen, Brian" <[email-masked]>
Date: Tue, 3 Jul 2018 14:26:10 +0000

Looks neat. 

1) TFO DOS vector: is the idea servers will disable TFO under strain but not be able to disable ESNI?

2) “clients might opt to attempt captive portal detection to see if they are in the presence of a MITM proxy, and if so disable ESNI.”

If I’m operating a great firewall, I can use this to discover dissidents, right?  Either they send me dangerous SNI values or they are configured to not disable ESNI, and taking the fifth is fatal. To protect them, I think nobody can have this mode. 

3) How many bits does this offer? Hiding in a set of a million uniform hosts is 20 bits, and the nonuniformity will accrue to the adversary’s benefit. Active probing will unmask visitors to dissident sites.

I worry that this tool is so weak against a GFW-style adversary for the purpose of allowing dissident access to restricted web sites that it will be dangerous if released. But maybe I misunderstand the purpose. If this is just to keep Western ISPs from monkeying with traffic, sure, ship it.  Labelling the encryption with its strength as applied, or showing CDNs and ISPs how to work out some bounds, seems one way to help users understand whether this can help them or put them more at risk. 

-- 
Brian Sniffen

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 3 Jul 2018 11:20:22 -0400

> This draft describes a DNS-based approach to doing encrypted SNI.

Thanks for this proposal, Eric.  I fully support this line of work.

This proposal obviously bears some relevance to the SNI Alt-Svc + DNS
ALTSVC drafts in HTTPBIS [1][2].  That's OK; we'll sort it out eventually.
I hope people interested in this draft will also check out those.  In my
view, ESNI and those drafts are two complementary approaches to this
problem.  I can see reasons to pick one, or both, or a combination.

[1] https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-02
[2] https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02

> On Mon, Jul 2, 2018 at 8:53 PM, Paul Wouters <[email-masked]> wrote:
...

> <https://github..com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906>
>

That logic (CNAME compatibility) requires not placing this information at
the apex, i.e. using a prefix, as you've done.  It doesn't preclude using a
new record type.  The DNS ALTSVC draft, for example, does both.

Some other thoughts:

I expect much nitpicking of the exact DNS syntax.  You may end up wanting
to describe that separately, especially since these "introduction tokens"
may well be useful to acquire over non-DNS channels (e.g. Alt-Svc) and may
be useful for non-SNI purposes (like 0-RTT, as you've noted).

I wonder how well this scales to a "large key" future (e.g. post-quantum).

As described, this approach seems hard to use with a domain load-balanced
across two CDNs.  (I don't know how important that use case is.)

One concern I've heard many times is that we can't add non-A/AAAA queries
to a browser's critical path because there are middleboxes and buggy
recursives that will just drop them, leading to a DNS timeout delay on
every new socket.  However, for encrypted SNI I think we can ignore this by
focusing on clients with DPRIVE or DOH enabled, which should avoid these
kinds of problems.

---

From: Patrick McManus <[email-masked]>
Date: Tue, 3 Jul 2018 11:26:51 -0400

> focusing on clients with DPRIVE or DOH enabled, which should avoid these
yes, and of course encrypting sni is a lot more valuable when the dns query
is also encrypted.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 3 Jul 2018 11:40:58 -0400 (EDT)

> https://github.com/ekr/draft-rescorla-tls-esni/issues/7#issuecomment-388531906

[Can we keep the discussion within the IETF and the Note Well please. We
  also don't know what happens in 10 years with these links.]

quoting from that link:

 	These facts lead to the conclusion that if we choose RRtype as the
 	method, there would often be cases where the DNS record of the ESNIKey
 	and the TLS server would be required to be operated by different
 	entities.

That seems to have confused two things with each other. I did not say
anything about the location of the DNS record, only of the RRTYPE.
Clearly, with the same location, it would be under control of the same
entity, so I don't understand why you bring this up as a reason against
using a dedicated RRTYPE.

Here is another argument against it, besides the generic IETF policy of
trying to not overload things or create kitchen sinks. If you used, or
were forced to use, a DNS under control of someone who can block things,
they might be instructed to block anything related to encrypted SNI,
and they might decide to just block all TXT records, even unrelated
ones, resulting in collateral damage.

Paul

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 3 Jul 2018 08:55:29 -0700

>  also don't know what happens in 10 years with these links.]

If you look carefully, you'll see that this discussion happened weeks ago.
I was
just pointing you at it because you asked why we did it the way we did.

With that said,IETF policy does not prohibit having discussions on Github.
We do it
regularly in TLS and it's the standard policy in QUIC.

> using a dedicated RRTYPE.

I'm just quoting Kazuho here, so I'll let him respond to himself.

-Ekr

---

From: Tim Hollebeek <[email-masked]>
Date: Tue, 3 Jul 2018 19:50:00 +0000

One of the things we found out with CAA is that this extremely optimistic view
of the support for unknown RR types by large hosting providers is not 
accurate.

-Tim

> -----Original Message-----
> From: TLS [mailto:[email-masked]] On Behalf Of Paul Wouters
> Sent: Monday, July 2, 2018 11:53 PM
> To: [email-masked]
> Subject: Re: [TLS] DNS-based Encrypted SNI
>
> RRTYPE? Everything these days knows how to serve unknown record types (see
> RFC 3597). The only possibly exception is provisioning tools of small 
> players,
> but this document starts of saying you basically need to be on a bulk 
> hosting
> provider anyway. They can properly provision.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 3 Jul 2018 17:46:30 -0700

> not be able to disable ESNI?

I hadn't thought about it, but that seems right. I'm not really seeing why
this is a DOS vector? At present, if you're able to pass a routability
test, you can force a server to do a DH exchange and a signature, so
forcing them to do ESNI decryption doesn't seem like it's that much of an
amplification.

> 2) “clients might opt to attempt captive portal detection to see if they
> are in the presence of a MITM proxy, and if so disable ESNI.”
>
> If I’m operating a great firewall, I can use this to discover dissidents,
> right?  Either they send me dangerous SNI values or they are configured to
> not disable ESNI, and taking the fifth is fatal. To protect them, I think
> nobody can have this mode.
>

This doesn't sound right to me. The idea here is that you only disable ESNI
if the attacker is able to generate a valid TLS connection to a
*non-default* root, which means that they are MITM-capable, which nation
state firewall operators typically are not. And of course if they are, then
you have real problems. Can you walk me through the flow you have in mind.

> 3) How many bits does this offer? Hiding in a set of a million uniform
> hosts is 20 bits,

Well, I would say it's got an anonymity set of 2^{20}. It's not 20 bits
strong in the sense that the attacker can do a computation of cost 2^{20}.n

and the nonuniformity will accrue to the adversary’s benefit. Active
> probing will unmask visitors to dissident sites.
>

I don't really follow this. Can you explain?

-Ekr

I worry that this tool is so weak against a GFW-style adversary for the
> purpose of allowing dissident access to restricted web sites that it will
> be dangerous if released. But maybe I misunderstand the purpose. If this is
> just to keep Western ISPs from monkeying with traffic, sure, ship it.
> Labelling the encryption with its strength as applied, or showing CDNs and
> ISPs how to work out some bounds, seems one way to help users understand
> whether this can help them or put them more at risk.
>
> --
> Brian Sniffen
>
>

---

From: Kazuho Oku <[email-masked]>
Date: Wed, 4 Jul 2018 10:36:59 +0900

2018-07-04 0:55 GMT+09:00 Eric Rescorla <[email-masked]>:
> If you look carefully, you'll see that this discussion happened weeks ago. I
> was
> With that said,IETF policy does not prohibit having discussions on Github..
> We do it

The discussion was about comparing two approaches: a) use a new record
type without suffix, b) use TXT record type with suffix.

My argument was that we should select b because a has the
deployability issue in regard to APEX names.

It is true that the deployability issue is a concern related to the
non-use of prefix. It is _not_ related to the selection of the record
type.

OTOH, I think that the reliability issue related to using a new record
type exists, as others have pointed out.

-- 
Kazuho Oku

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 4 Jul 2018 07:32:49 +0300

> of the support for unknown RR types by large hosting providers is not 

As context, problems with CAA were not limited to various DNS hosters
not supporting it or DNS recursives choking on it, but also things like:

1) Broken replies from _authoritative_ nameservers for CAA queries.
2) Timeouts from _authoritative_ nameservers for CAA queries.
3) Broken DNSSEC proofs for empty record sets.

The most worrisome here is the 2). Even with good DNS recursive, you
would still take timeouts.

There are quite a bit of CAA-related problem reports on Let's Encrypt
forums. Those are almost never of incorrect CAA records and rarely
questions on how to add CAA, but generally problems caused by some
authoritative nameserver being broken and causing CAA lookups to
fail or return bogus answers.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 4 Jul 2018 07:48:44 +0300

> once, thus removing the "standing out" issue and making a DNS-based

The recent Russia versus Telegram episode is kinda worrisome in this
regard. Basically, it looked like the actions that created massive
collaterial damage got at least two very large cloud provoders to
disable one technique of hiding the name of the target server.

> This is at a pretty early stage, so comments, questions, defect

One thing I noticed: First there is this in evaluation:

7.2.4.  Do not stick out

   By sending SNI and ESNI values (with illegitimate digests), or by
   sending legitimate ESNI values for and "fake" SNI values, clients do
   not display clear signals of ESNI intent to passive eavesdroppers.

Is that suggesting to send fake ESNI values? If so, there is this in
endpoint behavior:

5.2.  Client-Facing Server Behavior

   o  If the EncryptedSNI.record_digest value does not match the
      cryptographic hash of any known ENSIKeys structure, it MUST abort
      the connection with an "illegal_parameter" alert.  This is
      necessary to prevent downgrade attacks.

So sending out fake ESNI values seems unsafe. My reading of that is
that if server supports ESNI, but is not configured, then it MUST
terminate (illegal_parameter) any handshake where ESNI extension
was offered in. But that behaviour would cause any split mode
handshakes to fail if backend supports ESNI.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jul 2018 05:56:07 -0700

On Tue, Jul 3, 2018 at 9:48 PM, Ilari Liusvaara <[email-masked]>
wrote:

> On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote:=

No, you would not send fake ESNI values. The idea here is that there is a
group of IPs (associated with a big provider, then all ESNI-supporting
clients will send ESNI to it. So the provider will stick out, but the use
of site X versus site Y on the provider will not    stick out. And the
provider's IPs are reasonably well known through other mechanisms, so this
doesn't tell you much. Of course, this does not help big sites that aren't
using shared infrastructure (e.g., Facebook), but I don't know how to do
that.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Jul 2018 14:01:26 +0100

Hiya,

>   https://tools.ietf.org/html/draft-rescorla-tls-esni-00

Thanks for writing that up. I think it's an interesting
addition to the set of potential solutions.

> once, thus removing the "standing out" issue and making a DNS-based

I'm not sure I fully understand how this approach would fit
with others, nor to what extent it depends on the DNS and
CDN providers co-operating, but it definitely seems worth
exploring.

> This is at a pretty early stage, so comments, questions, defect

Quick comments after flicking through the draft:

- I'm not that fussed myself as to whether this uses a TXT
or new RRTYPE. But if the latter would work, it seems better.

- I didn't quite get what "all the domains" in 3.2 means. I
guess if a client uses non-encrypted sni for one of those,
it should still work, but I'm not clear if supporting esni
for any domain means that the provider has to decrypt esni
and then deal with successful decrypted sni values as if
the client had sent sni in clear. A concern is requiring
"all the domains" might make it hard to roll this out.

- I guess some form(s) of key rollover will be needed, ut
I'm not sure that not_before/not_after is the best way to
do that.

- The ESNIKeys structure generally seems a bit complicated,
it might be better to aim for simplifying that and maybe
making it more "zonefile friendly" (whether in a TXT RR
or not).

- It might be interesting to think about how this'd work
for e.g. the IETF web site (where ietf.org is hosted
locally but www.ietf.org is not), and for STARTTLS and
MX RRs. That's probably ok, but I've not gotten it
straight in my little head yet:-)

- Would it make sense to include the innocuous dummy sni
in the published RR, so that all clients use the same
one and stand out that bit less?

- 7.1 probably needs more work - I'm not sure that it's
that ok to use this with cleartext DNS. ISTM that DOH/DPRIVE,
or a client application that knows the ESNIKeys, are most
likely needed, but there's probably also some work to do
to analyse the recursive to authoritative interactions to
get the ESNIKeys even with DPRIVE.

Lastly, the topic of whether or not to try address this
problem is something that the WG has debated quite a bit,
and IIRC the consensus after that debate was to do work
on this (hence Christian's draft).

So I don't see any need to debate whether or not to work on
this is needed, and trying to re-open such a debate seems
somewhat disruptive to me. It is entirely reasonable to
consider what, if anything, widespread use of esni or other
approaches might break though. But going back to all this
"privacy at any cost" and "we're the enterprises" hyperbole
is not at all helpful IMO, so I hope we don't have to suffer
more rounds of that. But maybe that's inevitable with every
iteration of attempts to improve privacy sadly;-(

Cheers,
S.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 4 Jul 2018 16:08:34 +0300

> using shared infrastructure (e.g., Facebook), but I don't know how to do

What does "with illegitimate digests" mean then?

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jul 2018 09:53:30 -0700

> What does "with illegitimate digests" mean then?

I didn't write this text, but I agree that it's in conflict with the
requirement that
you abort with an unknown key. We went through some design variants and
this looks like a remnant of a previous one.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jul 2018 10:20:07 -0700

Stephen,

Thanks for your comments.

> CDN providers co-operating, but it definitely seems worth

I think the answer is "a lot". Basically, the entire reasoning here is that
you can convert a lot of people at once. If you can't, then I don't think
this is a viable option.

> "all the domains" might make it hard to roll this out.

Yeah, this is badly written. It just means "all the ESNI-supporting
domains". But as I said, if you host 50 domains and you only
turn on ESNI for one, it's kind of pointless.

> making it more "zonefile friendly" (whether in a TXT RR

The structure started a bit simpler and got new features to
deal with new issues. Specifically:

- The checksum is intended to deal with corruption
- The keys and cipher suites seem kind of mandatory
- The padded length is needed to tell the client how much to
  pad. Though I guess we could always pad to 260. If you don't
  pad at all, it doesn't work.
- I think it's clear what not_before and not_after are for. If you have
  more concrete feedback about better ways to do that, we'd welcome
  this.
- Extensions is just there because we're trying to be safe.

FWIW, this actually is pretty friendly because we b64-encode
(thus making the internal structure opaque to DNS). Removing
things won't make it much smaller because a big chunk of
the data is in the keys. For instance, in my implementation,
the object is 70 bytes long and 34 bytes of that is key (X25519)
and 8 bytes is cipher suite (each of these has 2 bytes of length).

> straight in my little head yet:-)

I don't think we're assuming it applies to subdomains.

> one and stand out that bit less?

We actually had an "alt-svc" thing in here for that and removed
it at the last minute. I'd welcome input on the best thing here.

> - 7.1 probably needs more work -

The whole draft needs more work!

I'm not sure that it's
> get the ESNIKeys even with DPRIVE.

"OK" might not have been the best choice of words. I think this actually
contains two arguments:

1. You don't need DNSSEC.
2. It doesn't make matters worse to do this over unencrypted DNS (i.e.,
you're already
in trouble).

That said, it also doesn't add much value to do ESNI if the attacker
controls your DNS, and in Firefox we're looking initially at just doing it
when DoH is in use.

> on this (hence Christian's draft).

Thanks for making this point. My understanding was that we had WG consensus
to protect SNI. Of course, it may be the case that the WG doesn't like this
solution for one reason or another -- including potentially that it has an
especially bad impact on enterprise deployments compared to other
approaches -- but that seems like a different thing than saying we
shouldn't try to protect SNI at all.

-Ekr

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Jul 2018 19:07:45 +0100

Hiya,

Just on this bit...

> - The checksum is intended to deal with corruption

I'm not sure I see why that's needed, but I believe you if
you say it might help with some home routers. (Though I'd
also be interested in information/citation about the
details of the problems seen there.)

> - The keys and cipher suites seem kind of mandatory

Yep. OTOH, given we need to support >1 value for the RR, if
mostly people just need one key+CS per-RR, it may be possible
to use multiple RRs to provide additional keys/CSes. (If most
uses would have a variable number of keys/CSes then I agree
the current structure is better.)

>   pad at all, it doesn't work.

Sure.

>   more concrete feedback about better ways to do that, we'd welcome

With not_before/not_after (and the TTL) there'll need to be some
consideration of the various overlaps, which has been a source of
bugs and ops screw-ups in other scenarios. I also don't like the
forced expiry of not_after - people will just put in 2038 all over,
or risk weird breakage. (X.509's mandatory notAfter was IMO an
error for most uses of X.509 - an error inherited from the X.500
DAP user authentication use-case that initially motivated X.509.)

I wonder would an incrementing counter (like SOA serial) maybe be
easier where the client just uses the highest value? (There was
some discussion on related topics during the work on MTA-STS, but
I forget the details, might be worth checking with the folks
involved.)

> - Extensions is just there because we're trying to be safe.

Sure, but I hope we consider dropping 'em if there's no need.
New RRTYPEs could always be used for extensions (if new RRTYPEs
are cheap, that is:-)

> and 8 bytes is cipher suite (each of these has 2 bytes of length).

That's good. But I was more thinking about how friendly this
would be for the DNS admin folks. One thing I like about TLSA
and CAA is that (for my use-cases:-) I can just cut'n'paste
the values into zone files and they'll be good until a CA root
key or name changes, which is pretty rare and would be widely
advertised ahead of time.

With RRSIGs and similar, I can also easily inspect values by
just looking at zonefiles and/or using dig, which is helpful
for me at least. But I don't have to deal with large zones so
that kind of inspection may not be of much use to larger
operators. So, I'd defer to real DNS server folks on whether
or not being able to directly view the internals of ESNIKeys
encoding makes any difference.

All that said, I did just suggest adding in the dummy sni
value:-) So I mostly think if this goes ahead (as I hope it
does), we spend a bit of time considering the above issues
before we're done.

Cheers,
S.

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 4 Jul 2018 14:10:18 -0400

Sent from my mobile device

> On Jul 4, 2018, at 9:01 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

I’m also fine with the work going forward, however it was only in March that EKR assured people concerned that they don’t need to worry about SNI being encrypted repeating similar statements previously made to the same effect.  Meantime, he was working on such a solution.  People need warning to prepare for changes, not to be surprised by them after being told not to worry.  They may not have had a chance to think through how they might adapt.

Kathleen 

> <0x5AB2FAF17B172BEA.asc>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jul 2018 11:20:05 -0700

Hi Kathleen,

On Wed, Jul 4, 2018 at 11:10 AM, Kathleen Moriarty <
[email-masked]> wrote:

> I’m also fine with the work going forward, however it was only in March
> that EKR assured people concerned that they don’t need to worry about SNI
> being encrypted repeating similar statements previously made to the same
> effect.  Meantime, he was working on such a solution.

This is not really correct. As of March, I had basically given up on how to
do ESNI in TLS the near future and wasn't really working on it [0] and then
in May, prompted by suggestions by Matthew Prince and Nick Sullivan, I
realized that the proposal in this document could work.

Moreover, I think I've been pretty clear that I wanted to do ESNI and it
was just that we didn't know how. For instance, here's what I said in
PATIENT:

   My evaluation of the current state of SNI encryption is that given the
   current technical state, it will not see particularly wide deployment,
with
   the primary scenario being "at-risk" sites who are subject to censorship
who
   either hide behind or co-tenant with sites which are not subject to
   censorship. That probably isn't going to be incredibly common right now.
Of
   course, this is regrettable from the perspective of people designing
these
   protocols, but I think that's the situation.

As I said the other day, predictions are hard, especially about the future,
and this turns out not to have been totally right (though I also don't
think it's really accurate to characterize it as my saying that people
don't need to worry). I'm sorry if people people are surprised now. That
wasn't my intent, but as I said above, I was surprised too!

-Ekr

[0] Just to be completely clear, there was and is ongoing work on
protecting SNI via HTTP connection coalescence (see Mike Bishop's
presentation in London), but that's a different flavor of approach, and
it's not like it's any secret it's happening.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 4 Jul 2018 11:23:41 -0700

> details of the problems seen there.)

Sure. that's a fair question. Kazuho proposed this, so I'd be interested in
his view.

> the current structure is better.)

I think it's bad to provide multiple options that aren't coupled together.
Moreover, from the perspective of the TLS stack, it's actually easier
to have them all bundled.

> forced expiry of not_after - people will just put in 2038 all over,

Note that this is 64 bits, so you can go far past 2038 :)

> New RRTYPEs could always be used for extensions (if new RRTYPEs

I would not be in favor of this. It's trivial to parse and ignore.

> does), we spend a bit of time considering the above issues

Sure, that seems reasonable. I think you are getting to something
important here: my philosophy here is that this should be a more
or less opaque blob which you provide to the TLS stack. So I'm
optimizing for what's convenient for that. I can understand that
others might feel differently.

-Ekr

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 4 Jul 2018 17:25:51 -0400

> On Jul 4, 2018, at 2:20 PM, Eric Rescorla <[email-masked]> wrote:
> 
> Hi Kathleen,
> 
>> On Wed, Jul 4, 2018 at 11:10 AM, Kathleen Moriarty <[email-masked]> wrote:
>> I’m also fine with the work going forward, however it was only in March that EKR assured people concerned that they don’t need to worry about SNI being encrypted repeating similar statements previously made to the same effect.  Meantime, he was working on such a solution. 
> 
> This is not really correct. As of March, I had basically given up on how to do ESNI in TLS the near future and wasn't really working on it [0] and then in May, prompted by suggestions by Matthew Prince and Nick Sullivan, I realized that the proposal in this document could work.
> 
> Moreover, I think I've been pretty clear that I wanted to do ESNI and it was just that we didn't know how. For instance, here's what I said in PATIENT:
> 
>    current technical state, it will not see particularly wide deployment, with
>    the primary scenario being "at-risk" sites who are subject to censorship who
>    censorship. That probably isn't going to be incredibly common right now. Of
>    course, this is regrettable from the perspective of people designing these
> As I said the other day, predictions are hard, especially about the future, and this turns out not to have been totally right (though I also don't think it's really accurate to characterize it as my saying that people don't need to worry). I'm sorry if people people are surprised now. That wasn't my intent, but as I said above, I was surprised too!
> 

Well, the messages on the Effects of Pervasive Encryption for Operators also factored into my response.  You wanted that text removed and we refused (rightly so).  You also had someone write a blog to have a reference that talked about it’s wide deployment.  The perception is from multiple interactions and I favor transparency.

Best,
Kathleen 

> -Ekr
> 
> [0] Just to be completely clear, there was and is ongoing work on protecting SNI via HTTP connection coalescence (see Mike Bishop's presentation in London), but that's a different flavor of approach, and it's not like it's any secret it's happening.
> 
> 
>  
>> Kathleen 
>> 
>> > 
>> > Cheers,
>> > S.
>> > 
>> > 
>> >> 
>> >> -Ekr
>> >> 
>> >> 
>> >>

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 5 Jul 2018 10:29:06 +0900

> Sure. that's a fair question. Kazuho proposed this, so I'd be interested in

IMO, when used, ESNIKeys is part of the handshake, and therefore
deserves (at least) the same level of end-to-end integrity protection
as what is provided by TCP.

ESNIKeys becomes part of the handshake in the following sense:

* a corrupt ESNIKeys will cause the handshake to fail
* ENSIKeys is used to negotiate the use of a TLS extension
* the value of ESNIKeys is part of the handshake transcript though
`EncryptedSNI.record_digest` which is a full digest of ESNIKeys, much
like the 1st CH when HRR is involved

TLS records (even the non-encrypted ones) are resistant to accidental
corruption thanks to the integrity check provided by TCP. OTOH,
ESNIKeys is transmitted though DNS authoritative server (by setting up
the DNS record either automatically or by hand), then a recursive
resolver, then a stub resolver, before reaching the client.

As Stephen says, some resolvers (e.g. home routers) could be the
source of corruption of DNS records. But even if we bypass them by
using DoH or DNS over TLS, the lack of end-to-end integrity check will
still be an issue. Corruption could for example happen when the record
is installed to the authoritative server, or when they are stored (or
cached) within the resolvers.

Considering the varying degree of the reliability provided by the
multiple parties involved in forwarding the ESNIKeys as DNS records,
my perception has been that it is a good idea to have end-to-end
integrity protection.

> to have them all bundled.

I also prefer them to be bundled, because it makes us easier and
faster to detect downgrade attacks.

Current draft uses a full digest of ENSIKeys (i.e.
`EncryptedSNI.record_digest`) to identify the ESNIKeys being used. If
a middlebox drops some key-share from ESNIKeys, the server will fail
to identify the ESNIKeys being used, and the handshake fails. This
would be the case even when DNSSEC is _not_ used.

If we use different DNS record for every key-share being negotiated,
the client will be required to wait for the response of all the
queries it has sent (more likely to suffer from delays), and there
will be no protection against a downgrade attack when DNSSEC is not
used.

> Note that this is 64 bits, so you can go far past 2038 :)

FWIW, the intent of having not_after in the draft is to avoid issues
when a DNS authoritative server and the TLS server (i.e. the entity
that generates the ESNIKeys) get out-of-sync [1].

When the TLS server rotates the ESNIKeys (which should happen
frequently), it needs to make sure that all the authoritative servers
receive the update. If that attempt fails, we'd rather fallback to
plaintext SNI rather than seeing handshake failures. Minimizing (or
nullifying) the increased chance of seeing handshake failures is
important for ESNI, because we want as many domains as possible (even
those that are not strongly interested in having their SNI protected)
to participate in the effort; otherwise, the domains using ESNI will
"stick out" [2].

However, DNS as a standard does not provide a way to set absolute
expiration dates. Not only the responses to queries but also AFXR
carries only the TTL. Therefore, an out-of-sync authoritative server
will continue to respond with the outdated ESNIKeys. The fact makes it
harder for server administrators to manage the keys.

To summarize, what we want is consistency (stop sending valid ESNIKeys
when authoritative servers get out-of-sync) over availability
(continue sending ESNIKeys when out-of-sync), which is contrary to
what DNS tries to provide.

Considering that and also the fact that we might want to distribute
ESNIKeys using methods other than DNS, I think it is a good idea to
have not_after (and not_before) in the specification.

[1] https://github.com/ekr/draft-rescorla-tls-esni/pull/23
[2] https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-03#section-3.4

>> Sure, but I hope we consider dropping 'em if there's no need..

-- 
Kazuho Oku

---

From: "Short, Todd" <[email-masked]>
Date: Fri, 6 Jul 2018 19:55:12 +0000

Fundamentally, unless this type of protection is baked into the protocol from the beginning, and is not an add-on option, any one/thing in the path can prevent the use of optional security features.

Don’t want people to access site XYZ? Block DNSSEC, block _ESNI DNS requests/responses, block the use of ESNI, etc.

A firewall can also use the record_digest to determine the destination, without even decrypting the ESNI. It just calculates the possible record_digests of the blocked sites; since the information is public. This will make it appear that ESNI is supported (for legal sites), but still block the use to illegal sites.

Or even do a reverse-DNS lookup on the destination IP, discover all the domains there, and then calculate the possible record_digests to see where the user is going.

This could be mitigated by having the same ESNIKeys for different websites, but that means the "Split Mode Topology" is broken as the record_digest cannot be used by the Client-Facing Server to select a Backend Server. Ah, but if the CDN maps the shared-ESNIKeys domains to be different IPs, then doesn’t matter. This is not the case, as the IP address can now be used along with the ESNIKeys to know what the final destination is.

--
-Todd Short
// [email-masked]<mailto:[email-masked]>
// "One if by land, two if by sea, three if by the Internet."

On Jul 3, 2018, at 10:26 AM, Sniffen, Brian <bsniffen=[email-masked]<mailto:bsniffen=[email-masked]>> wrote:

Looks neat.

--
Brian Sniffen

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 6 Jul 2018 13:42:31 -0700

On Fri, Jul 6, 2018 at 12:55 PM, Short, Todd <[email-masked]> wrote:

> Fundamentally, unless this type of protection is baked into the protocol
> from the beginning, and is not an add-on option, any one/thing in the path
> can prevent the use of optional security features.
>
> Don’t want people to access site XYZ? Block DNSSEC, block _ESNI DNS
> requests/responses, block the use of ESNI, etc.
>

These are sort of different things. It's true that if you control DNS, it's
basically game over, which is why this is most attractive with DOH to some
location not controlled by the censor. However, if you *do* have DOH, then
the client shouldn't fall back, with the result that blocking ESNI blocks
all ESNI-enabled sites, not just those which are sensitive

> A firewall can also use the record_digest to determine the destination,
> without even decrypting the ESNI. It just calculates the possible
> record_digests of the blocked sites; since the information is public. This
> will make it appear that ESNI is supported (for legal sites), but still
> block the use to illegal sites.
>
> Or even do a reverse-DNS lookup on the destination IP, discover all the
> domains there, and then calculate the possible record_digests to see where
> the user is going.
>
> This could be mitigated by having the same ESNIKeys for different
> websites, but that means the "Split Mode Topology" is broken as the
> record_digest cannot be used by the Client-Facing Server to select a
> Backend Server.
>

I think you may be misunderstanding the design here. All of the
ESNI-enabled sites behind the same client-facing server (split mode or not)
use the same keys, and hence have the same record_digest. Thus,
record_digest is just an alias for anonymity set. The client-facing server
does not use the record_digest to select the backend server. It uses the
record_digest to find which of the keys it has offered and then uses that
key to decrypt the true SNI. Note that in some naive sense you don't need a
record_digest at all. It's just there to facilitate the client-facing
server having multiple valid ESNI key sets (e.g., for rollover) at one time.

Ah, but if the CDN maps the shared-ESNIKeys domains to be different IPs,
> then doesn’t matter. This is not the case, as the IP address can now be
> used along with the ESNIKeys to know what the final destination is.
>

Yes, you need to use the same IPs.

-Ekr

> // [email-masked]
> On Jul 3, 2018, at 10:26 AM, Sniffen, Brian <bsniffen=40akamai.com@dmarc.
> ietf.org> wrote:
>
> Looks neat.
>
> hosts is 20 bits, and the nonuniformity will accrue to the adversary’s
> benefit. Active probing will unmask visitors to dissident sites.
>

---

From: Brian Sniffen <[email-masked]>
Date: Fri, 06 Jul 2018 17:41:34 -0400

> forcing them to do ESNI decryption doesn't seem like it's that much of an

This is the same worry I had talking about ESNI the first time: if
experiencing a lot of load, a server operator might like to route the
load-generating customers / apps / users to a different set of servers.
To do that, he needs to know which customers / apps / users are inviting
the load.  Is this a flash crowd to exampleA.com or exampleB.com?
Having to do crypto to determine that makes it *much* more expensive.
It rules out a bunch of ways of doing it on a separate device that
doesn't have the decryption key.

I guess you could put the ESNI key on scrubbing devices (Cisco, Arbor,
Prolexic) and not give them the real TLS keys?  That takes away the
routability test---they just test a sample of what's on the wire, but
that's probably okay.

> you have real problems. Can you walk me through the flow you have in mind.

My nation-state operator adversaries typically are MITM-capable.  Hunh.
And yes, I have real problems!  Lucky me.

But to generalize: even if it can't be done at the GFWoC, it's still
dangerous if done a cafe at a time.

> I don't really follow this. Can you explain?

I think it's at most 20 bits strong: the attacker can do a computation
of cost 2^{20}, and crack the anonymity.  It involves 2^{20}
cafe-at-a-time compromises, or 2^{20} operations involving rubber hoses.

But I think it's a *lot* weaker than 2^{20}: the needles of the
adversary's search are not uniformly distributed.  So he can block the
most popular site for a day.  That doesn't take off 1 bit; that takes
off the vast majority of the clients.  If sites are on a power-law
distribution, it gets down to where the remaining 2^5 are rubber-hosable
in just a few experiments.

-Brian

-- 
Brian Sniffen
Akamai Technologies

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 6 Jul 2018 14:51:46 -0700

> doesn't have the decryption key.

Well, the glib answer is "nobody is making you do ESNI". More concretely,
there are plenty of people who have to deal with DoS who don't have
the luxury of segmenting traffic by SNI (e.g., Google), so I'm unpersuaded
that this is a necessary part of DoS defense.

> Prolexic) and not give them the real TLS keys?

Yes, the system is specifically designed to allow this.

> And yes, I have real problems!  Lucky me.

I don't think anything can protect you from attackers who have a trust
anchor
on your machine. That's contrary to the whole TLS threat model.

> dangerous if done a cafe at a time.

Cafes do not generally have trust anchors on your machine.

> cafe-at-a-time compromises, or 2^{20} operations involving rubber hoses.

I'm sorry, I'm not following you. Can you please describe the precise
form of attack you have in mind.

> in just a few experiments
>

I don't follow this either. At this point it would perhaps be helpful if you
drew a diagram or described the attack in a lot more detail.

-Ekr

---

From: "Short, Todd" <[email-masked]>
Date: Sat, 7 Jul 2018 02:17:48 +0000

(Pardon phone typos below.)
--
-Todd Short
// Sent from my iPhone
// "One if by land, two if by sea, three if by the Internet."

On Jul 6, 2018, at 4:43 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Fri, Jul 6, 2018 at 12:55 PM, Short, Todd <[email-masked]<mailto:[email-masked]>> wrote:
Fundamentally, unless this type of protection is baked into the protocol from the beginning, and is not an add-on option, any one/thing in the path can prevent the use of optional security features.

These are sort of different things. It's true that if you control DNS, it's basically game over, which is why this is most attractive with DOH to some location not controlled by the censor. However, if you *do* have DOH, then the client shouldn't fall back, with the result that blocking ESNI blocks all ESNI-enabled sites, not just those which are sensitive

Which makes this mechanism potentially useless. If it was mandatory in TLSv1.3, then trying to block encrypted SNI would be break a lot more sites, and might have to be allowed.

This could be mitigated by having the same ESNIKeys for different websites, but that means the "Split Mode Topology" is broken as the record_digest cannot be used by the Client-Facing Server to select a Backend Server.

I think you may be misunderstanding the design here. All of the ESNI-enabled sites behind the same client-facing server (split mode or not) use the same keys, and hence have the same record_digest. Thus, record_digest is just an alias for anonymity set. The client-facing server does not use the record_digest to select the backend server. It uses the record_digest to find which of the keys it has offered and then uses that key to decrypt the true SNI. Note that in some naive sense you don't need a record_digest at all. It's just there to facilitate the client-facing server having multiple valid ESNI key sets (e.g., for rollover) at one time.

It's implied that record_digest is/can be used to select the "origin server". If not, then the wording should be clarified.

Again, because this is optional, the (initial) set of servers that use ESNI will be small, and can be reasonably determined. The anonymity set, at the least, can be reduced by destination address via reverse-DNS. CDNs will resolve domains to different IPs (on various metrics) which could leak information to help narrow down the actual domain. So, it still can expose a set of possible destination domains that the user is attempting to reach.

My fear is that there's enough potential leakage that something should be mentioned in security considerations.

Ah, but if the CDN maps the shared-ESNIKeys domains to be different IPs, then doesn’t matter. This is not the case, as the IP address can now be used along with the ESNIKeys to know what the final destination is.

-Ekr

Looks neat.

--
Brian Sniffen

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=jO6FtGxHwI8V5rcKNJJ3nyWt30nuYRxDsMw4SrDjQv8&s=ugN6SXThjZ5obqv2V3Ved7ilhh8n8gXdFsOVajJ9zR0&e=>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 6 Jul 2018 19:43:12 -0700

On Fri, Jul 6, 2018 at 7:17 PM, Short, Todd <[email-masked]> wrote:

> On Jul 6, 2018, at 4:43 PM, Eric Rescorla <[email-masked]> wrote:
>
>
>
> These are sort of different things. It's true that if you control DNS,
> it's basically game over, which is why this is most attractive with DOH to
> some location not controlled by the censor. However, if you *do* have DOH,
> then the client shouldn't fall back, with the result that blocking ESNI
> blocks all ESNI-enabled sites, not just those which are sensitive
>
>
> Which makes this mechanism potentially useless. If it was mandatory in
> TLSv1.3, then trying to block encrypted SNI would be break a lot more
> sites, and might have to be allowed.
>

I'm not sure I agree with this, but I also don't see a lot of point in
debating it.

> It's implied that record_digest is/can be used to select the "origin
> server". If not, then the wording should be clarified.
>

I'm not sure where you're getting this from. Here's the text in question:

"   o  If the EncryptedSNI.record_digest value does not match the
      cryptographic hash of any known ENSIKeys structure, it MUST abort
      the connection with an "illegal_parameter" alert.  This is
"

Anyway, if you think this should be clarified, please feel free to submit a
PR.

> Again, because this is optional, the (initial) set of servers that use
> ESNI will be small, and can be reasonably determined.The anonymity set, at
> the least, can be reduced by destination address via reverse-DNS. CDNs will
> resolve domains to different IPs (on various metrics) which could leak
> information to help narrow down the actual domain. So, it still can expose
> a set of possible destination domains that the user is attempting to reach.
>

Yes, it's true that the client-facing servers need to take steps to put
people in the same anonymity set on the same IP. In general, we have a pile
of sources of privacy leakage (cert in the TLS handshake, DNS, SNI, IP
addr, traffic analysis, etc.). In order to make any progress, we're going
to need to tackle them one at a time.

My fear is that there's enough potential leakage that something should be
> mentioned in security considerations.
>

Again, PR welcome.

-Ekr

>> On Jul 3, 2018, at 10:26 AM, Sniffen, Brian <
>> bsniffen=[email-masked]> wrote:
>>
>> Looks neat.
>>
>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tls&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=QBEcQsqoUDdk1Q26CzlzNPPUkKYWIh1LYsiHAwmtRik&m=jO6FtGxHwI8V5rcKNJJ3nyWt30nuYRxDsMw4SrDjQv8&s=ugN6SXThjZ5obqv2V3Ved7ilhh8n8gXdFsOVajJ9zR0&e=>
>>
>>
>>
>