Re: [dnsext] NSEC4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Roy,

Thanks for your kind reaction.

First of all, you mentioned that the "no hash" (or "zero hashing") was
also discussed during the development of NSEC3. Unfortunately, it is
hard (if not impossible) to define it as a new NSEC3 hash function: For
"zero hashing" the Next (Hashed) Owner Name field cannot be base32
encoded. Therefore, with our experiment we made the field a Domain Name.

Second, I cannot deny that adding unhashed named to NSEC3 looks a lot
like adding Opt-In to NSEC. I also think that document writes down a
very clever idea:).

We have code, adaptations of ldns and NSD on the authoritative side,
godns on the resolver side. An analysis on response size is difficult,
because it is zone and query specific. In general, all NXDOMAIN and
Wildcard NODATA responses will be reduced by one NSECx record and its
corresponding signatures.

Kind regards,
  Matthijs

On 01/04/2012 11:24 AM, Roy Arends wrote:
> On Jan 4, 2012, at 9:29 AM, Miek Gieben 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?
> 
> Nice!
> 
> During the development of NSEC3 we (nsec3 editors) discussed both
> optimizations (no hash, and wildcard bit). We called "no hash" an
> identity function [1], and figured out we could always define it as
> an NSEC3 hash function later. We called the wildcard bit an asterisk
> flag, but figured that wildcard expansions are per record type, not
> per full name, and that the proof would be even more different from
> nsec than before (and the group seemed to be suffering from NSEC3
> fatigue at the time). Again, we thought we could always define an
> additional flag later. However, both additions would break backwards
> compatibility if you want to optimize for response size.
> 
> Great stuff, thanks for documenting the effort. Do you have code, and
> any comparative analysis on response size? As for a proper place, I'd
> suggest
> 
> The added functionality of NSEC4 (smaller responses, unhashed names,
> opt-out) looks like the original opt-in specification: NSEC plus
> opt-in :-)
> 
> [1] http://en.wikipedia.org/wiki/Identity_function
> 
> Warm regards,
> 
> Roy
> 
> 
>> 
>> Best regards,
>> 
>> Miek Gieben, Matthijs Mekking 
>> _______________________________________________ dnsext mailing
>> list dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext
> 
> _______________________________________________ dnsext mailing list 
> dnsext@ietf.org https://www.ietf.org/mailman/listinfo/dnsext

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPBDKaAAoJEA8yVCPsQCW5d9MIAKiTz274i59GuJvQDssEV7s3
D8y+iEanQp+LpAd4o7L5uWQZjeenFzKVRffCOVEmoXnq9ATazxzNcMIEcXzZQimP
3Z1YPZLNKvErc4EnypcXoh/NLyZkfX11xLhEYm+4kxe+XKjhWc4UVMxJxfzfbMp6
OU4C35+gnWquXp0PiYULWWqyRXe125IHIkeil3zmloJ7PGBU99zaMz3ADaI4bme9
XmZP3X6y2G/c9SDroLQvgWNKDaSCv15jcVgZxDvJwKpcbbxRONogad9f7BIWJRsB
h11O7LNiEMTkDGhXwncRPv1Y/pJkiUaEUVq62xXu+8YBM8MdkMjTWXCUVQS3qjI=
=g3JT
-----END PGP SIGNATURE-----
_______________________________________________
dnsext mailing list
dnsext@ietf.org
https://www.ietf.org/mailman/listinfo/dnsext