Subject: Re: [dns-privacy] A different way to look at the problem

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 19 Feb 2015 22:16:26 -0500

On Thu, Feb 19, 2015 at 1:21 PM, Ted Hardie <[email-masked]> wrote:

> Howdy,
>
> On Thu, Feb 19, 2015 at 7:20 AM, Phillip Hallam-Baker <
> [email-masked]> wrote:
>
>> DNS privacy requires us to make two changes to the DNS protocol.
>>
>> ​I'm a little confused as to why this isn't on DPRIVE, but okay.
>

So was I. I typed in DNS-privacy... it ended up in DISCUSS. :-(

So lets continue the rest in DPRIV...

So let's agree to the framing a bit.  There are two exchanges in the
> current system:  resolver to authoritative and client to resolver.  It's
> important that the resolver to authoritative  exchange not leak more
> information to the authoritative server than is necessary (e,g, passing
> along the client's IP at single IP granularity).
>

Actually that part of the protocol is currently out of scope. We are
looking at the client-resolver link first. If/when we get to that part of
the protocol we should probably formalize some sort of mechanism to allow
the resolver to tell the authoritative what the BGP ASN number of the IP
address is precisely to prevent finer granularity leaking while allowing
CDNs to still work efficiently.

> It is useful if the system allows for the traffic between the two be
> encrypted so that eavesdroppers cannot read them​ (for large installations
> with lots of clients behind them, the leakage in that eavesdropping is
> diffused by the difficulty of associating it with specific clients, so it
> may not be used everywhere, but it should be possible).  I think the work
> so far has presumed that this exchange is, however, the less urgent one to
> protect, and that client to resolver is more urgent.
>

Yes, that is indeed where we are. While I would never design a
client-resolver loop without also writing a spec for a
resolver-authoritative to make sure that both can be handled in a
consistent and clean fashion, it is not necessary for us to be discussing
both in IETF at the same time.

> ​As you note, protecting the exchange between client and resolver so that
> it is confidential is one critical aspect; encrypting the exchange does
> that.  Having the client able to perform integrity checking (presumably
> using DNSSEC) allows it to verify that the  resolvers is providing the
> ​data entered by the zone maintainer.
>

Whose authentication is relevant depends on whether we are doing a layer 5
DNS lookup (A or AAAA) record or a layer 6 DNS lookup (everything else,
including TLSA records).

Authentication of A and AAAA records is certainly desirable in the now
obsolete approach of taking the nearest DNS service because you are taking
the data from an untrustworthy source. But once we direct our queries to a
service we consider to be trustworthy, it is neither necessary nor
desirable. It is actually better to let the resolver do the authentication.

An A or AAAA record is only a binding of a DNS name to an IP address.
Absent a fully deployed and 100% trustworthy BGP infrastructure, that does
not provide a secure binding to the endpoint. There are certainly good
reasons for wanting to provide DNSSEC records for A/AAAA to the resolver
but there isn't a good case for the client checking. [Again, TLSA and other
security policy records are a totally different matter.]

Allowing the client to rewrite A and AAAA records allows a DPRIV resolver
to provide DNS64 service so an IPv6 only client can function without any
IPv4 support at all. Whenever it tries to access an IPv4 only resource, the
resolver gives it an address at NAT64 gateway.

But that is a digression.

The critical issue here has often been latency--clients have been reluctant
> to do that in real time, as the resulting increase in latency was bad for
> operations.  There may be ways to improve that--by having the resolver
> perform those functions but also consistently provide the client with the
> data used to verify, so that it can cross-check at some configured rate
> ("trust, but verify").
>

In my current proposal, all the crypto in the client-resolver interaction
loop is done using symmetric key cryptography and a Kerberos ticket like
scheme. The performance impact is negligible.

Given the current state of the CFRG discussion on ECC curves, the use of
Curve25519 in place of the symmetric crypto is certainly worth considering
but it does not change the design very much.

> The other issue you raise--can you trust the resolver not to forward the
> data to some third party?
>

That depends on your definition of trust. I define trust as being able to
accurately estimate the probability of default and determine that it is
within acceptable limits.

What is key here is being able to chose your own trust provider. And there
are tradeoffs. You can't get privacy in this particular instance by
deciding to little red hen it and do it yourself. That is like trying to
hide a tree in the desert. You need a large portal like Comodo or Google
with a few million customers to be able to hide.

> boils down to a relationship question for which there are a couple of
> parts.  The first is "are you sure you are talking to who you think you
> are?", which means some form of resolver to client authentication.
>

Yep.

> The second is "should you be talking to the party named by the network or
> to one configured elsewhere?".  Split DNS has, unfortunately, meant that
> there are times when talking to the party named by the network is the only
> way to get an answer, but that's not a reason to talk to it for all
> things.
>

Very true and this is a case where it is long past time we recognized the
fact that people need to be able to connect to networks through the
Internet.

The short term deployment driver for this protocol is likely to be for
remote workers (like myself) wanting to access some corporate resources
from BYOD (personally owned) machines.

So I want there to be a process for binding to a DNS service that allows
the user to authenticate their device that does not force an every-time
authentication and also we need some mechanism that allows a DPRIV resolver
to say 'I have special data for example.com' in trustworthy fashion.

Again this is the sort of area where we can leverage DNSSEC probably.

> In general, we may want to develop code that allows us to use multiple DNS
> resolvers, some configured and some provided.  Not only would that raise
> the costs for attackers attempting to develop client profiles, it gives you
> a secondary method for checking accuracy when DNSSEC isn't available by
> using a voting-algorithm style anomaly detection (the large caveat here
> being the knock-on effect on CDN operations, which may well be returning
> different results to different resolvers if they have no other client data).
>

Actually for the specific purpose of preventing government censorship
attacks, DNSSEC does not actually help at all because all DNSSEC can do for
you is to tell you that there is a hole. If you are trying to access
Facebook from a censorship state you already know that. What you want to
know is how to get to Facebook.

> Again, though, I think this conversation is really squarely in DPRIVE
> territory, so I'd suggest follow-ups there.
>
>

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Feb 2015 09:42:36 -0800

Howdy,

Sorry for the delay in replying.  Additional comments etc. below.

On Thu, Feb 19, 2015 at 7:16 PM, Phillip Hallam-Baker <[email-masked]
> wrote:

> desirable. It is actually better to let the resolver do the authentication.
​I don't think I agree with this conclusion.  The theory of DNSSEC has
always been that if you can validate the cryptographic bits, that the
answer matches what the zone maintainer put in the zone, and so you don't
care any more where you got the data.  I think that remain pretty powerful,
especially for for the cases after bootstrapping.

> not provide a secure binding to the endpoint.
>
​
So, while I agree that you could construct a topology such that you don't
care where you got to, provided it can prove its the service you want, I
don't think that's the problem we're trying to tackle in this working group
(NDN and friends seem closer).  I think we are concerned with the privacy
of uses of the known-item search that is the DNS.

> There are certainly good reasons for wanting to provide DNSSEC records for
> A/AAAA to the resolver but there isn't a good case for the client checking.
> [Again, TLSA and other security policy records are a totally different
> matter.]
>
> The critical issue here has often been latency--clients have been
>> reluctant to do that in real time, as the resulting increase in latency was
>> bad for operations.  There may be ways to improve that--by having the
>> resolver perform those functions but also consistently provide the client
>> with the data used to verify, so that it can cross-check at some configured
>> rate ("trust, but verify").
>>
>
​So, I think on this part we're using slightly different terms but agree on
the substance.  If you contact the authoritative name servers directly, the
traffic to those servers is traceable even if the question asked is not.
If the authoritative servers themselves serve many different zones, there
may be some difficulty working out what's going on (e.g.
username.microblog.example style services), but generally the traffic to
the authoritative DNS server is revelatory enough.

​Confidential traffic to a large​ aggregator of queries gives you a better
shot at hindering attempts to correlate the queries in to the eventual
traffic out.

> to say 'I have special data for example.com' in trustworthy fashion.
​I'm not sure I understand this bit.  Are you saying that a query from a
client would trigger this disclosure via information in additional data?
Or that it would be discoverable via ​something like an SRV record?  or via
a different, non-DNS protocol?

>> In general, we may want to develop code that allows us to use multiple
>> DNS resolvers, some configured and some provided.  Not only would that
>> raise the costs for attackers attempting to develop client profiles, it
>> gives you a secondary method for checking accuracy when DNSSEC isn't
>> available by using a voting-algorithm style anomaly detection (the large
>> caveat here being the knock-on effect on CDN operations, which may well be
>> returning different results to different resolvers if they have no other
>> client data).
>>
>
​Again, I'm not sure that this group can solve that problem; we are trying
to make sure that the user can ask where Facebook is on the network without
exposing that question to common view and without losing the ability to
confirm that the answer was what Facebook intended.  Past that point, we
move out of DPRIVE territory.

At least in my opinion,

regards,

Ted

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Feb 2015 15:30:36 -0500

On Mon, Feb 23, 2015 at 12:42 PM, Ted Hardie <[email-masked]> wrote:

>> Whose authentication is relevant depends on whether we are doing a layer
>> 5 DNS lookup (A or AAAA) record or a layer 6 DNS lookup (everything else,
>> including TLSA records).
>>

This is actually a bit of a red herring as the only changes being
considered to the protocol that affect DNSSEC is that DPRIV makes it
possible to assume 100% reliability in delivery of the DNSSEC data rather
than the 97% reliability in delivery seen with the legacy protocol. Anyone
aborting connections on DNSSEC validation in the client today is going to
find people stop using their product very quickly.

Its like giving someone a shotgun for their 5th birthday secure in the
knowledge that they don't have any ammo. DPRIV isn't changing the fact that
the gun is pointed at the foot but it is adding ammunition.

Unfortunately, the 'theory of DNSSEC' has never explained what a client is
meant to do if the process fails.

The rule of the game here is that someone has to write a single,
deterministic algorithm that exhibits the desired behavior in every
circumstance. My experience in DKIM was that when most people played the
game they would have two algorithms,, one they proposed for the problem of
stopping spam and the other for ensuring connectivity.

Deciding what to do if you get a TLSA record with a bad signature, or a
missing TLSA record is straightforward: abort the connection because you
have a clear security policy failure.

Aborting the connection for A or AAAA records at the client looks to me
like introducing a DoS channel. It is certainly going to hit a lot of
unreliability due to DNSSEC admin goofs like the ones we have seen on the
IETF's own pages.

> of uses of the known-item search that is the DNS.

Establishing an encryption channel requires us to establish a shared
symmetric key. So we get client-resolver authentication for ~20 bytes of
additional overhead. We should make use of that for the following reasons:

1) Protect a DNSSEC aware client against a DNS spoofing attack on the
client for the 99% of DNS domains that don't have DNSSEC

2) Provide the client with a cheap mechanism for validation before
performing the expensive DNSSEC validation

3) Protect non DNSSEC aware clients.

4) Enable the 'trust at the resolver' model for applications where that is
preferred.

None of this stops folk who are ready to go ahead with the client DNSSEC
validation approach from doing that. All I am saying is that is one model
and not the model that I expect to be common for a very long time to come.

I engineered Private-DNS to reduce the cost of client-side DNSSEC
effectively to zero. We are agreed that should be an option DPRIV makes
possible. What I am saying is that it is an option that might not actually
meet the real security needs so I am not going to design a proposal that
only works that way.

> ​So, I think on this part we're using slightly different terms but agree
> on the substance.  If you contact the authoritative name servers directly,
> the traffic to those servers is traceable even if the question asked is
> not.  If the authoritative servers themselves serve many different zones,
> there may be some difficulty working out what's going on (e.g.

Exactly, if people are concerned about privacy protection they probably
want to hook their browser/device up to some large throughput aggregation
portal.

But that is not the only reason I would expect people to use A DNS protocol
transport that offers confidentiality and integrity enhancements.

I think the likes of a GM or a GE will run their own DPRIV servers to
protect their internal traffic and then do something 'clever' and bound by
a lot of confidentiality agreements to conceal their external traffic to
the authoritative servers.

> a different, non-DNS protocol?

Today a lot of enterprises have split horizon DNS. It is a hack but a
necessary one. The fact that I put orac.hallambaker.com on my Internal
network does not mean that I want the existence of that machine to be
visible to people outside my family.

So lets say I buy a new machine for work and for personal use. I want to be
able to access the following sites:

A) developer.corporate-internal.com
B) portal.corporate-internal.com
C) www.trainspotters.net
D) www.golf.net
E) pornography.com

Where A and B are sites my employer provides that are only visible to
employees. There is no reason for non-employees to know they exist so their
DNS records are behind split horizon DNS.

As an employee I want to be able to get access to the corporate site to do
my job but I don't want my employer to see any non-work related activity
that might be embarrassing like the golf site.

So when I configure my client I would begin by picking my DNS provider
'Comodo.com' which would return some sort of JSON structure describing its
services. Then I would add my employer DNS provider employer.com which
would return a JSON structure saying that it is 'better' for
corporate-internal.com.

This would of course be a one time config operation, set and forget. Unless
of course I changed employer in which case I would change my settings.

> move out of DPRIVE territory.

The problem comes when the site is russian-business-network.com and the
user definitely does not want to go there and get their machine infected.

Like it or not, the mere fact that someone has bought a domain name does
not mean that I want my machines to be able to connect to them.

Every security problem has a simple solution if you decide that it is the
only problem you are interested in solving.