All, I think this is a nice approach for gaining confidence in a rollover of a key that acts as a trust anchor. It can even be used to detect validators that have missed the rollover.
I would however be cautious with using the information as an event trigger. The draft says The goal of these options is to signal new trust anchor uptake in client code to allow zone administrators to know when it is possible to complete a key rollover in a DNSSEC-signed zone. Since the zone administrator can impossibly know whether all validators have signalled its trust anchor, you cannot use this information to speed up a key rollover. Also, the zone administrator already knows when to complete the key rollover by calculating the appropriate interval times (ttl, propagation, etc). This signalling does not add anything to that knowledge. Then some words about the uniqueness of key tags. The draft already mentions it briefly, but just within the same zone. Since the queries will visit various name servers, authoritative for different zones, how do you deal with such key tag clashes. For example, a validator has the root key set as a trust anchor, and the root and myzone.nl both have DNSSEC keys with tag 12345. Does the zone administrator of myzone.nl now also believe that its key is installed as a trust anchor? Also, like the draft also mentioned, these queries can be created by anyone and there is no way of authenticating the validator, so anyone can signal key tags to give a zone administrator a false sense of confidence. How could an administrator act on that such that valid signalling stays useful? To summarize, I am arguing that perhaps more bits than just the keytag must be signalled, and that more words should be spend on how to deal with the malicious key (tag) signalling. Best regards, Matthijs On 28-11-15 13:45, Tim Wicinski wrote: > > This starts a Call for Adoption for draft-wessels-edns-key-tag > > The draft is available here: > https://datatracker.ietf.org/doc/draft-wessels-edns-key-tag/ > > There was unanimous support this during the meeting in Yokohama, so this > is more of a formality, unless we hear strong negative reaction. > > However, please indicate if you are willing to contribute text, review, > etc. > > Since there was unanimous support for this draft, I am going with a one > week Call for Adoption. Please feel free to protest if anyone feels this > is out of line. > > This call for adoption ends 7 December 2015. > > Thanks, > tim wicinski > DNSOP co-chair > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
