Hi Paul, Warren,
Following up on the telechat:
On 5/15/24 20:34, Peter Thomassen wrote:
Section 2:
The DS enrollment methods described in Section 3 of [RFC8078]
are deprecated and SHOULD NOT be used.
I find this to be inconsistent with the Update: 8078 clause, as without
"Section 3", you are basically obsoleting the entire 8078. I don't think
this document should obsolete it, it should augment it. I would rewrite
the above like:
The DS enrollment method described in this document provides more
security than the methods described in Section 3 of [RFC8078],
and are therefor RECOMMENDED in favour of the methods specified
in [RFC8078].
If the authors/WG insists on the "deprecated" language, it should also
Obsolete: 8078. But be aware that the document currently does make references
to it, which it cannot do if it obsoletes the document.
I now understood better what this was about.
My understanding of the WG discussion [4] is that the intention of the current text ("the old
method is NOT RECOMMENDED") is quite similar to that of Paul's proposal ("the new method
is RECOMMENDED").
The word "deprecated" adds the aspect of "phasing out" (i.e., "with a negative slope"),
whereas "obsoleted" is stronger and means that it has already been phased out. (This is my limited non-native
interpretation of English.)
The telechat consensus appears to have been to adopt something like your
wording, without implying a phase-out (deprecation). If I captured this
correctly, we'll incorporate something along those lines.
[4]: https://mailarchive.ietf.org/arch/msg/dnsop/Ld0lgCwJJQvgKIA9eBv8yEtgeoI/
Section 5:
CDS/CDNSKEY records and corresponding signaling records MUST
NOT be published without the zone owner's consent.
This opens a can of worms. How is an implementer going to codify this
MUST? The only usable interpretation I can see is that the DNS hoster,
by being assigned the DNS hoster, has permissions to DNS host the zone
as it sees fit, and thus do DNSSEC. And especially not bother the zone
owner with techno-babble for permissions.
Likewise, the child DNS operator MUST enable the zone owner
Again, this wades into legalize and contractual matters best left
outside of RFC specifications.
These were added based on Warren's concerns that a DNS operator may lock in a
customer by enabling DNSSEC without consent, thus making it harder to move away
from that provider.
The authors believe either way is fine, and would like to hear the IESG's
decision on how to address this (or not).
If I recall correctly, the sentiment was to change the wording around this to
be less MUST-y, but still make the point. We'll try to come up with something
suitable and circulate it here.
Peter
--
https://desec.io/
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
