On Wed, Mar 18, 2015 at 11:45 PM, Andrew Sullivan <a...@anvilwalrusden.com> wrote: > 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.
Yay! Us too! > 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. Yah! > > In section 1, it'd be nice to break up some of the references to other > documents at the beginning. DONE. Actually, I don't really see a point in the document having a list of DNSSEC RFCs, so I just deleted them... it don't get more broken up than that :-) > > 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. DONE. I removed most of the final paragraph, but left in: "It is worth noting the following text from RFC4033: "In the final analysis, however, authenticating both DNS keys and data is a matter of local policy, which may extend or even override the protocol extensions defined in this document set." A responsibility (one of many) of a caching server operator is to "protect the integrity of the cache." I wouldn't really have called the original tone "argumentative", rather "overly defensive" -- we got well and truly whipped back when this document first came out, and some of the lashes still hurt :-P > 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. To my mind, *any* time in syllogism school is too much :-) > 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. DONE. Oooh, much better, thanks! > > 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. > DONE. Nice, thanks! > 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. DONE. This was a bit of a sales pitch to DNSOP folk :-) > > 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. DONE. Removed - I think that this was another instance where we had been repeatedly beaten over the whole idea (and the "Meh, if domain owners screw themselves you should let them fail - how else will they learn to be more careful in the future?!" attitude). > > 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. > DONE. This seems to make it more readable too. Thanks. > 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? Yup, mostly. Or some other strong signal... <handwave> keyroll timing, historical info from passive DNS, something </handwave> We are walking a fine line between expecting operators of validating resolvers to know what they are doing, and stop them from shooting themselves (and customers) in the foot. > > 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? Yup. Hence the " as soon as the misconfiguration is confirmed." There are a number of domains which have been DNSSEC bogus for a *long* time, but because they get basically no queries it is not worth^w appropriate to install a NTA for them. In the case of NASA.GOV (or HBONOW), where the impact of the failure affects a large number of people there is more urgency to fix the issue. > > 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. DONE. This was a bit tricky to word, but I think I got it... > > Respectfully submitted, And very gratefully received, W > > A > > -- > Andrew Sullivan > a...@anvilwalrusden.com > > _______________________________________________ > 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
