Thanks Peter and Paul I'll review the revised I-D but we were thinking of going another (perhaps shorter) follow up working group last call
tim On Fri, Jan 19, 2024 at 8:59 AM Peter Thomassen <pe...@desec.io> wrote: > For the record, Paul and I sorted these out off-list (for real, this > time!), and I'll push a new revision of the draft shortly. > > ~Peter > > On 11/20/23 16:49, Peter Thomassen wrote: > > Hi Paul, (off-list) > > > > To keep the ball rolling, may I nudge you for your opinion on the below? > :) > > > > Thank you very much for your input, > > Peter > > > > > > On 11/13/23 22:30, Peter Thomassen wrote: > >> 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 > >> > > > > -- > Like our community service? 💛 > Please consider donating at > > https://desec.io/ > > deSEC e.V. > Kyffhäuserstr. 5 > 10781 Berlin > Germany > > Vorstandsvorsitz: Nils Wisiol > Registergericht: AG Berlin (Charlottenburg) VR 37525 > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
