[dns-operations] [Ext] Re: Cloudflare TYPE65283

[Edward Lewis]

On 3/27/23, 9:08 PM, "dns-operations on behalf of Viktor Dukhovni" <dns-operations-bounces at dns-oarc.net on behalf of ietf-dane at dukhovni.org> wrote:
>    Perhaps, but until the mythical post-quantum DNSSEC is needed, online
>    signers will use ECDSA, for which denial of existence is already
>    sufficiently compact, even with 4 RRSIGs (SOA + 3 NSEC3).

Idle muttering (note, idle muttering) - if you are doing on-line signing, why stick with NSEC or NSEC3 for denial?  They were designed in an era when host security was so poor that having private key material on an internet-connected host was considered a very bad idea.

NSEC and NSEC3 work on the principle that "I don't know what the query asks in advance but I need to precompute something(*) to sign (where the private key is).  The approach is to reveal what I do have and let the requestor figure out that what they asked for isn't here."  That entire premise is blown away by on-line signing, calling into question all the energy we put into the size of the multi-NSEC(3) responses for negative answers and all the energy we put into mitigating zone walking.

(*) - prior to "Negative Caching of DNS Queries (DNS NCACHE)" [RFC 2308], a response with a return code of "Name Error" (that RFC defined the term NXDOMAIN) and 0 answer records, 0 authority records, and 0 additional records, was a legal way to indicate the queried name does not exist.  I.e., there was nothing (0 bytes) that a digital signature could cover.  The NSEC record (and then the NSE3) were created partly to have something to sign.

Sure, the cost of replacing NSEC and NSEC3 would be another resource record type code roll (such as 5->8, RSA-SHA1 vs RSA-SHA1-NSEC3).  But a new on-the-fly denial of existence might prove to be worth it in operations.