Re: [DNSOP] Ben Campbell's No Objection on draft-ietf-dnsop-negative-trust-anchors-10: (with COMMENT)

[Warren Kumari <[e-mail]>]

On Wed, Jul 8, 2015 at 2:08 PM, Ben Campbell <[e-mail]> 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