Subject: [dns-privacy] The case for both ends of 'end-to-end'

From: Hugo Maxwell Connery <[email-masked]>
Date: Mon, 20 Oct 2014 17:51:37 +0000

Hi,

I am deeply supportive of the IETF's effort to address
user privacy in all contexts.  Pervasive monitoring
is an attack, and I am grateful for the IETF acknowledging
it as such.

The core mission of DPRIVE is stated as "confidentiality
between DNS Clients and Iterative Resolvers" with possible
extension to end-to-end type scenarios.  Clarifying as
"DPRIVE will address risks to end-users' privacy".

I believe that an extended discussion of the area of
consideration is worthwhile.

The landscape could be classified into:

A) An end-user running some application that needs DNS, and
it (we hope) uses the stub resolver associated with the
operating system.  I group these as A.

B) A calls some iterative resolver, B, which returns
from cache or calls a collection of authoritative
resolvers, C.

C) The collection of authoritative resolvers.

These can be all on different systems (normal) or even
all collocated ($ dig localhost).

One can insert encrypted networks between components, and
those networks can handle all or some fraction of a client's
traffic.

As there is currently no provision for encrypting DNS
traffic, all claims that it is solved, for 'A to B' or
anywhere, by VPN or TOR (for example) are all false.

What they do is move the traffic to another end-point and
provide anonymity in proportion to the volume of the community
using the end-point.  TOR is far superior to a VPN as its
endpoint cannot know the source, by design.

Providing a standard for encrypting 'A to B' would create
a very similar situtation, where the privacy would really
be based on anonymity.  Only one person using the resolver?
Then all the authoritative queries are generated by their
queries.  This would still be an improvement as the frequency
of their queries would be unknown (i.e the TTL controls
the volume of frequency information leakage per zone).

So, it would seem to me that DPRIVE should also consider
the 'B to C' phase.  I state this, because TOR already
provides what only 'A to B' encryption could: anonymity
based on the volume of users.

Sincerely,
--
Hugo Connery, Head of IT, DTU Environment, http://www.env.dtu.dk
GPG: https://keys.env.dtu.dk/hugo-connery/email/valid-to-2015-04-15/Hugo-Connery.public-key.txt

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Oct 2014 18:10:08 -0700

i am not a member of the dns-privacy@ mailing list, but i was cc'd here,
so i'm responding. i hope that someone will kindly forward this response
to that mailing list, because i think my direct reply will bounce (as it
should, due to the spam problem.)

first let me say that i think privacy in dns is a very sensitive topic.
there are three points in the dns communication mesh where surveillance
is possible:

1. stub to recursive
2. recursive to authoritative
3. zone maintainance

i am in favour of query minimization on #2 because the current system
exposes unnecessary information to third parties. bortzmeyer's draft is
a great start on that. beyond query minimization i see no benefit or
need for secrecy since dns is a publication system -- if you don't want
people to see your information, don't put it into the dns. cache miss
transactions (#2 above) expose only server IP addresses, not end-user IP
addresses, and no re-use events. as such it has always been my position
that there is no PII and no privacy impact from having these recorded
and analyzed. i would not like to see the IETF work in that area.

i have a similar position on #3 -- if a zone administrator wants their
data to be secret, don't publish it, don't put it into the DNS at all. i
know that most people restrict zone transfers to a small set of known
secondary servers, or to the holders of a small number of TSIG keys, but
i have always viewed this as a way to protect the servers, not as a way
to keep data secret. the data is in the DNS -- so it is by definition
not intended to be secret.

the longer topic is #1, stub-to-recursive traffic. i think this is PII,
and i oppose surveillance of it, and i oppose collection and analysis of
it by anyone not a direct party to the relationship between the stub
operator (so, the owner of a laptop or smart phone or whatever) and the
recursive operator (who might be the employer or the ISP of the stub
operator, or google dns, opendns, or similar). this data path should in
my opinion be protected against third party observation, either by VPN
or IPSEC, or by a new stub-to-recursive transport. it is that third
option that should concern us -- i would like to see an XML schema for
DNS data (similar to bortzmeyer's effort) and a URL schema for encoding
DNS queries, and we should move the stub-to-recursive data path to
HTTPS. if XML loses this war that i'll suggest a RESTful/JSON API.
ultimately we should connect to an HTTP listener and use a URL pattern
like /dns/query/QNAME/QCLASS/QTYPE and get back an XML or a JSON blob.
TLS, with PFS, should protect the privacy of this data.

in that sense i would be alarmed to hear a proposal that the DNS
protocol itself should add features to support secrecy or privacy,
because that problem can be solved in the transport, and because we need
an HTTPS "Web API" to fix many other emergent and compelling problems in
the stub-to-recursive layer.

so, i don't understand why the IESG approved this working group, unless
it's to rubber stamp what we already know, or to investigate things we
already know should not be done.

with that background, let me respond to hugo's note, on which he
helpfully cc'd me.

> Hugo Maxwell Connery <mailto:[email-masked]>
> Monday, October 20, 2014 10:51 AM
> Hi,
>

i do not accept that redefinition as a "clarification".
> anywhere, by VPN or TOR (for example) are all false.

i disagree. a client could have a policy that only an encrypted tunnel
or negotiated IPSEC is acceptable, and return SERVFAIL if such is not
available. some sensitive networks already work this way, so, i have
witnessed and consulted on existence proofs of the statement you group
into the set "are all false".
> endpoint cannot know the source, by design.

you're overstating the problem and then claiming there is no solution.
that's a straw man fallacy.
> based on the volume of users.

i agree that if an attacker has control over the stub's choice of
recursive server, such that they can assign the surveillance target a
particular recursive server, then "stub-to-authoritative in the clear"
would be an information leak. however, that overstates the starting
conditions. the stub's recursive is either manually configured, or it is
assigned by their DHCP server operator, and either the owner themselves
or the DHCP server operator have many other methods of collecting this
traffic. so your starting conditions are operatively equal to the null set.

===

in conclusion, let me strongly urge that DPRIVE consider point solutions
such as query minimization and an HTTPS based transport between stubs
and recursives, and avoid system level structural changes to DNS itself.
let the DNSSEC effort, now in its 18th year, be a cautionary tale.

-- 
Paul Vixie

---

From: Jay Daley <[email-masked]>
Date: Tue, 21 Oct 2014 23:36:17 +1300

On 21/10/2014, at 2:10 pm, Paul Vixie <[email-masked]> wrote:

>  it is that third option that should concern us -- i would like to see an XML schema for DNS data (similar to bortzmeyer's effort)

Done:  http://tools.ietf.org/html/draft-daley-dnsxml-00

> and a URL schema for encoding DNS queries,

What an interesting idea.  

> and we should move the stub-to-recursive data path to HTTPS. if XML loses this war that i'll suggest a RESTful/JSON API. ultimately we should connect to an HTTP listener and use a URL pattern like /dns/query/QNAME/QCLASS/QTYPE and get back an XML or a JSON blob.

I prefer

	/query/QNAME.json?qtype=QTYPE
	/query/QNAME.json?qtype=QTYPE&qclass=QCLASS
	/query/QNAME.xml

But I suspect that needs a lot more thought.

Jay

> in that sense i would be alarmed to hear a proposal that the DNS protocol itself should add features to support secrecy or privacy, because that problem can be solved in the transport, and because we need an HTTPS "Web API" to fix many other emergent and compelling problems in the stub-to-recursive layer.
> 
> so, i don't understand why the IESG approved this working group, unless it's to rubber stamp what we already know, or to investigate things we already know should not be done.
> 
> with that background, let me respond to hugo's note, on which he helpfully cc'd me.
> 
> 
>> 	Hugo Maxwell Connery	Monday, October 20, 2014 10:51 AM
>> Hi,
>> 
> i disagree. a client could have a policy that only an encrypted tunnel or negotiated IPSEC is acceptable, and return SERVFAIL if such is not available. some sensitive networks already work this way, so, i have witnessed and consulted on existence proofs of the statement you group into the set "are all false".
>> 
> you're overstating the problem and then claiming there is no solution. that's a straw man fallacy.
>> 
> i agree that if an attacker has control over the stub's choice of recursive server, such that they can assign the surveillance target a particular recursive server, then "stub-to-authoritative in the clear" would be an information leak. however, that overstates the starting conditions. the stub's recursive is either manually configured, or it is assigned by their DHCP server operator, and either the owner themselves or the DHCP server operator have many other methods of collecting this traffic. so your starting conditions are operatively equal to the null set.
> 
> ===
> 
> in conclusion, let me strongly urge that DPRIVE consider point solutions such as query minimization and an HTTPS based transport between stubs and recursives, and avoid system level structural changes to DNS itself. let the DNSSEC effort, now in its 18th year, be a cautionary tale.
> 
> -- 
> Paul Vixie
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy

-- 
Jay Daley
Chief Executive
.nz Registry Services (New Zealand Domain Name Registry Limited)
desk: +64 4 931 6977
mobile: +64 21 678840
linkedin: www.linkedin.com/in/jaydaley

---

From: Ted Hardie <[email-masked]>
Date: Wed, 22 Oct 2014 12:55:19 -0700

On Tue, Oct 21, 2014 at 3:36 AM, Jay Daley <[email-masked]> wrote:

>  it is that third option that should concern us -- i would like to see an
> XML schema for DNS data (similar to bortzmeyer's effort)
>
>
​Um, RFC 4501 created one; other than the existing erratum noting a typo in
the reference to RFC 3490, is there something wrong with it?

regards,

Ted​

> and we should move the stub-to-recursive data path to HTTPS. if XML loses
> this war that i'll suggest a RESTful/JSON API. ultimately we should connect
> to an HTTP listener and use a URL pattern like
> /dns/query/QNAME/QCLASS/QTYPE and get back an XML or a JSON blob.
>
>
> I prefer
>
> in that sense i would be alarmed to hear a proposal that the DNS protocol
> itself should add features to support secrecy or privacy, because that
> problem can be solved in the transport, and because we need an HTTPS "Web
> API" to fix many other emergent and compelling problems in the
> stub-to-recursive layer.
>
> i disagree. a client could have a policy that only an encrypted tunnel or
> negotiated IPSEC is acceptable, and return SERVFAIL if such is not
> witnessed and consulted on existence proofs of the statement you group into
> the set "are all false".
>
>
> assigned by their DHCP server operator, and either the owner themselves or
> the DHCP server operator have many other methods of collecting this
> such as query minimization and an HTTPS based transport between stubs and
> recursives, and avoid system level structural changes to DNS itself. let
> the DNSSEC effort, now in its 18th year, be a cautionary tale.
>
> --
> Paul Vixie

---

From: Paul Ferguson <[email-masked]>
Date: Wed, 22 Oct 2014 13:08:46 -0700

Apologies for the top-post and the length of quoted text, but I wanted
to retain some context of Vixie's remarks.

I would also like to express my concern on the similar issues that Vix
expressed here, but perhaps a dprive "implementation and architecture"
document would be a good idea?

I am afraid that this efforts gets too far down the path before
realizing how some implementation of the "privacy path" before realizing
that the scheme breaks things like passive DNS collection.

For security operations folks, pDNS data collection is an imperative in
how we do reputation, etc., especially consider where the encryption

> 2. recursive to authoritative

I apologize if this topic has already been brought up, and if it has,
perhaps some kind soul could point me to the proper index in the list
archive. :-)

Cheers,

- ferg

-- 
Paul Ferguson
VP Threat Intelligence, IID
PGP Public Key ID: 0x54DC85B2
Key fingerprint: 19EC 2945 FEE8 D6C8 58A1 CE53 2896 AC75 54DC 85B2

---

From: Jay Daley <[email-masked]>
Date: Thu, 23 Oct 2014 09:15:17 +1300

On 23/10/2014, at 8:55 am, Ted Hardie <[email-masked]> wrote:

> ​Um, RFC 4501 created one; other than the existing erratum noting a typo in the reference to RFC 3490, is there something wrong with it?

Thanks Ted, I had no idea that RFC existed.  The only problem I can see with it is that it doesn't go far enough, but what it does it does simply enough.

Jay

---

From: Ted Hardie <[email-masked]>
Date: Wed, 22 Oct 2014 13:19:36 -0700

On Mon, Oct 20, 2014 at 6:10 PM, Paul Vixie <[email-masked]> wrote:

>
>  query minimization i see no benefit or need for secrecy since dns is a
> publication system -- if you don't want people to see your information,
> don't put it into the dns. cache miss transactions (#2 above) expose only
> server IP addresses, not end-user IP addresses, and no re-use events. as
> such it has always been my position that there is no PII and no privacy
> impact from having these recorded and analyzed. i would not like to see the
> IETF work in that area.ld be classified into:
>

At the STRINT workshop, we discussed the extent to which combining queries
at a proxy provides protection against analysis by a monitor.  It is
certainly the case that it provides some benefit, but we there are limits,
especially when the resolver serves a relatively small number of users.

To take an example:  Joe belongs a club, example.org, and is using their
network to look up a sensitiveblog.journal.example.  example.org hosts it
own DNS resolver, but few users connect to journal.example (having mostly
moved to face-example.org), so when Joe makes his look up, it's a cache
miss.  A surveillance entity will therefore see
sensitiveblog.journal.example as a target of the DNS query if it has a tap
on path between example.org and journal.example, and it now knows that the
traffic between example.org and journal.example is for the senstiveblog.

Note that it would not necessarily have known that otherwise.  Because
journal.example uses the HOST header to disambiguate traffic to different
hosted journals, thus consuming a very small number of IP addresses, the
connection itself would not have identified which blog was at issue. [There
are other potential sources of leaks, here, such as the unencrypted SNI in
TLS, but that has to be worked elsewhere.  I do not personally accept the
idea that we can't fix information leakage piece by piece, just because
other leaks are possible].

Clearly, had Joe used OpenDNS, Google's DNS, or a large ISP DNS service
which aggregates many more users, the chance of a cache miss would be lower
and the correlation would be much, much harder even in the case of a cache
miss.   But the DNS protocol cannot presume that sort of deployment, and
they have other consequences in terms of trust between users and large
services.

As long as the DNS continues to support deployment of recursive resolvers
in topologies that cannot effectively provide aggregation as a mitigation,
I believe that the recursive to authoritative problem should stay on the
table.  It is a lower priority, but it is a valuable piece of work.  I
personally also think that it is a substantially different problem from the
stub to recursive resolver problem, so we should treat them independently.

My two cents, in any case.

Ted Hardie

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Oct 2014 13:34:47 -0700

> document would be a good idea?

The charter says:

The Working Group will also
develop an evaluation document to provide methods for measuring the
performance against pervasive monitoring; and how well the goal is met.
The Working Group will also develop a document providing example
assessments for common use cases.

To me, this fits what you are asking for, yes?

(Note that PaulV indicated earlier that he had not been reading the list, and therefore might not have read the charter.)

> that the scheme breaks things like passive DNS collection.

Passive DNS collection is done at recursive and authoritative servers. How would encryption between the stub and its upstream recursive affect the ability to collect passive DNS data?

--Paul Hoffman

---

From: Jacob Appelbaum <[email-masked]>
Date: Wed, 22 Oct 2014 21:01:31 +0000

On 10/22/14, Paul Hoffman <[email-masked]> wrote:
> (Note that PaulV indicated earlier that he had not been reading the list,
> and therefore might not have read the charter.)
>
> Passive DNS collection is done at recursive and authoritative servers. How
> would encryption between the stub and its upstream recursive affect the
> ability to collect passive DNS data?
>

The NSA does that all over the place...

If you want someone to sniff and decrypt: Leak the state of your
PRNG/keys to your collector.

All the best,
Jacob

---

From: Paul Ferguson <[email-masked]>
Date: Wed, 22 Oct 2014 14:02:30 -0700

> Passive DNS collection is done at recursive and authoritative servers. How would encryption between the stub and its upstream recursive affect the ability to collect passive DNS data?

My concern here is in the "end-to-end" discussion, e.g. any obfuscation
or encrypting DNS traffic in the path in number 2 below basically breaks

> 2. recursive to authoritative

I may have misunderstood a portion of the discussion regarding "both
ends of the end-to-end", but that's probably what I get for responding
during a meeting. :-)

Cheers,

- ferg

- ferg

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Oct 2014 14:40:30 -0700

>> 2. recursive to authoritative

Again quoting from the charter:

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.

It sounds like you may be concerned about what the WG might do *later*, but brought it up in a way that seemed to be about what we are doing now.

--Paul Hoffman

---

From: Mark Andrews <[email-masked]>
Date: Thu, 23 Oct 2014 11:25:46 +1100

> My two cents, in any case.

And it is actually a solvable problem.  Lookup KEY, potentially in
the clear, for the server using DNSSEC to secure the response.  If
it has the correct flag bits set (TBD) issue encrypted DNS queries
using that KEY and a session key for the response.

The presence of the KEY with the correct flag bits indicates that
encryption is supported so there is no downgrade to plain text
possible.

Send the encrypted message using a new OPTCODE.  The format of the
body of the message is left as a exercise.

If we need to encode a list of offered cyphers then choose a new
type to use instead of KEY.  The client will choose from this list.

The only question is the KEY looked up by name or address?  I would
say address is better as you can't hide that you are talking to a
server.

As a additional benefit this also works for public recursive servers.

8.8.8.8.in-addr.arpa KEY ..... 

This can be looked up by validating stub resolvers in the clear
using 8.8.8.8.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: "Mankin, Allison" <[email-masked]>
Date: Thu, 23 Oct 2014 01:20:46 +0000

Very well said.  +Lots.

On Oct 22, 2014, at 4:19 PM, Ted Hardie <[email-masked]<mailto:[email-masked]>> wrote:

On Mon, Oct 20, 2014 at 6:10 PM, Paul Vixie <[email-masked]<mailto:[email-masked]>> wrote:

 query minimization i see no benefit or need for secrecy since dns is a publication system -- if you don't want people to see your information, don't put it into the dns. cache miss transactions (#2 above) expose only server IP addresses, not end-user IP addresses, and no re-use events. as such it has always been my position that there is no PII and no privacy impact from having these recorded and analyzed. i would not like to see the IETF work in that area.ld be classified into:

At the STRINT workshop, we discussed the extent to which combining queries at a proxy provides protection against analysis by a monitor.  It is certainly the case that it provides some benefit, but we there are limits, especially when the resolver serves a relatively small number of users.

To take an example:  Joe belongs a club, example.org<http://example.org/>, and is using their network to look up a sensitiveblog.journal.example.  example.org<http://example.org/> hosts it own DNS resolver, but few users connect to journal.example (having mostly moved to face-example.org<http://face-example.org/>), so when Joe makes his look up, it's a cache miss.  A surveillance entity will therefore see sensitiveblog.journal.example as a target of the DNS query if it has a tap on path between example.org<http://example.org/> and journal.example, and it now knows that the traffic between example.org<http://example.org/> and journal.example is for the senstiveblog.

Note that it would not necessarily have known that otherwise.  Because journal.example uses the HOST header to disambiguate traffic to different hosted journals, thus consuming a very small number of IP addresses, the connection itself would not have identified which blog was at issue. [There are other potential sources of leaks, here, such as the unencrypted SNI in TLS, but that has to be worked elsewhere.  I do not personally accept the idea that we can't fix information leakage piece by piece, just because other leaks are possible].

Clearly, had Joe used OpenDNS, Google's DNS, or a large ISP DNS service which aggregates many more users, the chance of a cache miss would be lower and the correlation would be much, much harder even in the case of a cache miss.   But the DNS protocol cannot presume that sort of deployment, and they have other consequences in terms of trust between users and large services.

As long as the DNS continues to support deployment of recursive resolvers in topologies that cannot effectively provide aggregation as a mitigation, I believe that the recursive to authoritative problem should stay on the table.  It is a lower priority, but it is a valuable piece of work.  I personally also think that it is a substantially different problem from the stub to recursive resolver problem, so we should treat them independently.

Ted Hardie

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

---

From: "Mankin, Allison" <[email-masked]>
Date: Thu, 23 Oct 2014 01:44:13 +0000

On Oct 22, 2014, at 4:34 PM, Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote in response to Paul Ferguson.

Encryption between the recursive and the authoritative would not prevent collection of passive DNS data at those points either.

Fergie, isn’t your point covered in the call to be aware of the “tension” between monitoring and privacy goals in the paragraph below from RFC 7258 (as well as in volumes of discussion
beforehand on the perpass list)?

   While PM is an attack, other forms of monitoring that might fit the
   definition of PM can be beneficial and not part of any attack, e.g.,
   network management functions monitor packets or flows and anti-spam

   mechanisms need to see mail message content.  Some monitoring can

   even be part of the mitigation for PM, for example, certificate
   transparency [RFC6962<http://tools.ietf.org/html/rfc6962>] involves monitoring Public Key Infrastructure
   in ways that could detect some PM attack techniques.  However, there
   is clear potential for monitoring mechanisms to be abused for PM, so
   this tension needs careful consideration in protocol design.  Making
   networks unmanageable to mitigate PM is not an acceptable outcome,
   but ignoring PM would go against the consensus documented here.  An
   appropriate balance will emerge over time as real instances of this
   tension are considered.

Best regards,

Allison

---

From: Jay Daley <[email-masked]>
Date: Thu, 23 Oct 2014 15:09:16 +1300

> Encryption between the recursive and the authoritative would not prevent collection of passive DNS data at those points either.

Why's that?

Jay

---

From: "Mankin, Allison" <[email-masked]>
Date: Thu, 23 Oct 2014 02:31:20 +0000

Jay,

I guess I model that there is an opportunity if desired to collect the DNS data for monitoring or security controls or whatever when it emerges from the encrypted channel at or near the server.  I can’t say that this is possible in all configurations that people might operate, of course.

Allison

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Oct 2014 01:17:18 -0400

> how we do reputation, etc., especially consider where the encryption

What on earth is passive DNS and what is the use case for it?

[I know, but I am certain most folk here don't or the conversation would be
different]

Your 'passive DNS' is just another form of intercept.

I am not obliged to trust your good faith and promise not to abuse that
information any more than the NSA, KGB[1] or PLA. Calling it imperative
does not excuse having collected it without explicit consent.

No, the fact that some folk like visibility into the system to collect data
does not mean that they get to keep that data channel open in perpetuity
because they got there first and have 'dibs' on that data. The data should
not have been visible in the first place.

Has anyone gone through a human subjects review before collecting this
data? Seems to me the fact that RFC 1262 hasn't been updated in quite a
while should worry a few people.

[1] Like Windscale they rebranded when the name became notorious but its
the same thing as before.

---

From: Jelte Jansen <[email-masked]>
Date: Thu, 23 Oct 2014 10:04:05 +0200

On 10/22/2014 10:19 PM, Ted Hardie wrote:
> which aggregates many more users, the chance of a cache miss would be
> lower and the correlation would be much, much harder even in the case of
> a cache miss.   But the DNS protocol cannot presume that sort of
> deployment, and they have other consequences in terms of trust between
> users and large services.
> 

To name one: the bigger the shared resolver, the higher the chance the
three letter agencies want and might have their taps there. So IMHO Joe
is simply shifting trust here, not necessarily in- or decreasing it.

Jelte

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Oct 2014 10:52:19 +0100

> is simply shifting trust here, not necessarily in- or decreasing it.

Yes, that's possible and we should figure out what's likely
to be better in terms of deployment. But out first job is to
define an agreed interoperable way of getting confidentiality.
When we're done I'm sure people will figure out how best to
(ab)use that;-)

S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Oct 2014 08:45:45 -0400

On Wed, Oct 22, 2014 at 5:02 PM, Paul Ferguson <[email-masked]>
wrote:

> > Passive DNS collection is done at recursive and authoritative servers.
> How would encryption between the stub and its upstream recursive affect the

> > 2. recursive to authoritative

I think you are going to find that the existence of pDNS has just turned
into a use case for #2 rather than a reason against doing it.

To be clear, any US academic using pDNS data who has not gone through human
subjects review had better do that right now. Its not just their career at
risk, if they are working under a US federal govt grant they may be
breaking the law.

At any rate, nobody seems to like DJB's ideas of eliminating recursives or
doing anything that would prevent caching.So the recursive will stay and
have visibility of the traffic.

Which in my view means that the recursive has to be a trusted service and
the notion of promiscuous recursive resolver use has to be stamped out.

> ends of the end-to-end", but that's probably what I get for responding

Yet another reason why recourse to the end-to-end principle rarely helps
clarify security questions because the ends are rarely where you would want
them to be and won't be people till Apple start selling their cyborg
implants that can offload the ECC calculations.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Oct 2014 08:51:23 -0400

> When we're done I'm sure people will figure out how best to

The objective here is to greatly reduce pervasive surveillance rather than
eliminate all possibility of vulnerability.

Forcing an adversary to perform an active, intrusive attack rather than a
passive attack is a substantial increase in work factor and increases the
risk of disclosure of the attack.

---

From: David Conrad <[email-masked]>
Date: Thu, 23 Oct 2014 08:47:21 -0700

On Oct 23, 2014, at 2:52 AM, Stephen Farrell <[email-masked]> wrote:
> But out first job is to define an agreed interoperable way of getting confidentiality.

Oh, that's easy... 

Given memory and bandwidth are so cheap, instead of simply asking for a single answer, we could combine Warren's draft and QNAME minimization: the resolver could cache the entire zone for every zone in a query. That is, if asked for "foo.example.tld A?", it would do a zone transfers of the root, "tld", and "example.tld". Popular zones (as defined by local policy) could be prefetched on resolver startup (and refreshed according to normal zone maintenance semantics).

Backwards compatible, interoperable, end user lookup performance would be improved (at least for popular zones or subsequent queries in a zone), and the information Evil Surveillers of resolver to auth traffic would be able to get would be vastly reduced without need of any stinking crypto or key management nightmares. Now, we just need to convince zone administrators to allow zone transfers from any/all resolver operators for confidentiality reasons... Hmm. There might be a flaw here...

(with tongue firmly in cheek if that wasn't obvious)

Regards,
-drc

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 23 Oct 2014 18:59:40 +0200

On Wed, Oct 22, 2014 at 01:08:46PM -0700,
 Paul Ferguson <[email-masked]> wrote 
 a message of 200 lines which said:

> the scheme breaks things like passive DNS collection.

It is already known (draft-bortzmeyer-dnsop-dns-privacy-02.txt,
sections 2.5 and 3) and, as Phillip Hallam-Baker noticed, it may be
seen as a feature, not a bug.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 23 Oct 2014 11:09:06 -0700

> Stephane Bortzmeyer <mailto:[email-masked]>
> Thursday, October 23, 2014 9:59 AM

since my company has a big passive dns investment, i should chime in here.

+1.

capturing dns traffic off the wire is difficult and unreliable, requires
reassembling fragmented udp, requires reassembling tcp sessions,
requires guessing the bailiwick, and misses off-the-wire events like
cache misses.

but also, and importantly, it risks having a network operator collect
passive dns traffic from down stream without having explicit permission
from each name server operator. we work hard at farsight to ensure that
our sensor operators always have such permission if they are running our
sensor code on a span port or passive ethernet tap rather than on a name
server itself. (our sensors is just a BPF app so it doesn't care where
it runs.)

for a lot of reasons, including privacy protection, we're developing
'dnstap' (see https://dnstap.info). this is a small patch for recursive
name servers that instruments parts of the data and control planes. it
is not service affecting in the way "query logging" can be. it gathers
off-the-wire events like cache purge, and gives reliable signaling for
bailiwick. and most importantly for privacy: it runs inside the
recursive name server, such that it cannot collect data without
server-by-server configuration, cooperation, and permission.

i see no problems for passive dns from encrypting more of DNS on the
wire, because we're moving off-the-wire anyway.

that url again is https://dnstap.info, and both the software and
protocol is apache-open-source-license-v2.0. there are patches for kdig,
knot, and unbound. work is about to start on bind9. we don't have an nsd
or powerdns story yet. vendor support from microsoft, nominum, cisco,
and other non-open-source name server implementors would be welcomed.

-- 
Paul Vixie

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 23 Oct 2014 19:50:13 -0400

> the notion of promiscuous recursive resolver use has to be stamped out.

I'm not convinced that your conclusion follows from your premise here,
Phil.

I agree with your premise that a recursive resolver needs to be a
trusted service.

But i don't see why a trusted recursive resolver can't be "promiscuous"
(though it's possible that i'm not understanding the term in the way you
mean it).

For example, anonymity-friendly service provider nologs.example might
offer a recursive resolver for anyone who wants to use it, while
identifying themselves to the public with cryptographically-strong
credentials.

The trust relationship for a recursive resolver is directional, not
symmetric.

    --dkg

---

From: "D. J. Bernstein" <[email-masked]>
Date: 24 Oct 2014 01:13:47 -0000

Phillip Hallam-Baker writes:
> At any rate, nobody seems to like DJB's ideas of eliminating
> recursives or doing anything that would prevent caching.

I've never proposed "eliminating recursives" (caches). What I propose is
complete _decentralization_ of the caches: you run your own trusted DNS
cache on your own laptop/smartphone/etc., talking directly to the
authoritative DNS servers---preferably with end-to-end encryption such
as DNSCurve, but there are several advantages even without encryption.

Decentralization has only a small effect on DNS load, compared to
centralized ISP caches. See, e.g., Manning's 2009 study:

   http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_12-2/122_dns.html

Eliminating caches has a much larger effect on DNS load. See, e.g.,
Section 5 of Shulman's recent paper:

   http://www.ietf.org/mail-archive/web/dns-privacy/current/pdfWqAIUmEl47.pdf

I'm surprised to see people confusing these two obviously different 
proposals. For example, Kaminsky has incorrectly claimed on several
occasions that end-to-end DNS encryption requires "abandoning caching", 
and similarly Shulman incorrectly presents the cost of uncached DNS as 
the cost of "end-to-end encryption". In fact, end-to-end encryption 
requires merely _decentralizing_ DNS caches, not _eliminating_ them.
Measuring the cost of uncached DNS is attacking a useless strawman.

I'm also surprised at how little common-sense perspective appears in
most discussions of DNS load. The largest DNS sites, such as .com, are
provisioned to survive massive distributed denial-of-service attacks,
and have no trouble handling small increases in DNS load. For the vast
majority of ISPs, HTTP+HTTPS load is a vastly larger cost than DNS load,
and again small increases in DNS load (or much larger increases, such as
the "send every query two or three times" proposals) are irrelevant.

Note that DNS load is very far from minimized today. People take small
TTLs, for example, because they care more about tiny improvements in
IP-address agility than about a big increase in their DNS load. Many
years ago I proposed having everyone run a local copy of the root zone
and local copies of TLDs on busier sites---a big reduction in overall
DNS load---but the reality is that DNS load wasn't a big deal then and
is even less important today. Maybe the same idea will make a comeback,
but if so then it will be for privacy reasons, not for load reasons.

---Dan

---

From: Paul Wouters <[email-masked]>
Date: Thu, 23 Oct 2014 22:29:41 -0400 (EDT)

> as DNSCurve, but there are several advantages even without encryption.

With a modern browser, these two are pretty much the same thing due to
in-application caching. So for the discussion on feasability of
infrastructure, the argument is moot.

Decentralising caches could actually be worse for dns privacy, as
your query no longer stops in the big ISP pool to gain some anonymity,
but instead links straight to you with specific TTLs on your personal
cache expiry/re-fetch timers.

Of course, you can get the best of both worlds by using "centralised"
(read ISP) caches for your own caching (validating) server on
localhost. Thanks to DNSSEC, we can rely on untrusted "centralised"
caches. Of course that doesn't work for DNScurve because DNScurve only
solves one little aspect of DNS security (transport encryption) and at the
cost of not being able to use any non-local caches and pushing the crypto
load of transport security completely onto the authoritative servers
opening those up to CPU DOS attacks easier then quertying for ANY isc.org.

> most discussions of DNS

I was surprised similarly, listening remotely to a CCC talk a few years
ago :)

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Oct 2014 22:44:19 -0400

> identifying themselves to the public with cryptographically-strong

I am all for the service user being anonymous. I do not want to use an
anonymous service though.

What I mean by promiscuous is using the service that happens to be
advertised in DHCP for anything other than bootstrapping and that only when
absolutely necessary.

> The trust relationship for a recursive resolver is directional, not

The resolver is trusted by the client. Ergo it must be chosen and it must
be trustworthy.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 23 Oct 2014 22:57:42 -0700

> cache expiry/re-fetch timers.

What's the threat model here? Is it that someone could be watching the
network above the ISP but not the link to the ISP from the local
machine?
> opening those up to CPU DOS attacks easier then quertying for ANY isc.org.

So the DNS server is now revealing queries to an attacker, and the ISP
cache is not? I fail to see why one is more trusted then the other.

Furthermore, every person connecting to vanguard.com is forcing the
vanguard.com web servers to carry out an RSA 2048 decryption. Forcing
the vanguard.com DNS server to do a single Curve25519 operation per
visitor doesn't increase the potential for a CPU DOS attack: they
already have to solve that problem on their webservers, and in fact
are vastly more vulnerable.

(One could ask about root nameservers. But there isn't really a
difference between root nameservers and other DNS servers: they both
need to be adequately sized to deal with hoards of malicious traffic)

> I was surprised similarly, listening remotely to a CCC talk a few years

I validated DJB's claims about the amplification potential of DNSSEC:
he gave a dig command, and sure enough, the response is many times
bigger than the query. The claims about performance are misleadingly
slow: at the cost of a 48 byte key, performance can be doubled on
commodity hardware. By contrast, claims that CPU load on DNS servers
will increase prohibitively with DNSCurve performance have been made
consistently over 8 years, with no evidence that they have been
updated or marked to market with increasingly fast CPU speeds.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Oct 2014 08:18:54 -0400

> updated or marked to market with increasingly fast CPU speeds.
Regardless of how fast you make ECC, the server has to do a lot more effort
than a DoS client sending garbage.

The DoS and amplification attacks are the reasons why I believe that
whatever mechanism we choose needs to authenticate requests and only
respond if the request is 'sufficiently' authentic.

The way that I got to PrivateDNS was that I started with DNSCurve and
pulled the key exchange out of the request/response loop so that public key
negotiation was a separate one-time operation resulting in a shared secret
and a kerberos ticket like identifier. Then rather than roll my own key
exchange, I leveraged the existing TLS library as an option.

Separating the key exchange from the packaging protocol means that it is
much easier to adapt to different use cases like really constrained
devices, etc. I can put the key exchange on a different machine and just
install the ticket/secret onto the lightswitch/stepper motor
driver/whatever.

---

From: Frederico A C Neves <[email-masked]>
Date: Fri, 24 Oct 2014 10:36:51 -0200

> On Fri, Oct 24, 2014 at 1:57 AM, Watson Ladd <[email-masked]> wrote:
...
> respond if the request is 'sufficiently' authentic.

We do have a "sufficiently" solution for this proposed now for more
than 8 years and counting.

http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-00

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Oct 2014 08:49:21 -0400

> http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-00

Which would be an approach to use if we were not also planning to encrypt
the messages which makes use of a MAC much easier and allows us to limit
the impact to the transport/presentation packaging and not impact the DNS
protocols.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 24 Oct 2014 11:17:20 -0400 (EDT)

> network above the ISP but not the link to the ISP from the local

That your query pattern when you open your laptop is not a unique
fingerprint on the net, because it stops and merges with other people's
queries in the ISP dns cache pool.

> cache is not? I fail to see why one is more trusted then the other.

This was not about trust, but about caching and not doing a DOS.

> are vastly more vulnerable.

Blowing a webserver offline and blowing an entire domain offline are
different emergencies. Losing your webserver doesn't lose your email.
Losing your nameservers, you lose everything.

> need to be adequately sized to deal with hoards of malicious traffic)

There couldn't be a greater difference between thousands of anycasted
root servers and my poor 3 nameservers.

> updated or marked to market with increasingly fast CPU speeds.

unless CPU's became a million times more powerful in the last year,
I think the botnet still easilly wins.

There is a reason we tend to put defense measures into our protocols
before we have confirmed the source addres is not spoofed, such as
IKEv2 DCOOKIEs.

Claiming we need more numbers to "proof" that forcing crypto operations on
a handful of auth servers instead of that crypto load being decentralised
over millions of caching servers is just silly.

There is a very good reason we are looking at stub-recursve and
recursive-auth privacy relationships differently.

Paul

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 24 Oct 2014 11:41:01 -0400

> anonymous service though.

Right, so you're saying "promiscuously using arbitrary recursive
resolvers is a bad idea", but not that "promiscuous recursive resolvers
are a bad idea".

> advertised in DHCP for anything other than bootstrapping and that only when

yep.

        --dkg

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 24 Oct 2014 12:19:25 -0400

On Fri, Oct 24, 2014 at 11:41 AM, Daniel Kahn Gillmor <[email-masked]

> resolvers is a bad idea", but not that "promiscuous recursive resolvers

Yes, I want to make sure that the user:

1) Gets to the same discovery service every time.

2) Has a means of checking they get to the discovery service they expect on
first contact.

3) Don't need to think about security after first contact.

(3) is the reason I don't want to go the DTLS route after first contact.
TLS depends on the user checking the padlock icon in the corner of the
browser. So how would a DNS scheme work, two padlocks?? If the user isn't
checking then we have a possibility of substitution attacks etc.

Using TLS once to set up a client/resolver connection is feasible. That is
a case where we can use the full PKIX stack and EV and logotypes etc. But
after that, DNS has to go right under the covers. But we only need to do
that if (2) is actually a requirement which it might not be.

Someone who is currently happy using 8.8.8.8 is probably going to be ok
with a setup dialog where they type in a domain name and everything is
automatic from there. Secure after first contact is probably good enough
for them.

I can make a case for better than secure on first contact as well. But I
don't think I will win that argument in the market if its only private DNS
on offer. But what would make that attractive is if I can bind a machine to
a package of security services all in one go. So the user types in
myemployer.com and the machine sets up a secure connection to the AV
signature/scanner service, the PKI service, the two factor auth service and
of course the private DNS.

Now obviously using the connection service for anything other than DNS is
out of scope. But designing a reusable architecture increases the chance
that it is going to be worthwhile for people to use the system securely.

---

From: Tim Wicinski <[email-masked]>
Date: Fri, 24 Oct 2014 19:54:30 -0400

> http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-00

Actually the most updated version is this:

https://datatracker.ietf.org/doc/draft-eastlake-dnsext-cookies/

version 5, and we've issues that Call for Adoption.  Also, Mark Andrews 
and Donald have made some changes to the design and have some data to 
discuss in HI.

tim

---

From: Mark Andrews <[email-masked]>
Date: Sat, 25 Oct 2014 12:25:14 +1100

> http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-00

And Donald and I are trying to finalise that so we can ship code
in BIND 9.11.

BIND 9.10 already has experimental code (SIT) which is similar.
The current difference is SIT doesn't have a error code and cookies
does.  When SIT was shipped the server cookies was completely
different.

The open question is the error code really useful.

SIT is enabled in the Windows builds and can be enabled at compile time
with --enable-sit.
 
Mark

---

From: "D. J. Bernstein" <[email-masked]>
Date: 25 Oct 2014 08:29:33 -0000

Phillip Hallam-Baker writes:
> Regardless of how fast you make ECC, the server has to do a lot more
> effort than a DoS client sending garbage.

If your CPU finishes the ECC computation (and the encryption etc.) in
less time than it took your network to transmit the ECC public key (and
other crypto overhead such as the nonce), the DoS _with_ crypto is no
more effective than the DoS _without_ crypto. Think about what will
happen if the attacker turns on crypto:

   * He won't be able to send you more network packets, or more bytes.
   * He won't gain amplification, if the protocol is designed carefully.
   * He'll _reduce_ your CPU load.

In the case of DNSCurve, a streamlined query packet is 68 bytes longer
than the original packet, and a typical server CPU handles the crypto
for 70000 worst-case packets per second. If a 1Gbps load is split across
merely 50 servers then adding crypto to 3.5 million packets consumes 1
second of CPU time on each server---but it consumes almost 2 seconds of
network capacity. The attacker doesn't gain anything from DNSCurve: if
he turns it on then, for whatever amount of traffic he can send, he
_reduces_ your CPU load. This is the opposite of what you claimed.

By the way, have you measured the CPU time required to generate a
typical NSEC3 response? How about an NSEC3 response to a query that's
chosen to burn CPU time?

---Dan

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 25 Oct 2014 11:03:51 +0200

On Mon, Oct 20, 2014 at 06:10:08PM -0700,
 Paul Vixie <[email-masked]> wrote 

> 2. recursive to authoritative

I am not happy with this list because it mixes two different types of
attackers (see RFC 6973, section 3.1, for terminology, and the
difference between attackers and observers): for #1, the DNS traffic
can be observed by a third-party sniffing the wire, or by the
recursor's operator. They call for different technical solutions
(encryption against sniffing, and may be running a local
resolver+cache on the user's machine to limit the amount of data
sent). Just saying "stub to recursive" is not sufficient.
 
> i see no benefit or need for secrecy since dns is a publication
> system -- if you don't want people to see your information, don't
> put it into the dns.

There is no problem about privacy of *data*. The problem is about
privacy of *requests*. The data in aa.org may be public, but the fact
I read it may be embarassing for me.

> there is no PII 

*If* the user runs its own resolver *and* does not forward to a bigger
resolver, yes, there is PII.

> the data is in the DNS -- so it is by definition not intended to be
> secret.

It is well-known for a long time that public availability of data is
not the same as bulk access. When I walk in the streets of Paris, it
is public, anyone can see me, but I still would be very pissed off to
learn that someone has a complete access to a comprehensive list of
all my moves in the city.

> because that problem can be solved in the transport,

DNS has some specific privacy issues. A typical example is that DNS
involves other actors, that may be unknown from the user ("enablers",
in RFC 6973 parlance). For instance, if someone in France visits the
e-shop <http://www.voyages-sncf.com/>, since the e-shop and himself
are in France, he may have an expectation that everything is regulated
by national laws and he may be unaware or not fully aware that his DNS
requests go to a different country, with different laws. That's why it
is at least necessary to document these issues.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 25 Oct 2014 11:11:15 +0200

On Thu, Oct 23, 2014 at 08:45:45AM -0400,
 Phillip Hallam-Baker <[email-masked]> wrote 
 a message of 118 lines which said:

> To be clear, any US academic using pDNS data who has not gone
> through human subjects review had better do that right now. Its not
> just their career at risk, if they are working under a US federal
> govt grant they may be breaking the law.

And if they operate in Europe, they have to abide by the European
directive 95/46/EC "on the protection of individuals with regard to
the processing of personal data and on the free movement of such data"
and its national implementations (CENTR members may look at the recent
talks in the Legal and Technical working groups in the last year,
about this subject).

> Which in my view means that the recursive has to be a trusted
> service 

"Trust" is not binary: I trust my bank with my money but not with my
nude selfies (which I entrust to Snapchat instead). So, even if you
trust your resolver, you may be interested in ways to decrease the
amount of data sent to it. Follow the arabic saying: "Trust God But
Tie Your Camel".

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 25 Oct 2014 11:17:59 +0200

On Thu, Oct 23, 2014 at 08:47:21AM -0700,
 David Conrad <[email-masked]> wrote 

> (with tongue firmly in cheek if that wasn't obvious)

Actually, the idea is not stupid at all. It was documented (at least a
variant of it, not requiring zone transfers) in section 2 of
draft-bortzmeyer-dnsop-privacy-sol-00: "gratuitous queries" (sending
queries which are not explicitely requested by the user, to blurr
data).

---

From: Paul Vixie <[email-masked]>
Date: Sat, 25 Oct 2014 10:47:45 -0700

stephane, you make a very important distinction:

> Saturday, October 25, 2014 2:03 AM
> recursor's operator. ...
as a matter of responsible disclosure, the IETF should note well and
publish widely the fact that a recursive name server operator receives
incredibly high insight into a stub resolver's operator's activities.
this risk begs for DNS RDNS privacy statements (google dns has a privacy
policy for example, but so should opendns and all ISP's).

witnessing re-use events and end-user IP is how many security companies
build their maps of who is infected with what, and which botnets are
spreading where and how fast. this can be done responsibly, but is also
a very attractive surveillance opportunity for commercial or political
oppression purposes.

RDNS users should be encouraged to only use RDNS servers whose operators
and whose privacy policies they trust. and, as previously stated, we
need to secure the last mile (stub-to-recursive) so that no third party
has surveillance powers.

finally, as previously stated, i would be alarmed to see changes
proposed to the DNS itself that somehow caused RDNS operators to see
only opaque data. the solution to RDNS operator surveillance is: use
only an RDNS service you trust.

note, i am not subscribed to dns-privacy@, other than to have posting
rights there. so cc me on anything you want me to see.

-- 
Paul Vixie