Re: [DNSOP] Call for Adoption for draft-wessels-edns-key-tag
All The Call for Adoption is over, and we've gotten good feedback and people agreeing to do reviews (thank you!). Authors, please submit the draft-ietf-dnsop-key-tag draft. thanks tim On 11/28/15 7:45 AM, 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
Re: [DNSOP] Call for Adoption for draft-wessels-edns-key-tag
Whoops, I thought I'd already responded to this, but apparently not... On Sat, Nov 28, 2015 at 7:45 AM 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. > I am willing to author, contribute text, edit, review, chase people, fold, mutilate and spindle. Whatever is helpful. This document has large overlap with draft-wkumari-dnsop-trust-management-01 - "Signalling of DNS Security (DNSSEC) Trust Anchors". It seems silly to work on two approaches to the same issue, so I am planning on dropping draft-wkumari-dnsop-trust-management. Some of the introductory text / other text may be helpful to incorporate into edns-key-tag (to avoid having to rewrite it). W > > 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
Re: [DNSOP] Call for Adoption for draft-wessels-edns-key-tag
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
Re: [DNSOP] Call for Adoption for draft-wessels-edns-key-tag
On Mon, Nov 30, 2015 at 05:29:53PM +, Wessels, Duane wrote: > As I've said a number of times before, the edns-key-tag proposal is modelled > after RFC 6975, which does the same thing for algorithms. If it works for > algorithms why wouldn't it work for key tags? Does it work? Has anyone deployed 6975? We have an experimental implementation of it in a development branch for BIND, but we decided not to release it because the benefits didn't seem commensurate with the extra complexity and packet size. I haven't checked to see whether any other implementations are using it. We've certainly encountered operational difficulties when sending unknown EDNS opcodes to broken servers. Mark has been pushing hard on this issue, and things are getting better, but it's still a problem. > > without needing the entire ecosystem to be upgraded > > which this proposal requires. > > I disagree with this characterization that "the entire ecosystem" needs > to be upgraded. Yes a non-key-tag-aware recursive won't know to forward > the option, but this is true for all EDNS options. But it isn't true for query names. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption for draft-wessels-edns-key-tag
Hi Mark, > On Nov 29, 2015, at 6:55 PM, Mark Andrews wrote: > > > > Some feedback with respect to installed trust anchors is needed. > > Whether this is the correct solution I'm not sure. It requires > updating all resolvers in the resolution path to both cache and > relay tags. I'm not sure where you got the idea that a resolver would cache key tags. The document I've drafted does not propose that. It does propose that a recursive would forward key tag values for cache misses. > The same can be achieved by encoding the tags into > qnames/qtypes Yes, perhaps. But then we start to run into all the problems of special use and non-service names, don't we? As I've said a number of times before, the edns-key-tag proposal is modelled after RFC 6975, which does the same thing for algorithms. If it works for algorithms why wouldn't it work for key tags? > without needing the entire ecosystem to be upgraded > which this proposal requires. I disagree with this characterization that "the entire ecosystem" needs to be upgraded. Yes a non-key-tag-aware recursive won't know to forward the option, but this is true for all EDNS options. DW > > e.g. > _ta_./NULL > > Mark > > In message <5659a1db.5090...@gmail.com>, Tim Wicinski writes: >> >> 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 > -- > 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 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption for draft-wessels-edns-key-tag
Some feedback with respect to installed trust anchors is needed. Whether this is the correct solution I'm not sure. It requires updating all resolvers in the resolution path to both cache and relay tags. The same can be achieved by encoding the tags into qnames/qtypes without needing the entire ecosystem to be upgraded which this proposal requires. e.g. _ta_./NULL Mark In message <5659a1db.5090...@gmail.com>, Tim Wicinski writes: > > 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 -- 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
