Paul Thank you for this detailed review! When I spoke with Peter on WGLC, I had documented organizational issues. I wasn't sure if my organization suggestions were any better, so I opted to mention this during WGLC and have people much smarter than me assist.
I will think out the document organization and normative text and work with Peter on that. I will let Peter and Nils respond to your technical comments. I do think all can be addressed, but I am also an optimist. Thanks again. tim On Sat, Nov 11, 2023 at 6:56 AM Paul Wouters <[email protected]> wrote: > > > Subject: Re: [DNSOP] Working Group Last Call for > draft-ietf-dnsop-dnssec-bootstrapping > > > On 9/19/23 21:48, Tim Wicinski wrote: > > > > > > This starts a Working Group Last Call for > draft-ietf-dnsop-dnssec-bootstrapping > > > > > > Current versions of the draft is available here: > > > > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/ > > < > https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/> > > 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. > > - 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. > > - 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. > > - 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. > > - 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. > > - 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 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. > > - 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. > > > 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. I think it best to limit the solution to > this space, and not try to fold in supporting other cases. Enterprise > deployments can use CDS/CDNSKEY with hooks in IXFR/AXFR detecting these > records automatically. All in-domain nameservers are people who registered > their own stuff and are running their own nameservers. Just let them to > EPP/Registrar UI. This of course goes back to like 2001 when the .nl.nl > experiment concluded what we really needed was a Security Contact. > > 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. > > 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. > > The parent can check all incoming NS records via their EPP system for > a match of "_cds" and do its "trigger" work. It could even suppress > actually including the special NS record in the parent zone but if it gets > published there is no real harm. Once DNSSEC is enabled by the Registry, > the DNS hoster can remove its special NS record and use CDS for further > updates, or the CDS nul record to delete all DS records. > > Paul > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop >
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
