Re: [DNSOP] I-D Action: draft-ietf-dnsop-dnssec-bootstrapping-01.txt

[Peter Thomassen <[e-mail]>]

Dear DNSOP,

We have addressed the WG's feedback from the Interim on May 24, and also addressed remaining outstanding issues (mainly editorial).

 From the authors' perspective, the protocol draft is now "final" (in the sense, that no action items remain). We would appreciate the group's thorough feedback, and -- if the group feels like it -- proceed to WG Last Call


The most significant changes are:

> Introduced Signaling Type prefix (_dsboot), renamed Signaling Name infix from _dsauth to _signal.
> 
> Allow bootstrapping when some (not all) NS hostnames are in bailiwick.

Due to the first change, DS signaling records now live at names such as: _dsboot.example.co.uk._signal.ns1.example.net


Other changes are:

> Clarified Operational Recommendations according to operator feedback.
> 
> Turn loose Security Considerations points into coherent text.
> 
> Do no longer suggest NSEC-walking Signaling Domains. (It does not work well due to the Signaling Type prefix. What's more, it's unclear who would do this: Parents know there delegations and can do a targeted scan; others are not interested.)
> 
> Editorial changes.
> 
> Added IANA request.


On other news, Cloudflare has announced production deployment of the protocol on all their signed domains (see slide 10 of Christian's slides at https://74.schedule.icann.org/meetings/WiPRZ59cBZDvj5ws2).

Thanks,
Peter



On 6/17/22 12:06, [e-mail] wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations WG of the IETF.
> 
>          Title           : Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator
>          Authors         : Peter Thomassen
>                            Nils Wisiol
> 	Filename        : draft-ietf-dnsop-dnssec-bootstrapping-01.txt
> 	Pages           : 14
> 	Date            : 2022-06-17
> 
> Abstract:
>     This document introduces an in-band method for DNS operators to
>     publish arbitrary information about the zones they are authoritative
>     for, in an authenticated fashion and on a per-zone basis.  The
>     mechanism allows managed DNS operators to securely announce DNSSEC
>     key parameters for zones under their management, including for zones
>     that are not currently securely delegated.
> 
>     Whenever DS records are absent for a zone's delegation, this signal
>     enables the parent's registry or registrar to cryptographically
>     validate the CDS/CDNSKEY records found at the child's apex.  The
>     parent can then provision DS records for the delegation without
>     resorting to out-of-band validation or weaker types of cross-checks
>     such as "Accept after Delay" ([RFC8078]).
> 
>     This document updates [RFC8078] and replaces its Section 3 with
>     Section 3.2 of this document.
> 
>     [ Ed note: This document is being collaborated on at
>     https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/
>     (https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/).
>     The authors gratefully accept pull requests. ]
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnsop-dnssec-bootstrapping/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-dnsop-dnssec-bootstrapping-01.html
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dnssec-bootstrapping-01
> 
> 
> Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts
> 
> 
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
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