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

Reply via email to