Subject: [dns-privacy] Scorecard for DPrive proposals.

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 11 Nov 2014 17:51:58 -1000

We have three proposals on the table. The question is how to score
them objectively.

One approach would be to ask some party that runs a public DNS
responder which of the protocols they are most likely to support. So
feedback from a Verizon or a Google/8.8.8.8 would be useful.

Another point to consider is whether we judge proposals as they stand
now or accept modifications. I have been working on my proposal for 4
years. I have developed one code base, abstracted it, generalized and
then reified the original problem in the general framework. So I don't
expect my proposal to change much unless someone brings up a use case
that I haven't thought about.

When we get to scoring however, I know that a response to every one of
the feature deficiencies I see in other proposals can be fixed. I know
because I have travelled that same path before. And the reason I
decided on the architecture I did was that it was the approach that
required least changes to and least invention on top of existing work.
The point is that if we are going to have a fair basis for comparison
then either we have to disqualify proposals that don't meet the
necessary feature set or we have to agree those features aren't
required or we have to let people change their proposals to add the
cruft necessary to meet the requirements before a comparison is made.

1) 100% connectivity

There are two compliance levels that might be proposed:

A) The protocol has to work in any network situation where normal DNS
works OVER UDP
B) The protocol has to work in any network situation where http works

DPLS was originally designed to meet the stronger criteria. Private
DNS only meets the second but could easily be extended to meet the
first if necessary. The reason for making this change is that there
are few places where DNS over UDP works but http does not.

The reason that I invented what is now SXS-Connect in the first place
was precisely because I can't meet that 100% connectivity requirement
without some form of transport agility. It is in effect a super SRV
record.

Of the proposals on offer, Paul's DNS over HTTPS is the only other one
that comes close to meeting this requirement. But do note that HTTPS
is banned in a lot of countries. Now this probably does not make much
difference if we are talking about a country like Russia or China that
has permanent police state apparatus in place. But it does make a very
big difference if we are talking about a situation where a government
is trying an Internet crackdown to suppress evidence of government
corruption ahead of an election or the like.

2) Basis for performance comparisons.

If we are looking at privacy then we should be looking at the
performance impact on a heavily trafficked public DNS service like
8.8.8.8, Comodo's public DNS, etc.

The reason for this is that we need to be able to aggregate client
requests sufficiently to avoid traffic analysis giving the game away.

Large public DNS resolvers try to reduce in-band lookups to the
absolute bare minimum. This is going to be even more important when
DNSSEC is finally deployed because its not just about caching the DNS
records and avoiding the round trip hit, its about minimizing the
inband DNSSEC path math.

So large public DNS resolvers will typically prefetch well trafficked
DNS records on expiry of the old records. The cache hit rate for
labels that exist should be well in excess of 90%. Therefore to
compare like with like we have to compare round trips and public key
operations for the case where we get a cache hit.

Private DNS = 1 round trip, 0 public key operations, 0 server state

Everything else is more.

3) DoS resilience

There are several different types of DNS DoS attack. There is the
attack on the resolver itself, there is the attack on an authoritative
through the resolver and there is the third party attack.

Private-DNS is the only proposal that considers these at all. Simply
adding cryptography to the existing protocol is not a neutral change.
You are going to make it impossible for ISPs to mitigate DNS attacks
coming out of their networks except by blocking DPRIVE DNS.

4) Building on existing standards.

I think I win this one as well.

It is not possible to solve this particular problem by just slapping
DTLS or TLS onto DNS. Every single one of the proposals has to add
some mechanism.

I arrived at my approach because it uses the least additional
mechanism. It is considerably simpler than TDNS today and is a lot
simpler than TDNS with the necessary extensions to address essential
requirements.

The problem with trying to fit TLS or DTLS into a DNS protocol is that
TLS is layered on top of PKIX and the DNS. DANE does not help at all
because we hit a bootstrap problem of trying to use the DNS to get
records to use the DNS securely.

5) Capable of extension to stricter security requirements.

Yes, I have considered cases where very high levels of concern are
warranted. The SXS-Connect key exchange is a mutual authentication
protocol that does not reveal the PIN inband. So if you have a 128 bit
PIN code then you have a work factor of 2^128 to break either the
client or service authentication.

And if I goofed or got it wrong, well the only thing we would need to
change is the connection protocol. But that is the easy part. I an
100% confident that myself, EKR and the security directorate will get
SXS-Connect right. Thats just crypto. And its new crypto so its easy.
What is hard, hard, hard is brownfield protocol design and having to
work round legacy DNS or TLS gotchas.

6) Capable of being reused in other protocols.

There are two ways to score reuse, one is does the protocol build on
existing work. We all build on TLS as a framework with some additional
stuff. I think I actually add the least but I will accept a draw on
that if people want to argue.

What I deliver that nobody else does is a general purpose module that
can be reused for other purposes without the usual thing of chucking
everything into the DNS (as per Warren's T-shirt).

SXS-Connect can be applied as a way of securing a connection to a 2
factor auth service or a time service or anything else you might want.
The JSON base gives you the power without any additional cost on the
use for securing DNS.