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

[Peter Thomassen <[e-mail]>]

Hi Paul,

On 5/17/24 20:45, Paul Wouters wrote:
>> # 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.

OK. This leads to the confusing constellation "for initial DS enrollment support", where "support" looks like a noun but is a verb. I thus restructured the last sentence equivalently as follows:

NEW
    The DS enrollment methods described in Section 3 of [RFC8078] are
    less secure than the method described in Section 4 of this document.
    Child DNS operators and parental agents wishing to use CDS/CDNSKEY
    records for initial DS enrollment SHOULD therefore support the
    authentication protocol described here.

>> 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"....

;-)

>> 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.

Section 5.2 (parent-side operational considerations) already says that it is "RECOMMENDED toperform queries into signaling domains with an (initially) coldresolver cache", so it actually fits well.

I used the opportunity to replace "cold" with "empty" (avoiding jargon), and added right after:

NEW
    It is also RECOMMENDED to use QNAME minimization [RFC9156] when
    resolving queries for signaling records, to guard against certain
    attacks (see Section 6).


In Section 6 (security considerations), I then added:

NEW
    If QNAME minimization [RFC9156] is not used when querying for
    signaling records, an upstream parent of a signaling domain will see
    those CDS/CDNSKEY queries and could respond with an authoritative
    answer signed with its own key, instead of sending the referral.
    Enabling QNAME minimization reduces the attack surface for such
    forgery.


What do you think?

>> 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".

Mmh, I find this quite prescriptive ("a priming example"). It could also be done as an info box when you create the zone (perhaps you can untick a box to disable), or as an advertised feature when you book the plan. Those approaches seem favorable, because they are ahead of time (before it actually happens), while a notification is after the fact.

Now, I'm not sure whether we should go into elaborating on all of this; but *if* we say something, I feel we should mention one of the "ahead-of-time" ways. I'd be curious to know what you think of this.

>>    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.

There's an assumption here that I don't share. It's rooted in the fact that it's very unclear what "not cooperate" means. Does it mean "not doing multi-signer transitions"?

I suppose many DNS hosters are not aware of multi-signer and its intricacies, and wouldn't dare such a setup until we come up with good automation schemes. (That gap is on us to fix.) But until that's there, a DNS hoster trying to cooperate may much more easily support CDS-delete.

But, should they? Isn't disabling DS the wrong thing to do? Well, the domain owner may have good reasons (they're not for us to judge), and in a properly automated environment, it should never be necessary to have a manual interaction with the registrar about DS.

So it seems reasonable to me that if you can turn something on without a human reaching out to the registrar, you should also be able to turn it off the same way. That also helps with cases where the domain owner hadn't agreed, and the operator provisioned DS records accidentally etc.


Finally, there are cases where cooperation doesn't get you where you want. Consider the following scenario: Moving from a DNS hoster that only does one algorithm to a hoster that only does another one (e.g., 8 vs. 13). Even if both want to cooperate, a valid multi-signer setup can't be constructed (because it would require announcing both algorithms via DS, which is illegal as long as they can't sign the zone with both algorithms [0]).

In this case, one might want to go insecure for a brief period (although that would of course be a very suboptimal thing to do; OTOH, asking one provider to implement the other's algorithm has near zero hopes to succeed). Using RFC 8078 CDS-delete would spare the domain owner from having to touch the registrar's DS interface, which I think is the right design.

[0]: In this context, Section 2.2 of https://datatracker.ietf.org/doc/draft-huque-dnsop-multi-alg-rules/ offers a solution that I think should be advanced.

> So I believe with this we addressed all concerns, and if a new draft is
> published I will update by DISCUSS ballot to Yes.

Thanks. I'll hold off with the submission in case you'd like to respond. Otherwise, I'm planning to upload a new revision on Monday.

Cheers,
Peter

-- 
https://desec.io/