Re: [DNSOP] 2nd Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

[Warren Kumari <[e-mail]>]

Firstly, thank you! (for keeping the WG informed, I met with Joe in Panama
and thanked him then too).

I generally like to update at least the GitHub version during WGLC so that
people can better see the current state, but this time travel and such got
in the way. I have integrated / addressed most of these, and posted a new
version.

Because I only got around to addressing them around 2 hours before the
draft cutoff I haven't checked with my co-authors, nor created separate
GitHub issues for them.

​Thanks again!
W​


On Fri, Jun 22, 2018 at 12:19 PM Joe Abley <[e-mail]> wrote:

> Hi Benno,
>
> On 22 Jun 2018, at 11:04, Benno Overeinder <[e-mail]> wrote:
>
> > This starts a *one* week Working Group Last Call process, and ends on:
> > 23:59 29 June 2018.
>
> Which timezone? Seems odd to specify a timestamp with minute-accuracy
> without specifying the hour :-)
>
> === General
>
> I have read draft-ietf-dnsop-kskroll-sentinel-14. In my opinion it is
> ready to proceed.
>
> I have some small nits that someone might care about, and if they don't
> care about them I will not be offended, even if they roll their eyes. I
> think at least some of them make the document clearer, though, and perhaps
> aren't very contentious. None of them take issue with the specification
> itself, just its description.
>
> === Section 1, Introduction
>
> DNS, RR and KSK are used as acronyms without being expanded on first use.
>

​I chose not to expand DNS (it is sufficiently well known, and ​doing so
made it unreadable).

I expanded RR and KSK.

Thank you!



>
> The first paragraph refers to "a formula similar to a ones-complement
> checksum" in reference to Appendix B of RFC 4034. In fact that document
> specifies two algorithms for computing key tags, one for the old RSA/MD5
> algorithm 1 and one for all others. "Ones-complement" is properly "ones'
> complement". This document uses "formula" to describe what 4034 describes
> as an algorithm. DNSKEY RRs don't validate signatures. These are
> ridiculously pedantic points (for the sake of brevity I will avoid
> mentioning that again, but you can assume it if it's not obvious).
>
> OLD:
>
> The Key Tag is a 16-bit value computed from the RDATA portion of a DNSKEY
> RR using a formula found in "Key Tag Calculation" (Appendix B of "Resource
> Records for the DNS Security Extensions" [RFC 4034]), a formula similar to
> a ones-complement checksum. RRSIG RRs contain a Key Tag field whose value
> is equal to the Key Tag of the DNSKEY RR that validates the signature.
>
> NEW:
>
> The Key Tag is a 16-bit value computed from the RDATA of a DNSKEY RR as
> described in Appendix B of RFC 4034. 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.
>
>

​Thank you, and thank you also for providing OLD and NEW. Done.​




> A little further in the same section: I don't think mechanisms meet
> use-cases, but rather satisfy their requirements. I think normative
> language for the configuration commentary could make the sentiment clearer.
> I think actually that it would be better for the advice about configuration
> defaults to be moved to section 2, since an implementer might reasonably
> skip over the introduction and miss it.
>
> OLD:
>
> The mechanism described in this document meets both of these use cases.
> This new mechanism is OPTIONAL to implement and use, although for reasons
> of supporting broad-based measurement techniques, it is strongly preferred
> that configurations of DNSSEC-validating resolvers enabled this mechanism
> by default, allowing for local configuration directives to disable this
> mechanism if desired.
>
> NEW:
>
> The mechanism described in this document satisfy the requirements of both
> these use-cases. This mechanism is OPTIONAL to implement and use. If
> implemented, this mechanism SHOULD be enabled by default to facilitate
> Internet-wide measurement. Configuration options MAY be provided to disable
> the mechanism for reasons of local policy.
>
>
​Thank you, and for providing NEW text (thanks implicit in all follow-ons
too!).
This adds a SHOULD -- I'm assuming that the WG is OK with it. ​
DONE.​




> In the final paragraph, I think speculating on the utility of this
> mechanism vs. RFC 8145 is unnecessary. Note that I don't disagree with the
> sentiment, I just don't think it's relevant or useful as commentary.
>
> OLD:
>
> Note that the sentinel mechanism described here measures a very different
> (and likely more useful) metric than [RFC8145].
>
> NEW:
>
> Note that the measurements facilitated by the mechanism described in this
> document are different from those of [RFC8145].
>

​Fair enough.
DONE. ​



>
> === Section 2, Sentinel Mechanism in Resolvers
>
> I wonder whether it's worth being explicit about labels in QNAMEs that
> almost match those specified, but not quite. Out of general enthusiasm for
> being generous about what you accept, for example, it seems possible that
> some implementors might choose to treat a label with a key tag that is not
> zero-padded to five digits as if it was. Perhaps:
>
> NEW:
>
> The precise specification of the special labels above should be followed
> exactly. For example, a label that does not include a Key Tag zero-padded
> to five digits does not match this specification, and should not be
> processed as if they did -- in other words, such queries should be handled
> as any other label and not according to Section 2.2.

Section 2 looks a bit like an introduction to the subsections that follow,
> but this point (about the zero-padding of the Key Tag value) is not
> mentioned in 2.1. I wonder if that section might be a better place for it.
>

​DONE and DONE (NEW added, text moved to S 2.1)​



>
> In Section 2.2 there's a possible inference that this mechanism implies
> support of RFC 5011. I don't think that's the intention -- a security-aware
> resolver with RFC 5011 disabled and manually-configured trust anchors could
> still usefully implement ksk-sentinel. I also don't think you mean root
> zone KSK here, but rather trust anchor. Perhaps:
>
> OLD:
>
> First, the resolver determines if the numerical value of <key-tag> is
> equal to any of the Key Tag values of an active root zone KSK which is
> currently trusted by the local resolver and is stored in its store of
> trusted keys. An active root zone KSK is one which could currently be used
> for validation (that is, a key that is not in either the AddPend or Revoked
> state as described in [RFC5011]).
>
> NEW:
>
> First, the resolver determines if the numerical value of <key-tag>
> corresponds to any active trust anchor available to the local resolver. An
> active trust anchor is one which could currently be used for validation
> (e.g. a trust anchor that has been locally configured, or a trust anchor
> corresponding to a key that is not in either the AddPend or Revoked state
> as described in [RFC5011]).
>

​Actually, we mean root trust anchor, which we are calling the root zone
KSK. The WG had previously agreed that, for simplicity's sake, we were
treating the root as special here (it required all sorts of ugliness
encoding where in the tree were were referring to, and if someone is using
e.g 20326 as a local TA for example.com we'd get bad results. We (of
course) would be fine with a -bis which adds support for signaling in other
places.
I'm choosing not to incorporate this text, but if I've misunderstood your
point, please let me know.

NOT DONE.


>
> Finally, two actions are specified in the table at the end of this section
> "return original answer". I think it's fairly obvious what this means, but
> it's not defined anywhere and "original" is a bit vague. We could add some
> certainty here with something like
>
> NEW:
>
> Instruction "return original answer" means that the resolver MUST process
> the query without any further special processing; that is, exactly as if
> the mechanism described in this document was not implemented or disabled.
>
>
​Oooh, nice, I like it!
DONE.​



> === Section 3.1, Forwarders
>
> There's no description of what a forwarder is. The terminology document
> teaches us that terms that seem obvious and well-known and still be
> contentious. I think what we mean by forwarder is the following. I think
> it's confusing to refer to a "recursive resolver using a forwarder" since
> if a forwarder is being used the resolver doesn't seem very recursive (even
> suppressing the compulsive urge to blurt "iterative" into the text). If I'm
> wrong I will duck and roll.
>
> OLD:
>
> There is also the common case of a recursive resolver using a forwarder.
>
> NEW:
>
> Some resolvers are configured not to answer queries using the recursive
> algorithm first described in RFC 1034 section 4.3.2, but instead relay
> queries to one or more other resolvers. Resolvers configured in this manner
> are referred to in this document as "forwarders".
>
>
​Fair 'nuff.
DONE.​



> === Section 4, Sentinel Tests for a Set of Resolvers
>
> A set can have a single element (or no elements). This whole section is
> concerned with stub resolvers that have more than one resolver configured,
> i.e. the case where the set of resolvers has more than one member. I
> suggest a better section heading might be "Sentinel Tests from Hosts with
> More than One Configured Resolver", and

​​
OK.

DONE.


>
> OLD:
>
> However, the common end user scenario is where a user's local DNS
> resolution environment is configured to use a set of recursive resolvers.
>
> NEW:
>
> However, the common end-user scenario is where a user's local DNS
> resolution environment is configured to use more than one recursive
> resolver.
>

​This one might be a bit pedantic, but there was NEW text, so I addressed
it :-)​

​DONE​



>
> === Section 7, Implementation Experience
>
> I don't know why the instruction to the RFC Editor to remove this section
> prior to publication is here. I think the information in this section is
> useful to retain. I suggest adding the date at which these observations
> were made so that future readers can put it in historical context and
> removing the instruction to the RFC Editor. Moving the whole section to an
> appendix would be a compromise if there's a desire to separate this
> commentary from the specification.
>
>
​RFC 7942 (Improving Awareness of Running Code: The Implementation Status
Section) sayeth:

 It is up to the individual working groups to use this information as
   they see fit, but one result might be the preferential treatment of
   documents, resulting in them being processed more rapidly.  We
   recommend that the Implementation Status section should be removed
   from Internet-Drafts before they are published as RFCs.  As a result,
   we do not envisage changes to this section after approval of the
   document for publication, e.g., the RFC errata process does not
   apply.

   This process is not mandatory.


and

Since this information is necessarily time dependent, it is
inappropriate for inclusion in a published RFC.  The authors should
include a note to the RFC Editor requesting that the section be
removed before publication.

and:

 Authors are requested to add a note to the RFC Editor at the top of
   this section, advising the Editor to remove the entire section before
   publication, as well as the reference to RFC 7942
<https://tools.ietf.org/html/rfc7942>.


If the WG would like, it is (obviously!) trivial to move this to an appendix.

WG, please tell us if you'd like that - as 7942 is so adamant, I'll
assume not for now.


NOT DONE.


​



> === Section 8, IANA Considerations
>
> According to RFC 8126/BCP 26 section 9.1, this section should not be
> removed by the RFC Editor, because that makes it hard for people to
> distinguish between the case where there are no IANA actions and the case
> where the authors just forgot to include them. The recommended text for
> this section is also specified in 8126, and it seems sensible to use it.


> OLD:
>
> [Note to IANA, to be removed prior to publication: there are no IANA
> considerations stated in this version of the document.]
>
> NEW:
>
> This document has no IANA actions.
>

​Okey dokey

DONE.​




>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>


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