On Thu, Feb 19, 2015 at 1:21 PM, Ted Hardie <ted.i...@gmail.com> wrote:
> Howdy,
>
> On Thu, Feb 19, 2015 at 7:20 AM, Phillip Hallam-Baker <
> ph...@hallambaker.com> 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.
>
>
_______________________________________________
dns-privacy mailing list
dns-privacy@ietf.org
https://www.ietf.org/mailman/listinfo/dns-privacy
