Re: A different way to look at the problem

[Ted Hardie <[e-mail]>]

Howdy,

On Thu, Feb 19, 2015 at 7:20 AM, Phillip Hallam-Baker <[e-mail]
> 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
>
>
>
>