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 a...@anvilwalrusden.com _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop