Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-kskroll-sentinel-15: (with DISCUSS and COMMENT)

[Warren Kumari <[e-mail]>]

On Wed, Sep 26, 2018 at 8:16 AM Benjamin Kaduk <[e-mail]> 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.


> 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.

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?

W



>
>
> ----------------------------------------------------------------------
> 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