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 protected]> wrote: > > 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 protected] > > _______________________________________________ > DNSOP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
