These are NSEC3 issues that we consider to be resolved.

Geoff

-----------------------------------------------------------------------

NSEC3 Issue 1: Use of Hashes Creates New Owner Names

Issue:

A signed zone which uses NSEC3 introduces new owner names which are
Base32-encoded hashes of existing owner names in the zone.


Resolution:

We do not see that, in and of itself, there is any problem with this.
It is possible for an NSEC3 RR may have the same owner name as a real
owner name; the consequences of this are considered in Issue 12.

-----------------------------------------------------------------------

NSEC3 Issue 2: RFC 3548 Base32 Sort Order

Issue:

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/namedroppe.../msg01423.html

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

http://www.ietf.org/internet-drafts/...3548bis-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.


Resolution:

If rfc3548bis is published, the nsec3 draft will be changed to reference
this encoding scheme; otherwise the draft will reference the one used
in RFC 2938.

-----------------------------------------------------------------------

NSEC3 Issue 3: Determination of Correct Zone Parameters

Issue:

A name server has to be able to look up the NSEC3 RR associated with an
owner name. To do this, it must have the correct values for the salt
and number of iterations required to produce the hash value which is
the owner name of the NSEC3 RR. However, an NSEC3 zone may contain any
number of incomplete chains of NSEC3 RRs provided that at least one is
complete. Consequently it cannot use the values contained in any
arbitrary NSEC3 RR in the zone. So how does a name server determine
the correct values for the zone?


Discussion:

One method for setting the correct values would be to provide them
externally, e.g. via the name server's configuration file or
out-of-band signaling. However this is not a practical option for
secondary servers, which will not have access to information in the
primary server's configuration file, and may additionally be running
different DNS implementations with no provision for out-of-band
signaling.

Another method for determining the correct values would be for the name
server to examine each NSEC3 RR with a unique combination of values for
salt and iterations, and to then enumerate any chains which might be
associated with those values to determine whether they form a complete
NSEC3 chain. This would of course be impractical for all but the
smallest of zones.

A third method would be to require that an NSEC3 RR for the host name
of the apex exist only if an (otherwise) complete chain of NSEC3 RRs
with the same parameters exists. This way, a name server may obtain
the correct values from any NSEC3 RRs that has the SOA bit set in the
Bit Type field. If more than one NSEC3 RR exists with the SOA bit set,
the values of any of them may be used, as each one would indicate the
existence of a complete NSEC3 chain.


Resolution:

The use of the third method will be specified in -04.

-----------------------------------------------------------------------

NSEC3 Issue 4: Design Rationale

Issue:

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

- Why use a salt?

- Why use iterations?


Resolution:

An expanded design rationale will be included in -04.

-----------------------------------------------------------------------

NSEC3 Issue 5: Hash Function RDATA Too Short

Issue:

The hash function field of the RDATA section of the NSEC3 RR is seven
bits long; however RFC 4034 specifies that DNSSEC security algorithms
are identified by 8-bit numbers (Appendix A, Section 1).


Resolution:

This will be corrected in -04.

-----------------------------------------------------------------------

NSEC3 Issue 6: Owner names of hashes are limited to case-folded names

Issue:

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.

[ Impact on truncation? ]


Discussion:

This would be a significant departure from previous IETF conservatism,
e.g. the selection of ASCII encoding for IDNs. It would also introduce
additional complexity to implementors, requiring broad, non-trivial
code base changes to existing implementations. Also significantly more
middleboxes might fail to properly handle the introduction of a new
label type than a new type code.


Resolution:

Base32-encoded labels will be used.

-----------------------------------------------------------------------

NSEC3 Issue 7: Maximum Domain Name Length

Issue:

The owner name of the apex of an NSEC3 zone is limited to 222 octets,
as the NSEC3 hash for the apex (and any other owner names in the zone)
is constrained to 255 octets. In practise vanishingly few domain
names approach this length. Zones that require such long names will be
constrained to using NSEC RRs.


Resolution:

It's unlikely many domain names will be affected by this limitation.
Those that are are probably pathological cases. If DNSSEC is to be used
for any domain names of > 222 octets then NSEC rather than NSEC3 will
have to be used.

(Note that for any zone which uses NSEC3, it may be desirable to limit
overall domain length to 202 octets, as longer names could not be used
in an NSEC3 zone using SHA-256 hashes.)

-----------------------------------------------------------------------

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: