On Sat, Jan 20, 2024 at 3:24 PM Tim Wicinski <tjw.i...@gmail.com> wrote:
> > All > > Peter has integrated feedback from the first working group last call, and > we'd like to do a followup last call. The diff with the current version > is here: > > > https://author-tools.ietf.org/iddiff?url1=draft-ietf-dnsop-dnssec-bootstrapping-05&url2=draft-ietf-dnsop-dnssec-bootstrapping-07&difftype=--html > > 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/ > > The Current Intended Status of this document is: Proposed Standards > > Please review the draft and offer relevant comments. > I have reviewed the draft, and support publication as an RFC. One minor comment is that I think it could be explained early in the document somewhere, about why/how this all works and is secure and scalable. What seems to be missing is the explanation: - The Child DNS Operator is assumed to be doing locally secured DNSSEC signing of the Child zone, or has a secure method of obtaining and publishing the already-signed Child zone (e.g. zone transfer with TSIG). - Since the Child DNS Operator has the signed child zone, the Child DNS Operator is able to obtain and publish the corresponding records in a trusted fashion. - The Signaling {name,zone,record(s)} are a secure method of indirection - The key (literally) is the delegation NS records in the Parent which point to the Name Servers of the Child DNS Operator. If and only if all of the conditions are met, can this bootstrapping protocol be used: - NS points to CDO - CDO nameservers are in a DNSSEC signed zone (meaning fully validated secure chain of trust from root to nameservers' names) - CDO nameservers publish Signaling records in their own signed zone(s) I'm not sure whether any aspects of the comment above would improve the draft. Either way (with or without), I'm fine with proceeding to published. Brian Dickson P.S. I'm no longer at GoDaddy, and no longer have any knowledge of the state of the implementation there. It may be advisable to contact someone there and adjust the implementation status info appropriately. > > For WGLC, we need positive support and constructive comments; lack of > objection is not enough. > So if you think this draft should be published as an RFC, please say so. > > If you feel the document is *not* ready for publication, please speak out > with your reasons. > > > This starts a two week Working Group Last Call process, and ends on: > February 3, 2024 > > thanks > tim > > _______________________________________________ > 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
