[DNSOP] negative-trust-anchors-02

[Andrew Sullivan <[e-mail]>]

Dear colleagues,

I have read draft-ietf-dnsop-negative-trust-anchors-02.  I have some
comments.

To begin with, I support, very strongly, getting this basic idea
documented and published soon.  Recent commentary (I will not say
"fatuous") on DNSSEC complained at length about DNSSEC failures, as
though returning to those halcyon days where "Certificate Invalid.
Proceed? [YES] [no, why would you ever press this?]" dialogues were
the norm would be nice.  NTAs are needed to aid with making DNSSEC
compatible with human expectations.

In section 1, it'd be nice to break up some of the references to other
documents at the beginning.

In my opinion, the final paragraph of section 1 could be cut without
any damage to the document.  Certainly, everything starting with,
"When I see folks voice opinions…" is editorial and can profitably be
removed.  Regardless of how much I might agree with the sentiments, I
don't think that's necessary for a protocol document to adopt that
argumentative tone.  The Introduction elsewhere gives ample reason
that NTAs are a potentially useful innovation for effective
deployment of DNSSEC.

In section 2, I am jarred slightly by the description of NTAs as the
inverse of TAs.  I wonder whether they're actually the converse or,
more likely, reverse of TAs.  None of these are satisfying to me.
Perhaps I spent too much time in syllogism school.  I don't feel
strongly about this, but I found it distracting, and probably just
saying, "By way of analogy, negative trust anchors stop validation…,"
or something along those lines.

In section 4, I would be stronger in this sentence:

   End users generally do not know what DNSSEC is, nor should they be
   expected to at the current time (especially absent widespread
   integration of DNSSEC indicators in end user software such as web
   browsers).

That sets the bar way too low.  How about this:

    End users generally do not know of, understand, or care about the
    resolution process that causes connections to happen.  This is by
    design: the point of the DNS is to insulate users from having to
    remember IP addresses through a friendlier way of naming systems.
    It follows from this that end users do not, and should not, be
    expected to know about DNSSEC, validation, or anything of the
    sort.

In section 5, I'd remove "and is potentially harmful to DNSSEC
adoption."  DNSSEC is not, as the I-D argues (IMO correctly) an end in
itself.  

I don't understand why section 6 is in the document, and I really
don't understand why it is in the location it is.

Everything up to section 7 seems to be motivational.  It might be nice
to group all of itq into a big section (Introduction and Motivation) or
something like that, and then deal with the normative parts in another
section (leaving the sections 1-6 as subsections instead).  There are
some people who feel very strongly that the motivation stuff needs to
be in a separate document, but publication would probably be eased by
the single introduction and motivation section.

In section 7, there are these bits:

   Technical personnel trained in the operation of DNS servers MUST
   confirm that a failure is due to misconfiguration, as a similar
   breakage could have occurred if an attacker gained access to a
   domain's authoritative servers and modified those records or had the
   domain pointed to their own rogue authoritative servers.
   […]
   Finally, they should make a
   reasonable attempt to contact the domain owner of the misconfigured
   zone, preferably prior to implementing the Negative Trust Anchor.

How are you going to do the first part without the last part?  Is this
to cover the, "I saw them post on a mailing list," case?

After that, there's

   In the case of a validation failure due to misconfiguration of a TLD
   or popular domain name (such as a top 100 website), this could make
   content or services in the affected TLD or domain inaccessible for a
   large number of users.  In such cases, it may be appropriate to use a
   Negative Trust Anchor as soon as the misconfiguration is confirmed.

It seems to me that the top 100 website cases are exactly where one
would most expect malfeasance, and therefore the names where one needs
the strongest diligence, no?

In the final paragraph of section 7, it'd be nice also to point out
the isolation across the tree: example.com's NTA need not (MUST NOT?)
affect .net or example.net or lower.example.net or even example2.com.

Respectfully submitted,

A

-- 
Andrew Sullivan
[e-mail]