Howdy,
On Thu, Feb 19, 2015 at 7:20 AM, Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx> 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.
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
Ted
1) The resolver is acknowledged as being a trusted service2) 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