On Mon, Dec 23, 2024 at 11:21 PM Shumon Huque <shu...@gmail.com> wrote:
> > 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. > [dropping last-c...@ietf.org for now] Update ... I've proposed the following new section of text to cover how this protocol can accommodate NSEC3. Please review. Since there are now already implementations in the field, I think it's important that the draft include this description of the small set of changes needed for NSEC3 to properly reflect deployment realities. Numerous inquiries have been posed in the past about the possibility of NSEC3 support, so rather than debating the merits or demerits, I am in favor of just documenting the tradeoffs and details of how to implement it. ------------------ Excerpt: --------------------------------------- 4. NSEC3 Support Requirements The NSEC3 protocol uses hashed names to provide zone enumeration defense. This protection is already better provided by minimally covering NSEC records. NSEC3's Opt-Out feature also provides no specific benefit for online signing implementations. Hence, there does not appear to be a strong advantage to implementing Compact Denial of Existence with NSEC3. An existing implementation of traditional online signing with NSEC3 migrating to Compact Denial of Existence may find it simpler to do so than implementing NSEC from scratch. The functional details of the protocol remain as described in Section 3, with the following changes: NSEC3 records and their signatures are dynamically generated instead of NSEC. The Owner Name of the NSEC3 resource record is the NSEC3 hash of the relevant domain name, and the next hashed owner name is the hash of the owner name plus one. In responses for non-existent names, the Type Bit Maps field will contain only the NXNAME meta-type. In responses to Empty Non-Terminal names, the Type Bit Maps field will be empty. As with other NSEC3 online signing implementations, there is no advantage to setting an NSEC3 salt or iterative hashing count. Thus, the recommended NSEC3 parameter configuration is a flags field of 0, an additional hash iteration count of 0, and an empty salt. In DNS presentation format syntax, the Resource Record data is thus "1 0 0 -". ------------------ End Excert. ------------------------------------ The full commit in the github repo is here, which includes some additional small tweaks to the draft to generalize the protocol description, and to address some of the comments from Patrick Mevzek's dnsdir review. https://github.com/shuque/id-dnssec-compact-lies/commit/d822db90d3de123cafdf5095f53fcf5ec3e94e3f Additionally, I've done a quick implementation of Compact DoE + NSEC3 in a test authoritative server, just to confirm my intuition that it is as straightforward as I expected (and deployed a test zone and verified it with a set of dnssec validator tools). Shumon.
_______________________________________________ DNSOP mailing list -- dnsop@ietf.org To unsubscribe send an email to dnsop-le...@ietf.org
