[dns-operations] NSEC3PARAM iteration count update

Sun Jan 7 18:55:55 UTC 2018

Sorry for the late response, 

> On Dec 21, 2017, at 3:17 AM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> [ I'm also posting a separate copy to dnsop at ietf.org ]
> 
> In light of the observations in:
> 
>   https://tools.ietf.org/html/draft-york-dnsop-deploying-dnssec-crypto-algs-05#section-2.3.1
> 
> I thought it would be useful to take another look at current practice.
> To that end, I gathered responses to NSEC3PARAM queries from the 5.147
> million DNSSEC-signed domains I'm tracking as part of the ongoing DANE
> SMTP survey.  This covers all the DNSSEC-signed domains from zones where
> I have a full field (.com, .net, .org, .se, .nu and a bunch of the more
> recent gTLDs for which CZDS provides access).  So the coverage is primarily
> incomplete just for various ccTLDs (.de, .nl, .ru, .uk, ...) where I've
> managed to collect around around 60% of the domains from other sources.
> 
> The overall sample characteristics are:
> 
>   5126588    successful NSEC3PARAM lookups
>     20820    failed lookups (ServFail or timeout)
>   3598119    NSEC3PARAM RRsets with 1 record
>         6    NSEC3PARAM RRsets with 2 records (two salts)
>   1523390    NODATA (presumably domain uses NSEC rather than NSEC3)
> 
> The below distribution of iteration counts (rounded up to the nearest
> multiple of 10 for values between 20 and 2500) is largely concentrated
> at 1, 5, 8, 10, 20, 40 and 100.  Values <= 150 should work for all key
> sizes with a correctly configured resolver, so the vast majority of
> domains don't have any trouble with secure denial of existence:
> 
> #domains iterations
> -------- ------
>     115      0
> 1501953      1
>    3513      2
>      92      3
>      10      4
>   58907      5
>      21      6
>     322      7
>  941391      8
>      17      9
>  194324     10
>       5     11
>     229     12
>      49     13
>       2     14
>     599     15
>    8778     16
>       4     17
>       1     19
>  317662     20
>     167     30
>   37138     40
>    3834     50
>       3     60
>      13     70
>      28     80
>       4     90
>  528157    100
>      32    130
>       1    140
>     307    150
>       3    200
>       1    240
>      49    250
>       1    260
>     261    300
>      70    330
>       3    400
>       1    430
>      24    500
>      24   1600
>      12   2500
>       1   4096
>       1  16384
>       2  65535
> 
> Of the 453 domains with iteration counts above 150 only 4 have counts
> in excess of 2500, which are unsupported by many resolvers with the
> default RFC5155 iteration count limits.  The remaining "interesting"
> domains are the 449 with iterations in the interval [151,2500].

Two point RFC5155 advise is in hindsight bad, it was written from the point of “more work is better protection”,
Advances in graphics cards have shown that NSEC3 is nothing but a obfuscation mechanism, it does nothing
to protect the integrity of names that fall into two categories 
     - short names  say 15 characters and less 
     - names in “directories” 
it is only a question how good a directory the cracker has and how many fast graphics cards. 
In addition Passive DNS services provide easy way to find the names as well. 

The harm from NSEC3 iterations if mainly felt be resolvers, but it is easy to generate an attack against 
authoritative servers that serve zones with high iteration counts causing them to fall over. 
I would like to see someone write an RFC saying Max iteration count of  <= 10 for all algorithms. 

> 
> Of these:
> 
>  * 258 have 512-bit P256 (algorithm 13) keys and 300 iterations.  This
>    exceeds the RFC5155 iteration limits and breaks secure DoE for many
>    resolvers.  All these domains are hosted at "ns1.desec.io”.
Nit: P256 keys are 256 bit long but have two 256 bit numbers in the key, but equivalent to 3100 bit RSA key. 

> 
>  * 1 has both a 512-bit P256 key and a 1024-bit RSA key and 250 iterations
>    in excess of the limits for either size.
> 
>  * 1 has a 1024-bit RSA key and 300 iterations.
> 
>  * 7 have 768-bit P384 (algorithm 14) keys and 500 iterations.
> 
>  * 2 have P384 keys and 200 iterations.

^^ all stupid or worse, 
> 
> So, in all, 273 domains are misconfigured with counter-productively high
> iteration counts.  So the problem described in the draft exists in the wild,
> but is, for the moment at least, quite infrequent.  The vast majority of
> domains use sensibly low counts (with 1 being the most popular value, though
> frankly 0 would have done just as well, but is perhaps not as well understood).

I think NSEC3 spec is counterproductive in specifying the iteration count as additional iteration
so value 1 is actually two iterations. 

> 
> With a bit of luck, better documentation and tools that warn users to
> not exceed 150 (regardless of key size) will keep the problem largely
> in check.

150 is still to high IMHO, 

> 
> I still think there's a lesson here for protocol design, quoting the draft:
> 
>   A simple design would have constrained the iteration count only by
>   the bit width of the iteration count field (perhaps 12 bits for up
>   4096 iterations), with all representable values supported by both
>   signers and resolvers.
> 
> At this time, I would say that just 7bits for the iteration count
> would have been plenty.  Few users want to hide their content against
> off-line dictionary attacks so badly, that they are willing to pay the
> cost of more than 100 iterations, and most are happy with 1, 10 or 20.
> 
> So an update to RFC5155 that sets a flat iteration limit of 127 and
> reserves the leading 9 bits of the iteration count would IMHO be a
> good idea.

^^^ Retiring NSEC3 is a better idea, 
and NSEC5 is not the solution, 
> 
> In any case, protocols with integral fields where only a subset of the
> values is supported, and the supported set depends on other parameters
> is a design feature that should be avoided.
> 
+1 

> -- 
> 	Viktor.
Olafur