Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative-trust-anchors-00.txt
[ Apologies for delay in getting to these. The draft-cutoff is a wonderful motivator! ] On Tue, Dec 16, 2014 at 12:57 PM, Evan Hunt wrote: > On Tue, Dec 16, 2014 at 10:47:33AM +, Tony Finch wrote: >> That is a good point. Happily I think the draft already makes it hard for >> operators to do that, since an NTA will be automatically removed if its >> zone validates (section 10). > > Thank you for pointing this out, Tony; I'd missed it when I read the draft, > and it would have been embarrassing if I'd gone ahead and posted my planned > comment to the effect that there ought to be text like this. :) > > > I will revise my planned comments to say there ought to be MORE text > like this. Mwah, weasel words :-) DONE. > > First, some clarification of of "attempt to validate the zone" is probably > called for. A resolver can't validate the entire zone; it can only spot- > check. BIND's method, for the record, is to send a periodic query for type > SOA at the NTA node; if it gets a response that it can validate (whether > the response was an actual SOA answer or a NOERROR/NODATA with appropriate > NSEC/NSEC3 records, which would imply that the NTA was placed at a node > which was not a zone cut [1]), the NTA is presumed no longer to be necessary > and is removed. (Note that under some circumstances, this is undesirable > behavior -- for example, if www.example.com had a bad signature, but > example.com/SOA was fine -- so we also provide a "force" option to set an > NTA which is *not* subject to this periodic spot-check.) DONE. Thanks for the text, I stole much of it, while making it clear that this is one way of implementing this. > > Second, I would upgrade the recommendation from "optimally this is > automatic" to at least a SHOULD, and maybe a MUST. DONE. > > Third, it's implied in section 8, but I would add to section 10 that > NTAs MUST expire automatically when their configured lifetime ends, and > that this lifetime MUST NOT exceed a week. DONE. I did this as a SHOULD, but could be convinced to change it to a MUST. I think that the operator running the recursive server has the final say, and so am uncomfortable forcing with a MUST, but am very much on the fence here. > My biggest fear with NTAs is > that someone will configure one and then forget about it forever. There > should be an expiry date associated with every NTA, and it should be > enforced by code. DONE. Oh, ok, I've been convinced and have changed the above SHOULD to a MUST :-) > > One final comment: in appendix A.2, the "rndc nta" description is > outdated and should now read: > > nta -dump > List all negative trust anchors. > nta [-lifetime duration] [-force] domain [view] > Set a negative trust anchor, disabling DNSSEC validation > for the given domain. > Using -lifetime specifies the duration of the NTA, up > to one week. The default is one hour. > Using -force prevents the NTA from expiring before its > full lifetime, even if the domain can validate sooner. > nta -remove domain [view] > Remove a negative trust anchor, re-enabling validation > for the given domain. DONE. Excellent, thank you for the text. W > > [1] ... which we presume to be legal, but maybe ought to be clarified > in the draft. Trust anchors are always at a zone apex; negative trust > anchors don't strictly need to be. > > -- > Evan Hunt -- e...@isc.org > Internet Systems Consortium, Inc. > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative-trust-anchors-00.txt
> Em 16/12/2014, à(s) 15:54:000, Warren Kumari escreveu: > > On Mon, Dec 15, 2014 at 9:17 PM, Rubens Kuhl wrote: >> >> My feedback to a possible -01 version is to add something related to not >> consider NTAs for the upper hierarchy of a failed DNSSEC domain. For >> instance, even if I see a good number of .gov domains failed DNSSEC, adding >> a NTA configuration for .gov would not be considered good operational >> practice, unless .gov itself starts failing DNSSEC validation. >> >> I know no RFC can determine what ops really end up doing, but not being >> allowed to claim that as a prescribed practice has some value. > > > We had tried to capture that with: > "It does not and should not involve turning off validation more broadly." > and > "Finally, a Negative Trust Anchor SHOULD be used only in a specific > domain or sub-domain and MUST NOT affect validation of other names up > the authentication chain. " > > I thought that we also had some text that said that the NTA should > cover the minimum necessary to fix the issue, but I cannot find that > text at the moment - we may have removed it because it was very > klunky. Anyway, do the above bits cover what you wanted, or do you > think we need to be more explicit? I think we need to be more explicit. Not from a formal perspective, which is truly addressed, but as a mean to say "don't use this RFC to justify adding .gov to NTA. Do that on your own and live with it.". Rubens ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative-trust-anchors-00.txt
On Tue, Dec 16, 2014 at 10:47:33AM +, Tony Finch wrote: > That is a good point. Happily I think the draft already makes it hard for > operators to do that, since an NTA will be automatically removed if its > zone validates (section 10). Thank you for pointing this out, Tony; I'd missed it when I read the draft, and it would have been embarrassing if I'd gone ahead and posted my planned comment to the effect that there ought to be text like this. :) I will revise my planned comments to say there ought to be MORE text like this. First, some clarification of of "attempt to validate the zone" is probably called for. A resolver can't validate the entire zone; it can only spot- check. BIND's method, for the record, is to send a periodic query for type SOA at the NTA node; if it gets a response that it can validate (whether the response was an actual SOA answer or a NOERROR/NODATA with appropriate NSEC/NSEC3 records, which would imply that the NTA was placed at a node which was not a zone cut [1]), the NTA is presumed no longer to be necessary and is removed. (Note that under some circumstances, this is undesirable behavior -- for example, if www.example.com had a bad signature, but example.com/SOA was fine -- so we also provide a "force" option to set an NTA which is *not* subject to this periodic spot-check.) Second, I would upgrade the recommendation from "optimally this is automatic" to at least a SHOULD, and maybe a MUST. Third, it's implied in section 8, but I would add to section 10 that NTAs MUST expire automatically when their configured lifetime ends, and that this lifetime MUST NOT exceed a week. My biggest fear with NTAs is that someone will configure one and then forget about it forever. There should be an expiry date associated with every NTA, and it should be enforced by code. One final comment: in appendix A.2, the "rndc nta" description is outdated and should now read: nta -dump List all negative trust anchors. nta [-lifetime duration] [-force] domain [view] Set a negative trust anchor, disabling DNSSEC validation for the given domain. Using -lifetime specifies the duration of the NTA, up to one week. The default is one hour. Using -force prevents the NTA from expiring before its full lifetime, even if the domain can validate sooner. nta -remove domain [view] Remove a negative trust anchor, re-enabling validation for the given domain. [1] ... which we presume to be legal, but maybe ought to be clarified in the draft. Trust anchors are always at a zone apex; negative trust anchors don't strictly need to be. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative-trust-anchors-00.txt
On Mon, Dec 15, 2014 at 9:17 PM, Rubens Kuhl wrote: > > My feedback to a possible -01 version is to add something related to not > consider NTAs for the upper hierarchy of a failed DNSSEC domain. For > instance, even if I see a good number of .gov domains failed DNSSEC, adding a > NTA configuration for .gov would not be considered good operational practice, > unless .gov itself starts failing DNSSEC validation. > > I know no RFC can determine what ops really end up doing, but not being > allowed to claim that as a prescribed practice has some value. We had tried to capture that with: "It does not and should not involve turning off validation more broadly." and "Finally, a Negative Trust Anchor SHOULD be used only in a specific domain or sub-domain and MUST NOT affect validation of other names up the authentication chain. " I thought that we also had some text that said that the NTA should cover the minimum necessary to fix the issue, but I cannot find that text at the moment - we may have removed it because it was very klunky. Anyway, do the above bits cover what you wanted, or do you think we need to be more explicit? W > > > Rubens > >> On Dec 15, 2014, at 11:15 PM, internet-dra...@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Domain Name System Operations Working Group >> of the IETF. >> >> Title : Definition and Use of DNSSEC Negative Trust Anchors >> Authors : Paul Ebersman >> Chris Griffiths >> Warren Kumari >> Jason Livingood >> Ralf Weber >> Filename: draft-ietf-dnsop-negative-trust-anchors-00.txt >> Pages : 17 >> Date: 2014-12-15 >> >> Abstract: >> DNS Security Extensions (DNSSEC) is now entering widespread >> deployment. However, domain signing tools and processes are not yet >> as mature and reliable as those for non-DNSSEC-related domain >> administration tools and processes. Negative Trust Anchors >> (described in this document) can be used to mitigate DNSSEC >> validation failures. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/ >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-00 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> ___ >> 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 -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative-trust-anchors-00.txt
Rubens Kuhl wrote: > > My feedback to a possible -01 version is to add something related to not > consider NTAs for the upper hierarchy of a failed DNSSEC domain. For > instance, even if I see a good number of .gov domains failed DNSSEC, > adding a NTA configuration for .gov would not be considered good > operational practice, unless .gov itself starts failing DNSSEC > validation. That is a good point. Happily I think the draft already makes it hard for operators to do that, since an NTA will be automatically removed if its zone validates (section 10). Tony. -- f.anthony.n.finchhttp://dotat.at/ Fisher, German Bight: West or northwest 6 to gale 8, backing southwest 5 to 7. Rough or very rough. Squally showers, rain later. Good, occasionally moderate. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] I-D Action: draft-ietf-dnsop-negative-trust-anchors-00.txt
My feedback to a possible -01 version is to add something related to not consider NTAs for the upper hierarchy of a failed DNSSEC domain. For instance, even if I see a good number of .gov domains failed DNSSEC, adding a NTA configuration for .gov would not be considered good operational practice, unless .gov itself starts failing DNSSEC validation. I know no RFC can determine what ops really end up doing, but not being allowed to claim that as a prescribed practice has some value. Rubens > On Dec 15, 2014, at 11:15 PM, internet-dra...@ietf.org wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Domain Name System Operations Working Group > of the IETF. > > Title : Definition and Use of DNSSEC Negative Trust Anchors > Authors : Paul Ebersman > Chris Griffiths > Warren Kumari > Jason Livingood > Ralf Weber > Filename: draft-ietf-dnsop-negative-trust-anchors-00.txt > Pages : 17 > Date: 2014-12-15 > > Abstract: > DNS Security Extensions (DNSSEC) is now entering widespread > deployment. However, domain signing tools and processes are not yet > as mature and reliable as those for non-DNSSEC-related domain > administration tools and processes. Negative Trust Anchors > (described in this document) can be used to mitigate DNSSEC > validation failures. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-00 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > ___ > 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
[DNSOP] I-D Action: draft-ietf-dnsop-negative-trust-anchors-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Domain Name System Operations Working Group of the IETF. Title : Definition and Use of DNSSEC Negative Trust Anchors Authors : Paul Ebersman Chris Griffiths Warren Kumari Jason Livingood Ralf Weber Filename: draft-ietf-dnsop-negative-trust-anchors-00.txt Pages : 17 Date: 2014-12-15 Abstract: DNS Security Extensions (DNSSEC) is now entering widespread deployment. However, domain signing tools and processes are not yet as mature and reliable as those for non-DNSSEC-related domain administration tools and processes. Negative Trust Anchors (described in this document) can be used to mitigate DNSSEC validation failures. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
