Subject: [dns-privacy] Oblivious DNS

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 09 Apr 2018 13:20:28 -0400

hey DPRIVE folks--

People on this list might be interested in the recent "Oblivious DNS"
work from Annie Edmundson, Paul Schmitt, and Nick Feamster:

https://freedom-to-tinker.com/2018/04/02/a-privacy-preserving-approach-to-dns/

https://odns.cs.princeton.edu/

This was presented at DNS-OARC 28 in March 2018.

     --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 09 Apr 2018 13:24:25 -0400

On Mon 2018-04-09 13:20:28 -0400, Daniel Kahn Gillmor wrote:
> work from Annie Edmundson, Paul Schmitt, and Nick Feamster

gah, i left off Jennifer Rexford from the list of researchers -- no
slight was intended by the oversight.

       --dkg

---

From: Allison Mankin <[email-masked]>
Date: Mon, 9 Apr 2018 18:25:30 +0100

Annie, Nick and Paul all plan to be at the Hackathon and the IETF in
Montreal.  This is work I'm also involved in, and we are working on an i-d
for DPRIVE, to come soon.

Allison

On 9 April 2018 at 18:20, Daniel Kahn Gillmor <[email-masked]> wrote:

> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 9 Apr 2018 10:53:34 -0700

At first sight, it seems that this moves the logging hole from the DNS recursive to the ODNS recursive, and that's a meh.

Also, instead of using a complicated tunneling through the recursive resolver via name obfuscation, why not establish a secure connection to the ODNS server in the first place?

-- Christian Huitema 

> On Apr 9, 2018, at 10:25 AM, Allison Mankin <[email-masked]> wrote:
> 
> Annie, Nick and Paul all plan to be at the Hackathon and the IETF in Montreal.  This is work I'm also involved in, and we are working on an i-d for DPRIVE, to come soon.
> 
> Allison
>

---

From: Shumon Huque <[email-masked]>
Date: Mon, 9 Apr 2018 13:59:47 -0400

On Mon, Apr 9, 2018 at 1:53 PM, Christian Huitema <[email-masked]>
wrote:

> At first sight, it seems that this moves the logging hole from the DNS
> recursive to the ODNS recursive, and that's a meh.
>
> Also, instead of using a complicated tunneling through the recursive
> resolver via name obfuscation, why not establish a secure connection to the
> ODNS server in the first place?
>

Because then the DNS client has exposed its network layer identity to the
ODNS server. By sending an encrypted query to the ODNS server, via the
recursive server, the client has allowed the ODNS server to resolve the
name on its behalf without the ODNS server knowing which end system this
name resolution is being performed for.

The ODNS server can still easily collude with recursive server operators to
unmask the clients though, so I'm not sure how much privacy we've really
gained. At some point, it may be reasonable to ask why aren't clients
funneling their queries through a real anonymity network instead, like Tor,
or better.

-- 
Shumon Huque

---

From: Warren Kumari <[email-masked]>
Date: Mon, 09 Apr 2018 18:00:38 +0000

> ODNS server in the first place?

The ODNS server doesn't know the client IP (it gets occluded by the
rescursive server), and the rescursive doesn't know the question. This is
kinda somewhat similar to the Tor model.

This is a fairly common question - I think that the ODNS documents / people
should clarify this better.

W

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Bill Woodcock <[email-masked]>
Date: Mon, 9 Apr 2018 11:16:31 -0700

> On Apr 9, 2018, at 10:59 AM, Shumon Huque <[email-masked]> wrote:
> The ODNS server can still easily collude with recursive server operators to unmask the clients though, so I'm not sure how much privacy we've really gained. At some point, it may be reasonable to ask why aren't clients funneling their queries through a real anonymity network instead, like Tor, or better.

Because Tor has exactly the same problem, but the intelligence agencies already have a ten-year head-start in setting up entry/exit nodes?

Still, I’m with Shumon on this…  It seems like a reasonable thing to do, but it only works as long as the entry and exit nodes are not affiliated…  If it provided any major privacy benefit, folks who wanted to deanonymize the traffic would just pay what it cost to set up both entry and exit nodes, and you’ll be right back in the jam that Tor is in.  So, I’m happy to support it, but it’s a layer of defense-in-depth, not a stand-alone solution.

                                -Bill

---

From: Shumon Huque <[email-masked]>
Date: Mon, 9 Apr 2018 14:40:44 -0400

On Mon, Apr 9, 2018 at 2:16 PM, Bill Woodcock <[email-masked]> wrote:

> > The ODNS server can still easily collude with recursive server operators
> to unmask the clients though, so I'm not sure how much privacy we've really
> Because Tor has exactly the same problem, but the intelligence agencies
> already have a ten-year head-start in setting up entry/exit nodes?
>

Well, that's one of the reasons I said "Tor, or better" :-) There are more
sophisticated anonymity networks, but they suffer from extracting increased
performance and usability costs.

But even considering just plain Tor, I think it's clear that the level of
effort a surveillance adversary has to undertake to compromise DNS privacy
is very significantly more than with ODNS.

Shumon.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 9 Apr 2018 11:43:44 -0700

On 4/9/2018 11:00 AM, Warren Kumari wrote:

> On Mon, Apr 9, 2018 at 1:53 PM Christian Huitema <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     At first sight, it seems that this moves the logging hole from the
>     DNS recursive to the ODNS recursive, and that's a meh.
>
>     Also, instead of using a complicated tunneling through the
>     recursive resolver via name obfuscation, why not establish a
>     secure connection to the ODNS server in the first place?
>
>
> rescursive server), and the rescursive doesn't know the question. This
> is kinda somewhat similar to the Tor model.
>
> This is a fairly common question - I think that the ODNS documents /
> people should clarify this better..

They should really clarify the problem that they are addressing. As
Shumon said, if the goal is to hide the source IP address from the
recursive resolver, then it seems that "DNS over onion routing" would be
easier to engineer and deploy than "oblivious DNS".

They should also clarify the use of symmetric key encryption. Is the
symmetric key specific to a client-server pair, or is shared by the
server with a large group of clients? If the key is specific to a
client, then it identifies the client even if the IP address is hidden.
If the key is widely shared instead, then it takes only one bad client
for the key to leak, and the traffic logs at the recursive DNS can be
de-obfuscated.

From an engineering point of view, I am concerned with applications of
encryption to small size objects like name part or IP addresses. Modern
symmetric algorithms operate on 128 bit blocks, with mainline AEAD
encryption adding 16 bytes of overhead to the object. That's bad enough,
but asymmetric algorithms are even worse. Even if you use Elliptic Curve
crypto, the smallest practical key is 256 bits, or 32 octets. The
overhead will make that impractical. If we happen to need longer keys it
will just not fit in the 63 octets of a domain name part, even if we
found a way to not require Base64 encoding. I am much more confident
that we can solve the engineering issues if we develop an encrypted
transport with onion routing.

-- Christian Huitema

---

From: Warren Kumari <[email-masked]>
Date: Mon, 9 Apr 2018 14:56:57 -0400

On Mon, Apr 9, 2018 at 2:43 PM, Christian Huitema <[email-masked]> wrote:
> should clarify this better..
>
>
> They should really clarify the problem that they are addressing.

Agreed -- I'm not supporting (or trashing!) ODNS, but I've heard the
above question basically every time I've heard ODNS described; seeing
as this is the main differentiator / benefit of ODNS, I think that it
would be good it it were clear(er).

W
>  As Shumon
> said, if the goal is to hide the source IP address from the recursive
> resolver, then it seems that "DNS over onion routing" would be easier to
> engineer and deploy than "oblivious DNS".
>
> symmetric key specific to a client-server pair, or is shared by the server
> with a large group of clients? If the key is specific to a client, then it
> identifies the client even if the IP address is hidden. If the key is widely
> shared instead, then it takes only one bad client for the key to leak, and
> the traffic logs at the recursive DNS can be de-obfuscated.
>
> encryption adding 16 bytes of overhead to the object. That's bad enough, but
> asymmetric algorithms are even worse. Even if you use Elliptic Curve crypto,
> the smallest practical key is 256 bits, or 32 octets. The overhead will make
> that impractical. If we happen to need longer keys it will just not fit in
> the 63 octets of a domain name part, even if we found a way to not require
> Base64 encoding. I am much more confident that we can solve the engineering
> issues if we develop an encrypted transport with onion routing.
>
> -- Christian Huitema
>
>

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Hugo Connery <[email-masked]>
Date: Mon, 9 Apr 2018 22:32:30 +0200

Hi,

Many interesting points, and +1 to "Yes, please clarify your threat
modeling in the i-d which you develop".  ODNS looks interesting,
and the more ideas in the pot the better.

However, lets not forget that we've just "approved" the re-charter.

As I said, years ago, without attacking the recursive to auth layer
all we have done is made DNS's security less than that of Tor (as
a community using any small collection of recursers would be likely
smaller than a Tor exit node).  So, lets welcome new ideas, encourage
their careful expression, improve them were possible, *and* get onto
the recursive to auth layer.  There is likely to be push back from
large auth resolver players against adding encryption.  

However, Tony Finch's recent "here are some numbers" indicates that
this is all doable.  Nice to see BIND gaining next to top spot on their
D(TLS) work with 9.11.  Hats off to ISC, and whoever is working on
that.

One very interesting result there, is that TCP is near to UDP in
response timing.  Thanks to IETF's TLS heroes we can throw TLS 1.3 
derived solutions at the TCP version of recursive to auth, and by
extension of the DTLS stuff too.

Lets be proud of the D(TLS) and padding work, be happy that
implementors are implementing, push forward on recurse to auth and
welcome all the interesting overlay network suggestions which help
in disaggregating the (client net id, query) privacy smash.

There is one subtle(ish) point: encryption solves the mass surveillance
problem, the overlay solutions solve the aggregation problem.

The first really addresses the work post "mass surveillance is an
attack ...".  I think we need *both*.  

Regards,  Hugo

PS: ODNS reminds me a little of Moxie's Convergence.  I like the idea
of having a random round robin of user-selected trusted authoritative
ODNS (or whatever) resolvers in use.  Its like using different internet
search engines over Tor ; spray my quasi-anonymous logs all over the 
place.  I'm apparently in (France, Ukraine, Australia, Brazil, ...) and
my logs are at (Bing, DuckDuckGo, Yahoo, ...) and its all transport 
encrypted.  Try and aggregate that!

---

From: Willem Toorop <[email-masked]>
Date: Tue, 10 Apr 2018 09:22:37 +0200

> Still, I’m with Shumon on this…  It seems like a reasonable thing to do, but it only works as long as the entry and exit nodes are not affiliated…  If it provided any major privacy benefit, folks w…

ODNS queries could be nested.  I.e.

{{{www.foo.bar}k.odns.google.com}k.odns.quad9.net}k.odns.cloudflare.com

You need only one honest, trust-worthy ODNS server to get the privacy
guarantee.

Also, if all the ODNS servers in the nested list would be anycasted,
performance penalty might be quite reasonable.  Something for the
current serious anycasted Private DNS providers to consider perhaps.

---

From: Tony Finch <[email-masked]>
Date: Tue, 10 Apr 2018 11:05:59 +0100

> {{{www.foo.bar}k.odns.google.com}k.odns.quad9.net}k.odns.cloudflare.com

OnionDNS :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
West Fitzroy: Northwesterly 7 to severe gale 9, veering northerly 5 to 7. High
or very high, becoming rough or very rough. Rain or thundery showers. Good,
occasionally poor.

---

From: Shumon Huque <[email-masked]>
Date: Tue, 10 Apr 2018 11:18:12 -0400

> > {{{www.foo.bar}k.odns.google.com}k.odns.quad9.net}k.odns.cloudflare.com

Yeah, that would make it look increasingly more like Tor, so why don't we
just use that instead! :-)

In a sense, I would be pleased to see a new I-D in this general area.
Privacy protection against recursive DNS operators is an area that has been
largely ignored in IETF work. But assuming clients also want privacy from
authoritative servers, I don't see a good solution other than real
anonymity networks.

To continue on that trajectory though, perhaps a logical next step might be
to propose that authoritative DNS operators run one or more nodes as Tor
hidden services (and advertise one or more corresponding onion addresses in
their NS sets). That would take care of the additional leak of DNS queries
via exit nodes. A very powerful adversary could still try to compromise the
network by operating enough guard and middle nodes and hoping their targets
end up using them to build Tor circuits -- but they could still only
identify the endpoints and not the queries. Some mainstream services
(Facebook, New York Times, Duckduckgo, etc) have already deployed onion
services. Maybe DNS operators are next ..

-- 
Shumon Huque

---

From: Lanlan Pan <[email-masked]>
Date: Fri, 13 Apr 2018 07:46:23 +0000

Christian Huitema <[email-masked]>于2018年4月10日周二 上午2:44写道：

> They should really clarify the problem that they are addressing. As Shumon
> identifies the client even if the IP address is hidden. If the key is
> widely shared instead, then it takes only one bad client for the key to
> leak, and the traffic logs at the recursive DNS can be de-obfuscated.
>
> crypto, the smallest practical key is 256 bits, or 32 octets. The overhead
> will make that impractical. If we happen to need longer keys it will just
> not fit in the 63 octets of a domain name part, even if we found a way to
> not require Base64 encoding. I am much more confident that we can solve the
> engineering issues if we develop an encrypted transport with onion routing.
>

I designed another EPT asymmetric tunnel extension in 2017:
https://github.com/abbypan/dns_test_ept

Use EDNS padding to lighten the length limit (but recursive must forward
the padding), use XOR_IP to obscure the A RR.

The problem I want to address seems similar to ODNS.

-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan