Hi Peter, Nils, DNSOP,
In general, I very much like the Bootstrapping idea, and the draft. I
also like that it now allows in-bailiwick NS (unless in-bailiwick-only).
However, I'd like to discuss if it really should *replace* RFC8078,
Section 3 whatsoever.
Sure, it's definitely more secure than the rather quirky Accept after
Delay/Checks/Challenge procedures, but it adds also more limitations, as
described in section 3.4 anyway.
I would prefer if both options remained standardized in parallel, so
that anyone can choose between more secure, or more universal way of
DNSSEC bootstrapping.
Alternatively, we may say that the RFC8078 bootstrapping is deprecated,
but still, it doesn't mean that we replace it.
Thanks for more opinions,
Libor
Dne 17. 06. 22 v 12:17 Peter Thomassen napsal(a):
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, internet-dra...@ietf.org 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
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
