On 19 Aug 2014, at 10:41, Paul Wouters <[email protected]> wrote: > Note that DNSSEC provides authenticity of DNS data. So the only part of > authentication that you gain is about privacy (encryption) of data, not > about data integrity.
Just a small word of caution, here: the gap between DNSSEC does and DNSSEC can is deployment, and deployment to date has been modest. [With a handful of glorious exceptions, TLDs that have made DNSSEC available to date have struggled to get more than a handful of registrants to do anything with it. With a similarly-glorious handful of exceptions, registrars who have the ability to ship DS/DNSKEY data upstream for their customers have declined to let their customers do so. Most resolvers don't have a trust anchor robustly installed, or are not configured for or cable of validation in any case. Things are getting better; this is intended to be realism, not pessimism.] When we say "we don't have to worry about X because DNSSEC" we are in some sense making our proposals operationally dependent on widespread DNSSEC deployment. Perhaps this is not always a bad idea, since DNSSEC needs more reasons for people to deploy it; on the other hand, in some cases perhaps it *is* a bad idea, since gating deployment of your own protocol on something that is struggling seems like a losing proposition unless you're quietly placing side bets the other way and intend to throw the race. It's possible to detach DNSSEC deployment from privacy. We think we are doing that in dns-onion. (Granted, that proposal does not even attempt to address privacy between stub and resolver.) Just a thought. Joe _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
