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

["Ben Campbell" <[e-mail]>]

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

Ben.

On 8 Jul 2015, at 21:59, Warren Kumari wrote:

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

[...]

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

That one, sorry. Thanks for the reference.

[...]


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

Okay. I accept that an operator can make reasonable decision here in 
many cases.
>>
>> -- 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...

Okay.

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

Ah, I hadn't considered that case.

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

Agreed.

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

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

[...]

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

That works for me.

[...]