Subject: [DNSOP] Changing NSEC3 salts regularly is useless

From: Mark Andrews <[email-masked]>
Date: Fri, 25 Jul 2014 08:02:09 +1000

I just sent the following to bind-users.  We need to kill the myth
that changing NSEC3 salt provides any real benefit.

"Actually it is useless to change the salt regularly.  Changing the
salt provides no real benefit against discovering the names in a
zone which is the reason people were saying to change the salt.

The attacker uses cached NSEC3 records.  When it gets a cache miss
it asks the servers for the zone, puts the answer in the cache and
continues.  When the salt changes it just maintains multiple nsec3
chains eventually discarding the old nsec3 chain eventually.  I
would wait until the new NSEC3 chain has as many cached records as
the old NSEC3 chain.  Changing the salt slows things up miniminally
for a very short period of time after the change.  Additionally
once you have some names you ask for those names for a non-exisisting
type to quickly pull in part of the new NSEC3 chain you know exists.

The only reason to change the salt is if you have a collision of
the hashed names.  This will be a very very very rare event."

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE:	+61 2 9871 4742		         INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Sat, 26 Jul 2014 18:53:02 -0400

There’s a lot of guidance needed for operators and tools developers (who set defaults) with regards to DNSSEC.  (I.e., Define and quantify “useless.”)

Three old presentations on studies (involving operations TLDs only) I have done on this topic in 2012:

http://iepg.org/2012-03-ietf83/IETF83IEPGLewis.pdf
(how the protocol engineer’s expectations differed from what operators were doing)

https://ripe64.ripe.net/presentations/46-RIPE64PlenaryTLDDNSSEC.pdf
(began to analyze the difference between protocol engineering and operations)

https://www.nanog.org/meetings/nanog56/presentations/Tuesday/tues.general.lewis.14.pdf
(same, based on more data)

If you are going to produce such a document, cover a range of choices being made, including the salt change frequency.  There’s been a strong need for a DNSSEC implementers guide covering cryptographic parameter selection ever since well, forever.  Yes we have NIST 800-81 (http://csrc.nist.gov/publications/nistpubs/800-81r1/sp-800-81r1.pdf).

One issue with the salt (in particular) is that the RFC recommendation is (RFC 5155  Appendix C.1) says this:

"The salt SHOULD be changed periodically to prevent pre-computation using a single salt.  It is RECOMMENDED that the salt be changed for every re-signing."

This was written without dynamically updated zones in mind (or so I’m guessing - 5155 is “not my fault” ;) ).

On Jul 24, 2014, at 18:02, Mark Andrews <[email-masked]> wrote:

> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop