On Wed, Sep 26, 2018 at 10:12:08AM -0700, Warren Kumari wrote: > On Wed, Sep 26, 2018 at 8:16 AM Benjamin Kaduk <ka...@mit.edu> wrote: > > > Benjamin Kaduk has entered the following ballot position for > > draft-ietf-dnsop-kskroll-sentinel-15: Discuss > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ > > > > > > > > ---------------------------------------------------------------------- > > DISCUSS: > > ---------------------------------------------------------------------- > > > > Thanks for preparing this document and mechanism; it is good to have more > > data about the expected impact of the root KSK roll. That said, I have two > > Discuss-worthy points, albeit both fairly minor. > > > > The first one may just be something that I missed, but does this document > > actually say anywhere that there needs to be a real zone with real > > configured A and/or AAAA records for the query names used for these tests? > > The Appendix sort-of-mentions it, but I feel like there needs to be a > > mention in the main body text. > > > > > No hats (OMG, everyone will see I'm going bald...) > > Ok, fair. This was actually a source of confusion when we first started > discussing the document -- we explained it on-list / at mics / in person, > but it became so well understood that we didn't notice that it is not > actually specified in the document. I'll try figure out text.
Thanks. It eventually became pretty clear to me from things like "return the A or AAAA response unchanged" that there was supposed to be a valid response provisioned so that it could be returned, but I don't want to rely on all readers making the same inference. > > > The other point basically is a procedural one, in that we are in effect > > claiming a couple of leaf name prefixes in all domains to exhibit "weird > > and surprising behavior" (that is, for parties unaware of this > > specification). We generally try to avoid this sort of namespace > > squatting, preferring (e.g.) /.well-known for HTTP requests, various > > underscore-prefixed tricks for the DNS, etc. I see in the changelog that > > initial attempts did use an underscore prefix but ran into implementation > > difficulty, and acknowledge that using a "magic" name is much easier to get > > deployed than (e.g.) a new RR type. But I do not want the IESG to > > implicitly approve a namespace claim like this; it's better to be explicit > > about it if this is the best way to go. > > > > > Ok, I see your point. We've actually done something similar in RFC8145 > where we "reserved" (caused funny behavior) for _ta-XXXX.example.com, but > this is subtly different. There was some discussion on this and the fact > that could cause "unexpected" behavior. Unfortunately underscore labels > really don't work for us -- for example, Android (and some unix machines) > will not follow / fetch a link of the form http://_foo.example.com. The > labels that we are chose (after a huge amount of discussion) are > "root-key-sentinel-is-ta-XXXX" > and "root-key-sentinel-not-ta-XXXX". These labels seem sufficiently long > and obtuse that we don't expect them to be used for anything else (e.g: > risk of people happening to choose to name a machine > root-key-sentinel-is-ta-1234.example.com and then being surprised) is > vanishingly small. I agree that it's vanishingly small, and the "magic" behavior is just to return a SERVFAIL, something that in theory could happen at arbitrary times anyway, so the practical effect is not something I'm especially concerned about. (Hey, I did say it was a procedural point!) > But, yes, this does let let the camel's nose into the tent - we are > co-opting some names. > > Do you have any suggested text that you could provide to help us explain > this? I didn't have anything in particular in mind when I balloted, no (and in fact I wasn't entirely sure that any new text would be needed, depending on how we felt about it). But you're probably right that we should describe that this is exceptional behavior of a spec, why the impact is minimal, and why alternative approaches were not suitable. Feel free to ping me again about proposing concrete text ... after the telechat. -Benjamin > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Other than my Discuss points, I just have a number of essentially editorial > > nits. > > > > Abstract > > > > This document specifies a mechanism that > > will allow an end user and third parties to determine the trusted key > > state for the root key of the resolvers that handle that user's DNS > > queries. [...] > > > > This wording feels confusing to me; I think what it's trying to say is "the > > root key(s) that are in use by the resolver" but am having a hard time > > grouping these words to achieve that meaning. (Is "trust" really necessary > > to mention, here?) > > > > Section 1 > > > > RRSIG RRs contain a Key Tag field whose value is equal to > > the Key Tag of the DNSKEY RR that was used to generate the > > corresponding signature. > > > > nit: Is the RR used to generate the signature, or just the key? > > > > o Users may wish to ascertain whether their DNS resolution > > environment resolvers is ready for an upcoming root KSK rollover. > > > > nit: I think there's a singular/plural mismatch or similar here, maybe > > "environment's resolver"? > > > > o Researchers want to perform Internet-wide studies about the > > proportion of users who will be negatively impacted an upcoming > > root KSK rollover. > > > > nit: "by an upcoming" > > > > If a browser or operating system is configured with multiple > > resolvers, and those resolvers have different properties (for > > example, one performs DNSSEC validation and one does not), the > > sentinel test described in this document can still be used, but it > > > > nit: this usage of "but" feels a bit misplaced to me, as the thing being > > warned about is more that the test may produce indeterminate or > > inconsistent results. Or perhaps that the assumptions it makes may not > > necessarily hold in the specific environments being described (i.e., "these > > environments"). > > > > makes a number of assumptions about DNS resolution behaviour that may > > not necessarily hold in all environments. If these assumptions do > > not hold (such as, for example, requiring the stub resolver to query > > the next recursive resolver in the locally configured set upon > > receipt of a SERVFAIL response code) then this test may produce > > indeterminate or inconsistent results. In some cases where these > > assumptions do not hold, repeating the same test query set may > > generate different results. > > > > Section 1.1 > > > > Please use the RFC 8174 boilerplate. > > > > Section 3 > > > > I'll note without further comment that we had a long thread on ietf@ > > relevant to the term "slave resolver". > > > > Section 3.1 > > > > If the resolver is non-validating, and it has a single forwarder, > > then the resolver will presumably mirror the capabilities of the > > forwarder target resolver. > > > > Perhaps this is just me misreading the previous paragraph's introduction to > > what is clearly a more widely known term of art, but in "has a single > > forwarder" is the thing of which there is only one the "one or more other > > resolvers" that the "forwarder" is relaying queries to? It's just weird > > for the word "forwarder" mean a different protocol participant when used as > > a noun vs. adjective. Or perhaps this is meant to be possessive; the > > "forwarder's target resolver"? > > > > As noted in the directorate review, "use the CD bit" needs disambiguation. > > > > Section 4 > > > > nit: missing trailing 'r' in the section title > > > > Section 4.3 > > > > Maybe call out that these are the same general categories of query as in > > Section 3 but the key tag used is different for some queries? > > > > It's also a bit weird to use new notation for this section as opposed to > > consistent notation between the different types of test. > > > > > > > > -- > 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
