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, [email protected] 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
[email protected]
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
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
