Subject: [dns-privacy] Fwd: New Version Notification for draft-annee-dprive-oblivious-dns-00.txt

From: Allison Mankin <[email-masked]>
Date: Tue, 3 Jul 2018 17:39:32 -0400

DPRIVE-ites,

Please take a look at a new individual internet-draft we will introduce at
the Montreal DPRIVE meeting, targeted eventually for Experimental.

Its novelty is that it meets a strong privacy goal: that no single party
should be able to associate DNS queries with a client IP address that
issues those queries.  We are looking forward to all comments and reviews
both in email in and in person.

Thanks!

Nick and Allison for the authors

> A new version of I-D, draft-annee-dprive-oblivious-dns-00.txt
> has been successfully submitted by Allison Mankin and posted to the
> IETF repository.
>
> Name:           draft-annee-dprive-oblivious-dns
> Revision:       00
> Title:          Oblivious DNS - Strong Privacy for DNS Queries
> Document date:  2018-07-02
> Group:          Individual Submission
> Pages:          11
> URL:            https://www.ietf.org/internet-
> drafts/draft-annee-dprive-oblivious-dns-00.txt
> Status:         https://datatracker.ietf.org/
> doc/draft-annee-dprive-oblivious-dns/
> Htmlized:       https://tools.ietf.org/html/d
> raft-annee-dprive-oblivious-dns-00
> Htmlized:       https://datatracker.ietf.org/
> doc/html/draft-annee-dprive-oblivious-dns
>
>
> Abstract:
>    Recognizing the privacy vulnerabilities associated with DNS queries,
>    a number of standards have been developed and services deployed that
>    that encrypt a user's DNS queries to the recursive resolver and thus
>    obscure them from some network observers and from the user's Internet
>    service provider.  However, these systems merely transfer trust to a
>    third party.  We argue that no single party should be able to
>    associate DNS queries with a client IP address that issues those
>    queries.  To this end, this document specifies Oblivious DNS (ODNS),
>    which introduces an additional layer of obfuscation between clients
>    and their queries.  To accomplish this, ODNS uses its own
>    authoritative namespace; the authoritative servers for the ODNS
>    namespace act as recursive resolvers for the DNS queries that they
>    receive, but they never see the IP addresses for the clients that
>    initiated these queries.  The ODNS experimental protocol is
>    compatible with existing DNS infrastructure.
>

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 3 Jul 2018 18:18:51 -0400

I'm glad this is coming to DPRIVE.

My main question for the authors is: how does this compare to routing a
DNS-over-TLS socket through a TCP forwarder?  It seems to me that a TCP
forwarder (operated by a separate party from the DNS-over-TLS recursive)
would offer a similar level of privacy protection as ODNS, but with
off-the-shelf software and at lower CPU cost (better amortization of
public-key operations).

On Tue, Jul 3, 2018 at 5:39 PM Allison Mankin <[email-masked]>
wrote:

>> URL:
>> https://www.ietf.org/internet-drafts/draft-annee-dprive-oblivious-dns-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-annee-dprive-oblivious-dns/
>> Htmlized:
>> https://tools.ietf.org/html/draft-annee-dprive-oblivious-dns-00
>> Htmlized:
>> https://datatracker.ietf.org/doc/html/draft-annee-dprive-oblivious-dns
>>
>>
>> Abstract:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 14 Jul 2018 20:27:39 -0400

On Tue, Jul 03, 2018 at 06:18:51PM -0400,
 Ben Schwartz <bemasc=[email-masked]> wrote 
 a message of 293 lines which said:

> My main question for the authors is: how does this compare to
> routing a DNS-over-TLS socket through a TCP forwarder?

Isn't it what Tor is doing? Reasons to use Tor:

* well known and studied, privacy-wise
* there is even a public DoH resolver in .onion
  <https://blog.cloudflare.com/welcome-hidden-resolver/>

My first feeling about Oblivious DNS is that it looks like a
reinvention of Tor, specific to the DNS.

---

From: Nick Feamster <[email-masked]>
Date: Sat, 14 Jul 2018 21:13:56 -0400

> On Jul 14, 2018, at 8:27 PM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Quite a different thing entirely.  

A few notes:
1. Tor is vulnerable to DNS fingerprinting, particularly at the recursive resolver. Many Tor exits use Google public DNS (~40%, by exit throughput), making re-identification possible.  See our paper on this:
  https://arxiv.org/abs/1609.08187

2. Tor users pay a significant performance cost vs. ODNS.

3. Tor and .onion in particular have some pretty serious usability problems.  See our recent study on that:
  https://arxiv.org/abs/1806.11278
  Quite a bit easier to run ODNS, and it can be done per domain, as well, as opposed to all or nothing.

I could go on.  Basically: not the same thing at all.

-Nick

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 14 Jul 2018 21:27:47 -0400

On Sat, Jul 14, 2018 at 09:13:56PM -0400,
 Nick Feamster <[email-masked]> wrote 
 a message of 40 lines which said:

> 1. Tor is vulnerable to DNS fingerprinting, particularly at the
> recursive resolver. Many Tor exits use Google public DNS (~40%, by
> exit throughput),

I know this research but I don't see the point. You typically connect
to your DoH or DoT resolver by IP address so the resolver used by the
exit node is irrelevant.

(Also, if you use a .onion, there is no exit node.)

> 3. Tor and .onion in particular have some pretty serious usability
> problems.

Users typically don't interact directly with their DNS resolver,
unlike they like to use dig so, again, I don't see how it is related
to the problem.

---

From: Nick Feamster <[email-masked]>
Date: Sat, 14 Jul 2018 21:35:33 -0400

> On Jul 14, 2018, at 9:27 PM, Stephane Bortzmeyer <[email-masked]> wrote:
> 

The work shows how intersection attacks are possible with the client IP.

> unlike they like to use dig so, again, I don't see how it is related

Exactly. They do, however, interact with the Tor Browser (and not well), and that’s exactly the point.

-Nick

---

From: Ben Schwartz <[email-masked]>
Date: Sat, 14 Jul 2018 21:43:26 -0400

On Sat, Jul 14, 2018 at 8:30 PM Stephane Bortzmeyer <[email-masked]>
wrote:

> Isn't it what Tor is doing?

For the record, I'm proposing something much _weaker_ than Tor: a TCP
packet forwarder relaying a DNS-over-TLS stream.  It seems to me that this
matches Oblvious DNS's security components: a non-transforming element (TCP
forwarder, recursive resolver) to obscure the client IP, and then a
cryptographic element (DPRIVE resolver, Oblivious DNS resolver) to decrypt
the query without knowledge of the true source.

I would be interested in understanding why the authors don't find this
sufficient, especially since (unlike Tor) it's compatible with deployed
DNS-over-TLS clients like Stubby.

(I suspect they might object to the multi-query session semantics, or the
wide variety of TLS ClientHellos, but I don't actually know.)

> Reasons to use Tor:

---

From: Nick Feamster <[email-masked]>
Date: Sun, 15 Jul 2018 10:20:22 -0400

> On Jul 14, 2018, at 9:43 PM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> For the record, I'm proposing something much _weaker_ than Tor: a TCP packet forwarder relaying a DNS-over-TLS stream.  It seems to me that this matches Oblvious DNS's security components: a non-transforming element (TCP forwarder, recursive resolver) to obscure the client IP, and then a cryptographic element (DPRIVE resolver, Oblivious DNS resolver) to decrypt the query without knowledge of the true source.
> 

Yes, absolutely, this is a lot closer to the guarantees we’re going for. You’ve captured the spirit and the design goals. :-)

> I would be interested in understanding why the authors don't find this sufficient, especially since (unlike Tor) it's compatible with deployed DNS-over-TLS clients like Stubby.
> 
> (I suspect they might object to the multi-query session semantics, or the wide variety of TLS ClientHellos, but I don't actually know.)

A reasonable idea, definitely.

It strikes me that there will definitely be more overhead unless you’re pipelining queries on the connection, of course. We haven’t tried this, but I also wonder what happens to the TLS handshake if the IP address is rewritten through the forwarder.

It does seem like a reasonable design alternative to consider and evaluate against.  Are you here at the Hackathon today?  We can/should chat a little bit.  I’m sitting near the front.

-Nick

---

From: Ben Schwartz <[email-masked]>
Date: Sun, 15 Jul 2018 17:08:12 -0400

OK, I implemented this using a very simple systemd-system-proxyd config,
which took less time than writing this e-mail.  You can try it at
104.196.109.96:853, with a TLS authentication name of "dns.quad9.net".  If
you run DNS over TLS to that machine, you can verify that your queries are
going to Quad9, but they'll see my machine's IP, not yours.

Some other thoughts:
If deployed at scale, this approach would create some interesting questions
around rate limiting and DDOS defense.  Oblivious DNS has an advantage here.

This could be compatible with "name only" DPRIVE clients (like Android), if
the backend domain owner creates a subdomain that resolves to the
forwarder's IP and is covered by the backend cert.  This requires a lot of
trust in the backend domain owner, who could change the subdomain to their
own IP at any time.

Session Tickets and ClientHello Fingerprinting seem important.

A pervasive surveillance adversary can defeat these approaches pretty
easily.  Defending against that would probably require another layer of
encryption, as well as agreed-upon padding discipline and a delay strategy.

On Sun, Jul 15, 2018 at 10:20 AM Nick Feamster <[email-masked]>
wrote:

> Yes, absolutely, this is a lot closer to the guarantees we’re going for.
> You’ve captured the spirit and the design goals. :-)
>
> > (I suspect they might object to the multi-query session semantics, or
> the wide variety of TLS ClientHellos, but I don't actually know.)
>
> It strikes me that there will definitely be more overhead unless you’re
> pipelining queries on the connection, of course. We haven’t tried this, but
> I also wonder what happens to the TLS handshake if the IP address is
> rewritten through the forwarder.
>
> It does seem like a reasonable design alternative to consider and evaluate
> against.  Are you here at the Hackathon today?  We can/should chat a little
> bit.  I’m sitting near the front.
>
> -Nick
>
>
>

---

From: Tony Finch <[email-masked]>
Date: Mon, 16 Jul 2018 15:21:18 +0100

> wide variety of TLS ClientHellos, but I don't actually know.)

Multi-query sessions are much less objectionable than one-shot sessione:
you amortize both the session setup crypto costs and the latency. (If you
have a browser-like spikey query profile then sessions don't need much
idle time to win.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
reject all prejudice and discrimination based upon race, colour,
religion, age, disability, gender, or sexual orientation

---

From: Paul Wouters <[email-masked]>
Date: Mon, 16 Jul 2018 10:27:36 -0400 (EDT)

> have a browser-like spikey query profile then sessions don't need much

Not from a privacy point of view. Me opening my laptop with 15 browser tabs
is basically guaranteed to fingerprint me completely.

There are of course other mitigations (no cache flush between network
switching, prefetching, etc) and I don't think the user can afford every
single DNS query to start its own TCP connection, but not allowing one
shot sessions would be rather drastic.

Paul

---

From: 神明達哉 <[email-masked]>
Date: Tue, 24 Jul 2018 16:32:03 -0700

On Tue, Jul 3, 2018 at 2:39 PM Allison Mankin <[email-masked]> wrote:

> Please take a look at a new individual internet-draft we will
> introduce at the Montreal DPRIVE meeting, targeted eventually for
> Experimental.

I've read draft-annee-dprive-oblivious-dns-00.  At a high level I
found the idea interesting: decoupling DNS query details from client's
source IP address.  On the other hand the current version of the draft
lacks many necessary details to actually implement the idea, and
(maybe partly because of that) I have questions on its technical
details and deployability.  So at this moment I'm not sure if I
support this particular protocol for eventual WG adoption or
publication.

Some specific points follow:

- I hope the next version will specify at least the following details
  as a protocol specification, that is, in a way that someone can
  write an interoperable implementation just by reading it:
  + how to build (including encryption) the obfuscated query name
  + how to include the encrypted session key in the query (assuming
    it's an EDNS option, with a specific option format)
  + how to exchange the ODNS server's public key (ditto)

- the current version of the draft seems to intend to use EDNS options
  for exchanging session and public keys, and expect intermediate
  recursive servers to "forward" the options to ODNS authoritative
  servers.  But since EDNS is a hop-by-hop protocol, you cannot just
  assume such a behavior; it must be part of the protocol
  specification in, e.g., a "recursive server behavior" section (this
  is what I tried to say at the mic in the meeting).  And then it
  means we need to update all relevant recursive servers for ODNS to
  work, so I suspect this claim of section 2 is a bit too strong:
  "ODNS operates in the context of the existing DNS protocol, allowing the
  existing deployed infrastructure to remain unchanged".

- If we use a (set of?) well-known domain suffixes to distinguish
  ODNS-encrypted qnames from other general names, and if the basic
  motivation is that we really don't trust the recursive server
  operators, then I'm afraid we should also worry about those
  operators "blocking" these suffixes.  If they are well-known it's
  pretty easy, and many commercial operators already have and use a
  framework (such as RPZ) to make it possible.

- In Section 3 the draft refers to ECS and states: "ODNS hides a
  client's IP address from the authoritative name servers at different
  levels of the DNS hierarchy".  But ECS already provides a
  privacy-conscious client with a way to hide it address from
  authoritative servers, so it doesn't seem to be a particular
  advantage of ODNS.

- I'm afraid we need more careful assessment on scalability issues.
  The current draft mentions anycast for scalability concerns.  It may
  work, but unlike other anycast authoritative servers in the DNS,
  ODNS authoritative servers need to handle queries for the entire
  name space (they can't just "delegate" the load); and unlike other
  anycast recursive servers an ODNS anycast instance needs to handle all
  (essentially) recursive queries in that anycast domain.  It may
  still work, but it doesn't seem to be so obvious to me.  (In the end
  we may not be able to be sure until we have large scale
  experiments).

--
JINMEI, Tatuya