On Mon, Jul 7, 2014 at 12:42 PM, Paul Vixie <p...@redbarn.org> wrote:
> > there are two kinds of channel in dns queries. (i'm not going to account > for updates or zone transfers here.) > > one channel is from the stub to the recursive. it's pointless to add > secrecy to that unless a stub wants to use a very distant name server, > Not at all. Trying to get any sort of privacy guarantee while sending your DNS queries to any agent or service that you have not carefully selected and decided to trust is the futile quest. If we are going to have privacy then the DNS queries are going to be directed at a trusted resolver and not the closest resolver on the network. > the other channel is from the recursive to the authoritative. these > transactions contain very little PII, since the IP address of the end-user > is not present, and since cache re-use events are not present, only > cache-miss events. > Agreed. However that is based on a lot of assumptions on how the DNS works that are currently true but need not be true in the future. If you have a DNS server that is advertising names that are geolocation dependent then the caching assumption breaks down and you start to leak privacy sensitive information. It would be a mistake to accept a DNS privacy solution that unnecessarily boxes the protocol in for future developments. You might want to make use of a PKI to set up credentials for the stub-resolver case. And you might well want to make use of the WebPKI etc. to achieve that in a convenient way without falling into an infinite regression trap of 'what is this anyway'. But that approach does not meet every use case. Once the credentials are set up you don't need that PKI any more because the trust relationship is now a binding between the end user's client and the service. In sxs-connect the original design brief was to support omnibroker which (among other things) allows the broker to advise on choice of WebPKI roots rather than rely on the browser choice. So there are mechanisms that don't rely on PKI to establish that binding which might well be preferred in an enterprise. In fact the reason I split that part out was that I realized that almost all the complexity in the problem was setting up that initial relationship and that the problem was much more general. The resolver to authoritative loop is very different. You probably do want to ground that in DNSSEC or else what is it for? Now you can't necessarily use DANE for that directly because the TLSA record is specified for TLS and the authors decided (against advice) to make it more than just a publication mechanism for keys. But you could certainly adapt the spec without much trouble and you might just want to publish raw keys.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
