[dns-operations] NSEC3 parameter selection (BCP: 1 0 0 -)

[Roy Arends]

Hi Viktor,

> On 18 Jan 2021, at 06:57, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> TL;DR.  The BCP NSEC/NSEC3 choices are IMHO:
> 
>    - NSEC          ; for smaller response sizes and realistic
>                    ; acceptance that the zone data is not secret
>                    ; This also facilitates aggressive negative
>                    ; caching, reducing query loads.
> 
>    - NSEC3 1 0 0 - ; for zones that prefer to discourage zone-walking
>                    ; at the cost of larger DoE response packets.
> 
>    - NSEC3 1 1 0 - ; for just a handful of the largest TLDs, where
>                    ; building the full NSEC3 chain is a non-trivial
>                    ; burden.  Pretty much .COM, but perhaps a few more.
> 
> Three recent data points are perhaps an indication that the message
> about best-practice in this space has not yet been widely assimilated
> even at TLDs.  [ "Leaf" zones lower down the tree have even less just
> cause to enable NSEC3 opt-out. ]
> 
> In particular, the recently launched ".spa" and ".amazon" gTLDs, and
> newly signed ".aero" are using NSEC3 with opt-out, and wasteful extra
> hash iterations (I find the shared "salt" value somewhat "amusing"):
> 
>    h01ujevptngfpnlqv5o7ljtr5mgpmmuu.aero. IN NSEC3 (
>      1 1 100 332539ee7f95c32a H024I3M5E7N82AKIEKRKG4JKJB4JOSH8
>      NS SOA RRSIG DNSKEY NSEC3PARAM )
> 
>    g19djt2akj752esm388ouk6aj02qo882.spa. IN NSEC3 (
>      1 1 100 332539ee7f95c32a ALB20V7NTUH2AJJD7JJ7L9IG7MICR7RF
>      A NS SOA MX TXT SRV RRSIG DNSKEY NSEC3PARAM )
> 
>    kdp5tstbb6u4p70q8e3l7ea74ksvg6lc.amazon. IN NSEC3 (
>      1 1 10 76a1ff9f Q2R4LHDLQ71EMMA9JVAF2IIQDEAT9JDV
>      NS SOA RRSIG DNSKEY NSEC3PARAM TYPE65534 )
> 
> but the full zone file is (or will soon be) accessible via CZDS and
> is otherwise in good measure available from other informal sources
> (certificate transparency logs, zmap, ...).
> 
> To the extent that NSEC3 still makes sense for TLDs, the closest
> examples to best-current-practice are .GOOG, .DEV, .PAGE, ...
> 
>    25um4oo0vkc0v0tcjprl5qj82pv2e3ui.goog. IN NSEC3 (
>      1 0 1 8f3fee3d92a4c131 2HM8UMA28IIQ4SUBT347HQ7FII5RJVEH
>      NS SOA RRSIG DNSKEY NSEC3PARAM )
> 
>    6n3ds9aanpq49o7cm0cdh9382a0jh2n5.dev. IN NSEC3 (
>      1 0 1 b7b0891083980e59 6N3MCHJEC01UPT3IR676PLEQGRVJ2UTC
>      NS SOA RRSIG DNSKEY NSEC3PARAM )
> 
>    98cqn8pmrp6sdug39rvmhse4cg61linm.page. IN NSEC3 (
>      1 0 1 b335b7536f34f743 98CUIOFUAMGOBON90HPNK6HJTVM42OBQ
>        NS SOA RRSIG DNSKEY NSEC3PARAM )
> 
> where there's no opt-out, and just one extra SHA1 iteration (though zero
> IMHO is just as effective and cheaper).  The non-empty salt is
> pointless, but basically harmless.
> 
> For the largest extant TLDs, which are not yet ready to abandon opt-out,
> the BCP examples are .COM and .NET where NSEC3 is used exclusively for
> the "opt-out" support, (empty salt, 0 extra iterations):
> 
>     CK0POJMG874LJREF7EFN8430QVIT8BSM.com. IN NSEC3 (
>       1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A
>       NS SOA RRSIG DNSKEY NSEC3PARAM )
> 
>     A1RT98BS5QGC9NFI51S9HCI47ULJG6JH.net. IN NSEC3 (
>       1 1 0 - A1RUUFFJKCT2Q54P78F8EJGJ8JBK7I8B
>       NS SOA RRSIG DNSKEY NSEC3PARAM )
> 
> But for new gTLDs, I'd argue that they're far from likely to get
> anywhere near the size of .NET any time soon (or ever), and that
> "opt-out" is entirely the wrong tradeoff.
> 
> The storage cost of listing every domain in the NSEC3 chain for a
> typical-size TLD (pretty much all except .COM) is modest, and there's no
> reason to sacrifice denial of existence security for little to no gain.
> 
> Similarly, the 100 iterations just slow down the authoritative servers
> and validating resolvers for no good reason.
> 
> I'd like to encourage the operators of TLD zones to use either
> simply NSEC (IIRC .ORG have indicated intent to move to NSEC),
> or where modest zone-walking protection is deemed appropriate,
> use NSEC3 with no opt-out, no salt, and no extra iterations.
> 
> Just the first (implicit) SHA1 iteration is quite enough to
> discourage most zone-walkers, and the zone content of TLDs
> is far from secret.  Even where zone feeds are not generally
> available, I am typically able to obtain 75-90% of the names
> in a TLD zone from other sources, without resorting to any
> zone walks.

Hi Viktor,

I agree with you. 

Large iteration values put a heavy burden on validating resolvers, opt-out should _only_ be used if the cost of signing a large, unsigned-delegation-centric zone prohibits normal operations, and lastly, if salt is not regularly changed, it is useless and might as well not be used at all to save a few bytes in responses. NSEC should be the norm, NSEC3 the exception.

Please note that moving from NSEC3 to NSEC should be done carefully, but is not impossible. The Swedish Internet Foundation (IIS.SE) has done this last year for both .SE and .NU.

https://internetstiftelsen.se/en/tech/first-large-top-level-domain-to-transition-from-nsec3-to-nsec/ <https://internetstiftelsen.se/en/tech/first-large-top-level-domain-to-transition-from-nsec3-to-nsec/>

Warmly,

Roy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20210118/25dd9285/attachment.html>