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
