[DNSOP]Re: Paul Wouters' Discuss on draft-ietf-dnsop-dnssec-bootstrapping-08: (with DISCUSS and COMMENT)

[Paul Wouters <[e-mail]>]

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