On Mon, Dec 23, 2024 at 10:31 PM John Levine <johnl@xxxxxxxxx> wrote:
It appears that Patrick Mevzek via Datatracker <ietf-datatracker@xxxxxxxxxxxxxxxx> said:
>However, I do find in §3 this to be a little weak:
>" While it could support NSEC3 too, there is no benefit in introducing the
>additional complexity associated with it." Because Motivation in §1 clearly
>explains that this new scheme allows fewer number of NSEC records... and
>mentions 3 of them are needed in NSEC3 case, so the benefit is (should be) even
>better here for NSEC3 than NSEC. So I would suggest either giving more details
>here on what would be additional complexity for NSEC3, or just removing the
>whole line and stating unambiguously that the document applies only to zones
>using NSEC.
I think the point here is that NSEC3 is intended to prevent zone walking, but
if you're doing this kind of signing, there's nothing to walk, so NSEC3 has
no benefit. The text could be clearer.
Yes, that is indeed the point.
However, it appears now that circumstances on the ground have changed.
I recently discovered that Oracle Cloud (OCI) has actually implemented
and deployed NSEC3 with Compact Denial of Existence! Do we have any
contacts at Oracle that could elaborate on their motivation? If they already
had a prior NSEC3 implementation and they wanted to simplify it by
adopting this protocol mechanism with a smaller set of tweaks than migrating
to NSEC, that might be a persuasive enough reason. But it appears that their
implementation is brand new (Oracle announced DNSSEC support in October).
(NSEC3 also supports Opt-Out, but that is mainly beneficial to large zones
using pre-computed signatures and with sparse signed child delegations.
Online signers do not benefit much from it.)
In light of this, I am contemplating revising the text in the draft about "no
benefit" and adding a small section describing what needs to be done to
implement this protocol with NSEC3. The changes are very simple. The
owner name of the NSEC3 record is the NSEC3 hash of the owner name,
and the next hashed owner field of the RDATA is the hash of the owner
name plus one.
Since this is arguably a bit more than a trivial change to the draft, we
should probably solicit broader input from the working group.
Shumon.
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
