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

[Viktor Dukhovni]

On Mon, Jan 18, 2021 at 09:53:20PM +0100, Vladimír Čunát wrote:

> >      1.  Every zone is effectively already salted, because as you
> >          note below the hash covers the FQDN.
> >
> >      2.  Changing the salt takes some care, so "nobody" does it.
> >
> >      3.  Combining 1 and 2 we conclude that a fixed salt is no
> >          better than an empty salt.
> 
> OK.  I do agree that salt is pointless *unless* rotated.  Even the 
> original RFC 5155 clearly says that "The salt SHOULD be changed 
> periodically".  And to me it just... seemed relatively easy to do, if 
> you already do resigning, rotating *SKs, etc.  Both technically and in 
> practice: 
> https://www.knot-dns.cz/docs/3.0/singlehtml/#nsec3-salt-lifetime (since 
> year 2016 in this case)

Yes, if one always does full-zone resigning, which regenerates the
complete NSEC3 chain, then changing the salt is no big deal.  If
on the other hand signing is incremental, record by record, then
there's rarely a good time to change the salt, as that requires
rebuilding the entire chain.

So my conjecture is that the salt is rarely if ever changed, because it
is either inopportune, or operators are "just lazy" (perhaps justifiably
so, because, after all, the data is not that secret).

Which ultimately boils down to the salt being generally pointless.

> The best part IMHO is that rotating a few bytes of salt is relatively 
> easy and cheap for the good guys, in comparison to how much it hinders 
> dictionaries.  Properties of the iteration count seem far worse.

The dicionary needs to be per-zone anyway, by the time someone has
bothered to do that, they can capture a snapshot of the chain under a
stable salt, and work with that.  I really don't see any value in it,
especially for TLDs, or leaf zones with just a few names.

For the salt to makes sense, and warrant rotation, one would have to
operate a zone with enough records that some are hard to predict,
sensitive and yet published (and not visible in transparency logs,
PTR records, ...).  This is very much a corner case.

> > It would be good to see all the iteration counts drop to 10 or less,
> > ideally just 0.
> 
> Certainly.  100 iterations seems ridiculous to me and I'm surprised the 
> number got such a large share, though perhaps I'm personally biased 
> against trying to hide contents of common TLD zones by NSEC3.

The iterations story is even worse. The RFC-specified ceiling the
resolvers are expected to support is tied solely to the DNSKEY
size in bits, *regardless* of algorithm!

If some naive operator sets up "turned up to 11" iteration counts based
on extant RSA 2048-bit keys, and later migrates to say ECDSA P-256 (with
512-bit keys), the iteration count will exceed the limits and many
resolvers will treat all DoE responses from the domain as insecure!

Some resolvers on the other hand were (last I looked) willing to do
up to 65535 iterations regardless of key size.  Nice CPU you've got
there, it'd be a shame if it spent all its cycles doing SHA1...

-- 
    Viktor.