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/

_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org

Reply via email to