On Tue, Aug 8, 2023 at 10:45 AM Ben Schwartz <bemasc= 40meta....@dmarc.ietf.org> wrote:
> Hi DNSOP, > > draft-ietf-dnsop-compact-denial-of-existence currently says the following > about RFC 4470: > > The response for a non-existent name requires up to 2 signed NSEC > records or up to 3 signed NSEC3 records (and for online signers, the > associated cryptographic computation), to prove that (1) the name did > not explicitly exist in the zone, and (2) that it could not have been > synthesized by a wildcard. > > However, it seems to me that the wildcard response is extremely cacheable, > so in practice online signing with RFC 4470 only requires one signature > (even during a cache-busting attack), i.e. the same computational cost as > draft-ietf-dnsop-compact-denial-of-existence. This leaves response packet > size as the primary advantage over RFC 4470. Is this a fair assessment? > Yes, the wildcard at the closest encloser name is certainly amenable to pre-computation and caching. Perhaps at a certain scale or under duress, there would be operational issues. The wildcard non-existence proof also requires knowledge of zone structure, which I'm told some DNS implementations have challenges with. Even with only a hash table of names though, this only requires a quick upward search and stripping off a few leading labels, so I'm not convinced this is a practical impediment. There is another case where things can't be pre-computed though. A wildcard "match" in 4470 needs a dynamically generated NSEC covering non-existent labels, which could be randomly posed by an adversary. Compact DoE prevents this by pretending there is an exact match (I'm not sure if that was a design goal though). At any rate, as I've remarked before, I'm not convinced that the optimizations offered in Compact DoE were actually necessary as an operational matter. But I'll leave it to our colleagues at Cloudflare to argue that case. My interest in publishing this spec is (1) to officially record one of the now dominant implementations of DNSSEC amongst the commercial online DNS signers, and (2) to restore more precise NXDOMAIN visibility. Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
