Hi Paul,
Thanks for your thoughts. I'd like to address your points below and would very
much appreciate your follow-up response.
On 11/11/23 12:55, Paul Wouters wrote:
I have read the document and I am supportive of the idea, but I find the
document not ready. Some issues I have with the document in the current form:
- It "deprecates" RFC8078 but does not offer a solution for all cases of
8078, such as when all nameservers are in-domain of the child.
That is correct. This deprecation was requested to be clarified (but not
challenged) in the Dnsdir review [1].
During the subsequent considerations on the list, nobody objected, which I read as
"the WG prefers deprecation".
If the WG feels differently, let's change the text. Perhaps one or two people
could speak up if they would prefer such a change.
The question at hand is whether, given the cryptographically secure method of
this document, we want to continue endorsing an insecure method, even if only
for in-domain nameservers.
I can imagine three kinds of things to say in the draft without continuing to
endorse insecure bootstrapping:
1.) discourage the insecure method (by deprecating it);
2.) perhaps even discourage in-domain nameservers;
3.) perhaps point out that one might perform DNSSEC bootstrapping with at least
one out-of-domain nameserver, then switch to in-domain nameservers (e.g., via
CSYNC).
The draft currently does the first thing, but not the other two.
In-domain nameservers cause a bunch of problems (including the orphaned glue
saga), and are also foreseen to be incompatible with DELEG-style delegations in
ServiceMode [2].
Reserving any judgment on the DELEG mechanism itself, it appears to me that
in-domain nameservers are best advised against. So perhaps what we should do is
(1) + (2).
[1]: https://mailarchive.ietf.org/arch/msg/dnsop/04LYtemBnRjOBLWzgdD6RuaD5UU/
[2]: https://mailarchive.ietf.org/arch/msg/dnsop/rUY8CJHrrZYa0Sdvi3BV10IsfiE/
- Section 4.3 is named "Triggers" but it basically only describes
"Timers". Some of us have significant scar tissue on this matter,
and I don't see new information or a new technology here that
resolves this old discussion. It feels a lot like restating RFC8078.
The situation in this draft is different from the trigger conditions in in
Section 6.1 of RFC 7344 (which I think is what you meant). That RFC lists
conditions for *updating* a DS RRset. This one here is for *initializing*, so
other scenarios apply.
For example, one condition listed here (but not in RFC 7344) for triggering the
CDS authentication procedure is when the parent receives a new or updated NS
record set for a child.
Besides scans (which of course have a timer) and the receipt of a new NS RRset
(which doesn't), the draft also mentions walking a list of children known to be
in need of bootstrapping, perhaps received by AXFR or extracted via NSEC walk
of signaling zones (and the NS receipt). I don't see any relation to timers
here.
However, this is second instance (after [3]) that someone suggests to remove
this section, so perhaps it's time to do so. Before doing so, I'd like to point
out the following:
The main takeaway from Section 4.3 is that the authentication mechanism
requires reliable knowledge of the delegation's NS records, which -- depending
on the trigger method -- may or may not be implicit in the trigger condition;
as a result, a cross-check in the parent's database may be needed for certain
triggers. This point is not contained in RFC 7344 (which deals with updates
which use the child's existing chain of trust, so this point doesn't apply).
In particular, scanning the registry database or installing a new NS RRset
gives *certain* knowledge of what the NS records are, because the trigger
conditions directly derive from processing an NS RRset that has previously been
accepted for delegation.
In contrast, when processing some kind of list fetched externally (e.g. walking
the signaling domain _signal.$NS), it's possible to encounter signaling records
pertaining to domains that are *not* delegated to $NS; therefore, the parent
has to check that what's found in the list matches an actual delegation.
I would like to hear your opinion on whether this point warrants the existence
of Section 4.3; if it doesn't, I'll go ahead and remove it.
[3]: https://mailarchive.ietf.org/arch/msg/dnsop/toP-e7Rc-ZLg0dR2SvzC25kAGxk/
- Style: I think the document is a lot more verbose and repetitive than
it needs to be. Condensing this would increase clarity of the
document.
It looks like opinions within the WG differ here: the only other two feedbacks on style
asked for more examples and otherwise described it as "very clear" (both from
Secdir, [4]), and suggested to be more verbose by adding full RRset examples [5].
I'll be happy to make adjustments, but I'm uncertain about what to change without
"making it worse" from the perspective of others. Would you be able to suggest
specifically which paragraphs/sentences you would like to be removed/condensed?
[4]: https://mailarchive.ietf.org/arch/msg/dnsop/rIHtAMZ7erJ2Pc0NIAG1V6hlSrM/
[5]: https://mailarchive.ietf.org/arch/msg/dnsop/nBsMo1nENZzgUWd7-42zzAuM76w/
- There is the non-RRR model flavour of this and the RRR-model flavour.
What the parent can do greatly depends on the flavour and I think the
document instead focused on only using something that works with either
flavour.
The document is fully agnostic of RRR considerations, and instead focuses on adding an
authentication mechanism for RFC 8078, which also is agnostic of RRR considerations.
(That's why the term "parental agent" is used.)
Of course, when considering other options for delegation maintenance, a
registry could do different things than a registrar; but to my understanding
these are out of scope for RFC 8078 and, by extension, for this authentication
mechanism. Given that, I'm not sure what your comment is trying to say?
- It seems WHOIS/RDAP could be better integrated for relaying a secure
signal instead of relying on insecure DNS lookups with the RRR-flavour.
For example, advising parents with delegation information (eg TLDs) to
lookup NS records in their own WHOIS/RDAP databse instead of using DNS
queries.
The draft does not rely on insecure DNS lookups. Instead, parents directly use
the knowledge they have as a parent, namely, the NS hostnames present in the
delegation. (This point is emphasized in Section 4.3 which is also discussed
above.)
- There are issues with very long domain names not fitting in the
current signal. Why not use hashed FQDNs as part of the signal part.
Additionally this might have some privacy and security advantages too.
(including friendlier to query minimalization :-)
I completely agree with that. In fact, for precisely these reasons, hashing (of
all labels but the first) was part of earlier incarnations of the draft, but,
after discussions [6][7] around IETF 112, it was removed in
draft-thomassen-dnsop-dnssec-bootstrapping-03.
(The WG had settled on the plain variant mainly to ease debugging by visual
inspection without additional tooling. Hashing also poses a challenge for
synthesis of signaling records, which requires reversing the hash. That might
be doable if only the parent name is hashed, see [6].)
[6]: Slide 11 of
https://datatracker.ietf.org/meeting/112/materials/slides-112-dnsop-sessb-automatic-bootstrapping-of-dnssec-delegations-00
[7]: https://mailarchive.ietf.org/arch/msg/dnsop/FE5Sm5vzZtq9VgKxgkfmv4VuVI8/
- I find Section 4.1 and 4.2 and the Security Considerations a bit of
of a weird split. A bullet list of things to do is specified but
then additional things are specified in the Security Considerations.
I agree that Security Considerations are not the place for specification.
There's only one uppercase keyword there, namely that it's RECOMMENDED to
diversify a delegation's NS hostnames across several TLDs, for security
reasons. As this doesn't pertain to the authentication protocol of Section 4
itself, I felt that's OK. But sure, let's move it upstairs! :-)
So, how do you feel about the following?
At the end of 4.1, add:
NEW
To avoid relying on the benevolence of a single Signaling Domain
parent (such as the corresponding TLD registry), it is RECOMMENDED to
diversify the pathfrom the root to each nameserver. This is best
achieved by usingdifferent and independently operated TLDs for each
one.
... and replace the last paragraph of the Security Considerations with the
following two:
NEW
In any case, as the Child DNS Operator has authoritative knowledge of
the Child's CDS/CDNSKEY records, it can readily detect fraudulent
provisioning of DS records.
In order to prevent the TLD of nameserver hostnames from becoming a
single point of failure in a delegation (both in terms of resolution
availability and for the trust model of this protocol), itis
advisable to use NS hostnames that are independent from each other
with respect to their TLD.
- The "_signal" name is very generic. It would be clearer to use a more
descriptive name that also has less chance of being used by completely
different technologies.
The structure of the signaling name was discussed at the DNSOP Interim in May
2022 [8]. To avoid limiting operators' freedom to introduce zone cuts at
arbitrary points in the tree, the WG settled on using a structure that includes
a descriptive prefix label as well as a generic intermediate label. Details on
rejected alternatives can be found in [7].
Keeping the intermediate label generic comes with the side effect that new operator signals (such
as multi-signer key exchange [9]) can be easily introduced via a new prefix, avoiding the need for
a new entry in the "underscored names registry" each time. -- The draft reserves the
"_signal" label for use such operator-side signaling, to prevent collision with other
technologies.
[8]: "Open Issue 3" in
https://datatracker.ietf.org/meeting/interim-2022-dnsop-01/materials/slides-interim-2022-dnsop-01-sessa-authenticated-dnssec-bootstrapping-00.pdf
[9]: https://datatracker.ietf.org/doc/draft-thomassen-dnsop-mske/
I think the goal of the document is to further widepsread automated
deployment of DNSSEC. This happens by the bigger DNS hosters, mostly
for delegations under a TLD.
It may also happen by smallrt DNS hosters, in case implementations are added in
common authoritative server software.
The IETF 114 hackathon has produced a LUA implementation for PowerDNS (used at
deSEC), and the RIPE 86 hackathon worked on a native implementation for Knot
DNS. We're planning to finish this as part of a project funded by NLnet [10].
[10]: https://nlnet.nl/project/AuthenticatedDNSSECbootstrap/
I think it best to limit the solution to
this space,
For what reason? -- Those preferring other solutions may certainly use them,
but I don't see why that should imply a restriction on the applicability of any
specific one.
and not try to fold in supporting other cases. Enterprise
deployments can use CDS/CDNSKEY with hooks in IXFR/AXFR detecting these
records automatically.
I'm not sure what you mean here.
All in-domain nameservers are people who registered
their own stuff and are running their own nameservers.
That's not correct; we have a bunch of users on our managed DNS hosting
platform who insist on creating vanity nameserver names under their domains.
We'd like to stop them (so that it's easier for us to renumber our NS), but it
seems we can't really.
The main use case is non-technical people getting a domain with DNS/web
hosting, where the DNS hoster uses DNSSEC and would like to tell the TLD
to enable DNSSEC. If the Hoster is the Registrar, there is no problem.
It should be able to use EPP to get a DS into the Registry. If the
DNS hoster is not the Registrar, then this EPP path is not available.
But usually those DNS hosters _are_ Registrars already, but only for their
own zones and their customers zone. Just this customer is using their
DNS service but not their registrar service. Place the information there,
eg via EPP. This would be much more secure than DNS timers/triggers.
I agree with parts of that and don't with other parts; but I think it's a
tangent. The draft doesn't tell everyone to use the protocol, and certainly not
internally within a registrar that's also the operator.
What the draft does is taking the existing method of RFC 8078 and adding
authentication. I assume we're generally in agreement that that is a good thing
(please correct me in case you disagree). The use cases are the same use cases
as for RFC 8078, and the draft isn't touching that.
If this is truly too complicated (which I think it should not be), DNS
signals could be used, but I would simplify it by telling the customer
that for moving the domain to the new DNS hoster, to add a special NS
record that indicates the DNSSEC information, eg:
customer.example IN NS ns0.dnshoster.tld.
customer.example IN NS ns1.dnshoster.tld.
customer.example IN NS <hash of DNSKEY>._cds.dnshoster.tld.
The DNS hoster can confirm they are the hoster by simply putting a
(signed) A/AAAA record at <hash of DNSKEY>._cds.dnshoster.tld. using one
of the real nameserver IPs as RDATA. This prevents people from
adding the DNS hoster without permission.
Preventing illegitimate use of nameservers ("lame delegations") is an entirely
different protocol. The draft is trying to authenticate DS records.
Thanks,
Peter
