Re: [DNSOP] [e-mail]

[Warren Kumari <[e-mail]>]

On Fri, May 1, 2015 at 2:25 PM, 神明達哉 <[e-mail]> wrote:
> At Fri, 24 Apr 2015 23:59:22 -0400,
> Warren Kumari <[e-mail]> wrote:
>
>> So, I have gone back through previous mail and it seems that this was
>> the only email that got missed.
>> Anyway, it seems that other folk also made similar comments, and so,
>> by -03, we had addressed almost all of them.
>>  Apologies again for not seeing and responding to your mail.
>
> No worries, and thanks for addressing these so quickly.
>
>> >   I agree with the sense of the statement, but specifically how can
>> >   the operator confirm that it's misconfiguration? [...]
>>
>> My last update (a few days ago) included inserting an Appendix that
>> covers some of this. It is somewhat rough,and more conversational in
>> tone than if it were in the main part of the draft, but I think
>> strikes a nice balance.
>
> Do you mean Appendix B?  It certainly looks good enough to me to
> address this point.

Yup. Excellent!

>
>> > - Also on that sense and this one in Section 8:
>> >
>> >    Use of a
>> >    Negative Trust Anchor MUST NOT be automatic.
>> >
>> >   Again, I agree with the sense, but I wonder whether players like big
>> >   ISPs or public DNS services are really willing to follow the
>> >   suggestion of human intervention and/or ban of automation.
> [...]
>> >   For these recommendations to be really effective rather than just
>> >   ignored, I think we need to provide some more information, e.g.,
>> >   statistics on how often these events are happening in actual
>> >   providers that use NTAs, show example of operational practices
>> >   (which I guess would include some level of automation).
>>
>> We don't really have anything published, but I spoke with the person
>> who deals with these and it is around once per quarter (it has slowed
>> down). This year we have only done it once - for the .KE keyroll event
>> ( thread here: https://lists.dns-oarc.net/pipermail/dns-operations/2015-March/013060.html
>> )
>
> Okay, then I'd suggest adding some brief note on this point.  One
> possibility would be to add something like this to the end of the
> first paragraph of Section 2:
>
>    [... prior to implementing the Negative Trust Anchor.]  Involving
>    trained technical personnel is costly, but operations experiences
>    so far suggest that this is a very rare event such as around once
>    per quarter or even less.
>

Will do.

> (and if we can include a concrete reference, do that)
>
>> > - Also on Section 8:
>> >
>> >    Finally, a Negative Trust Anchor SHOULD be used only in a specific
>> >    domain or sub-domain and MUST NOT affect validation of other names up
>> >    the authentication chain.
>> >
>> >   I think it would also help clarify that the deepest anchor should be
>> >   used, whether positive or negative. [...]
>>
>> Actually, an NTA stops validation at that point, which includes things
>> under that.
>> Here is text (which probably changed after your comment:
>> "This Negative Trust Anchor can potentially be implemented at any
>> level within the chain
>>  of trust and would stop validation from that point in the chain down."
>>
>> This gave us the needed behavior when .ke broke...
>> Yes, turning off validation for an entire ccTLD is a big hammer --
>> but, it is better than turning off validation for *everyone*, or just
>> leaving an entire country unresolvable for many hours....
>
> Hmm...first, if this is really the intent, I'd suggest revising
> Section 8, too, to state it more explicitly (also possibly with an
> example).
>
> Secondly, does it make most sense?  If we have a manually configured
> positive trust anchor for "good.example.ke", isn't it better to still
> use it for anything on or below that, but skip DNSSEC validation for
> everything else on or under .ke?  At least this shouldn't mean
> "turning off validation for *everyone*" or "just leaving an entire
> country unresolvable for many hours", so such arguments don't seem to
> be a reason for not doing this.

Ah! I've just realized that I'd misunderstood your question -- I'd
somehow completely skipped over the "whether **positive** or negative"
(emphasis added). This isn't a very common case for us, and so I'm not
sure that the authors have discussed it.

The way that our resolver works is the most specific ("deepest") TA
would win, so, assuming that we had a positive TA for good.example.ke
it *would* override the NTA for .ke.

I personally (and I think you as well) believe that this makes the
most sense, but let me double check with co-authors.
Whatever the case, we don't actually address this in the document, and
it should be....



>
>> > - Section 10
>> >
>> >    validates can have security considerations.  It is therefore
>> >    recommended that NTA implementors should periodically attempt to
>> >    validate the domain in question, for the period of time that the
>> >
>> >   I wonder whether this 'should' may better be SHOULD.  Not a strong
>> >   opinion, but it seems to be similar to other recommendations using
>> >   the capitalized keyword in Section 8.
>>
>> So, I went to go make that change, and discovered it is already a SHOULD.
>> Sometime between when you wrote this mail (11/14) and version -03 I
>> incorporated this change.
>
> It's still a "should" in the 04 version:


Will fix.



>
>    validates can have security considerations.  It is therefore
>    recommended that NTA implementors should periodically attempt to
>    validate the domain in question, for the period of time that the
>    Negative Trust Anchor is in place, until such validation is again
>    successful.
> (from https://tools.ietf.org/html/draft-ietf-dnsop-negative-trust-anchors-04)
>
>> > - Appendix A: not intending to endorse a particular implementation(s),
>> >   but I'd suggest clarifying which specific implementations support
>> >   various recommendations of the draft.  For example, BIND 9 is quite
>> >   diligently follow it while (if my memory is correct and it's still
>> >   the case today) unbound's support is quite primitive and you cannot
>> >   specify timeouts.  I think it's important to avoid allowing lazy
>> >   operators to just configure some NTAs and forget them.  It would
>> >   also encourage "lazy developers" to support full recommendations
>> >   sooner.
>>
>> I'm a little uncomfortable doing this. This is still only a draft, and
>> vendors will continue to add support when it gets published as an RFC.
>> I'd hate vendor X to add support for all the rest of the requirements,
>> but have customers discriminate against them because the RFC didn't
>> predict that...
>
> Okay, then I won't push that.  But I'd like to suggest adding some
> more general note like this to Appendix A:
>

Will do!

>    Please note: These are simply examples - nameserver operators are
>    expected to test and understand the implications of these operations.
>    Note also that some of available implementations may not implement
>    all recommended functionality in this document.  In that case it is
>    advisable to request the developer or vendor of the implementation
>    to support the missing feature, rather than start using the
>    incomplete implementation.
>
> --
> JINMEI, Tatuya



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