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

[Peter Thomassen <[e-mail]>]

Hi Paul,

Thanks once more. Suggested changes and other comments below. Text edits can be previewed in this PR: https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/pull/16/commits

On 5/17/24 04:15, Paul Wouters wrote:
>>>  Section 2:
>>>
>>>           The DS enrollment methods described in Section 3 of [RFC8078]
>>>           are deprecated and SHOULD NOT be used.
> 
> This was discussed on the IESG telechat today, and I think we had
> consensus around some text that RECOMMENDS this documenter over
> the existing methods, but does not obsolete/deprecate them because
> those methods might be the only ones available for now. At a future
> point this decision could be updated to obsolete the older methods.

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.

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

Does that work?

>>>  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.
>>
>> The authors don't insist on anything, and I find this language slightly irritating.
> 
>> (In my understanding of the word, it implies the absence of a rationale and/or an unwillingness to engage in a discussion. I assume that was not the intention ...)
> 
> Note that this seems to be just a miscommunication.
[...]
> In this
> context, the word "insists" just meant to convey "sticks to their current
> views" and did not convey anything about intensions of parties involved.

Indeed, it must have been my misinterpretation. (For context, in my native tongue, "insistieren" implies some degree of stubbornness, and throwing it in someone's face has a somewhat judgmental undertone.)

Apologies! Thank you for clarifying.

>>>  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 ?
>>
>> The document does not insist that there be a zone cut.
> 
> 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.

Further, the draft uses "signaling name" for the things that are prefixed to the signaling domain, such as _dsboot.example.com, so one would have to find a new term for that as well. (Note that "signaling prefix" would not be good choice either because it is easily confused with _dsboot, the "signaling type".)

We agree that it is somewhat suboptimal terminology, and there indeed has been an earlier attempt to find better terminology. Unfortunately, that didn't lead anywhere. For things attempted, see https://mailarchive.ietf.org/arch/msg/dnsop/_hQhxmTMJ7qwsj2N6P9uqSRKADY/.

However, the definition of "Signaling Domain" could be made more clear. We've included the suggestion from Joe's message.

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

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

>> In case that was an attack, the TLD (or root) would have to conceal the delegation of example.net in order to then get asked for _signal.ns1.example.net/CDS, to then publicly fabricate a signed response.
> 
> Unfortunately, they do not need to conceal it. If the .net TLD receives
> a query for _signal.ns1.example.net, they can just give an authoritative
> answer signed by their .net key, even if they publish NS records for
> example.net. A resolver that does not do query minimalization will just
> believe it.
> 
>> That would discredit the operator quite significantly, and thus seems very unlikely. Additionally, mitigation is available by using nameservers under different TLDs, as mentioned in the document.
> 
> I still think placing an additional security control here makes
> sense. Just to ensure that the DNS hoster is in fact the party that
> signed the signaling data.
> 
>> The problem lies in identifying "the DNS hoster's zone". There's no a priori knowledge about how far up the tree it is.
> 
> You can detect a "deep sign", eg a signature that crosses a delegation.
> It does not matter how many zone cuts there are, as long as the CDS is
> not signed by a key on the upper side of a NS/DS delegation. I
> understand this does involve some manual work (eg not just stock DNSSEC
> validation).

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

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.

Note that "beyond the DNSSEC security model" isn't only a phrase, it's also impossible to get it right. Consider the following:

The attack requires the parent (of a nameserver hostname) to be malicious. If we assume that, they can easily work around the proposed control by observing for a while which are the source IP addresses that the victim registrar/registry uses for CDS/CDNSKEY queries, and then concealing any downstream delegations (towards the signaling zone) for those source IP addresses only. The parent (of the child being bootstrapped) will then not see the zone cut between the child's NS hostname and its TLD. As a result, this defense won't work.

Given such a malicious parent, it seems more effective to diversify NS top level labels, which the draft already says.

Your comment on QNAME minimization is a pretty interesting one, however -- because when used, the malicious parent cannot a priori know that the eventual query will be about CDS/CDNSKEY. It thus won't be able to reliably prevent the delegation from reaching the querier's cache, at which point it's too late to conceal it. Once in the cache, the NS domain parent no longer will get asked for CDS/CDNSKEY records (only the authoritative server of the nameserver domain will), so that RRSIGs will originate from the DNS hoster's zone, and the attack falls apart.

Thus: Would it address your concern if we said that QNAME minimization is REQUIRED or RECOMMENDED for resolving signaling records? (Which of the two?)

>>>  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.
>>
>> These were added based on Warren's concerns that a DNS operator may lock in a customer by enabling DNSSEC without consent, thus making it harder to move away from that provider.
> 
> I talked to Warren a bit, and I think he understands my concern a bit
> better. Perhaps something like this could work:
> 
> 
>      CDS/CDNSKEY records and corresponding signaling records can be
>      added using this protocol without explicit knowledge of the
>      domain owner. When transferring a domain to a new DNS hoster,
>      the old and new DNS hoster need to cooperate to allow for a
>      smooth transition. In the worst case, this might involve the
>      requesting the Registrar to remove all DS records and perform
>      a transfer as per draft-hardaker-dnsop-intentionally-temporary-insec

I tried to merge this with the sentence Warren suggested in his post in this thread, and came up with the following:

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.

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

Does this work for you?

>> The authors believe either way is fine, and would like to hear the IESG's decision on how to address this (or not).
> 
> The IESG does not make decisions like that. It points at what it thinks
> are issues and everyone in the community hopefully works together to
> resolve it. So above is my proposal. Let's see if Warren or you have
> some improvements on this first proposal of me.

Oh, yes of course. I meant, we'd like the IESG's advice, which we would effectively use as a decision to settle the question, given that we know the question was contentious within your group. Sorry for the blurry words.

Thanks,
Peter

-- 
https://desec.io/