Re: [dnsext] NSEC4

On Wed, Jan 4, 2012 at 9:29 AM, Miek Gieben <miek@miek.nl> wrote:
> Dear dnsext,
>
> We have written down a little experiment that we have performed, called NSEC4.
> The goal of the experiment was to optimize denial of existence records.
> It is not our intention to standardize this, as we are aware of the backwards
> compatibility issues this has with the current DNSSEC family RFCs, and we do
> not want to discomfort the ongoing DNSSEC deployment.
>
> However, we do want to document this to archive the insights we have gained
> by doing this experiment. Therefor, we have submitted the following draft:
>
>    http://www.ietf.org/id/draft-gieben-nsec4-00.txt
>
> This experiment resolves two things:
> * Reduces the size of the denial of existence response;
> * Adds Opt-Out to un-hashed names.
>
> We would be grateful if you would like to read this.
>
> Our question is what is the best place to archive this? Re-reading RFC 2026,
> we are considering to put this on the experimental non-standards track.
>
> Thoughts?

Cute. One minor quibble: in 3.2 you say that if the hash algorithm is
0, then Salt Length MUST be ignored. Strictly speaking, if it is
ignored, then the Salt field cannot be ignored (since you don't know
how long it is). :-)

On that note, you could save 4 bytes by omitting those fields in this case.

A more major observation: when the hash alg is 0 you specify that
domain names are sorted in canonical order (6.1. step 7 and presumably
elsewhere). Clearly this cannot be required to make the algorithm
work, or it would fail when hashing was used. So, either this is
suspicious, in that it suggests a weakness in the protocol, or you
could make the protocol simpler by always sorting in byte order.

Note that the canonical sort is vital to NSEC: it is what keeps the
proof down to 2 records instead of 3 (hence the reason this might be
suspicious).
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext