Subject: [DNSOP] various approaches to dns channel secrecy

From: Paul Vixie <[email-masked]>
Date: Fri, 04 Jul 2014 20:04:02 -0700

i've now seen a number of proposals reaction to "the snowden
disclosures", seeking channel encryption for dns transactions. i have
some thoughts on the matter which are not in response to any specific
proposal, but rather, to the problem statement and the context of any
solution.

first, dns data itself is public -- the data is there for anybody to
query for it, if you know what to query for. only the question,
questioner, and time can be kept secret. answers are only worth keeping
secret because they identify the question, questioner, and time.

second, dns transactions are not secret to protocol agents. whether stub
resolver, full resolver, forwarder, proxy, or authority server -- the
full identity of the question must be knowable to the agent in order to
properly process that question. if the agent does logging, then the
question, questioner, and time will be stored and potentially shared or
analyzed.

by implication, then, the remainder of possible problem statement
material is "hide question from on-wire surveillance", there being no
way to hide the questioner or the time. to further narrow this, the
prospective on-wire surveillance has to be from third parties who are
not also operators of on-path dns protocol agents, because any second
party could be using on-wire surveillance as part of their logging
solution, and by (2) above there is no way to hide from them. so we're
left with "hide question from on-wire surveillance by third parties."

this is extremely narrow but i can envision activists and dissidents who
rightly fear for their safety based on this narrowly defined threat, so
i'm ready to agree that there should be some method in DNS of providing
this secrecy. and as we know from the history of secrecy, if you only
encrypt the things you care about, then they stand out. therefore,
secrecy of this kind must become ubiquitous.

datagram level channel secrecy (for example, DTLS or IPSEC) offers a
solution which matches the existing datagram level UDP transport used
primarily by DNS. however, the all-pervasive middleboxes (small plastic
CPE devices installed by the hundreds of millions by DSL and Cable and
other providers) have been shown to be more powerful than IPv6, DNSSEC,
and EDNS -- we could expect them to prevent any new datagram level
channel secrecy protocol we might otherwise wish to employ.

TCP/53 is less prone to middlebox data inspection, and may seem to be an
attractive solution here. i think "not" for two reasons. first, TCP/53
is often blocked outright, and second, because TCP/53 as defined in RFC
1035 has a connection management scheme that prohibits persistent TCP/53
connections at Internet scale, and we cannot afford the setup/teardown
costs of a non-persistent TCP-based channel secrecy protocol for DNS. to
those who suggest redefining TCP/53 and upgrading the entire physical
plant and all software and operating systems, i challenge you to first
show how this is less global effort than other proposals now on the
table, and then show how you would handle the long-tail problem, since
many agents will never be upgraded, or will only be upgraded on a scale
of half-decades. DNS works today because TCP/53 is a fallback for
UDP/53. its definition and deployment makes it unsuitable either
currently or as-would-be upgraded to become the primary transport.

i suggest that any channel secrecy protocol we wish to add to the DNS
system must be suitable as the primary transport, to which the existing
UDP/53 and TCP/53 protocols are fallbacks. i further suggest that any
new transport be operable at internet scale, which demands connection
persistence. finally i suggest that this be done using a protocol that
the internet's "middle boxes" (cheap CPE devices who think they know
what all valid traffic must look like) will allow to pass without comment.

one candidate for this would be RESTful JSON carried over HTTPS. because
of its extensive use in e-commerce and "web API" applications, HTTPS
works everywhere. because HTTPS currently depends on X.509 keys, other
groups in the IETF world are already working to make HTTPS proof against
on-path surveillance. (google for "perfect forward secrecy" to learn
more), and others are working to defend the internet user population
against wildcard or targeted SSL certificates issued by governments and
other anti-secrecy agents with on-path capabilities.

stephane bortzmeyer has already shown us that JSON representation of DNS
transactions is possible. i have heard from another protocol engineer
who is also working in this area (and who credits bortzmeyer for
informing his work).

the special advantage of TCP/443 as a primary transport for persistent
DNS with channel secrecy is that HTTPS's connection management permits
massive scale, as in, a single protocol agent with tens or hundreds of
thousands of open connections, even with local and global load balancing
and connection pinning.

in summary, i agree that we have a narrowly defined problem of on-path
surveillance of dns questions by third parties, but i do not think it
can be solved by further EDNS extensions to UDP/53, and i know it cannot
be handled by using or redefining TCP/53. i have identified a way
forward that relies on TCP/443, noting that other groups are already
repairing SSL to add perfect forward secrecy and to solve the
"government-controlled X.509 CA" problems, and that we can leverage that
work. i've suggested that we specifically focus on the bortzmeyer
solution involving RESTful queries and JSON responses, or perhaps
RESTful URI's using POST of JSON, and JSON responses.

thank you for your time spent reading this. note that i am not a member
of int-area@ but am allowed to post there, so, if you want me to see
your response, please cc me.

vixie

---

From: Matthäus Wander <[email-masked]>
Date: Sat, 05 Jul 2014 19:17:51 +0200

> channel secrecy protocol we might otherwise wish to employ.

DTLS works on top of UDP (among others) and thus can pass CPE devices.

> costs of a non-persistent TCP-based channel secrecy protocol for DNS.

Could you elaborate on why RFC 1035 prohibits persistent connections?

My reading of Section 4.2.2 is that persistent connections are supported:
- Servers should keep TCP connections open after transactions.
- Clients can keep connections open, if they want to.
- The minimum idle time before closing a persistent connection on
server-side is 2 minutes. There is no maximum.

> works everywhere.

I don't see the need to use HTTP. Middleboxes cannot look into TLS
traffic, so they will pass DNS-over-TLS like they pass HTTP-over-TLS.

> who is also working in this area (and who credits bortzmeyer for

Does JSON have an advantage over binary DNS?

> RESTful URI's using POST of JSON, and JSON responses.

Let's sum up the list of possible protocols:
- DNS over DTLS over UDP
- DNS over TLS over TCP
- JSON over HTTP over TLS over TCP

Also proposed elsewhere:
- DNS over DNSCrypt over UDP/TCP

So far I don't see the benefit of JSON and HTTP. Anyway, thanks for
framing the problem.

Regards,
Matt

---

From: Paul Vixie <[email-masked]>
Date: Sat, 05 Jul 2014 10:47:41 -0700

> DTLS works on top of UDP (among others) and thus can pass CPE devices.

no, it cannot. DTLS does not look something that the CPE was programmed
to accept; thus in many cases it is silently dropped.

---

From: Matthäus Wander <[email-masked]>
Date: Sun, 06 Jul 2014 14:26:14 +0200

> to accept; thus in many cases it is silently dropped.

DTLS can be used on top of UDP. CPE devices allow outgoing UDP sessions
to arbitrary ports. If they didn't, many online games and VoIP
applications would not work.

Here's an example DTLS session passing my DSL router at home:
> https://www.cloudshark.org/captures/7d2ae4cfe155

Source code found here:
> http://marc.info/?l=openssl-users&m=113009464321966&w=3

Regards,
Matt

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sun, 6 Jul 2014 13:04:25 -0400

This is really a design question.

As far as I am concerned, DNS is and always will be a first class Internet
protocol. It is the foundation for everything else. The syntax etc can
change but it is a building block other stuff should build on, not
something that can leverage other facilities.

So the approach I would take to dealing with legacy infrastructure is a two
pronged approach:

1) A principled approach that does not make allowance for network
deployment constraints.

2) One or more mechanisms to ensure service is available in restricted
networks.

So a browser would need to implement (1) and (2) but an Internet connected
coffee pot might only support (1) plus legacy DNS because it isn't a device
that would require the connectability guarantees that (2) provide.

Having experimented with it seems that a UDP service plus a Web Service
over HTTP are the best choice. I have tried using DNS as a tunnelling
protocol (TXT lookups) but that does not seem to be worth the hassle.

DTLS looks like a good idea at first but it is a bolt on to TLS which is
already a thick stack. DTLS is really designed to secure protocols that are
essentially emulating TCP in UDP.

There are times to stick with the existing standards and time to make a
fresh start. I think DNS is a case where a fresh start is appropriate.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 06 Jul 2014 10:29:36 -0700

> applications would not work.

it's possible to find single counter examples to almost any assertion.
however, consider RFC 2671 (EDNS), published fifteen years ago. because
it changes the format of a UDP/53 datagram, there is silent loss across
most CPE boundaries. implementers of EDNS have had to investigate and
deploy about a dozen different fallback strategies since then, not to
make EDNS work, but to make it fail reliably enough so that normal
non-EDNS can be tried. since DNSSEC relies on EDNS0, this is a real
problem. to the extent that it's gotten any better it's because someone
changed this CPE logic:

    if (normal dns packet)
        intercept it and answer inappropriately, 30% of the time;
        let it get where it's going, 70% of the time;
    else
        drop;

to this:

    if (normal dns packet)
        intercept it and answer inappropriately, 30% of the time;
        let it get where it's going, 70% of the time;
    else if (normal edns packet)
        intercept it and answer inappropriately, 30% of the time;
        let it get where it's going, 70% of the time;
    else
        drop;

in other words what fixes have been made have been EDNS specific, where
the real fix is:

    if (packet addressed to you)
        handle it or send ICMP;
    else
        let it get where it's going;

that fix is not going into the O(10^9) CPE devices now in place, ever.

if we can't get this right for EDNS in 15 years, my bet is that another
15 (or 150) years of trying won't produce better results. in fact, by
jim gettys and dave taht i've been made to understand that the world's
CPE problem is much worse than i knew. we might be able to fix it for
the next billion devices some day, but the devices shipping today are
still crippled.

incentives are such that a CPE provider hopes to sell web access, not
internet access.

your counter-example of DNS gaming does not change the treatment now
accorded UDP/53 at the internet edge. if you seriously think that a DTLS
solution can be universally deployed, including in hotel rooms, home CPE
environments, coffee shops, and mobile, then you and i are having a
"same planet, different worlds" experience, and i wish you well on your
walk.

vixie

---

From: Eliot Lear <[email-masked]>
Date: Mon, 07 Jul 2014 06:48:05 +0200

Paul,

This seems like a fine and modular approach that doesn't boil the ocean.

Eliot

On 7/5/14, 5:04 AM, Paul Vixie wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>
>

---

From: Eliot Lear <[email-masked]>
Date: Mon, 07 Jul 2014 09:14:41 +0200

Hi Hannes,

On 7/7/14, 8:23 AM, Hannes Tschofenig wrote:
> Just a minor note on this paragraph:
>
> On 07/07/2014 06:48 AM, Eliot Lear wrote:
>> because HTTPS currently depends on X.509 keys, other

I didn't write the above, Paul did.  But to your point below...
> TLS has this ciphersuite concept and allows you to more than just X.509
> certificates. As such, you have more freedom than you think (if you know
> what you want).

Yes.  This is something you might know something about ;-)
>
> It would be funny if the precondition using using DANE would be to
> require a PKI as currently used on the Web...
>

Unless what you're using ISN'T a PKI.  Any DNS mechanism must be free
and clear of dependency loops.  While that may be theoretically possible
with a PKI, I'd hazard a guess (perhaps worth a drink at a bar) that the
number of dependencies explodes, making such a loop more likely in an
operational environment.

Eliot

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 07 Jul 2014 08:23:52 +0200

Ciao
Hannes

PS: I don't think that the solution for addressing government
surveillance is addressed by that proposal but it might solve other things.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 7 Jul 2014 04:09:02 -0700

>> rightly fear for their safety based on this narrowly defined threat

[BA] Presumably protection would only be from an attacker that can snoop on the wire, but not have access to the logs? Is the assumption that the DNS server is hosted out of country, and that measures are used to avoid identification of DNS traffic?  I am trying to understand the scenario in which this actually would have a plausible chance of making a difference.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 07 Jul 2014 13:19:38 +0200

On 7/7/14, 1:14 PM, Hannes Tschofenig wrote:
>
> I also struggle to see the significant improvement for the cases that
> had been discussed on the list. I would say that they go close to zero
> when one uses DNS servers provided by the local network operator.
>

That's a matter of service selection and orthogonal to Paul's proposal.

Eliot

---

From: Paul Ferguson <[email-masked]>
Date: Mon, 07 Jul 2014 08:20:38 -0700

On 7/7/2014 12:14 AM, Eliot Lear wrote:

> Unless what you're using ISN'T a PKI.  Any DNS mechanism must be 
> free and clear of dependency loops.  While that may be 
> theoretically possible with a PKI, I'd hazard a guess (perhaps 
> worth a drink at a bar) that the number of dependencies explodes, 
> making such a loop more likely in an operational environment.

In fact, some sort of "PKI-free" framework might even be more
preferable for some folks. The problem with a PKI is not necessarily a
technical problem -- a trust anchor has to be established somewhere
with a PKI scheme, and politically that presents a lot of problems in
this day & age.

That is *not* to say that DANE is not a desirable thing to
deploy/accomplish.

Just sayin'.

$.02,

- - 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: John Kristoff <[email-masked]>
Date: Mon, 7 Jul 2014 10:24:26 -0500

On Fri, 04 Jul 2014 20:04:02 -0700
Paul Vixie <[email-masked]> wrote:

> questioner, and time can be kept secret. answers are only worth
> keeping secret because they identify the question, questioner, and
> time.

Hi Paul,

This may traditionally be true and ideally in the coherent name space
world be true, but is not necessarily true.  Thanks to views and other
so-called DNS tricks, particularly those that in essence or a weak
form of authentication (or even stronger form such as when attaching
TSIG to them), answers that may never otherwise be seen by some subset
of clients, or perhaps more correctly synthesized for some clients, may
be candidates for enhanced secrecy.

I wouldn't necessarily optimize for or argue to support such uses, just
pointing out that they do exist in some corner cases.

> left with "hide question from on-wire surveillance by third parties."

This sounds like DNSCurve's approach.

John

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 07 Jul 2014 13:14:47 +0200

On 07/07/2014 01:09 PM, Bernard Aboba wrote:
> [BA] Presumably protection would only be from an attacker that can
> snoop on the wire, but not have access to the logs? Is the assumption
> that the DNS server is hosted out of country, and that measures are
> used to avoid identification of DNS traffic?  I am trying to
> understand the scenario in which this actually would have a plausible
> chance of making a difference.

---

From: "Tirumaleswar Reddy (tireddy)" <[email-masked]>
Date: Mon, 7 Jul 2014 15:39:26 +0000

> -----Original Message-----
> From: Int-area [mailto:[email-masked]] On Behalf Of Matthäus
> Wander
> Sent: Sunday, July 06, 2014 5:56 PM
> To: Paul Vixie
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Int-area] [DNSOP] various approaches to dns channel secrecy
> 
> > no, it cannot. DTLS does not look something that the CPE was
> > programmed to accept; thus in many cases it is silently dropped.
> >
> 
> DTLS can be used on top of UDP. CPE devices allow outgoing UDP sessions to
> arbitrary ports. If they didn't, many online games and VoIP applications would
> not work.
> 

WebRTC enabled browsers already use DTLS to secure media.

-Tiru

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 7 Jul 2014 09:19:36 -0700

> This sounds like DNSCurve's approach.

One important observation:  ONLY the path between the client and the recursive resolver in the classic model substantially benefits from channel security.

Even if you wave a magic wand and all resolver<->authority communication becomes protected with 0-cost, 100% perfect data encryption, basic traffic analysis will largely be able to determine which domains are being looked up.  Individual names within the domain are protected, but that is relatively minor.

The other problem is DNS is used to guide endpoint communication.  Between the resolver<->authority information leak, and the actual IP selected by the endpoint itself for communication, this allows a nation-state observer adversary to pretty much recover what the hostname was in question in many cases, and at least the domain in almost all cases.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Paul Vixie <[email-masked]>
Date: Mon, 07 Jul 2014 09:33:49 -0700

> certificates. As such, you have more freedom than you think (if you know

you are right of course. we would use TLS PSK for this, avoiding the
X.509 system entirely.

vixie

---

From: Paul Vixie <[email-masked]>
Date: Mon, 07 Jul 2014 09:42:07 -0700

Bernard Aboba wrote:
> [BA] Presumably protection would only be from an attacker that can snoop on the wire, but not have access to the logs?

so, to your question:

> Is the assumption that the DNS server is hosted out of country, and that measures are used to avoid identification of DNS traffic?  I am trying to understand the scenario in which this actually would have a plausible chance of making a difference.

there are two kinds of channel in dns queries. (i'm not going to account
for updates or zone transfers here.)

one channel is from the stub to the recursive. it's pointless to add
secrecy to that unless a stub wants to use a very distant name server,
like opendns or googledns, or as in your example, one in another
country. however, these long stub/recursive paths do exist and are
becoming more common, either to avoid poisoning by the local recursive
operator (typosquatting and so on) or to avoid surveillance by the local
recursive operator or to access poisoning by a distant local recursive
operator (opendns for example is actually a security company, and they
deliberately filter out dns results to known-dangerous locations, as a
service.)

the other channel is from the recursive to the authoritative. these
transactions contain very little PII, since the IP address of the
end-user is not present, and since cache re-use events are not present,
only cache-miss events. however, this channel is frequently intercepted
(see china's GFW) and frequently observed/logged. (my $DAYJOB does this
kind of observation/logging, but only with the explicit permission of
the recursive operator who must deliberately install our sensor
software, and only with the implicit permission of their stub
population, which we can't ourselves verify, but we require be attested.)

secrecy on either of these channels is only rarely important, but in
order to avoid exceptional appearance (standing out like a sore thumb)
it's going to be necessary to make secrecy on both of these channels
ubiquitous.

vixie

---

From: Paul Vixie <[email-masked]>
Date: Mon, 07 Jul 2014 09:44:13 -0700

Paul Ferguson wrote:
> ...

DANE relies on DNSSEC which relies on EDNS. the placement of a
DNS-over-HTTPS channel would have to be below EDNS in the stack, and
non-reliant. therefore my correction up-thread -- this HTTPS session
would rely on PSK for keying information, not X.509.

vixie

---

From: Paul Vixie <[email-masked]>
Date: Mon, 07 Jul 2014 09:52:24 -0700

> One important observation:  ONLY the path between the client and the recursive resolver in the classic model substantially benefits from channel security.

if i were proposing a secrecy scheme that was easy to do on
stub-to-recursive but hard to do on recursive-to-authority, then i'd be
looking very much harder at the benefits of recursive-to-authority.
however, what i'm proposing is no easier to do in one case than the
other, and so any purported difference in benefit is outweighed by the
lack of difference in the cost. pay once, benefit twice, is good
engineering economics as far as i'm concerned.

> The other problem is DNS is used to guide endpoint communication.  Between the resolver<->authority information leak, and the actual IP selected by the endpoint itself for communication, this allow…

i wish it noted that i am responding to the general post-snowden call
for channel secrecy, and that i don't myself see much need for it in the
case of DNS, but that the proposals i've seen come out of the security
community for how to add channel secrecy to DNS are alarming in their
lack of understanding of what DNS is, how large DNS is, and how DNS
works. therefore, i'm attempting to isolate the cases which might be
relevant to somebody, i am drumming up a definition of "dissident", and
crafting a proposal that would protect that mythical person's interests.

the fact that the QNAME can be recovered in many cases by a well
resourced nation-state actor is meaningless here, since that
surveillance would have to be targeted, and would be both inaccurate and
expensive; whereas the surveillance i'm solving for is the ubquitous
kind, which is presently very accurate and very cheap.

vixie

---

From: Matthäus Wander <[email-masked]>
Date: Mon, 07 Jul 2014 19:58:42 +0200

> it's possible to find single counter examples to almost any assertion.

My point is that for a significant portion of Internet users, e.g.
residential, HTTPS tunneling is not necessary. HTTPS tunneling should
not be mandatory if it comes with disadvantages to a large user base who
don't need it.

The extra HTTPS layer suggests negative performance implications
compared to a tailored protocol (maybe negligible, maybe not). Requiring
TCP/443 is a dealbreaker when the port is already occupied by a small
business web server or by an administration interface on a plastic device.

> most CPE boundaries.
> [...]

Agreed.

> "same planet, different worlds" experience, and i wish you well on your

I didn't mean to imply that a DTLS solution can be universally deployed.
I'm just not convinced that mandatory HTTPS tunneling built into a new
DNS protocol is the appropriate solution here. My experience is that
HTTPS tunneling is unnecessary in most (not all) networks. If I want to
use SSH or VoIP in one of those crippled networks, I need a generic
tunneling solution anyway. Admittedly, if I only need the web in a
crippled network then encrypted DNS over HTTPS is a plus. That use case
seems very narrow.

Regards,
Matt

---

From: Paul Vixie <[email-masked]>
Date: Mon, 07 Jul 2014 11:04:56 -0700

> I didn't mean to imply that a DTLS solution can be universally deployed.

because the dns is a map to the territory known as the internet, and
because most internet packet flows begin with a dns transaction, i'm
dismissing out of hand anything that will almost universally not work
for some class of user, such as those in hotel room wireless networks,
or behind CPE that either can't pass new protocols or would require
above-average skill to configure for such.

in my own configuration i'd set EDNS to be the primary protocol, and add
HTTPS as the first fallback to be tried, so that the fallback to plain
DNS on UDP/53 can be as rare as possible. this may even be a reasonable
default.

but we can't spend any of our time pretending that the internet
architecture isn't a hostage to a billion poorly built CPE devices, no
matter how hopeful we are as to the future, and no matter how many
personal counter-examples we can cite.

vixie

---

From: Nicholas Weaver <[email-masked]>
Date: Mon, 7 Jul 2014 12:54:35 -0700

On Jul 7, 2014, at 9:52 AM, Paul Vixie <[email-masked]> wrote:
> i wish it noted that i am responding to the general post-snowden call for channel secrecy, and that i don't myself see much need for it in the case of DNS, but that the proposals i've seen come out of the security community for how to add channel secrecy to DNS are alarming in their lack of understanding of what DNS is, how large DNS is, and how DNS works. therefore, i'm attempting to isolate the cases which might be relevant to somebody, i am drumming up a definition of "dissident", and crafting a proposal that would protect that mythical person's interests.
> 
> the fact that the QNAME can be recovered in many cases by a well resourced nation-state actor is meaningless here, since that surveillance would have to be targeted, and would be both inaccurate and expensive; whereas the surveillance i'm solving for is the ubquitous kind, which is presently very accurate and very cheap.

No, its ubiquitous and cheap, and reasonably accurate.  

This type of traffic analysis correlation is bread and butter for a nation-state adversary running a pretty conventional real-time or even near real time IDS.  Doing it on the backbone is not hard, and overall, its no more complex than analysis we know they do like identify ALL users based on cookies and HTTP replies.

It is AMAZING the IDS analyses you can run on a 10 Gbps link when you are using a 20-system cluster.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 7 Jul 2014 16:25:24 -0400

> secrecy to that unless a stub wants to use a very distant name server,

Not at all. Trying to get any sort of privacy guarantee while sending your
DNS queries to any agent or service that you have not carefully selected
and decided to trust is the futile quest.

If we are going to have privacy then the DNS queries are going to be
directed at a trusted resolver and not the closest resolver on the network.

> transactions contain very little PII, since the IP address of the end-user
> is not present, and since cache re-use events are not present, only
> cache-miss events.
>

Agreed.

However that is based on a lot of assumptions on how the DNS works that are
currently true but need not be true in the future. If you have a DNS server
that is advertising names that are geolocation dependent then the caching
assumption breaks down and you start to leak privacy sensitive information.

It would be a mistake to accept a DNS privacy solution that unnecessarily
boxes the protocol in for future developments.

You might want to make use of a PKI to set up credentials for the
stub-resolver case. And you might well want to make use of the WebPKI etc.
to achieve that in a convenient way without falling into an infinite
regression trap of 'what is this anyway'. But that approach does not meet
every use case.

Once the credentials are set up you don't need that PKI any more because
the trust relationship is now a binding between the end user's client and
the service.

In sxs-connect the original design brief was to support omnibroker which
(among other things) allows the broker to advise on choice of WebPKI roots
rather than rely on the browser choice. So there are mechanisms that don't
rely on PKI to establish that binding which might well be preferred in an
enterprise. In fact the reason I split that part out was that I realized
that almost all the complexity in the problem was setting up that initial
relationship and that the problem was much more general.

The resolver to authoritative loop is very different. You probably do want
to ground that in DNSSEC or else what is it for?

Now you can't necessarily use DANE for that directly because the TLSA
record is specified for TLS and the authors decided (against advice) to
make it more than just a publication mechanism for keys. But you could
certainly adapt the spec without much trouble and you might just want to
publish raw keys.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Jul 2014 10:59:08 +1000

Personally I would use a new opcode and fall back to query on NOTIMP.
The payload of the new OPCODE does not have to be decodable by
existing servers.  This is also how EDNS should have been done.

Since it is next to impossible to hide that you are talking to a
server use unencrypted DNS w/ DNSSEC to get a public key for
authoritative servers stored in its own type.  This signals support
for the new OPCODE.

Use that key to encrypt the payload the payload to the server using
the new OPCODE.  With a session key returned for followup transactions.

For recursive server add a DHCP and RA options which distribute the
public keys of the recursive nameservers.

This should work through pure DNS proxies.

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

---

From: John Heidemann <[email-masked]>
Date: Tue, 08 Jul 2014 23:30:28 -0700

[I added dns-privacy to the cc list, since that seems like a relevant
forum for this discussion.]

On Mon, 07 Jul 2014 11:04:56 -0700, Paul Vixie wrote: 
>in my own configuration i'd set EDNS to be the primary protocol, and
>add HTTPS as the first fallback to be tried, so that the fallback to
>plain DNS on UDP/53 can be as rare as possible. this may even be a
>reasonable default.
>

These comments bring out a very important question that has been lurking,
somewhat unstated:

What IS the consensus about the completeness of deployment required to
declare "success" for DNS channel privacy?

Focusing on middleboxes for now (although deployability applies to
servers and users, too):

Paul "dismisses out of hand anything that is not almost universal,
including hotel rooms and behind broken CPE", because (A) there
widespread broken CPE devices and (B) we must protect the Internet
architecture from and the global DNS namespace.  (To paraphrase.)

With those assumptions, arrival at DNS-over-HTTPS [* footnote 1] makes
some sense, since HTTPS is the least protocol least-molested by CPE to
date [* footnote 2].

But I'm not sure those are the best assumptions to start with.  We're
talking about *adding privacy* to the existing DNS infrastructure.
What's important is that privacy is a *new feature*.

Thinking about things this way suggests two observations:

1. One can separate requiring privacy from providing a global namespace.
Since the Internet has survived without privacy DNS queries until now,
surely it won't melt if some queries continue to lack protection from
eavesdropping.

About the assumptions: if you accept fallback to current DNS, then new privacy
methods that don't reach 99% deployment do NOT break global naming---we
can reject assertion (B) if we allow fallback.

2. Because privacy is a new feature, (a) users or companies interested
in that feature *can advocate* for it, (b) they *have motivation* to fix
it because privacy can be a potential differentiator of what is today
commodity service, and (c) some have the *ability* to fix it.

Some people will care about DNS privacy and some not.  But for those
that care, users can replace their CPE, or can request their ISP upgrade
their CPE, or switch ISPs.  While many users may not do this (many will
not care), they all can.  As proof, consider reaction to bufferbloat,
where publicity has raised awareness.  Some users have switched
hardware, and I hope new CPE is being more reasonably configured.

(Or consider DNSsec.  Yes, there have been a couple publicized failures,
but one can look for domain providers that advertise DNSsec or not
today.  And end-users can generally use it, or fall back if they don't
care.)

This approach can generalize to ISPs or governments, too.  If, say,
there were a mandate that all DNS users in a state must use DNS privacy,
then that state's government could identify local ISPs with broken CPE,
and either ask them to estimate the cost of hardware upgrade or software
reconfiguration, or estimate the lifecycle of natural CPE turnover.

About the assumptions: because users (or ISPs) that care often have some
control over CPE, we can sometimes reject assertion (A).

In fact, given enough time, all the hardware will turn over.  I believe
the Internet no longer has any active Fuzzball routers. :-) More
seriously, telecos seem to be agressively moving people off DSL now, so
perhaps 10 years is plausible EOL for 90% of hardware.  We can reject
assertion (A) for most hardware if we allow enough time to pass.

If you accept that some people will continue with current DNS while
others have improved privacy, then we can think about a 10 year rollout
and accept that some stragglers with old CPE will continue without
privacy for DNS.

For users who have strong privacy requirements and refuse to fallback to
current DNS---replace your CPE for US$50 OR walk down the block to an
open wifi that isn't broken.

Some users will stick with old stuff until it dies.  See (for example)
the lingering installs of Windows XP.  That's OK---they know what
they're not getting, and they make a choice about benefit vs. cost of
upgrading.

It seems to me that assumption that "must work for 99% of users, right
now, in spite of today's broken hardware, OR it's not acceptable" is a
false dichotomy.  I hope we consider the several possible designs (some
of which may not work for 10% of today's users), not discard them
out-of-hand.

It may be that fast deployment trumps alternative designs in the end,
but let's have that discussion and not cut it off.

Back to the question: "what completeness of deployment
required to declare success for DNS channel privacy?":

My assumptions and a suggested answer:  I assume software upgrades to
the (a) interested clients and (b) servers.  (c) I assume the servers
are reasonably current hardware.  I assume (c) most CPE doesn't
interference, and (d) some interfering CPE can be fixed with a software
upgrade.  I think success would be (e) 80% of users *can* use DNS
privacy (possibly with software installation) in 5 years, and (f) 60% of
people *do* use DNS privacy in 10 years.  Those are just guesses to put
a stake in the ground, and (f) is probably optimistic.  But to me
"immediate and near universal" is not a requirement for success.

Which perhaps raises the question: how often will CPE actually interfere
with whatever we try?  I don't know, but the closest data I know of is
from Netalyzr in 2011 (see "Implications of Netalyzr's DNS Measurements"
by Weaver et al, SATIN).  They say:  88% of their sessions are behind
NATs, and 73% of these hit a DNS proxy---so there's a lot of CPE in the
way by default.  BUT they estimate that about 1.4% of sessions are
"proxied or modified by the network" when they try to directly talk past
the CPE, so it may be that most CPE will get out of the way if one
choses to bypass it.  So sure, we can use DNS-over-HTTPS to bypass the
CPE.  But this data suggests we could also use DNS-over-TLS or -DTLS to
do the same.

I'll cut off this long note here, just focusing on deployment CPE.  But
similar questions come up around deployment in the client itself and in
the servers (recursive and authoritative).  It's been suggested that
solutions must work on old server hardware.  That too seems like an
overly strong constraint to me.  (And, by they way, a constraint that is
completely incompatible with standing up a bunch of new webservers to
run DNS-over-HTTPS.)  That's a related but hopefully separable
discussion.

[* footnote 1: DNS-over-HTTPS: the Bortzmeyer JSON encoding was
mentioned, and XML has been proposed and I-D'ed before.]

[* footnote 2: I'm not sure I believe the assumption is that HTTPS is
nppever interferened with.  Some companies put up TLS-intercepting
middleboxes to snoop TLS to "protect their employees", so even HTTPS is
no longer free from interference and assumptions.]

   -John

---

From: Tony Finch <[email-masked]>
Date: Wed, 9 Jul 2014 10:33:07 +0100

Paul Vixie <[email-masked]> wrote:
> transactions contain very little PII, [..]

Two things might make this less true:

Firstly, some people advocate running full resolvers as close to the users
as possible, e.g. on the user's machine itself. The fewer users per
resolver the more PII in the rec -> auth channel.

Secondly, if DANE for OpenPGP starts being used at all then there will be
more interesting PII in this channel than at present.

> it's going to be necessary to make secrecy on both of these channels

Yes.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Dogger: Northwest 6 to gale 8, veering north 4 or 5. Moderate or rough.
Thundery rain. Moderate, occasionally poor.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Jul 2014 16:44:01 -0400

On Jul 4, 2014, at 11:04 PM, Paul Vixie <[email-masked]> wrote:
> way to hide the questioner or the time.

This is only true if you leave out "from whom."   If in order to know who made a query, I have to be snooping in many places, much closer to the source of the query, that's better for avoiding pervasive monitoring than if I can very easily figure out who made the query by snooping at a relatively constrained set of places.

As an example using reductio ad absurdum, you can always know everything about any given network activity if you have supervisor access on the node on which the activity is originating, but of course we still care about securing the communication on the wire in many cases.