Subject: [dns-privacy] [DNSOP] deployment requirements for dns channel privacy [was: various approaches to dns channel secrecy]

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: 
>Matthäus Wander wrote:
>
>    ...
>    
>    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.

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