Libor,
On 6/19/22 16:41, libor.peltan wrote:
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.
I understand the concern, and I believe that at least those parents which already do
implement unauthenticated RFC 8078 bootstrapping (e.g. "accept after delay")
should not immediately run into a situation where the spec is violated. Some parents may
also have other reasons for supporting a less secure method.
So I agree that strictly "replacing" Section 3 may be too much, but we should strongly discourage
its use. Perhaps its enough to state that the draft "obsoletes" (or "deprecates"?) RFC
8078 Section 3?
If we do so, the current draft still has Section 3, which says:
Child DNS Operators and Parental Agents who wish to use CDS/CDNSKEY records for
DNSSEC bootstrapping SHOULD support the authentication protocol described in
this section.
... so this already leave some wiggle room to do things differently.
Any preferences on the wording?
Thanks,
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
