On Wed, Jul 8, 2015 at 2:08 PM, Ben Campbell <b...@nostrum.com> wrote: > Ben Campbell has entered the following ballot position for > draft-ietf-dnsop-negative-trust-anchors-10: No Objection >
Thank for you review. I have posted a new version in github at https://github.com/wkumari/draft-livingood-dnsop-negative-trust-anchors > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > -- General: > > This is just an observation, since this is informational draft. I do not > expect or suggest any action on it. (But if it had been standards or BCP > track, I might have made it a discuss.) If I understand this correctly, > it suggests that resolvers be configured to stop validating known broken > names. This of course has the risk of circumventing the protection that a > domain intended by using DNSSEC in the first place. The draft does > discuss those risks. But I would have been happier to have seen something > with a tone more along "We know you are going to do this thing, and it's > probably better than globally switching to a non-validating resolver-- so > here's the risks, and here's some ways to minimize those risks" (which I > think might have been good BCP material) rather than "This is a good > practice to work around broken DNSSEC configurations." > > -- section 1.2, last paragraph, last sentence: > Out of curiosity, has this been an issue? Erm, I'm a bit lost -- Section 1.2 is only really a header. I'm not sure if you mean section 1.2.1, last paragraph, last sentence or 1.2.3, last paragraph, last sentence. Both are true / have been issues. If 1.2.1: "For example, it is conceivable that a domain may be DNSSEC signed properly, and one vendor's DNS recursive resolvers will validate the domain but other vendors' software may fail to validate the domain." Yup, this has happened a few times -- there are part of the DNSSEC specs that e.g BIND and Unbound interpreted (or implemented) differently. An example: http://comments.gmane.org/gmane.network.dns.bind.user/49875 If 1.2.3: "Thus, switching to a non-validating resolver to restore access to a domain that fails DNSSEC validation is not a recommended practice, is bad advice to others, is potentially harmful to end user security." Yup, unfortunately this seems to be the standard user behavior. During the standard example of Comcast and NASA ( http://www.internetsociety.org/deploy360/blog/2012/01/comcast-releases-detailed-analysis-of-nasa-gov-dnssec-validation-failure/ ) a bunch of users changed their resolvers. This happens time and time again... > > -- 2, 2nd paragraph: > Can an operator be reasonably expected to be able to confirm that a > domain is being operated by its rightful owner? In many cases, yes. For example, if the website says: "Hacked by Syrian Electronic Army" (http://arstechnica.com/security/2015/06/us-army-website-defaced-by-syrian-electronic-army/) you can be fairly sure it is *not* being operated by the rightful owner :-) More seriously, usually you *can* tell -- for example, if the signatures have expired but everything else remained the same it is likely operated by the rightful owner. Also, during the recent .ke (Kenya) DNSSEC issue ( http://ianix.com/pub/dnssec-outages/20150331-ke/ ) various people were in contact with the ccTLD operator. There are also various things like passive DNS services which keep historical data on things like nameservers. If the NS hasn't changed, you can be fairly sure it is being operated by the owner... > > -- 2, 2nd to last paragraph: > > Since the requirement to limit the time an NTA is used is a MUST, it > seems like the ability to configure that time should also be a MUST. Hmmm.... I'm not sure I agree. The document says: "NTAs MUST expire automatically when their configured lifetime ends. The lifetime MUST NOT exceed a week. " An implementation *could* always install one for a week, and the operator could remove it before it automatically expires. If I'm installing one I would install it for the full week and then check it every few hours, and remove it before it expires. I cannot think of a scenario where I'd know ahead of time that the problem will be all solved in e.g 3 days, and so choose a shorter lifetime. If I *did* think it would be solved in 3 days I'd still set it for a week and then have a calendar reminder / bug in my bug tracking system that went "Ping" to make me check it manually. Having the NTA expire before the issue is resolved makes the domain go bogus again, and users become frustrated... > > -- 2, last paragraph: > > Why is the requirement not to affect another branch weaker than the > requirement not to affect other names higher up the same branch? You may have an example like: example.net IN NS ns1.example.com If I install an NTA for example.com (and so make ns1.example.com alive again) example.net will now work again, so fixing something in one branch affects something in another branch. What we are do not want to have happen is that installing an NTA for example.com disables validation for .com -- it is probably possible that something like: .com IN NS foo.bar.example.com and foo.bar.example.com becomes bogus. Installing an NTA *does* now affect names higher in the tree, but this is (I think) pathological and not worth trying to address. > > -- 4, first paragraph, last sentence: > > This seems to favor erring on the side of keeping the NTA. I think > security would suggest erring on the side of removing the NTA. I think it is actually more of a stability / "know what you are doing before mucking with stuff" argument. The next sentence says: "Once all testing succeeds, an NTA should be removed as soon as is reasonably possible." It you ends up in a situation where e.g the master is serving good data, but the 3 slaves are all serving expired signatures and the operator happens to query the master and remove the NTA you may end up in a situation where 3/4 queries die and 1/4 succeed. This will end up creating user confusion and a very difficult to debug situation. The above is mainly a "hey, before removing an NTA, make sure you aren't shooting yourself in the foot" reminder. > > Editorial and Nits: > > -- If you plan to use capitalized 2119 terms, please add the appropriate > boilerplate and a 2119 reference. Doh! Can't believe I missed that -- I'm sure I ran the nit checker... anyway... I will add an editors note to remind me to do so before publication -- I don't want to add it in properly now because it will throw off the section numbers, confusing things during the rest of the IESG feedback... > > -- section 4, first paragraph: "It is therefore RECOMMENDED that NTA > implementors SHOULD" > redundant 2119 keywords (RECOMMENDED and SHOULD ) Oooh, good catch. Thank you. Done. > > -- 7, paragraph 4, last sentence: > I suggest adding “At the time of this writing…”, and add additional text > to remind people these may change over time. Good point. I changed it to: "At the time of this writing are several tools to do this, including: DNSViz (http://dnsviz.net) Verisign DNSSEC debugger (http://dnssec-debugger.verisignlabs.com) zonemaster (http://www.zonemaster.fr, https://github.com/dotse/zonemaster) most of these tools are open source and can be installed locally. However, using the tools over the Internet has the advantage of providing visibility from a different point. This is an incomplete list, and it is expected that additional tools will be developed over time to aid in troubleshooting DNSSEC issues. " > > -- 7: > This section jumps into 2nd person. I don’t want to stand on formality, > but it would be good to keep a consistent tone across the draft. Yup, a different author wrote that bit. I will update it to fix the tone (in the next commit). W -- 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
