> On 6 Mar 2018, at 9:31 am, Wessels, Duane <dwess...@verisign.com> wrote: > > >> On Mar 3, 2018, at 2:32 PM, Geoff Huston <g...@apnic.net> wrote: >> >> I guess that the knowledge that resolver X trusts a key with a hash value of >> Y does not leave me much the wiser in terms of exploitable knowledge about >> the (in)security of that resolver. > > If there is a key or algorithm compromise for key Y then that seems like > useful information to an attacker. > > >> >> >> Aren’t we getting into issues of DNS privacy here rather than the sentinel >> per se? Its not as if the sentinel process calls for any change in the DNS >> query response mechanism. There is no forking off information to third >> parties in any form in this draft - the user agent asks a particular query >> form to its DNS resolvers and the user agent will get a response. As far as >> I can tell, in the same way that the DNS itself admits third parties to look >> over the shoulder of DNS transactions in every other DNS query and response, >> this is no different as far as I can tell. And in the same way as various >> DNS privacy mechanisms make it harder for third parties to eavesdrop on user >> activity, this is no different, and the user agent can take the same >> measures to attempt to increase the eavesdropping degree of difficulty on >> sentinel queries as much as any other DNS query that the user agent may make. >> >> It seems I must be missing something here that has triggered your concerns >> Duane - could you explain them in a little more details? > > > No, I wasn't thinking of eavesdropping. I'm thinking whatever Geoff can do, > a motivated nation state can just as easily do. For example... > > The country of Freedonia decides it doesn't trust the ICANN-controlled > Internet and goes off and builds its own root server system and signs its > version of the root zone with its own set of DNSSEC keys. Persons and > organizations operating in Freedonia are required to install this trust > anchor and remove the IANA trust anchor. kskroll sentinel provides a way for > Freedonia to monitor compliance with this policy. They can use known > techniques (ads, embedded javascript, unique URL hostnames) to learn which > keys are in the trust anchor set for resolvers/devices within (and even > outside) its realm.
And recursive servers will just be modified to lie to hide non compliance. Also how do you prevent there being minor differences in the zone content which are identifiable? > DW > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
