Howdy,
On Thu, Feb 19, 2015 at 7:20 AM, Phillip Hallam-Baker
<phill(_at_)hallambaker(_dot_)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 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). 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.
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. 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").
The other issue you raise--can you trust the resolver not to forward the
data to some third party? 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. 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. 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, though, I think this conversation is really squarely in DPRIVE
territory, so I'd suggest follow-ups there.
Ted
1) The resolver is acknowledged as being a trusted service
2) Some form of crypto is added between the transport and application
layer in the client-resolver protocol.
So far we seem to have focused on the second issue. But that is the easy
one. There is really nothing at all special or interesting in the way TLS
or DTLS or my proposal add crypto to packets. That part of the spec can be
implemented in an afternoon.
The hard part is the consequences of the first issue. Whether or not we
want to trust the resolver to give us the right data (integrity), privacy
demands that we trust the resolver not to disclose the data
(confidentiality).
Question: Is anyone proposing that we can achieve DNS privacy while
maintaining the current practice of the client defaulting to the DNS server
advertised in DHCP?
I don't think that is the case. But I thought best to check.
Once we decide that the client is going to have a persistent relationship
with a specific DNS service we face the problem of how to establish and
secure that relationship.
The main difference between my proposal and the VeriSign/USC proposal is
how we go about achieving that.
We are both proposing to use TLS as a basis for this interaction. The
difference being that I am proposing to use the TLS infrastructure and PKI
path math once to establish a long term credential and the VeriSign
proposal is to use TLS on each client-resolver interaction.
Now before making a choice between one approach or the other, I strongly
recommend people look at what is being proposed in ACME. While this looks
like a completely different problem (PKI credential provisioning versus
service discovery), it actually isn't.
In both cases we have a hard problem and an easy problem. The easy part
being the bit that is different and the hard part being how to establish
and maintain the binding between the client and a trusted service.
I think that if we could factor that part out and make it a reusable
component, we would be doing the IETF a big favor.
The reason I don't want to use TLS for this is that neither TLS not PKIX
is a good tool for this particular job. PKIX