A Root Key Trust Anchor Sentinel for DNSSEC
draft-ietf-dnsop-kskroll-sentinel-17

[Ballot comment]
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
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.

[Ballot comment]
Benjamin asked:

  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.

The same question bothered me a lot and made understanding purpose of the document hard. Please clarify this early on in the document.

[Ballot comment]
I am balloting "no objection," although I share Benjamin's concerns about the
claiming of leaf nodes in the DNS system. However, I think that issue is larger
than just this document, and that we are unlikely to come to an agreement within
the DNS community about how to handle it in a reasonable amount of time.

I have some additional comments, below.

---------------------------------------------------------------------------

§4:

> 4.  Sentinel Tests from Hosts with More than One Configured Resolve

Nit: "...Resolvers"

---------------------------------------------------------------------------

§4.2:

One of the implicit assumptions of this section appears to be that the client
performing this test will necessarily be using gethostbyname() (or something
similar), and at the mercy of the underlying library with regard to the test
assumptions. On systems where the list of configured resolvers can be retrieved
programmatically (e.g., 'scutil --dns' under OS X, or the contents of /etc/hosts
on most other Unices), I would guess that more reliable results could be
achieved by treating the three bullets in section 4.2 as requirements on the
testing client rather than assumptions that may make the results invalid if they
don't hold.

Concretely: I believe it would be useful to add text to this section suggesting
that clients can achieve more reliable results by bypassing the local stub
resolver and implementing queries themselves (in a fashion similar to the
popular "dig" utility), which allows them to ensure that these assumptions are
true.

---------------------------------------------------------------------------

Appendix A:

This walkthrough uses the name "bogus.example.com" for the bogus record used in
the testing. I've gone looking through the document and cannot determine whether
this is canonical or just the name this example uses. I presume it's the latter.
It's probably worth adding text to this example which explains that the choice
of "bogus" by Geoff is a site-local decision. What I'd like to avoid is having
situations where people hardcode "bogus" into some tooling suite, and then cause
sites like "github.io" grief in the case that the (already-registered) user with
a username of "bogus" attempts to set up a page at "https://bogus.github.io/").

[Ballot comment]
Just a couple of nits:

§1, the two bullet points:

"... DNS resolution environment resolvers is ready...": Plural mismatch, although I wonder if both "environment" and "resolvers" were intended to be there.

"... negatively impacted an upcoming root KSK rollover.": Missing word after "impacted"?

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

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.

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

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-dnsop-kskroll-sentinel-15, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-09-06):

From: The IESG
To: IETF-Announce
CC: tjw.ietf@gmail.com, dnsop-chairs@ietf.org, Benno Overeinder , dnsop@ietf.org, Tim Wicinski , terry.manderson@icann.org, draft-ietf-dnsop-kskroll-sentinel@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Root Key Trust Anchor Sentinel for DNSSEC) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'A Root Key Trust Anchor
Sentinel for DNSSEC'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-09-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  The DNS Security Extensions (DNSSEC) were developed to provide origin
  authentication and integrity protection for DNS data by using digital
  signatures.  These digital signatures can be verified by building a
  chain of trust starting from a trust anchor and proceeding down to a
  particular node in the DNS.  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.  Note that this method is only applicable for determining
  which keys are in the trust store for the root key.

  [ This document is being collaborated on in Github at:
  https://github.com/APNIC-Labs/draft-kskroll-sentinel.  The most
  recent version of the document, open issues, etc should all be
  available here.  The authors (gratefully) accept pull requests.  RFC
  Editor, please remove text in square brackets before publication. ]




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested

  Standards Track


(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

  The DNS Security Extensions (DNSSEC) were developed to provide origin
  authentication and integrity protection for DNS data by using digital
  signatures.  These digital signatures can be verified by building a
  chain of trust starting from a trust anchor and proceeding down to a
  particular node in the DNS.  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.  Note that this method is only applicable for determining
  which keys are in the trust store for the root key.


Working Group Summary:

  This document has had a short history, and came about while working with ICANN on
  the KSK rollover process, as a way to assist tracking the addition and removal of DNSSEC
  keys.


Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough?

  WG criticism of the design approach produced at least two implementations of the design.


Document Quality:

Are there existing implementations of the protocol? Have a significant number of vendors
indicated their plan to implement the specification?

  There are two different implementations of the design.

Are there any reviewers that merit special mention as having done a
thorough review, e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If there was a
MIB Doctor, Media Type or other expert review, what was its course
(briefly)? In the case of a Media Type review, on what date was the
request posted?

  No.


Personnel:

Document Shepherd: Tim Wicinski

Responsible Area Director: In this case since the DNSOP AD is a co-author (Warren Kumari),
  we have Terry Manderson to step in his place.  They chairs thank Mr. Manderson for
  his assistance in this.

(3) Briefly describe the review of this document that was performed by the Document Shepherd.
If this version of the document is not ready for publication, please explain why the document
is being forwarded to the IESG.

  The shepherd has been involved during the working group process reviewing versions,
  looking for editorial issues,

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

  No.


(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

  No other reviews are needed.


(6) Describe any specific concerns or issues that the Document Shepherd has with this
document that the Responsible Area Director and/or the IESG should be aware of?

None.


(7) Has each author confirmed that any and all appropriate IPR disclosures required for
full conformance with the provisions of BCP 78 and BCP 79 have already been filed.
If not, explain why?

  Yes.


(8) Has an IPR disclosure been filed that references this document? If so, summarize any
WG discussion and conclusion regarding the IPR disclosures.

  No.

(9) How solid is the WG consensus behind this document? Does it represent the strong
concurrence of a few individuals, with others being silent, or does the WG as a whole
understand and agree with it?

  Solid.


(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so,
please summarise the areas of conflict in separate email messages to the
Responsible Area Director. (It should be in a separate email because this
questionnaire is publicly available.)

  No.


(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

  No nits.


(12) Describe how the document meets any required formal review criteria, such as
the MIB Doctor, media type, and URI type reviews.

  None needed. 

(13) Have all references within this document been identified as either normative or informative?

  Yes.


(14) Are there normative references to documents that are not ready for advancement or
are otherwise in an unclear state? If such normative references exist, what is the
plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)? If so,
list these downward references to support the Area Director in the Last Call procedure.



(16) Will publication of this document change the status of any existing RFCs? 
Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction?

  No.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document.

  N/A


(18) List any new IANA registries that require Expert Review for future allocations.
Provide any public guidance that the IESG would find useful in selecting the IANA
Experts for these new registries.

  None.


(19) Describe reviews and automated checks performed by the Document Shepherd to
validate sections of the document written in a formal language, such as XML code, BNF
rules, MIB definitions, etc.

  The documents were produced with an XML editor and were processed
through the IETF's ID Nits engine, and txt files were produced from the
XML by the IETF's Internet Drafts submission process.