[DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-kskroll-sentinel-15: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 18 October 2018 17:59 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EBFEE130DC0; Thu, 18 Oct 2018 10:59:56 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-dnsop-kskroll-sentinel@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, Benno Overeinder <benno@NLnetLabs.nl>, dnsop-chairs@ietf.org, tjw.ietf@gmail.com, dnsop@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <153988559695.22180.12914096026956523943.idtracker@ietfa.amsl.com>
Date: Thu, 18 Oct 2018 10:59:56 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/uikSPtv46d2z7wGDJNEzbmOFpco>
Subject: [DNSOP] Benjamin Kaduk's No Objection on draft-ietf-dnsop-kskroll-sentinel-15: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Oct 2018 17:59:57 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-dnsop-kskroll-sentinel-15: No Objection

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:


Thanks for addressing my Discuss points -- the text in the github version of
this document helps a lot, and I'm happy with the direction we're going in
for the more general case.

[original ballot comments preserved below]

Other than my Discuss points, I just have a number of essentially editorial


                                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

   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.