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

[Warren Kumari <[e-mail]>]

[ Top post]
Only replying to the biggest issue here, will reply to the rest later today.

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.
>
>> 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 got a little confused by this comment (because that isn't what
I'd meant to say), and so went back to Jinmei's comments on -04... and
realized that I'd misunderstood one of them (I'd missed the "positive"
in the question).

The way that our resolver works is that the closest TA would win, and
so a positive TA under a negative trust anchor *would* be used. To me
this seems to be the obviously right thing to do, and so, unless
anyone objects, I'll add text to the document stating that.

So, in summary, a configured *positive* trust anchor for
good.subdomain.example would override a negative trust anchor for
.example.

This seems to very much be in keeping with the principle of least surprise...

W


> 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.
>
> 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.
>
> - Section 4: likewise, maybe s/should/SHOULD/
>    When removing the NTA, the implementation should remove all cached
>    entries below the NTA node.
>
> 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]
>
> - Section 7.1: s/has have/has/
>    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
>
> - Appendix B: s/them install/install them/
>    most of these tools are open source so you can them install locally
>    if you want.
>
> - 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.
>
> - Appendix B: s/server.s/servers./
>    consistently around the world and from all authoritative server.s Use
>
> - Appendix B: s/an guarantee/a guarantee/
>    attack, although that is not an guarantee.  Also if the output from
>
> - Appendix B: it's now a dnsop wg document
>    EDNS0 client subnet (draft-vandergaast-edns-client-subnet) applied to
>    the domain.
>
> - 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.
>
> - Appendix B: s/parents/parent's/ (or "parent zone's ?)
>    o  DNSKEYs in child zone don't match parents zone DS record.  There
>
> - 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.
>
> - 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.
>
> --
> 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