Re: [dns-privacy] Oblivious DNS

[Hugo Connery]

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!





___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Oblivious DNS

[Warren Kumari]

On Mon, Apr 9, 2018 at 2:43 PM, Christian Huitema  wrote:
> On 4/9/2018 11:00 AM, Warren Kumari wrote:
>
> On Mon, Apr 9, 2018 at 1:53 PM Christian Huitema 
> 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?
>
>
> 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..
>
>
> 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".
>
> 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
>
>



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

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Oblivious DNS

[Shumon Huque]

On Mon, Apr 9, 2018 at 2:16 PM, Bill Woodcock  wrote:

>
>
> > On Apr 9, 2018, at 10:59 AM, Shumon Huque  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?
>

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.
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Oblivious DNS

[Bill Woodcock]

> On Apr 9, 2018, at 10:59 AM, Shumon Huque  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



signature.asc
Description: Message signed with OpenPGP
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Oblivious DNS

[Warren Kumari]

On Mon, Apr 9, 2018 at 1:53 PM Christian Huitema 
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?
>

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



>
> -- Christian Huitema
>
> On Apr 9, 2018, at 10:25 AM, Allison Mankin 
> 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
>
> On 9 April 2018 at 18:20, Daniel Kahn Gillmor 
> wrote:
>
>> 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
>>
>> ___
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
-- 
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
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Oblivious DNS

[Shumon Huque]

On Mon, Apr 9, 2018 at 1:53 PM, Christian Huitema 
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
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Oblivious DNS

[Christian Huitema]

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  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
> 
>> On 9 April 2018 at 18:20, Daniel Kahn Gillmor  wrote:
>> 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
>> 
>> ___
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
> 
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Oblivious DNS

[Allison Mankin]

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  wrote:

> 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
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Oblivious DNS

[Daniel Kahn Gillmor]

On Mon 2018-04-09 13:20:28 -0400, Daniel Kahn Gillmor wrote:
> People on this list might be interested in the recent "Oblivious DNS"
> 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

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Potential re-charter text

[Tony Finch]

Let's retry the tests with a hot cache, since that's maybe a bit more
fair. I've picked the shortest times I could get, which involved heating
up the resolver until it was no longer waiting 10s or 30s on lame
authoritative servers.

Unbound 1.6.0 TCP 8s
Unbound 1.6.0 UDP 0.4s
BIND 9.11 TCP 0.5s
BIND 9.11 UDP 0.5s
BIND 9.10 TCP 3s
BIND 9.10 UDP 0.5s
1.1.1.1 TCP 0.5s
1.1.1.1 UDP 0.4s
8.8.8.8 TCP 5s # drops connection after 60 queries
8.8.8.8 UDP 220s # it hates me
9.9.9.9 TCP 1s
9.9.9.9 UDP 3s
64.6.64.6 TCP 0.5s
64.6.64.6 UDP 0.5s

Tony.
-- 
f.anthony.n.finch    http://dotat.at/
Trafalgar: Cyclonic gale 7 to severe gale 9, occasionally storm 10 for a time
in northwest, becoming northwesterly 5 to 7 later. Very rough or high,
occasionally very high for a time in west, becoming rough or very rough later.
Rain or showers. Good, occasionally poor.

___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy

Re: [dns-privacy] Potential re-charter text

[Erik Kline]

Charter 2.1 looks fine to me.

On 5 April 2018 at 12:44, Brian Haberman  wrote:
> Tim & I are still looking for feedback on this updated charter. Please
> chime in or we will have to close the WG down.
>
> Brian
>
>
> On 3/21/18 9:44 AM, Brian Haberman wrote:
>> Slightly updated text to capture a missing work item...
>>
>> https://github.com/DPRIVE/wg-materials/blob/master/dprive-charter-2.1.txt
>>
>> Regards,
>> Brian
>>
>> On 3/19/18 11:07 AM, Brian Haberman wrote:
>>> All,
>>>  The chairs have been chatting with our AD about re-chartering the
>>> WG. The text below is our proposed charter that we will discuss in our
>>> session this week.
>>>
>>> Regards,
>>> Brian & Tim
>>>
>>>
>>> DPRIVE Charter 2.0
>>>
>>> The DNS PRIVate Exchange (DPRIVE) Working Group develops mechanisms to
>>> provide confidentiality to DNS transactions in order to address concerns
>>> surrounding pervasive monitoring (RFC 7258).
>>>
>>> The set of DNS requests that an individual makes can provide an attacker
>>> with a large amount of information about that individual.  DPRIVE aims
>>> to deprive the attacker of this information (The IETF defines pervasive
>>> monitoring as an attack [RFC7258]).
>>>
>>> The initial focus of this Working Group was the development of
>>> mechanisms that provide confidentiality and authentication between DNS
>>> Clients and Iterative Resolvers (published as RFCs 7858 and 8094). With
>>> proposed standard solutions for the client-to-iterative resolvers
>>> published, the working group turns its attention to the development of
>>> documents focused on: 1) providing confidentiality to DNS transactions
>>> between Iterative Resolvers and Authoritative Servers, and 2) measuring
>>> the performance of the proposed solutions against pervasive monitoring.
>>> Some of the results of this working group may be experimental. There are
>>> numerous aspects that differ between DNS exchanges with an iterative
>>> resolver and exchanges involving DNS root/authoritative servers. The
>>> working group will work with DNS operators and developers (via the DNSOP
>>> WG) to ensure that proposed solutions address key requirements.
>>>
>>> DPRIVE is chartered to work on mechanisms that add confidentiality to
>>> the DNS. While it may be tempting to solve other DNS issues while adding
>>> confidentiality, DPRIVE is not the working group to do this.  DPRIVE
>>> will not work on any integrity-only mechanisms.  Examples of the sorts
>>> of risks that DPRIVE will address can be found in [RFC 7626], and
>>> include both passive wiretapping and more active attacks, such as MITM
>>> attacks. DPRIVE will address risks to end-users' privacy (for example,
>>> which websites an end user is accessing).
>>>
>>> DPRIVE Work Items:
>>>
>>> - Develop requirements for adding confidentiality to DNS exchanges
>>> between recursive resolvers and authoritative servers (unpublished
>>> document).
>>>
>>> - Investigate potential solutions for adding confidentiality to DNS
>>> exchanges involving authoritative servers (Experimental).
>>>
>>> - Define, collect and publish performance data measuring effectiveness
>>> of DPRIVE-published technologies against pervasive monitoring attacks.
>>>
>>>
>>>
>>> ___
>>> dns-privacy mailing list
>>> dns-privacy@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>>
>>
>>
>>
>> ___
>> dns-privacy mailing list
>> dns-privacy@ietf.org
>> https://www.ietf.org/mailman/listinfo/dns-privacy
>>
>
>
> ___
> dns-privacy mailing list
> dns-privacy@ietf.org
> https://www.ietf.org/mailman/listinfo/dns-privacy
>


smime.p7s
Description: S/MIME Cryptographic Signature
___
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy