A different way to look at the problem

[Phillip Hallam-Baker <[e-mail]>]

DNS privacy requires us to make two changes to the DNS protocol.

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