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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Sep 2018 08:16:24 -0700

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.

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.

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 26 Sep 2018 10:12:08 -0700

> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
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.

> 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

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

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 26 Sep 2018 13:16:47 -0500

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

> root-key-sentinel-is-ta-1234.example.com and then being surprised) is

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

> Do you have any suggested text that you could provide to help us explain

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 26 Sep 2018 12:07:10 -0700

On Wed, Sep 26, 2018 at 11:16 AM Benjamin Kaduk <[email-masked]> wrote:

> > > Please refer to
> https://www.ietf.org/iesg/statement/discuss-criteria.html
So I opened my editor to add text, and scrolled down to try figure out
where to add this.
"Section 4.3 - Test Procedure" seemed like a good spot -- and it already
has this text:

A query name containing the left-most label
"root-key-sentinel-not-ta-<key-tag-of-KSK-current>". This name MUST be a
validly-signed. ***Any validly-signed DNS zone can be used for this test.***
A query name containing the left-most label
"root-key-sentinel-is-ta-<key-tag-of-KSK-new>". This name MUST be a
validly-signed. ***Any validly-signed DNS zone can be used for this test.***

(emphasis mine).

Does this perhaps address your concerns?
W

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 26 Sep 2018 12:40:36 -0700

On 26 Sep 2018, at 12:07, Warren Kumari wrote:

>>>> Thanks for preparing this document and mechanism; it is good to 
>>>> have
>> more

It should not: Section 2.1 specifically says that the query must be for 
A or AAAA.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Wed, 26 Sep 2018 14:30:31 -0700

> It should not: Section 2.1 specifically says that the query must be for
Ah, I think I'm starting to understand...

A query name containing the left-most label
"root-key-sentinel-not-ta-<key-tag-of-KSK-current". This name MUST be a
validly-signed name." cover it?
I'd tried putting in stuff like "in a public zone" (but this isn't actually
true, I could do this entirely in a private namespace if I only wanted to
test a closed network).
Or perhaps: "This name MUST be a validly-signed name in a validly signed
zone"? (which is somewhat redundant, but makes it clearer)?

Any suggestions?
W

---

From: "Paul Hoffman" <[email-masked]>
Date: Wed, 26 Sep 2018 15:13:27 -0700

On 26 Sep 2018, at 14:30, Warren Kumari wrote:

>>>>>> email addresses included in the To and CC lines. (Feel free to 
>>>>>> cut
>>>>>> this
>>>>>> data about the expected impact of the root KSK roll.  That said, 
>>>>>> I
>>>> have two
>>>>>> 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
>>>> It eventually became pretty clear to me from things like "return 
>>>> the
>>>> A or
>>>> provisioned so that it could be returned, but I don't want to rely 
>>>> on
>>>> all
>>> "root-key-sentinel-not-ta-<key-tag-of-KSK-current>". This name MUST 
>>> be
>>> a

Ben asked for the text to appear early, so I think that putting it in 
the last section before the Security Considerations doesn't really 
count. :-)

How about in Section 2.2 where the document defines the special 
processing. Adding a last sentence to the last paragraph might clear 
things up:
    The answer for the A or AAAA query is sent on to the client.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Wed, 26 Sep 2018 16:35:58 -0700

Thank you for providing text. I put that in the GitHub version.

W

---

From: Joao Damas <[email-masked]>
Date: Thu, 27 Sep 2018 09:31:30 +0200

Good additions, warren

Joao

> On 27 Sep 2018, at 01:35, Warren Kumari <[email-masked] <mailto:[email-masked]>> wrote:
> 
> On Wed, Sep 26, 2018 at 3:13 PM Paul Hoffman <[email-masked] <mailto:[email-masked]>> wrote:
> > On Wed, Sep 26, 2018 at 12:40 PM Paul Hoffman <[email-masked] <mailto:[email-masked]>> 
> > wrote:
> >
> >>> On Wed, Sep 26, 2018 at 11:16 AM Benjamin Kaduk <[email-masked] <mailto:[email-masked]>> 
> >>> wrote:
> >>>
> >>>>> On Wed, Sep 26, 2018 at 8:16 AM Benjamin Kaduk <[email-masked] <mailto:[email-masked]>>
> >>>>> wrote:
> >>>>>
> >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html <https://www.ietf.org/iesg/statement/discuss-criteria.html>
> >>>>>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ <https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/>
> >>>>>>
> >>>>>>
> >>>>>>
> >>> "root-key-sentinel-is-ta-<key-tag-of-KSK-new>".. This name MUST be a
> 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
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop