12. Security Considerations

12.1. Hashing Considerations

12.1.1. Dictionary Attacks

The NSEC3 RRs are still susceptible to dictionary attacks (i.e., the attacker retrieves all the NSEC3 RRs, then calculates the hashes of all likely domain names, comparing against the hashes found in the NSEC3 RRs, and thus enumerating the zone). These are substantially more expensive than enumerating the original NSEC RRs would have been, and in any case, such an attack could also be used directly against the name server itself by performing queries for all likely names, though this would obviously be more detectable. The expense of this off-line attack can be chosen by setting the number of iterations in the NSEC3 RR.

Zones are also susceptible to a pre-calculated dictionary attack -- that is, a list of hashes for all likely names is computed once, then NSEC3 RR is scanned periodically and compared against the precomputed hashes. This attack is prevented by changing the salt on a regular basis.

The salt SHOULD be at least 64 bits long and unpredictable, so that an attacker cannot anticipate the value of the salt and compute the next set of dictionaries before the zone is published.

12.1.2. Collisions

Hash collisions between QNAME and the owner name of an NSEC3 RR may occur. When they do, it will be impossible to prove the non- existence of the colliding QNAME. However, with SHA-1, this is highly unlikely (on the order of 1 in 2^160). Note that DNSSEC already relies on the presumption that a cryptographic hash function is second pre-image resistant, since these hash functions are used for generating and validating signatures and DS RRs.

12.1.3. Transitioning to a New Hash Algorithm

Although the NSEC3 and NSEC3PARAM RR formats include a hash algorithm parameter, this document does not define a particular mechanism for safely transitioning from one NSEC3 hash algorithm to another. When specifying a new hash algorithm for use with NSEC3, a transition mechanism MUST also be defined. It is possible that the only practical and palatable transition mechanisms may require an intermediate transition to an insecure state, or to a state that uses NSEC records instead of NSEC3.

12.1.4. Using High Iteration Values

Since validators should treat responses containing NSEC3 RRs with high iteration values as insecure, presence of just one signed NSEC3 RR with a high iteration value in a zone provides attackers with a possible downgrade attack.

The attack is simply to remove any existing NSEC3 RRs from a response, and replace or add a single (or multiple) NSEC3 RR that uses a high iterations value to the response. Validators will then be forced to treat the response as insecure. This attack would be effective only when all of following conditions are met:

There is at least one signed NSEC3 RR that uses a high iterations

value present in the zone.

The attacker has access to one or more of these NSEC3 RRs. This

is trivially true when the NSEC3 RRs with high iteration values are being returned in typical responses, but may also be true if the attacker can access the zone via AXFR or IXFR queries, or any other methodology.

Using a high number of iterations also introduces an additional denial-of-service opportunity against servers, since servers must calculate several hashes per negative or wildcard response.

12.2. Opt-Out Considerations

The Opt-Out Flag (O) allows for unsigned names, in the form of delegations to unsigned zones, to exist within an otherwise signed zone. All unsigned names are, by definition, insecure, and their validity or existence cannot be cryptographically proven.

In general:

Resource records with unsigned names (whether existing or not)

suffer from the same vulnerabilities as RRs in an unsigned zone. These vulnerabilities are described in more detail in [RFC3833] (note in particular Section 2.3, "Name Chaining" and Section 2.6, "Authenticated Denial of Domain Names").

Resource records with signed names have the same security whether

or not Opt-Out is used.

Note that with or without Opt-Out, an insecure delegation may be undetectably altered by an attacker. Because of this, the primary difference in security when using Opt-Out is the loss of the ability to prove the existence or nonexistence of an insecure delegation within the span of an Opt-Out NSEC3 RR.

In particular, this means that a malicious entity may be able to insert or delete RRs with unsigned names. These RRs are normally NS RRs, but this also includes signed wildcard expansions (while the wildcard RR itself is signed, its expanded name is an unsigned name).

Note that being able to add a delegation is functionally equivalent to being able to add any RR type: an attacker merely has to forge a delegation to name server under his/her control and place whatever RRs needed at the subzone apex.

While in particular cases, this issue may not present a significant security problem, in general it should not be lightly dismissed. Therefore, it is strongly RECOMMENDED that Opt-Out be used sparingly. In particular, zone signing tools SHOULD NOT default to using Opt- Out, and MAY choose to not support Opt-Out at all.

12.3. Other Considerations

Walking the NSEC3 RRs will reveal the total number of RRs in the zone (plus empty non-terminals), and also what types there are. This could be mitigated by adding dummy entries, but certainly an upper limit can always be found.