I read the draft and support the document moving forward. I find it nice to leverage the secure link between the child zone owner and the DNS hoster. Having the full RRSet in the zone being explicitly mentioned in the document might ease the reading. I have the impression the mechanism could only involve ns1.example.net as opposed to ns1.example.net and ns2.example.org and so maybe some text may explain the additional security provided by associating both of them.
Yours, Daniel On Sat, Nov 11, 2023 at 2:35 PM Tim Wicinski <tjw.i...@gmail.com> wrote: > > 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 <p...@nohats.ca> 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 >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Daniel Migault Ericsson
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
