Subject: Re: [dns-privacy] WG Review: DNS PRIVate Exchange (dprive)

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Oct 2014 14:44:57 +0200

[Keep [email-masked] in the loop only if it is substantive comments on
the WG creation, please]

On Fri, Oct 03, 2014 at 10:38:35AM -0700,
 The IESG <[email-masked]> wrote 
 a message of 68 lines which said:

> The primary focus of this Working Group is to develop mechanisms
> that provide confidentiality between DNS Clients and Iterative
> Resolvers,

I do not see why the group is limited to this point. 1) Some technques
(such as hop-to-hop encryption) work exactly the same for this case
and the case of resolvers<->authoritative. 2) The problem of data
gathering by authoritative name servers is as serious as the problem
of sniffing by third parties between a stub client and a resolver, and
should be addressed at the same level.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 06 Oct 2014 10:47:29 -0400

On 10/06/2014 08:44 AM, Stephane Bortzmeyer wrote:
> I do not see why the group is limited to this point. 

But it is not limited.  The full text of the paragraph you've quoted is:

>> The primary focus of this Working Group is to develop mechanisms that
>> provide confidentiality between DNS Clients and Iterative Resolvers,
>> 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. Some of the results of
>> this working group may be experimental.

So the argument appears to be that we should focus on standardizing
private communication between clients and resolvers, but if we happen to
be able to solve private between resolvers and authoritative nameservers
as well, that would also be considered in-scope.

I'm not sure i have strong opinions either way, but focusing on solving
one problem concretely can be useful if it means we don't get bogged
down in wrangling over which problem to solve first.  If it turns out to
be easy to settle on something for the client→resolver link, it sounds
like we can move on to solving the resolver→authoritative link without
trouble.

	--dkg

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Oct 2014 08:03:56 -0700

> as well, that would also be considered in-scope.

That seems right to me. Two of the operational problems with adding encryption between iterative (recursive) resolvers and authoritative servers that keep being brought up are DoS-by-crypto and establishment of trust. And opt-in, always-oppurtunistic approach could work, although we would then probably have the "you should never encrypt operations traffic" and "opportunistic is not good enough for my particular security scenario" discussions all over again.

--Paul Hoffman

---

From: Dan York <[email-masked]>
Date: Mon, 6 Oct 2014 15:23:43 +0000

Stephane,  (and dropping IESG as I don't think my comment needs to go to them)

On Oct 6, 2014, at 10:47 AM, Daniel Kahn Gillmor <[email-masked]<mailto:[email-masked]>>
 wrote:

<snip>

I agree with Daniel on this interpretation of the charter.

I'm not sure i have strong opinions either way, but focusing on solving
one problem concretely can be useful if it means we don't get bogged
down in wrangling over which problem to solve first.

Exactly.  If we go back to the DNSE BOF at IETF 89 where this was all discussed, there seemed to be a division between people who wanted to solve the client/resolver issue and people who wanted to solve the resolver/authoritative issue. (And varying opinions about whether there *were* issues with each and whether those issues were even solvable.)

I like the approach of picking *one* of the problem areas and trying to tackle THAT first.

 If it turns out to

Yes... or if in looking at solutions for the client/resolver link we happen to come up with one that ALSO works for the resolver/authoritative link, that work would certainly be allowed under this charter.

My 2 cents,
Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 6 Oct 2014 11:26:19 -0400

> should be addressed at the same level.

Well different techniques might be “better” in the two cases, i.e. connection from client to Recursive resolver 
may only be kept open for a short time while the connection from Recursive Resolver to a BIG DNS data provider 
might be always-on. 
So I think the charter is right in saying “will focus on last mile” and check if that solution will scale to other cases. 

	Olafur

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 6 Oct 2014 15:32:22 +0000

I am really interested to know the opinion of people about the comparison of the following cases:

consider a scenario where someone only hides the source of traffic using any approach (presume it can be onion based approaches, etc.) without encryption. In this scenario a DNS server receive from an anonymous network or user (because the IP address was hidden behind several nodes). For example DNS server receives something like example.com from anonymous entity. 
Now please compare the above scenario to the scenario where you have encryption only. For this comparison please use different factors such as DoS, performance (client, server), delay, any other factor that you can add.

For this comparison, please consider different attack scenarios by presuming that the surveillance actor have access to all traffic and the cases where he doesn't have access to all traffic. In former case, for example, he logs all information in the DNS server. Another example is that he monitors all traffic and the third example is the interception of traffic by any intermediate device. In latter case, he is somewhere in other network or might not have access to all traffic.

Advantages of using encryption
----------------------------
Passive attack:
Active attack:

Disadvantages of using encryption
--------------------------
Passive attack:
Active attack:

Advantages of hiding only source of traffic without encryption (anonymous user or network sending request to a DNS server)
-----------------------------------
Passive attack:
Active attack:

Disadvantage of hiding only the source of traffic without encryption
-------------------------------------
Passive attack:
Active attack:

Advantage of combining both approaches
----------------------------------
Passive attack:
Active attack:

Disadvantage of combining both approaches
----------------------------------
Passive attack:
Active attack:

Thanks,
Best,
Hosnieh

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Oct 2014 17:42:24 +0200

On Mon, Oct 06, 2014 at 03:23:43PM +0000,
 Dan York <[email-masked]> wrote 
 a message of 128 lines which said:

>  If it turns out to be easy to settle on something for the
> client→resolver link, it sounds like we can move on to solving the
> resolver→authoritative link without trouble.

My concern is about qname minimization: where will it fit here? (It's
useless for the stub<->resolver communication)

---

From: Dan York <[email-masked]>
Date: Mon, 6 Oct 2014 15:51:36 +0000

Stephane,

> useless for the stub<->resolver communication)

I would see that in the second phase of the working group's work.  To Daniel's point, if the WG solves the client/resolver link, it could then continue on to resolver/authoritative ... and at that point qname minimization could enter into the picture.

Dan

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 6 Oct 2014 17:52:06 +0200

On Mon, Oct 06, 2014 at 08:03:56AM -0700,
 Paul Hoffman <[email-masked]> wrote 
 a message of 93 lines which said:

> Two of the operational problems with adding encryption between
> iterative (recursive) resolvers and authoritative servers that keep
> being brought up are DoS-by-crypto and establishment of trust. 

Careful: the future working group is not about encryption but about
confidentiality (the charter does not mention explicitely
encryption). Encryption is just one possible tool in the toolbox.

qname minimization, for instance, is another one. I would like to be
sure the charter does not prevent the working group to work on it.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 6 Oct 2014 12:02:27 -0400

On Oct 6, 2014, at 11:42 AM, Stephane Bortzmeyer <[email-masked]> wrote:

> _

Stephane is right the,
when I read the current draft charter all I got out of it was channel protection thus I assumed that
query minimization was out of scope. 

     Olafur

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Oct 2014 09:03:27 -0700

> encryption). Encryption is just one possible tool in the toolbox.

Fully agree, but so far, that's all people have wanted to focus on. I find that unfortunate.

> sure the charter does not prevent the working group to work on it.

I agree, but I also think that document does not need to be process in the DPRIVE WG. In fact, it would be better done in DNSOP, and could (and should!) be done much sooner than "after we solve the client-to-recursive privacy problem". I said as much in an earlier message to the IESG about DPRIVE.

--Paul Hoffman

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 06 Oct 2014 12:17:23 -0400

Our thought process (or perhaps mine) was that it's so easy to offer to 
solve everything and you end up solving nothing.

I've been reticent to put forth the qname-minimisation work in DNSOP not 
because I don't think it belongs there, but the time spent on the 
editorial minutia of the DNSOP rechartering left me a bit bewildered.

I suspect the chairs should just ask our Glorious AD for advice.

tim

On 10/6/14 11:26 AM, Olafur Gudmundsson wrote:
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: Brian Haberman <[email-masked]>
Date: Mon, 06 Oct 2014 12:40:30 -0400

Hi All,

> I suspect the chairs should just ask our Glorious AD for advice.

I am not sure if I qualify as the Glorious AD mentioned above, but...

I think the QNAME minimization approach is something that should be
pursued.  The proposed charter for DPRIVE would put it as a follow-on
work item so that the focus can be on the client <-> iterative resolve
problem.

I could see one of three options for progressing the qname work...

1) Wait for the re-charter of DPRIVE
2) Ping Joel about getting it done in DNSOP
3) Ask for AD sponsorship

Regards,
Brian

>> Well different techniques might be “better” in the two cases, i.e.
>> connection from client to Recursive resolver
>> may only be kept open for a short time while the connection from
>> Recursive Resolver to a BIG DNS data provider
>> might be always-on.
>> So I think the charter is right in saying “will focus on last mile”
>> and check if that solution will scale to other cases.
>>
>>     Olafur
>>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 6 Oct 2014 12:51:02 -0400 (EDT)

> query minimization was out of scope.

This has such a strong operational component, it shouldreally be done by
dnsop

Paul

---

From: "Mankin, Allison" <[email-masked]>
Date: Mon, 6 Oct 2014 16:52:47 +0000

A comment of Olafur's has triggered me to write something I like about the charter, and also something in support of Stephane.  Olafur wrote;

> So I think the charter is right in saying “will focus on last mile” and check if that solution will scale to other cases. 

The charter uses the noun “mechanisms” not “solutions, and doesn't to indicate the development of single one-size-fits all solution, as I read it.  It also makes explicit in the milestones that multiple “solutions” might be developed.  

Stephane’s existing draft about the problem statement has done a great job in leading us to understand that there are varied operational realizations that need to be served by IETF’s work here.

Operationally end-systems reach the iterative resolver and beyond in different ways.  Taking just two, there’s the case in which a stub and iterative resolver are both running on the same computer, and the case in which many end-systems reach the iterative resolver through enterprise name system management of some kind.  In both cases, you can see that the end-systems are subject to having their queries linkable (in a privacy-revelation sense) and subject to compromise of their DNS private exchange, even if some mechanism for confidentiality of the stub-to-iterator is present.  

I’d like to see the working group propose and specify whatever the needed deployable mechanisms are to provide the end-system(s) with DNS private exchange, and not start with a mechanistic boundary.

Best regards,

Allison

---

From: Gilles Massen <[email-masked]>
Date: Mon, 06 Oct 2014 21:24:53 +0200

On 6/10/14, 18:51 , Paul Wouters wrote:
> This has such a strong operational component, it should really be done by
> dnsop

Full support. It is an elegant yet simple and available solution almost
entirely based on operations. I'd love to see the document adopted by
DNSOP right away...

Gilles

--
DNS-LU

---

From: Warren Kumari <[email-masked]>
Date: Tue, 7 Oct 2014 17:54:41 -0400

>>> query minimization was out of scope.

[ Apologies if this has already been covered, reading mail a: lagged
because I'm at nanog and b: out of order]

Sorry, to me Stephane's qname minimizations is an obvious no-brainer
-- we should Just Do It(tm)[0].

The charter doesn't mention it because:
A: we started writing this charter a while back, and I'd figured it
would have been adopted and worked on by DNSOP by now and
B: getting a new WG producing stuff takes some time - this shouldn't
be delayed while DPRIVE gets organized
C: this feels more DNSOPish

>> This has such a strong operational component, it should really be done by

Yah, me too...  But I personally really like qnm - if folk want this
in the dprive charter, and dnsop and the ADs and Stephane all want
this, I'd be more than happy for us to do it...

> entirely based on operations. I'd love to see the document adopted by

+1.

[0]: Yes, we should test it and make 100% sure it doesn't break
something[1]. It seems so obviously safe that I'm concerned there is a
monster under the bed...

[1]: Hi Peter!

-- 
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: Stephen Farrell <[email-masked]>
Date: Tue, 07 Oct 2014 23:01:14 +0100

> -- we should Just Do It(tm)[0].
...
> something[1]. It seems so obviously safe that I'm concerned there is a

+1 getting that done in DNSOP or DPRIVE is right, I don't really
care so much myself

S.

---

From: "Mankin, Allison" <[email-masked]>
Date: Fri, 10 Oct 2014 21:02:47 +0000

After a little bit of online discussion with the chairs-to-be and the AD, I’m following my earlier email up with a couple of small suggested edits to the charter.
EXISTING:
Milestones:
  Dec 2014 - WG LC on an problem statement document
  Mar 2015 - WG selects one or more primary protocol directions
  Jul 2015 - WG LC on primary protocol directions

SUGGESTED:
Milestones:
  Dec 2014 - WG LC on an problem statement document
  Mar 2015 - WG selects primary protocol directions
  May 2015 - WG LC on privacy evaluation document
  Jul 2015 - WG LC on primary protocol directions

The suggested privacy evaluation draft would describe methods for assessing the results of the DNS private exchange mechanisms.  Is the application of one or several mechanisms an effective choice for mitigating against pervasive monitoring in particular operational configurations or use cases?

I argue that this is important to help with the two cases I posed in my first message, where a channel encryption mechanism could be applied between End-system and Iterator but not mitigate at all.

Additional suggested wording about privacy evaluation for the charter body, addition of one sentence:
EXISTING:

SUGGESTED:
[Add to the end of the above paragraph]  The Working Group will also
develop a privacy evaluation document to provide methods for assessing
how well the goal of mitigating against pervasive monitor is met, and
to provide example assessments for common use cases.

Best,

Allison

On Oct 6, 2014, at 12:52 PM, Mankin, Allison <[email-masked]<mailto:[email-masked]>> wrote:

Best regards,

Allison

On Oct 6, 2014, at 11:26 AM, Olafur Gudmundsson <[email-masked]<mailto:[email-masked]>> wrote:

On Oct 6, 2014, at 8:44 AM, Stephane Bortzmeyer <[email-masked]<mailto:[email-masked]>> wrote:

[Keep [email-masked]<mailto:[email-masked]> in the loop only if it is substantive comments on
the WG creation, please]

On Fri, Oct 03, 2014 at 10:38:35AM -0700,
The IESG <[email-masked]<mailto:[email-masked]>> wrote
a message of 68 lines which said:

Olafur

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 10 Oct 2014 20:54:27 -0400

The focus on the client-resolver link is the right one precisely
because the resolver-server link raises very different privacy issues.
Yes, the scheme I proposed, PRIVATE-DNS can be applied to either the
client-resolver link or the resolver-server link. But the privacy
concerns being addressed are completely different and so are the DoS
by crypto issues and much else.

Query minimization looks to me to be something where the security part
takes five minutes 'don't send information that isn't necessary' and
the DNS part takes five meetings. It is all going to be considering
DNS corner cases and so let DNSOPs have it.

Doing the crypto for PRIVATE-DNS is easy. The hard part is considering
the corner cases. And the sets of corner cases are very different.

For the resolver-server link the server does not have a long term
relationship with the client by default. So DoS by crypto is a huge
issue. We can use a Kerberos approach to amortize the cost of public
key crypto across multiple connections. But the leverage might be
rather disappointing.

For the client-resolver link the first step to sanity is that the
client picks one DNS service and sticks with it. No more casual-DNS.
Once that decision is taken we can amortize the cost of public key
crypto over the lifetime of the client-resolver relationship. It makes
perfect sense to key once in a lifetime. So DoS by crypto is a
completely avoidable problem.

The other big corner case for the client-resolver link is obnoxious
middleboxes. My view is that its time to just give up on port 53 and
pick a new one. That works well enough for 97% of network locations.
So do that when you can and fall back to port 80 when you can't.

The charter seems to be less enthusiastic about authentication than I
would want. I see no point in crypto without authentication. But again
the game is very different. For the resolver-server link the game to
play is probably DNSSEC while for the client-resolver link it almost
certainly isn't DNSSEC unless you are doing DANE like records. Getting
a DNSSEC A record is like getting an armored truck making silver
bullion deliveries to your park bench - after you have switched to the
gold standard.

What is critical is that the resolver has to be able to authenticate
its response to the client so that it can't be spoofed. Without
authentication on that link it is possible to compromise privacy
through an integrity attack.

So net-net, I can make a case for a DNSCurve 'make public key crypto
fast' approach being an acceptable answer at the resolver-server link.
But I think it is clearly not the answer for the client-resolver link
where a two step process is much better.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 12 Oct 2014 16:34:07 -0700

> to provide example assessments for common use cases.  

This sounds like a good addition. We already have at least three proposals that look similar but have slightly different privacy properties. Having a document that catalogs these (which is different than what is in the problem statement) would be useful for both the WG and the larger community.

--Paul Hoffman

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 13 Oct 2014 15:37:34 +0200

On Mon, Oct 06, 2014 at 03:32:22PM +0000,
 Hosnieh Rafiee <[email-masked]> wrote 

I really wanted to try your erxrcice but I lacked time. Just one point:

> consider a scenario where someone only hides the source of traffic
> using any approach (presume it can be onion based approaches, etc.)
> without encryption. 

Always keep in mind that QNAMEs can be revealing, too. There are some
examples in my draft (QNAME with the source IP address, obtained from
a PTR query, QNAME revealing the person/company, etc).

> In this scenario a DNS server receive from an anonymous network or
> user 

In security, "anonymous" is a very strong word, with specific
properties. "Not easily linkable" would be a better term here.

---

From: Hosnieh Rafiee <[email-masked]>
Date: Mon, 13 Oct 2014 15:20:20 +0000

Hi Stephane,
Thanks for your message.

> examples in my draft (QNAME with the source IP address, obtained from a
> PTR query, QNAME revealing the person/company, etc).

I actually haven't reviewed your draft but will do it. Thanks. 

> properties. "Not easily linkable" would be a better term here.

You're right. Agree. 

Best,
Hosnieh