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

[ Top post ]
Integrating these -- 'parently I'm processing emails out of order...

Thank you for your comments, I've integrated them and will post a new
version soon (planning on incorporating some of Jinmei's comments
before posting).

On Tue, May 5, 2015 at 5:53 PM, Paul Hoffman <paul.hoffman@vpnc.org> wrote:
> This document has progressed very well and is nearly ready for publication.
>
> Related to an earlier thread about intended status: "Informational" is most appropriate here because the document is all about proposed operations but no "best current practice". There is no problem with WGs producing Informational RFCs, and Informational RFCs can have RFC 2119 language.
>

Thanks.

> In Section 2, there should be a new paragraph after the first paragraph that describes why the "reasonable attempt" in the first paragraph is needed to determine whether the attacker has partial control of the zone, or is just mounting an on-path attack between all the nameservers and the recursive.

DONE?
"It is important to confirm that the comains is still under the
ownership / control of the legitimate owner of the domain - this is to
ensure that disabling validation for a specific domain does not direct
users to an address under an attackers control. Contacting the domain
owner allows the resolver operator to determine if the issue is a
DNSSEC misconfiguration or an attack."

I'm not really sure if this addresses your concerns? If not, do you
happen to have any suggested text?

>
> In Section 2, it talks about "a popular domain name" but don't say how to determine that. Giving examples of sources of that data would be valuable.

DONE.
I added: "An example of a list of "top N" websites is the <xref
target="Alexa">"Alexa Top 500 Sites on the Web" </xref>"

Is this OK?

>
> Section 5 is one paragraph too short. It says what other misconfigurations should not be fixed by recursive resolver operators, but it does not say why likely DNSSEC validation errors should be. The (missing) second paragraph should say something to the effect of "with DNSSEC breakage, it is often possible to tell that there is a misconfiguration by looking at the data and not needing to guess what it should have been".
>

DONE.
I was going to add some hand-wavy bit about the fact that DNSSEC is an
"added feature" and that the behavior differs based upon if you have
turned validation on or not, but this didn't feel helpful, so I just
used your text. Thanks.

> In Section 6, add a second sentence to the second paragraph: "Such additions are prevented by the requirement that the operator attempt to contact the administrators for the zone that has broken DNSSEC."

DONE.
Thank you.

>
> In Section 7.1, the second paragraph is *not* a security consideration, it is a proposal for how NTAs should be implemented. Please make this its own section earlier in the document, possibly called "Altering Users of NTA Use".

DONE.
I'm fairly jetlagged, and it took me a silly amount of time to parse
the suggested name :-) Yay autocorrect.

>
> There is no stated reason for Appendix B to be an appendix. It is just as important as other sections in the main body of the text, and should be moved there.

DONE.
It had felt more "Appendixy" to me, but I don't know why. Moved it
into the body of the doc.

>
> References to other documents are done inconsistently. For example, there is both "from RFC4033 [RFC4033]" and "in [RFC5914]".

DONE.
Thank you, and apologies for the delay.

W

>
> --Paul Hoffman
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> 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