How often should the NSEC3 params (salt in particular) be changed.
I was sent an article on "rainbow"? attacks, and there was mention of changing/updating the NSEC3 salt might be beneficial. One problem I had with the piece was that I could not find a date for, so it might be obsolete, secondly I cold not find the author though the piece was reported to be from Digital Ocean.
JohnA
PS. Sorry to post this here I thought there was a DNSSEC mailing list, but everything gets rejected!
On Feb 28, 2017, at 8:36 PM, John Allen john@klam.ca wrote:
How often should the NSEC3 params (salt in particular) be changed.
For now, never. Choose a suitable random value around 8 octets long, and keep it fixed.
Transitions between different NSEC3PARAM values may not be seamless, and for many domains the bulk of the names are trivially found via PTR lookups for their IPv4 blocks.
You probably don't have any strong reasons to attempt to hide the names in your domain. I also don't encourage large iteration counts, 10 or less, perhaps 0 is best in most cases. This reduces the CPU load on your server in generating negative replies.
The ".com" zone an iteration count of zero and an empty salt:
com. NSEC3PARAM 1 0 0 -
This is a good starting point.
oooooops!
I just set the nsec3 params to 1 0 17 "16 digit random number"
I guess I will just have to back off.
As you point out a PTR lookup probably does everything that an attack would do any way. If that is the case is it pointless to have nsec3 set at all.
JohnA
On 2017-02-28 9:12 PM, Viktor Dukhovni wrote:
On Feb 28, 2017, at 8:36 PM, John Allen john@klam.ca wrote:
How often should the NSEC3 params (salt in particular) be changed.
For now, never. Choose a suitable random value around 8 octets long, and keep it fixed.
Transitions between different NSEC3PARAM values may not be seamless, and for many domains the bulk of the names are trivially found via PTR lookups for their IPv4 blocks.
You probably don't have any strong reasons to attempt to hide the names in your domain. I also don't encourage large iteration counts, 10 or less, perhaps 0 is best in most cases. This reduces the CPU load on your server in generating negative replies.
The ".com" zone an iteration count of zero and an empty salt:
com. NSEC3PARAM 1 0 0 -
This is a good starting point.
John Allen wrote:
As you point out a PTR lookup probably does everything that an attack would do any way. If that is the case is it pointless to have nsec3 set at all.
This is not entirely true, as you may have multiple names that resolve to one address, with only a single PTR record. If you put the names of upcoming products and such in your domain names, you may find that NSEC3 offers some protection (at least if you change the salt often enough to prevent brute-force attacks). But if you don’t care about zone walking, there are many advantages to using NSEC, not just simpler signing and smaller responses. In particular, some recursive resolvers already use cached NSEC responses to synthesize NXDOMAIN responses (https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-08 https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-08 – currently only Unbound and Google Public DNS). This can provide some mitigation of random-prefix DoS attacks on your authoritative name servers. The RFC does describe the possibility of using cached NSEC3 responses but this is more complicated, and because of NSEC hashing, the effectiveness is reduced (the recursive resolver has to cache many more NSEC3 responses to get the coverage it can get from much smaller sets of NSEC responses.
It is absolutely true that there is no point ever using NSEC3 for reverse (in-addr or ip6) .ARPA zones, since you can use NXDOMAIN responses on partial results do an efficient search of only the populated parts of the zone time proportional to number of domains in the reverse zone rather than the number of addresses in the delegated name space (in other words, even IPv6 is no protection). See https://tools.ietf.org/html/rfc7707#section-5.1.4 https://tools.ietf.org/html/rfc7707#section-5.1.4.
A reasonable split-the-difference approach can be to use NSEC for your domain’s top-level zone (example.com) where the domain names are likely to be “www” “mail” “smtp” and so forth, and only use NSEC3 for delegated subdomains where confidentiality may be more important (dev.example.com).
@alex
Am 01.03.2017 um 03:12 schrieb Viktor Dukhovni:
How often should the NSEC3 params (salt in particular) be changed.
For now, never. Choose a suitable random value around 8 octets long, and keep it fixed.
Hello Viktor,
Your suggestion differ from RFC 5155. https://tools.ietf.org/html/rfc5155#appendix-C.1: "It is RECOMMENDED that the salt be changed for every re-signing"
Could you explain your choice more verbose?
Thanks Andreas
On Mar 6, 2017, at 4:39 AM, Andreas Schulze andreas.schulze@datev.de wrote:
Hello Viktor,
Your suggestion differ from RFC 5155. https://tools.ietf.org/html/rfc5155#appendix-C.1: "It is RECOMMENDED that the salt be changed for every re-signing"
Could you explain your choice more verbose?
If you do manual full-zone re-signing, feel free. Most zones are re-signed incrementally and automatically, but the entire NSEC3 chain must use a single salt (or two chains need to be built during the transition).
In any case, the main benefit of NSEC3 is "opt-out" to allow sparse signing in TLDs, hiding the zone content is only an emotional impulse, there's little rational use for it in the vast majority of cases.
Others may of course disagree, ... Be sensible, but focus on operational reliability above all other considerations.
On Mon, Mar 06, 2017 at 09:20:09AM -0500, Viktor Dukhovni wrote:
On Mar 6, 2017, at 4:39 AM, Andreas Schulze andreas.schulze@datev.de wrote:
Hello Viktor,
Your suggestion differ from RFC 5155. https://tools.ietf.org/html/rfc5155#appendix-C.1: "It is RECOMMENDED that the salt be changed for every re-signing"
Could you explain your choice more verbose?
If you do manual full-zone re-signing, feel free. Most zones are re-signed incrementally and automatically, but the entire NSEC3 chain must use a single salt (or two chains need to be built during the transition).
see also section 5.3.3 of RFC 6781, but take it with, well, a grain of salt.
In any case, the main benefit of NSEC3 is "opt-out" to allow sparse signing in TLDs, hiding the zone content is only an emotional impulse, there's little rational use for it in the vast majority of cases.
In the context of (future) DANE applications, enumeration resistance might become more critical even for those cases. The point probably is that if you chose a salt - rather than indeed applying NSEC3 for opt-out only - then you might want to change that, occasionally.
-Peter
participants (5)
-
Alexander Dupuy -
Andreas Schulze -
John Allen -
Peter Koch -
Viktor Dukhovni