Re: [dns-privacy] Deployment issues

[Hugo Maxwell Connery]

Hi,

I hope the WG will start looking at that "next step".

There are resource issues with running TLS to auth servers.

But, that is easily solved: the people who want to do this 
bear the burden, and those that dont get publically shunned
(and possibly dont care).

Hugo Connery

From: dns-privacy [dns-privacy-boun...@ietf.org] on behalf of Dan York 
[y...@isoc.org]
Sent: Thursday, 2 June 2016 20:39
To: Robert Edmonds
Cc: dns-privacy@ietf.org; Christian Huitema
Subject: Re: [dns-privacy] Deployment issues

> On Jun 2, 2016, at 2:11 PM, Robert Edmonds  wrote:
>
> Christian Huitema wrote:
>> Is this part of DPRIVE's charter?
>
>"...but it may also later consider mechanisms that provide
>confidentiality between Iterative Resolvers and Authoritative
>Servers, or provide end-to-end confidentiality of DNS transactions."

Yes, there was a great bit of discussion about this back when DPRIVE formed.  
My recollection is that we decided to focus on the stub resolver to recursive 
resolver *first* because the view was that this would protect the largest 
surface area against attacks. The view was that there were many, many more stub 
resolvers and fewer recursive resolvers.

We also didn't want to "boil the ocean" and wanted to have focused, achievable 
milestones.

To me what Christian is pointing out is that if there is change happening 
within the Internet's infrastructure to increasingly move recursive resolvers 
into the user clients... well... then perhaps the "later" in the charter has 
arrived and it's time to start looking at that next step.

Dan



___
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] Deployment issues

[Hugo Maxwell Connery]

Hi,

I  tried to point this out at the beginning;

  encrypting connections to local caching resolvers 
  without encrypting the auth resolver connection 
  gives the same security as Tor Browser.

But, something is better than nothing.  Better for the world 
having the "I live in an anonymity set" security than none.  

If that set is small, you are hosed.

/Hugo

Or, we need to encrypt the caching to auth connection.
There is no way out of this.

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

Re: [dns-privacy] Deployment issues

[Robert Edmonds]

Christian Huitema wrote:
> Is this part of DPRIVE's charter?

"...but it may also later consider mechanisms that provide
confidentiality between Iterative Resolvers and Authoritative
Servers, or provide end-to-end confidentiality of DNS transactions."

-- 
Robert Edmonds

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

[dns-privacy] Deployment issues

[Christian Huitema]

I have been pondering DNS Privacy issues for some times, and I read with
interest a recent blog by Geoff Huston and Joao Luis Silva Damas
(http://www.circleid.com/posts/20160526_the_path_to_dns_privacy/).
Basically, we have two trends, somewhat conflicting. On one side, DPRIVE is
standardizing an encrypted connection to a trusted recursive resolver; on
the other side, efforts like GetDNS would generalize the use of recursive
resolvers on the client itself. There are pros and cons on both sides.

The privacy benefits of DPRIVE depend on the trusted resolver handling lots
of traffic. If the trusted resolver handled only one customer at a time, it
would be easy to correlate the encrypted messages coming to the server and
the clear text queries sent to the authoritative resolvers, and there would
be little privacy gains. If the resolver handles millions of queries,
correlation becomes much harder, but something else happens. The big
resolver becomes a very tempting target for attacks, from data mining to
criminal hacks, legal warrants, censorship mandates, or secret national
security letters. 

The distributed approach is somewhat more robust against attacks, especially
if the distributed resolver implements QName Minimization. But there is
little privacy if the queries are sent in clear text. In fact, clear text
queries can also be attacked with a combination of deep packet inspection
and automated spoofing - some big national firewalls are already doing just
that, and the infamous "quantum Insert" service was doing something similar.
DNS SEC will allow resolvers to detect the attack, downgrading them from
MITM to denial of service, but that's not exactly perfect robustness. 

So, what shall we do? I suppose recursive resolvers could use DNS over TLS
to get data from authoritative resolvers. Or DNS over DTLS. Or a variation
of DNS over HTTPS. But are we standardizing that? Is this part of DPRIVE's
charter?

-- Christian Huitema



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

Re: [dns-privacy] DPRIVe Agenda requests for Berlin

[Tim Wicinski]

All

Since we never heard anything back from folks about needed face time in 
Berlin, Warren and I have decided to cancel our time slot and give it to 
a more needy working group.


We will both be around in Berlin if anyone feels the need to bend our 
collective ears.


tim

On 5/25/16 7:54 PM, Tim Wicinski wrote:

All

Since the last meeting, the DNS over TLS draft has been published as
RFC7858.  The drafts on DNS over DTLS and the Profiles drafts received
feedback during the last meeting and we are awaiting updates.

The chairs have requested a slot for the upcoming Berlin meeting, though
we feel that currently in a waiting position.  We're asking authors if
they wish for any time for the meeting, and if so to please contact the
chairs, as well as have document updates before 1 June 2016.

The chairs currently are considering returning the meeting slot for
Berlin if there is not enough work to consider.

thanks


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

[dns-privacy] dprive - Cancelling a meeting request for IETF 96

["IETF Meeting Session Request Tool"]

A request to cancel a meeting session has just been submitted by .

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