Hi Paul,
Thank you for a thorough review! We've addressed most of your comments and
submitted a new revision (-09) so that the IESG can look at an updated document
during the telechat tomorrow.
Some responses below.
On 5/14/24 19:23, Paul Wouters via Datatracker wrote:
----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------
I have a few items to discuss and some comments. I'm leaving out the discussion
of _signal as a name, as this discussion is taking place on dnsop. While I have
a preference, I'll abide by the consensus call of the dnsop wgchairs.
I requested the chairs to do a consensus call on the matter two weeks ago. The response
was that the document is no longer a WG document, so the chairs "have no role in
this".
For the IESG record: The authors don't feel comfortable overriding WGLC
consensus and changing the protocol, given the absence of unanimous consensus
in the WG and skepticism voiced by implementers (who are most affected) [1].
Also, some more deployments have popped up [2]; not sure how to make sure
everyone is aware of the change.
The authors agree with your earlier suggestion [3] to leave this up to the
IESG, and have them decide whether it's worth the breaking change.
[1]: https://mailarchive.ietf.org/arch/msg/dnsop/XobU0tgxTlRaGc2LsUJP-pYADNg/
[2]:
https://lists.nic.cz/hyperkitty/list/knot-dns-us...@lists.nic.cz/message/5D2WQ5W53CJS5K7LZOI72RCZPJNVFSXF/
[3]: https://mailarchive.ietf.org/arch/msg/dnsop/bHtfwOZ0ow4RKH1PbpX2LRuXsN8/
All Sections:
This document uses the term "bailiwick" a lot. The DNS Terminology series of
RFCs recommands to avoid this term and use "in-domain" or "not in-domain".
done
Section 1:
Readers are expected to be familiar with DNSSEC, including
[RFC4033], [RFC4034], [RFC4035], [RFC6781], [RFC7344], and
[RFC8078].
It should say:
Readers are expected to be familiar with DNSSEC [BCP237].
done
Section 2:
The DS enrollment methods described in Section 3 of [RFC8078]
are deprecated and SHOULD NOT be used.
I find this to be inconsistent with the Update: 8078 clause, as without
"Section 3", you are basically obsoleting the entire 8078. I don't think
this document should obsolete it, it should augment it. I would rewrite
the above like:
The DS enrollment method described in this document provides more
security than the methods described in Section 3 of [RFC8078],
and are therefor RECOMMENDED in favour of the methods specified
in [RFC8078].
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 ...)
Regarding the suggestion: As you noticed correctly, the document *does* make reference to
RFC 8078, which is why it cannot be obsoleted. It's not clear why you then say that it
"should"?
Further reasons why RFC 8078 isn't simply obsoleted:
- RFC 8078 has normative language in Section 4 (Disabling DNSSEC with Null CDS
record), and in Section 5 (Security Considerations). There has been no
proposal/intention to obsolete the content of these sections.
- RFC 8078 elevates RFC 7344 from Informational to Standards Track. Wouldn't that be
"undone" by obsoleting RFC 8078?
- RFC 8078 registers the "Delete DS" algorithm in an IANA registry. This
continues to be needed.
Deprecating the methods of section 3 therefore is very different from
obsoleting RFC 8078.
The language of "deprecate" vs "obsolete" has been discussed on the list. Libor Peltan and John
Levine suggested to "deprecate" the insecure method [4], and Paul Hoffman pointed out that we could
"obsolete" RFC 8078 only if everything is restated [5]. The WG did not express a desire to restate things
like the Null CDS record in the new document. I guess that's because it is unrelated to bootstrapping.
If you have any specific suggestions for how to address your concern, please
let us know. We can also ask the WG to discuss this matter again to find out if
their view has changed or not.
[4]: https://mailarchive.ietf.org/arch/msg/dnsop/Ld0lgCwJJQvgKIA9eBv8yEtgeoI/
[5]: https://mailarchive.ietf.org/arch/msg/dnsop/CDIUGxpYYsWtT3araRwnRXSMV9Y/
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.
I think zone cut should not be mandatory, in which case the language that
uses "signaling domain" should be cleaned up to make this clear.
The Terminology section says:
Signaling domain: A hostname from the child's NS RRset, prefixed
with the label _signal.
It is not implied that this is a zone, but just a domain name. It may surely be
a subdomain in some zone.
That would also mean language like this is no longer needed:
The records are accompanied by RRSIG records created using the
key(s) of the respective signaling zone.
It could just state something like:
These records are signed with DNSSEC just like any other zone data.
done
Later on in the Operational Considerations, the issue is mentioned and
it states zone cuts are not mandatory. So I do think this needs some cleanup.
I'm not sure what to clean up. Please let us know which specific text is
ambiguous (if any), and perhaps how the wording could be improved.
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.
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. 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.
The problem lies in identifying "the DNS hoster's zone". There's no a priori
knowledge about how far up the tree it is. Similarly as their is no requirement for the
signaling domain to be in a separate zone, there's no requirement for the DNS hoster to
use a zone distinct from the TLD. Such a requirement would seem similarly unjustified as
an imposed zone cut at _signal.
So, I'm getting the feeling that I may have misunderstood the scenario you
described, in which case I'd appreciate your elaboration to that we can include
suitable text.
Alternatively, feel free to reword the above paragraph as you see fit, and
we'll include it in the draft.
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.
The authors believe either way is fine, and would like to hear the IESG's
decision on how to address this (or not).
a zone cut ensures that bootstrapping activities do not require
modifications of the zone containing the nameserver hostname.
Why does this matter?
Because nameserver addresses are very static, so rarely touched. Touching a
zone comes with a risk that something goes wrong; at the same time, the
correctness and availability of nameserver addresses is critical to a DNS
operator.
It thus seems a good thing to not needlessly give write permission to
nameserver zones (or any zone, for that matter). Some provisioning systems
(such as at deSEC) follow this approach, and do not have production credentials
available for editing the nameserver zones (there's no API token that can
access them).
The idea is simply, if you screw up your _signal subdomain (e.g. because you
generate it using a script, it exists unexpectedly and the zone still gets
deployed -- a scenario not unheard of), it would be a good thing if nameserver
address records remained unimpressed.
----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------
If a child DNS operator implements the protocol
If a child DNS operator implements this specification
done
(i.e. have a valid DNSSEC chain of trust)
I would say:
(i.e. have a valid publicly resolvable DNSSEC chain of trust)
Otherwise one could argue the parent has to have some "special configuration"
(eg trustanchors) and then it is "valid".
done
that are authoritative for the signaling domains
_signal.ns1.example.net and _signal.ns2.example.org.
This implies that _signal MUST live at a zone cut. Is that required?
If so, why? [other text seems to say that it is not required]
It is not required, and it is also not implied. The full sentence is:
the zone(s) that are authoritative for the signaling domains
_signal.ns1.example.net and _signal.ns2.example.org
The authoritative zone for _signal.ns1.example.net may very well be example.net.
If a zone cut was required, then the text should simply say:
the zone(s) _signal.ns1.example.net and _signal.ns2.example.org
But it does not say that, exactly because a zone cut is not required.
as an authenticated signal as described in Section 3.
I find Section 3 is not a real full "description" of the "authenticated
signal". Reading it is not enough to create such a "authenticated signal".
Paraphrasing, it currently says: Under each NS hostname, using some well-known
child-specific prefix, publish whatever record you want (identically under each
of these names), and make sure it's signed and resolvable with DNSSEC. The
prefix also identifies the type of signal.
The intention is for this to provide a general way for DNS operators to signal
arbitrary information about their hosted zones, in an authenticated way.
Happy to improve. What's missing?
To avoid relying on the benevolence of a single signaling
domain parent (such as the corresponding TLD registry), it is
RECOMMENDED to diversify the path from the root to the child's
nameserver hostnames. This is best achieved by using different
and independently operated TLDs for each one.
This should move to a Security Considerations section, and not be part
of the core protocol. Actually, it is ALSO already in there, so I would
just remove this paragraph.
done. (Actually merged the last sentence of above quote with the corresponding
sentence in the Security Considerations, and remove the rest.)
Section 4.2:
1. verify that the child is not currently securely delegated and
that at least one of its nameservers is out of bailiwick;
I think the first part should clarify this be "ensuring the domain has
no DS records published at the parent". The way it is written, is that
if .ca would briefly lose its DS record, then nohats.ca can be considered
"not currently securely delegated", even if there is a DS record in .ca.
done
2. query the CDS/CDNSKEY records at the child zone apex directly
from each of the authoritative servers as determined by the
delegation's NS record set (without caching);
What is "the delegation's NS record set"? Do you mean the NS RRset at
the parent or at the child?
The former, fixed.
I think there should also be some text on
what to do when the parent and child NS RRsets for the domain mismatch.
(abort?)
The question really is whether CDS processing (also for updates, not only for
bootstrapping) should use child-centric or parent-centric resolution. It can be further
exacerbated by the question whether one needs to ensure consistency across all NS
*addresses* in case there are several. This rabbit hole has been discussed in connection
with draft-ietf-dnsop-cds-consistency, where it was found that such "deep
expansion" consistency checks are not needed.
In addition, the child NS are insecure (a parent cannot obtain them securely at
bootstrapping time), whereas the parent-side NS are definite knowledge (the
domain owner gave them to the parent). Ignoring the additional step of having
to retrieve the child-side NS RRset, it's not clear that the parent should use
any data that can't be verified.
Based on the unverifiability and on the other feedback mentioned, the authors
think that it's best to not consider the child-side NS in this context. If you
feel strongly, we can of course revisit, but I think we would have to involve
the WG.
all record sets
All RRsets
done
If the above steps succeed without error, the CDS/CDNSKEY records
are successfully validated,
I would use verified instead of validated to avoid confusion with DNSSEC
validation.
done
However, the parental agent MUST
Remove the word "However, ".
done
in Step 1: the child is already securely delegated or has
in-bailiwick nameservers only;
or the path from the root to the child traverses an insecure delegation.
Why is that a problem?
It seems fine to provision DS records for an insecure child even if the parent
is insecure, as long as the signaling records can be validated.
Use cases could be trust anchor islands, or subtrees that get set up with
DNSSEC before the parent DS gets enabled. Not sure why the protocol should
forbid that.
CDS/CDNSKEY records [...]
CDS/CDNSKEY RRsets [...]
USe consistent terminology. I recommend RRsets
done
Thanks,
Nils and Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
