Hi Benno, On 22 Jun 2018, at 11:04, Benno Overeinder <be...@nlnetlabs.nl> 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. 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. 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. 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]. === 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. 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]). 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. === 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". === 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 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. === 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. === 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.
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
