Re: [DNSOP] Working Group Last Call for draft-ietf-dnsop-negative-trust-anchors

[Warren Kumari <[e-mail]>]

... and now I'm replying to the rest of the comments.

I've integrated them and posted a new version with the clarifications
on a *positive* **trust anchor** under an NTA.
I'm not very happy with the text I added, if others have better text
happy to consider it...

Huge thanks to Jinmei for the careful review, catching this corner
case, and providing helpful text...

More comments inline.


On Mon, May 4, 2015 at 2:25 PM, 神明達哉 <[e-mail]> wrote:
> At Mon, 27 Apr 2015 18:58:10 -0400,
> Tim Wicinski <[e-mail]> wrote:
>
>> This starts a Working Group Last Call for Adoption for
>> draft-ietf-dnsop-negative-trust-anchors
>
> (I guess this is "for Publication", not "for Adoption").
>
> Also, have we decided to publish it as an Informational document?  I'm
> not opposed to it, but this document contains some normative text and
> affects inseparability in some sense, so a standard truck seems to be
> a more appropriate choice for me.
>

I personally don't have a strong opinion here. I think that the
authors figured that it "felt" more informational, and mainly (in our
view) provided advice to operators -- but, we are perfectly happy to
change it to Std if that's what the chairs would like...


>> Current versions of the draft is available here:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-negative-trust-anchors/
>>
>> https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-04
>>
>> Please review the draft and offer relevant comments. Also, if someone
>> feels the document is *not* ready for publication, please speak out with
>> your reasons
>
> I do not think it's ready for publication yet.
>
> I'd like to see a discussion on whether it really makes sense that an
> NTA for a domain name even disables a positive trust anchor below the
> name.  I made more specific comment on this in a separate message:
> http://www.ietf.org/mail-archive/web/dnsop/current/msg14170.html
> (with some other comments on the 04 version of the draft).
>

So, I've heard back from some of the other authors (and Evan, one of
the implementors), and what we'd all assumed / understood was what you
also believe is the "right thing". Since the root is signed we haven't
really been seeing many manually configured trust anchors, and so we
hadn't really discussed it much.

If there is a *positive* *trust anchor* for foo.bar.baz.example, it
takes precedence over a negative trust anchor at baz.example. The
mental model I've been using is "just pretend that there is no DS in
the parent" when you see an NTA.

So, now all I need to do is try craft some text (and probably an
example to illustrate).
There are number of places where I'll have to make some changes to
clarify this. I've just posted a new version that somewhat clarifies
this, but more text gratefully accepted...


> I also think Appendix B needs more editorial cleanups.  Those
> editorial matters may not be a showstopper by themselves, but I guess
> it's better to fix them before sending it to the IESG.
>


Fair. I'll do those. I may post a new version with the larger changes
first, as they may need more discussion.

> A couple of other comments on version 4:
>
> - Section 4:
>    It is therefore
>    recommended that NTA implementors should periodically attempt to
>    validate the domain in question, for the period of time that the
>
>   I guess this 'recommended' may be better RFC2119 capitalized, i.e.,
>   "RECOMMENDED".  Not a strong opinion, but it seems to me to be more
>   aligned with general tone and other usage of RFC2119 keywords of
>   this section.

DONE.

I now have "It is therefore RECOMMENDED that NTA implementors SHOULD
periodically attempt to validate the domain in question..."
Is that what folk would like?

>
> - Section 4: likewise, maybe s/should/SHOULD/
>    When removing the NTA, the implementation should remove all cached
>    entries below the NTA node.

DONE.
Looks good.


>
> Editorial and minor comments:
>
> - Section 3: there's an awkward blank line (and spaces) before the
>   reference:
>    names for a Negative Trust Anchor.  For example, Unbound calls their
>    configuration "domain-insecure."
>
>    [Unbound-Configuration]

DONE.
Weird...


>
> - Section 7.1: s/has have/has/


DONE.
Good catch.

>    Thus, there may be a gap between when a domain has have been re-
>
> - Appendix B: s/servers/server's/ (?)
>    domain is consistency and history.  It therefore is good if you have
>    the ability to look at the servers DNS traffic over a long period of

DONE.

>
> - Appendix B: s/them install/install them/
>    most of these tools are open source so you can them install locally
>    if you want.
>


DONE.


> - Appendix B: this sentence doesn't parse well to me...
>
>    Using the tools over the Internet has the advantage though that as
>    these are not located in the same part of the network you already
>    will have more than local view by using different tools.

DONE.


>
> - Appendix B: s/server.s/servers./
>    consistently around the world and from all authoritative server.s Use

DONE.

>
> - Appendix B: s/an guarantee/a guarantee/
>    attack, although that is not an guarantee.  Also if the output from

DONE.
Wow, I didn't do a good proofreading here, did I? :-)


>
> - Appendix B: it's now a dnsop wg document
>    EDNS0 client subnet (draft-vandergaast-edns-client-subnet) applied to
>    the domain.

DONE.
Doh!

>
> - Appendix B: this sentence doesn't parse well to me...
>
>    Again if the data is the same this
>    is an indication that the error is operator caused not an guarantee.

DONE.

>
> - Appendix B: s/parents/parent's/ (or "parent zone's ?)
>    o  DNSKEYs in child zone don't match parents zone DS record.  There

DONE.
Huh. Yeah. I couldn't figure out which, so I made it 'DNSKEYs in child
zone don't match the DS record in the parent zone.'


>
> - Appendix B: these two sentences seem too informal grammatically, if
>   not broken:
>       Has the existed before and was used?
>       Was there a change in the DNSKEY RRSet recently (indicating a key
>       rollover) and of course has the actual data in the zone changes.

DONE. I think.

>
> - Appendix B:
>    o  Data in DS or DNSKEY doesn't match the other.  This is more common
>       in initial setup when there was a copy and paste error.  Again
>       checking history on data is the best you can do there.  It's not
>       possible to give a checklist just to run through to decide if a
>       domain is broken because of an attack or an operator error.
>
>   Is the "It's not possible..." sentence supposed to belong to the
>   bullet?  This sentence seems to talk about something general, and
>   seem to make more sense if it's part of the sentence that follows:
>
>    All of the above is just a starting point for consideration when
>    having to decide to deploy or not deploy a trust anchor.

DONE

Thanks for all of the suggestions.

>
> --
> JINMEI, Tatuya
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> 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