Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator
draft-ietf-dnsop-dnssec-bootstrapping-11

Received changes through RFC Editor sync (changed state to RFC, created became rfc relationship between draft-ietf-dnsop-dnssec-bootstrapping and RFC 9615, changed IESG state to RFC Published)

[Ballot comment]
Thanks for addressing all my DICSUSS items and comments. I have updated my ballot to Yes,

One last comment left on the new text:

      If all else fails, the domain owner might have to request the removal of
        all DS records (e.g., by using the special-value CDS/CDNSKEY RRset
        specified in [RFC8078] Section 4) and have the transfer performed

I think the "e.g." sentence should be removed. This is "in case the dns operator
is not cooperating", so in that case one would assume they wouldn't update these
records either (and the domain owner would need to go through their registrar
website, which would cause the records to be removed at the parent via EPP.

[Ballot comment]
# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-dnssec-bootstrapping-08

Thank you for the work put into this document, if widely used then it could help the deployment of DNSSEC.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Tim Wicinski  for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status and uses an old template.

Other thanks to Benson Muite, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-dnsop-dnssec-bootstrapping-08-intdir-telechat-muite-2024-05-12/ (and I have read Peter's reply)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

I am sympathetic to Paul Wouter's comments about 'bailiwick' and the use of "_signal". The latter is probably to late to be changed.

## Section 2

Two normative "SHOULD" but no reason/suggestion on when the SHOULD can be bypassed.

## Section 4.1.1

"example.co.uk" is not a IANA/IETF reserved domain name. Suggest to use an actual reserved domain name.

Suggest to also add the RR type in the example.

Perhaps explain `Publication of signaling records under the in-bailiwick domain _signal.ns3.example.co.uk is not required`.

## Section 7

Like Erik Kline, I wonder whether the IANA considerations should include a request for _dsboot. The use of _dsboot is only briefly mentioned in section 1.1, which is rather weak for a proposed standard document (I was close to open a DISCUSS on this topic).

[Ballot comment]
I support Paul's DISCUSS especially with respect to Section 2.  It's peculiar to say a past process is obsolete and you SHOULD NOT use it, because then continuing to use it is technically still supported by this document.  Don't we want to say that new implementations MUST NOT do the old thing and MUST do the new thing?  Using SHOULD effectively leaves two systems "live" rather than one.

This may be some ignorance talking, but: In Section 4.2, if it's found that the child is already securely delegated, should this be an error, or just treat the whole thing like a no-op?  Redundant verification returning an error seems an odd choice, but I'm probably missing some context.

I think the SHOULD in Section 4.3 should really be more like "Parental agents normally trigger ...".  I'm not clear on why this is a normative SHOULD.  What if I don't do it in those circumstances, but possibly in others?  I'm still compliant with a SHOULD then, right?  Why might I do it in other situations?  The text doesn't say.

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

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

[Ballot comment]
Thank you to Peter Yee for the GENART review.

** Section 6.  Editorial.
  The level of rigor in Section 4.2 is needed to prevent publication of
  a half-baked DS RRset

Is “half-baked DS RRset” a term-of-art?  To improve readability, I recommend not using an idiomatic expression.

** Section 7.  Editorial. Per the reference to [draft-ietf-dnsop-dnssec-bootstrapping], this should likely be something like “[This RFC]” and subsequent comment of that string being replaced by the RFC Editor. 

** idnits reports:
  ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499)

[Ballot comment]
# Gunter Van de Velde, RTG AD, comments for draft-ietf-dnsop-dnssec-bootstrapping-08.txt

Please find https://www.ietf.org/blog/handling-iesg-ballot-positions/ documenting the handling of ballots.

#GENERIC COMMENTS
#================

## idnits: There seems to be an obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499)

[Ballot comment]
# Internet AD comments for draft-ietf-dnsop-dnssec-bootstrapping-08
CC @ekline

* comment syntax:
  - https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
  - https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

### S7

* Should there be some kind of registration or reservation for the "_dsboot"
  meaning and usage described in this document?

Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list. Submission of review completed at an earlier date.

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

IANA has completed its review of draft-ietf-dnsop-dnssec-bootstrapping-08. If any part of this review is inaccurate, please let us know.

The IANA understands that, upon approval of this document, there is a single action which we must complete.

In the Underscored and Globally Scoped DNS Node Names registry located on the Domain Name System (DNS) Parameters registry group located at:

https://www.iana.org/assignments/dns-parameters/

two new registrations will be made as follows:

RR Type: CDS
_ NODE NAME: _signal
Reference: [ RFC-to-be ]

RR Type: CDNSKEY
_ NODE NAME: _signal
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we have initiated the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

We understand that this is the only action required to be completed upon approval of this document.

NOTE: The action requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the action that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-04-26):

From: The IESG
To: IETF-Announce
CC: dnsop-chairs@ietf.org, dnsop@ietf.org, draft-ietf-dnsop-dnssec-bootstrapping@ietf.org, tjw.ietf@gmail.com, warren@kumari.net
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator) to Proposed Standard


The IESG has received a request from the Domain Name System Operations WG
(dnsop) to consider the following document: - 'Automatic DNSSEC Bootstrapping
using Authenticated Signals from the
  Zone's Operator'
  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
last-call@ietf.org mailing lists by 2024-04-26. 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


  This document introduces an in-band method for DNS operators to
  publish arbitrary information about the zones they are authoritative
  for, in an authenticated fashion and on a per-zone basis.  The
  mechanism allows managed DNS operators to securely announce DNSSEC
  key parameters for zones under their management, including for zones
  that are not currently securely delegated.

  Whenever DS records are absent for a zone's delegation, this signal
  enables the parent's registry or registrar to cryptographically
  validate the CDS/CDNSKEY records found at the child's apex.  The
  parent can then provision DS records for the delegation without
  resorting to out-of-band validation or weaker types of cross-checks
  such as "Accept after Delay".

  This document deprecates the DS enrollment methods described in
  Section 3 of RFC 8078 in favor of Section 4 of this document, and
  also updates RFC 7344.

  [ Ed note: This document is being collaborated on at
  https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
  (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/).
  The authors gratefully accept pull requests. ]




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



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

(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

  This document introduces an in-band method for DNS operators to
  publish arbitrary information about the zones they are authoritative
  for, in an authenticated fashion and on a per-zone basis.  The
  mechanism allows managed DNS operators to securely announce DNSSEC
  key parameters for zones under their management, including for zones
  that are not currently securely delegated.


Working Group Summary:

The working group consensus was strong, and work was done to improve the examples
and the implementation section.

Document Quality:

Document quality is good - implemntations do exist and are documented, and testing
has been done to confirm interoperability.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Personnel:

Tim Wicinski is the Document Shepherd.

Warren Kumari is the Area Director.

(3) The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.


(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state

(15) There are no downward normative references

(16) Document will update RFCs 7344 and 8078 and they are listed in the abstract and the introduction.

(17) Review of the IANA considerations is consistent with the document.


(18) No new IANA registries.

(19) N/A

(1) RFC is Standards Track, and this is the correct RFC type.

(2)

Technical Summary:

  This document introduces an in-band method for DNS operators to
  publish arbitrary information about the zones they are authoritative
  for, in an authenticated fashion and on a per-zone basis.  The
  mechanism allows managed DNS operators to securely announce DNSSEC
  key parameters for zones under their management, including for zones
  that are not currently securely delegated.


Working Group Summary:

The working group consensus was strong, and work was done to improve the examples
and the implementation section.

Document Quality:

Document quality is good - implemntations do exist and are documented, and testing
has been done to confirm interoperability.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Personnel:

Tim Wicinski is the Document Shepherd.

Warren Kumari is the Area Director.

(3) The Document Shepherd did a detailed review of the document
for content as well as simple editorial checks (spelling/grammar).
The shepherd feels the document is ready for publication.


(4) The Document Shepherd has no concerns on the depth or breadth of the reviews.

(5) There is no need for broader review.

(6) There are no concerns from the document shepherd.

(7) No IPR disclosures

(8) There is no IPR

(9) The WG Consensus on this document is strong.

(10) There has been no appeals.

(11) All nits found have been addressed by the authors.

(12) No formal review needed

(13) All references have been identified as normative or informative.

(14) All normative references are in a clear state

(15) There are no downward normative references

(16) Document will update RFCs 7344 and 8078 and they are listed in the abstract and the introduction.

(17) Review of the IANA considerations is consistent with the document.


(18) No new IANA registries.

(19) N/A