On Thu, May 16, 2024 at 11:48 AM, Peter Thomassen <pe...@desec.io> wrote:
> 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.
>
Yup, I believe that this is correct.
> [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.
>
Yup. Paul W and I had a long (and fruitful) discussion. I'm personally
still twitchy about the potential for vendor lock-in and zones being
changed without the users' consent — but I'm willing to concede that I'm in
the rough here.
I'd be fine with this being changed to something along the lines of "Users
should be informed that the operator may enable DNSSEC on their behalf…" or
similar weasel-words…
W
> Peter
>
> --
> https://desec.io/
>
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
