Re: [dnsext] NSEC4

[Ben Laurie <[e-mail]>]

On Wed, Jan 4, 2012 at 12:33 PM, Matthijs Mekking <[e-mail]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Ben,
>
> Thanks for your response.
>
> On 01/04/2012 12:26 PM, Ben Laurie wrote:
>> On Wed, Jan 4, 2012 at 9:29 AM, Miek Gieben <[e-mail]> 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). :-)
>
> A quibble, but indeed.
>
>> 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.
>
> My apologies, I fail to see what the problem is. If "no hash" is used,
> we can order the NSEC4s in canonical order, just like NSEC. If hashing
> is used, we order them in hash order, like NSEC3. In both cases you make
> a usable linked-list. I guess my confusion is about:
>
>     ... when the hash alg is 0 you ...
>     work, or it would fail when hashing was used.
>
> But when hash alg is 0, that implies that hashing cannot be used.

Sure. But my point is that the order is arbitrary, therefore you can
use the same ordering regardless of whether hashing is used or not.

>
> Step 7 of the sign algorithm in Section 6.1 says:
>
>  7.   Sort the set of NSEC4 RRs into hash order or canonical order,
>        depending on the value of the hash algorithm;
>
> Maybe we have to clarify that canonical order is only for algorithm
> number is 0?
>
>> 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).
>
> Yes, because you can always the closest encloser from the NSEC RRs. With
> hashing that is not possible.
>
> Best regards,
>  Matthijs
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJPBEcTAAoJEA8yVCPsQCW5+T4H/jRGxj456YibwPfBQL5gsr/F
> Ty+cP1Xsq2XhfCsshAEm3q8lB1ezSkW53/6XkuXAWXcjy6If854bCkbMx0qepNoV
> FYhnS8DWgkHQZH/d3SeWkg9fko9e7JLjM74Joa8is3MpJb07J8lmuMNPFzT2eFqQ
> um1jJIo2JJgDcBv39dS/mIlzDO6gCE0RwkhyQDOYmjL37JaNd+QH1vPBC37/UOzU
> MmsY2l1IWwWpsgTgxO0elRTlavvHu0xYncn5M/vvsEeC9YvD6pEhJyTZlpp2DFN/
> SfITazW1ZrlqZlVozoEBJDAbgfXss6iYdzM05smgoR+KGfJndRRJAlO/toB67mU=
> =sxGe
> -----END PGP SIGNATURE-----
_______________________________________________
dnsext mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dnsext