On Fri, 17 May 2024, Peter Thomassen wrote:
Proposed text:
# Abstract
OLD
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.
NEW
This document establishes the DS enrollment method described in
Section 4 of this document as the preferred method over those from
Section 3 of RFC 8078. It also updates RFC 7344.
Good for me.
# Section 2
OLD
The DS enrollment methods described in Section 3 of [RFC8078] are
deprecated and SHOULD NOT be used. Child DNS operators and parental
agents who wish to use CDS/CDNSKEY records for initial DS enrollment
SHOULD instead support the authentication protocol described in
Section 4 of this document.
NEW
The DS enrollment methods described in Section 3 of [RFC8078] are
less secure than the method described in Section 4 of this document.
It is therefore RECOMMENDED that Child DNS operators and parental
agents who wish to use CDS/CDNSKEY records for initial DS enrollment
instead support the authentication protocol described here.
I would remove the word "instead", as it now doesnt deprecate it.
Otherwise okay.
So in that case, I think it would be more clear to rename "Signaling
domain" to "Signaling name".
The authors agree with Joe's observations (in a "sibling post" to this
message), and believe that "domain" is accurate.
Okay, since we have trouble coming up with a better name, let's keep it.
I'm not sure. It's conceivable for a TLD operator to run DNS service for
some of its child zones, and if I recall correctly, some of the smaller
ccTLDs do. In this case, address records of nameservers operated under a
child may be part of the TLD zone (along with the corresponding signaling
names), so the signaling records' signer name is indeed the TLD.
But then it is not a domain that can request DS records anyway
That's a misconception; the zone that's authoritative for some the
*nameserver name* (and, perhaps including the signaling stuff if there's no
zone cut) is independent of the child that gets bootstrapped (which is often
under a different parent). It is the latter where DS records are requested.
Ok, let's drop my proposal.
(eg like in .de)
Not sure what you mean here; .de does delegations, and also publishes DS
records. (They want the input to be DNSKEY-style, though, and compute DS
themselves.)
.de allows direct entries for "simple" domains, eg MX plus "www", to be
hosted by them. It becomes part of the de. TLD itself. Not using
zonecuts at all. I thought that's what you were referring to.
That adds significant complexity, to defend against a scenario that is simply
"part of life" in the DNSSEC security model ("there is no way to defend
against the parent").
We will leave it to dnssec transparency logging to find "deep signs"....
I am very skeptical of adding mandatory implementation complexity to cover
something that reaches beyond the DNSSEC security model. If OTOH it were
optional, I have my doubts that parents would implement it.
Fair.
Thus: Would it address your concern if we said that QNAME minimization is
REQUIRED or RECOMMENDED for resolving signaling records? (Which of the two?)
Let's leave it out for now. Or if you want you can add it as
RECOMMENDED, but I think then you'd also need to talk a bunch about
starting from an empty cache and stuff, so I would leave it out
completely.
OLD
CDS/CDNSKEY records and corresponding signaling records MUST NOT be
published without the zone owner's consent. Likewise, the child DNS
operator MUST enable the zone owner to signal the desire to turn off
DNSSEC by publication of the special-value CDS/CDNSKEY RRset
specified in [RFC8078] Section 4. To facilitate transitions between
DNS operators, child DNS operators SHOULD support the multi-signer
protocols described in [RFC8901].
NEW
It is possible to add CDS/CDNSKEY records and corresponding signaling
records to a zone without explicit knowledge of the domain owner. To
spare domain owners from being caught off guard by state changes
induced by this practice, Child DNS operators doing so are advised to
make this transparent.
Maybe add: ", for example by notifying the domain owner via email".
When transferring a zone to another DNS operator, the old and new
child DNS operators need to cooperate to achieve a smooth transition,
e.g., by using the multi-signer protocols described in [RFC8901]. 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
insecurely (see [I-D.hardaker-dnsop-intentionally-temporary-insec].)
If the current DNS hoster does not cooperate, It would not let you use
CDS/CDNSKEY,
so I wouldn't mention 8078.
So I believe with this we addressed all concerns, and if a new draft is
published I will update by DISCUSS ballot to Yes.
Paul
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
