Paul Wouters has entered the following ballot position for draft-ietf-dnsop-dnssec-bootstrapping-08: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I have a few items to discuss and some comments. I'm leaving out the discussion of _signal as a name, as this discussion is taking place on dnsop. While I have a preference, I'll abide by the consensus call of the dnsop wgchairs. All Sections: This document uses the term "bailiwick" a lot. The DNS Terminology series of RFCs recommands to avoid this term and use "in-domain" or "not in-domain". Section 1: Readers are expected to be familiar with DNSSEC, including [RFC4033], [RFC4034], [RFC4035], [RFC6781], [RFC7344], and [RFC8078]. It should say: Readers are expected to be familiar with DNSSEC [BCP237]. It includes the same RFCs but BCP237 will get updated in the future. Section 2: The DS enrollment methods described in Section 3 of [RFC8078] are deprecated and SHOULD NOT be used. I find this to be inconsistent with the Update: 8078 clause, as without "Section 3", you are basically obsoleting the entire 8078. I don't think this document should obsolete it, it should augment it. I would rewrite the above like: The DS enrollment method described in this document provides more security than the methods described in Section 3 of [RFC8078], and are therefor RECOMMENDED in favour of the methods specified in [RFC8078]. If the authors/WG insists on the "deprecated" language, it should also Obsolete: 8078. But be aware that the document currently does make references to it, which it cannot do if it obsoletes the document. Section 4.1.1: It is not clear to me if the "signaling domain" really has to be its own zone or not. eg: _dsboot.example.co.uk._signal.ns1.example.net Could this be signed using the DNSKEY of "example.net", or does the document insist on a zone cut at _signal.ns1.example.net ? I think zone cut should not be mandatory, in which case the language that uses "signaling domain" should be cleaned up to make this clear. That would also mean language like this is no longer needed: The records are accompanied by RRSIG records created using the key(s) of the respective signaling zone. It could just state something like: These records are signed with DNSSEC just like any other zone data. Later on in the Operational Considerations, the issue is mentioned and it states zone cuts are not mandatory. So I do think this needs some cleanup. in Step 3: any failure to retrieve the CDS/CDNSKEY RRsets located at the signaling name under any signaling domain, including failure of DNSSEC validation, or unauthenticated data (AD bit not set); I think it also needs to exclude signaling signatures made by any DNSSEC keys upstream from the DNS hoster's zone. Eg if we have _signal.ns1.example.net we also do not want to see the CDS/CDNSKEY RRsets signed by .net or the root. Section 5: CDS/CDNSKEY records and corresponding signaling records MUST NOT be published without the zone owner's consent. This opens a can of worms. How is an implementer going to codify this MUST? The only usable interpretation I can see is that the DNS hoster, by being assigned the DNS hoster, has permissions to DNS host the zone as it sees fit, and thus do DNSSEC. And especially not bother the zone owner with techno-babble for permissions. Likewise, the child DNS operator MUST enable the zone owner Again, this wades into legalize and contractual matters best left outside of RFC specifications. a zone cut ensures that bootstrapping activities do not require modifications of the zone containing the nameserver hostname. Why does this matter? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- If a child DNS operator implements the protocol If a child DNS operator implements this specification (i.e. have a valid DNSSEC chain of trust) I would say: (i.e. have a valid publicly resolvable DNSSEC chain of trust) Otherwise one could argue the parent has to have some "special configuration" (eg trustanchors) and then it is "valid". that are authoritative for the signaling domains _signal.ns1.example.net and _signal.ns2.example.org. This implies that _signal MUST live at a zone cut. Is that required? If so, why? [other text seems to say that it is not required] as an authenticated signal as described in Section 3. I find Section 3 is not a real full "description" of the "authenticated signal". Reading it is not enough to create such a "authenticated signal". To avoid relying on the benevolence of a single signaling domain parent (such as the corresponding TLD registry), it is RECOMMENDED to diversify the path from the root to the child's nameserver hostnames. This is best achieved by using different and independently operated TLDs for each one. This should move to a Security Considerations section, and not be part of the core protocol. Actually, it is ALSO already in there, so I would just remove this paragraph. Section 4.2: 1. verify that the child is not currently securely delegated and that at least one of its nameservers is out of bailiwick; I think the first part should clarify this be "ensuring the domain has no DS records published at the parent". The way it is written, is that if .ca would briefly lose its DS record, then nohats.ca can be considered "not currently securely delegated", even if there is a DS record in .ca. 2. query the CDS/CDNSKEY records at the child zone apex directly from each of the authoritative servers as determined by the delegation's NS record set (without caching); What is "the delegation's NS record set"? Do you mean the NS RRset at the parent or at the child? I think there should also be some text on what to do when the parent and child NS RRsets for the domain mismatch. (abort?) all record sets All RRsets If the above steps succeed without error, the CDS/CDNSKEY records are successfully validated, I would use verified instead of validated to avoid confusion with DNSSEC validation. However, the parental agent MUST Remove the word "However, ". in Step 1: the child is already securely delegated or has in-bailiwick nameservers only; or the path from the root to the child traverses an insecure delegation. CDS/CDNSKEY records [...] CDS/CDNSKEY RRsets [...] USe consistent terminology. I recommend RRsets _______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
