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

[Brian Haberman]

All,
 Thanks for the feedback. Tim and I will add some milestones to the
proposed charter and get it to our illustrious AD for review/handling.

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



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

Re: [dns-privacy] Oblivious DNS

[Shumon Huque]

On Tue, Apr 10, 2018 at 6:05 AM, Tony Finch  wrote:

> Willem Toorop  wrote:
> >
> > ODNS queries could be nested.  I.e.
> >
> > {{{www.foo.bar}k.odns.google.com}k.odns.quad9.net}k.odns.cloudflare.com
>
> OnionDNS :-)
>

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

Re: [dns-privacy] Oblivious DNS

[Tony Finch]

Willem Toorop  wrote:
>
> ODNS queries could be nested.  I.e.
>
> {{{www.foo.bar}k.odns.google.com}k.odns.quad9.net}k.odns.cloudflare.com

OnionDNS :-)

Tony.
-- 
f.anthony.n.finch    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.

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

Re: [dns-privacy] Oblivious DNS

[Willem Toorop]

Op 09-04-18 om 20:16 schreef 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.

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.



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