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

From: "Ben Campbell" <[email-masked]>
Date: Wed, 08 Jul 2015 11:08:34 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-dnsop-negative-trust-anchors-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-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?

-- 2, 2nd paragraph:
Can an operator be reasonably expected to be able to confirm that a
domain is being operated by its rightful 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.

-- 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?

-- 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.

Editorial and Nits:

-- If you plan to use capitalized 2119 terms, please add the appropriate
boilerplate and a 2119 reference.

-- section 4, first paragraph: "It is therefore RECOMMENDED that NTA
implementors SHOULD"
redundant 2119 keywords (RECOMMENDED and SHOULD )

-- 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.

-- 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.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 8 Jul 2015 22:59:30 -0400

> 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

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...

> 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...

> 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...

> 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.

> 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.

> 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...

> redundant 2119 keywords (RECOMMENDED and SHOULD )

Oooh, good catch. Thank you. Done.

> 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.
"

> 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

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 08 Jul 2015 22:10:39 -0500

Hi, thanks for the response. Comments inline--I've deleted text that 
doesn't seem to require further discussion.

Ben.

> https://github.com/wkumari/draft-livingood-dnsop-negative-trust-anchors

[...]

> An example: 
> http://comments.gmane.org/gmane.network.dns.bind.user/49875
>

That one, sorry. Thanks for the reference.

[...]

> you can be fairly sure it is *not* being operated by the rightful

:-)

> being operated by the owner...

Okay. I accept that an operator can make reasonable decision here in 
many cases.
> the issue is resolved makes the domain go bogus again, and users

Okay.

> branch affects something in another branch.

Ah, I hadn't considered that case.

> and not worth trying to address.

Agreed.

> aren't shooting yourself in the foot" reminder.

After re-reading some of the other text about determining when to remove 
an NTA, I'm okay with this.

[...]

> time to aid in troubleshooting DNSSEC issues.

That works for me.

[...]

---

From: [email-masked] (Paul Ebersman)
Date: Mon, 20 Jul 2015 16:32:15 +0200

Thanks for the comments and input.

bcampbell> Can an operator be reasonably expected to be able to confirm
bcampbell> that a domain is being operated by its rightful owner?

A fair amount of the time, yes. I run the DNS team for Comcast and we've
had pretty good luck getting to zone owners. Better than I'd expected,
to be honest.

bcampbell> This seems to favor erring on the side of keeping the NTA. I
bcampbell> think security would suggest erring on the side of removing
bcampbell> the NTA.

Operationally painful without a noticable improvement in
security. Checking that the FQDN now validates would be done the same
way it was done initially, so we should have the same confidence level
that an NTA is still or is now not necessary.