{11} Active Tickets by Component (Full Description) (50 matches)

prove_nx_domain() uses the SOA to create FQDNs from hash values. This is not necessary, and doesn't always work, since the SOA may not be present in the response.

Make it compare hashes directly instead of as FQDNs.

This is the opposite to standard practice so note it in the I-D.

Show how a large zone can incrementally roll the salt.

Specify that the apex NSEC3 determines which paramaters cover the whole zone.

i.e. NSEC3 doesn't replace NSEC, it is a choice zone owners make.

In order to estimate zone size it is not necessary to walk the whole zone, or even much of it. Just query random names and look at the interval between hashes - a few of these will give an accurate estimate.

...to see what happens with updates...

The editor believes this is not an issue. Rob Austein said that he's 3/4 close to leaning towards Peter Koch's half-serious new label type proposal. He feels this is a much cleaner solution to all this collision stuff and has the added benefit that it can be defined as a binary-only label type which removes the sort order issue as well. Ben Laurie asked how this would interact with caches that don't grok the new label type. Rob replied that dnssec-bis doesn't work through dnssec-oblivious middle boxes, so this might just be a non-issue. Paul Vixie stated that the original idea behind the separate label type was to provide a way to store the various sets of metadata that aren't truly dns data and hence don't really belong in the actual database proper. This data we're talking about here is also not dns data and so a separate label type would go a long way to helping this. Ben asked if people were okay waiting until implementations were done before deciding on this.

...so we can share the DS hash registry.

http://www.iana.org/assignments/ds-rr-types

'I think that the document should say "...all included NSEC3 rrsets MUST use the same set of parameters..." (or something like that). And possibly additionally "...if the response contains NSEC3 records that use different hash parameters, then treat as a validation failure..."' (David Blacka)

Evil authoritative servers can select such a high number of iterations that resolvers are overwhelmed. The proposal is to allow resolvers to specify an upper limit for iterations that it will accept and if a response has a higher number the resolver will treat is as bogus. Olafur Gudmundsson asked why we can't get rid of iterations and just use the salt. Ben explained that the iterations are designed to increase the cost of a dictionary attack, while the salt is used to increase the cost of a pre-computed dictionary attack. Olafur rephrased his question to is the salt sufficient for the threats people are seeing? Ben feels this is no, as a single iteration is very easy to handle with a network probe. Olaf expressed a concern that leaving this up to resolvers will cause some resolvers to set a low number and some a high number causing a zone to appear secure or bogus to different resolvers. Ben answered that by picking a sufficiently high number this shouldn't be a problem. It should be a single number and not in the draft. Mike St.Johns said that if a number is going to be chosen, please put it in the draft and be nice to implementors and users, don't make it configurable, just set it across the board. Ben says if the working group feels strongly about this it will be done. Someone asked if a mechanism could be added such that parent zones can set limits for the iterations. The room response was highly negative.

Issue:

What should be contained in responses to queries where the QNAME is the
owner name of an existing NSEC3 RR and the QTYPE is NSEC3?


Discussion:

There are several possible responses:

1.  Return the actual NSEC3 RR with owner name

    - The response returns status RCODE = 0 and contains the NSEC3 RR
      with the owner name (and corresponding RRSIG RR if the bit is set
      in query).

2.  Return proof of nonexistence of owner name

    - The response returns status RCODE = 3 (NXDOMAIN) and contains the
      NSEC3 RRs required to prove nonexistence (and corresponding RRSIG
      RRs if DO bit is set in query).

3.  Return both the NSEC3 RR at with the owner name and proof of
    non-existence of the owner name.

    - The response returns status RCODE = 3 (NXDOMAIN) and contains both
      the NSEC3 RR with that owner name and the the NSEC3 RRs required
      to prove nonexistence (and corresponding RRSIG RRs if DO bit is
      set in query).

      It's possible for the NSEC3 RR for which the query was received
      to be also one of those required to prove non-existence.  In this
      case, duplicate NSEC3 RRs are eliminated.  Consequently as few as
      one and as many as four NSEC3 RRs may be returned.

Resolution:

We propose to use the third type of response, as it is the most
unambiguous.

Issue:

When a DDNS client sends an UPDATE transaction containing RRs for a new
unsigned delegation to be inserted into an NSEC3 zone, there is no
obvious way for the server to determine whether or not the new
delegation should be included in the NSEC3 chain.  This is because the
values of the Opt-In fields of NSEC3 RRs in the zone need not be
uniform.  In other words, it's permissible to include and exclude
unsigned delegations in the NSEC3 chain in any combination.


Discussion:


Possible approaches:

1.  No support for Opt-In in DDNS

    - All NSEC3 RRs produced as a result an UPDATE will
      default to Opt-In = 0

    - Cannot change value of NSEC RR.

2.  Use overloaded NSEC3 RR to signal Opt-In

    - New unsigned delegations will default to Opt-In = 0, i.e. they
      will be included in the NSEC3 chain.  An unsigned delegation may
      be removed from the NSEC3 chain by sending an UPDATE containing
      an NSEC3 RR with the /unhashed/ owner name of the delegation and
      the Opt-In flag set to 1.  If the NSEC3 RR is included in the
      same atomic update as the RRs of the new unsigned delegation,
      the new delegation will not be inserted into the NSEC3 chain in
      the first place.

    - This method is in effect an overloading of the NSEC3 RR.
      The owner name of the NSEC3 RR in the UPDATE is be the owner name of
      the delegation, not the hashed value.  Only the value of the Opt-In
      field is meaningful; the other data in the RDATA section is ignored.

    - UPDATEs containing NSEC3 RRs with the owner name of an unsigned
      delegation and Opt-In = 0 will cause the owner name to be inserted
      into the NSEC3 chain if it isn't already.

    - UPDATEs containing RRs for existing unsigned delegations but no
      NSEC3 RR will leave the current value of the Opt-In field of the
      relevant NSEC3 RR unchanged.

    - If an UPDATE contains an NSEC3 RR for a non-existent owner name, an
      owner name that is a signed delegation, or for any owner name for
      which RRs other than on RRs exist, the server will return an error.

    However:

    - Convoluted use of NSEC3 RR.

    - NSEC3 RR is larger than required, as only one bit of the
      16 octet RDATA section will be meaningful in a DDNS context.

    - Has unresolved corner cases, e.g. what if an UPDATE removes
      an unsigned delegation which is at the boundary of two
      spans, one with Opt-In = 0 and the other with Opt-In = 1?

3.  Introduce a new RRTYPE for used with DDNS updates

    - Similar to previous, but uses a new RRTYPE, e.g. `OPTOUT', rather
      than overloading the NSEC3 RR.

    - RR more compact as only one octet will be required for RDATA
      section.

    However:

    - requires use of a dedicated RRTYPE which would be meaningful only
      in the context of DDNS updates.

    - Has corner cases such as the one described in Approach 2.

4.  Inherited behaviour

    - If an update containing a new unsigned delegation falls in
      a span with Opt-In = 1, then it's not added to the NSEC3
      chain; if falls on one one which is Opt-In = 0, it is added.

    However:

    - Mismatch between granularity of control permitted by

    - Has corner cases such as the one described in Approach 2.

5.  Discourage or prohibit partial Opt-In zones.

    - Opt-In = 0 or Opt-In = 1 for all NSEC3 RRs in a chain.

    - Use cases unknown for partial Opt-In zones.

    However:

    - Adds unnecessary restrictions to the protocol.


Resolution:

None.  We are still investigating the problem space.

Issue:

The draft discusses a presentation format in which the algorithm
mnemonics are represented as alphanumeric labels; however there
is no registry for any such representation.  The mnemonics are
_implied_ by the IANA registry at:

    http://www.iana.org/assignments/ds-rr-types

Resolution:

None.  We will investigate the feasability of establishing an
IANA registry for presentation format mnemonics.

Currently, the NSEC3 draft indicates that it uses the same IANA registry as DS for its hash algorithms. This leads to a number of potential concerns:

a) Operators might get the impression that if a new hash algorithm is added to the DS registry, then it is automatically defined for use in NSEC3. I'm not sure that this is correct.

b) The desirable criteria for a DS digest algorithm and an NSEC3 hash algorithm are not exactly the same. For instance, NSEC3 is less sensitive to the second pre-image resistance property of a hash. In fact, algorithms that would simply not be acceptable for DS may be totally fine for NSEC3 (e.g., MD5.)

c) There are things that must be defined about how a hash works with NSEC3 before it can be successfully used. For instance, if the hash length is longer that 63 characters in base 32, then the hash must be split across multiple labels. The consequences of this will no doubt require a significant amount of specification, possibly modifying the current NSEC3 specification.

Discussion:

1) The draft can establish a new IANA registry for NSEC3 hash algorithms, or

2) the draft can continue to use the DS registry. This will prevent people from defining new hash algorithms that are fine for use with NSEC3 but not acceptable for use with DS (point b, above).

Independent from this decision the draft could be modified to stress that hash algorithms MUST be specified before use.

My recommendation:

Both establish a new registry and require that new algorithms have a specification describing its use with NSEC3.

If a validator ignores an NSEC3 resource record because it contains an unknown hash algorithm and subsequently treat a dnssec/nsec3 response as 'unsigned', the validator must check that the NSEC3 record came from the proper zone.

This check needs to be done to avoid a replay of some arbitrary NSEC3 with an unknown hash algorithm, that happens to be signed with a key that the validator trusts. A successful replay can lead to a downgrade attack.

The ownername of the NSEC3 record contains the hash value, prepended to the zone name. Since we want the NSEC3 record to be future proof, we have to allow digests to be longer than the maximum label size, and so, a future hash algorithm might have a digest that is presented over multiple labels.

We can therefor not safely assume that the first label contains the hash value, and the rest of the name is the zone name.

So, we need to find a way to discover the zone that the NSEC3 is from.

We have several approaches for this, described here in no particular order:

1) it is possible to calculate the number of labels that contains the hash from the hash length field. The hash length field contains the length of the hash of the Next Hashed Owner Name field. This length is in octets. The following formula determines the amount of labels used for the hash, and indicates that the rest of the labels contain the zone.

Let L be the value of the hash length field

Then labelcount = 1+((L*8)/315)

This approach assumes that all hash outputs for this single (unknown) algorithm have the same length, since the hash length field applies to the Next Hashed Ownername, not to the Owner Name of the NSEC3 record. Hence, an Identity Hash function, a function with variable length output, can not be easily defined this way.

2) it is possible to use the Signer's Name field of the RRSIG record that accompanies this NSEC3 record. The drawback is that the validator, while checking the applicability of the NSEC3 record, must have knowledge of the RRSIG at that stage. Note that the validator _has_ to check the validity of the signature anyway if it decides to treat a response as insecure due to an unknown hash algorithm.

3) Add a 'Zone labels field' to the rdata field that indicates of how many labels the zone consists of, and hence, use that as a mask for the ownername of the NSEC3 record to determine the zone name. The drawback here is that the NSEC3 rdata is changed Yet Again.

4) drop the 'unknown hash' methodology alltogether. This means that if an unknown hash is encountered, it is discarded. When the validator tries to validate the response, it ignores unknown hash NSEC3's and will treat the response as bogus. The drawback is that it will be hard to introduce new hash algorithms, unknown to a deployed base. The penalty is that zones using this new hash algorithm will be treated as bogus, thus unresolveable, for the deployed base.

5) truncate all hash outputs over 315 bits to 315 bits so it will always fit in a single label. The drawback here is that the 2nd-preimage resistance of a hash function is then restricted to 2³¹⁵,and thus less futureproof.

Note, the number 315 is the amount of significant bits of a base32 decoded maximum length label (5 * 63)

The NSEC3 owner names would be below the DNAME, which is illegal. The draft needs to clarify and allow this exception to that rule.

To create additional flags for future expansion, we take the first octet of iterations and designate it as a flags octet. One bit is opt out (0x01, the same presentation format) and the rest are reserved. The iterations field is reduced to two octets.

Dave will write up the proposal and send to namedroppers.

Issue:

A potential DoS condition exists in which the operator of a malicious
server could select an impractically high number of iterations for the
NSEC3 RRs in an signed zone.  The NSEC3 RDATA format permits values as
high as 2 ^ 23, or 8,388,608 (N.B. this is a change in -04; in -03 it
was 2 ^ 24).  Consequently, when a resolver receives multiple queries
for names (existent or non-existent) in this zone, the resolver must
perform the same number of hash iterations for each query.  This could
result in a significant denial-of-service on the resolver.


Discussion:

One solution would be to permit resolvers to set an upper limit for the
number of iterations that would be permitted in an NSEC3 RR, and to
treat NSEC3 RRs with values exceeding this as insecure or bogus.  This
could be accomplished at the implementation level alone, or it could be
governed by a recommendation or standard.

One subsidiary issue is that any limit may have to change over time in
response to increases in computational speed: a limit which may
initially reflect an unjustifiably high number of iterations may later
be considered cryptographically weak.


Proposed Resolution:

We agree that it is desirable for resolvers to set an upper limit.

We propose to submit the following two questions for consideration by
the IETF Security Area Directorate:

1.  Should an upper limit be specified in the standard?

2.  If so, should the upper limit be specified in a separate document
    so that the it may be updated without having to re-publish the
    entire standard.

RFC 3548 describes a Base32 encoding that is unsuitable for NSEC3 hashes, as the sort order of the encodings differ from binary sort order. This issue was raised in this post to namedroppers:

http://ops.ietf.org/lists/namedroppers/namedroppers.2005/msg01423.html

Subsequent to this post, the author of RFC 3548 submitted a new draft:

http://www.ietf.org/internet-drafts/draft-josefsson-rfc3548bis-00.txt

This draft adds a new encoding called "base 32 extended hex alphabet" which preserves the sort order of encoded data, and describes the encoding used in -nsec-03. This is the same encoding used in Section 3.1 of RFC 2938.

The draft needs to include more information about rationale underlying various design decisions, for example:

- Why use a salt?

- Why use iterations?

The owner names of NSEC3 RRs are currently restricted to case-folded names as non-case folded names will not be ordered properly in a zone. Base32 has been selected for this encoding. As a consequence, NSEC3 RRs require a 32 octet owner name to represent each hash, 12 more than the binary representation of the hash. If NSEC3 were to be subsequently modified to use SHA-256, then each owner name would require 20 more octets than the binary representation.

Some have suggested that NSEC3 could use a new binary label type for owner names rather than Base32-encoded labels; this would marginally reduce the size of DNSSEC responses for zones using NSEC3. It would also marginally increase the total length domain names which could be permitted in an NSEC3 zone.

A single zone may contain NSEC3 records with the optout bit set or clear. To cope with the granularity of a per-record signal of opt-out introduces additional complexity for signing and dynamically updating such a zone while the use case for this granularity is not clear.

The use of Optout is restricted to unsigned delegations. This restriction is inherited from the experimental Opt-In draft. Even-though the restriction is in place, it can't be enforced on the server side, i.e. there is a way to allow unsigned records other than delegations to exist in an optout span, without it ever to appear as such on the wire, by means of delegating them to unsigned subzones with the same name.

Should the document specify a recommendation about if a validating resolver should process first the range of NSEC3 names covers query name or the signature on the NSEC3 records is valid.

RFC4035 specifies/recommends that validating resolver first check that the name range applies before validating the signature, as that is the less expensive operation. For a NSEC3 with high iteration count it is possible that validating the signature is less expensive than checking the name range.

If there exists a name and a wildcard record where the corresponding hash values collide, an attacker can replace a positive answer with a wildcard and vice versa. Though hash functions are designed to be collision resistant, the question has been raised if signers are allowed to, or should check.