Subject: Re: NSEC+ and NO

From: Ben Laurie <[email-masked]>
Date: Fri, 16 Jul 2004 14:15:20 +0100

Ólafur Guðmundsson wrote:
> <chair-hat off>
> Thanks Ben for sticking to technical issues.
> 
> At 11:01 25/05/2004, Ben Laurie wrote:
> 
>> Ólafur Guðmundsson wrote:
>>
>>> 2. MarkK is too much of an gentleman to say this, so I will:
>>>     - opt-in addresses your publicly stated issue with NSEC.
>>>         only by securing a domain does become it trivial to
>>>         find whois info.
>>
>>
>> Security or privacy, choose one, you mean?
>>
>> Another problem with this coould be that you are now publishing a list 
>> of high-value targets.
> 
> But it is the "targets" choice, not the registries.

It is not a free choice - by choosing to be secure, they also choose to 
be exposed.

>>> 6. Current NSEC2 proposal does not address the issue of name conflict 
>>> between
>>>     a valid name and a digest, NO addressed this by moving all NO 
>>> records
>>>     into a separate name space.
>>
>> I haven't understood why this is needed - why do name conflicts 
>> matter? Since NSEC2 records are special, they can be treated as being 
>> in a separate namespace anyway. Explicitly adding one just wastes 
>> space. Or am I missing something?
> 
> Ok let me demonstrate, for the sake of argument we hash with md5 once
> and the hashed name is encoded in hex.
>         MD5("amazon.co.uk") = beb32a6851b0317502d5a40ce5146e43.co.uk.

I make it 4d99aa84d5d72b1b57e56a5b186a0c64.co.uk. (or 
873bcdba87401b485022b8dcd4190e3e.co.uk. if the more correct 
"amazon.co.uk." is the string).

> Now, what if I have already registered that name and even gone as
> far as trademarking it.
>         what happens ?

Nothing - that name only appears in NSEC2 records - it would not be a 
trademark infringement for it to do so.

>         how will resolvers react seeing both NS and NSEC-bis at the same 
> note?

I'm not sure I understand this question.

>         what does the denial for my name look like ?

MD5("873bcdba87401b485022b8dcd4190e3e.co.uk.")=ac054ef84e1e8228996513d3ea6d8484.co.uk.

> The current proposal addresses this partially by having multiple rounds
> of hash, and salt. But these parameters can only be changed once in a 
> while.

No, these measures are not intended to address this problem.

> Moving the rounds into the NSEC2 record allows the zone signer to keep 
> trying
> until there is no conflict, but there is no way for resolver to query 
> directly
> for the NSEC2 record as the resolver does not know how many rounds there 
> are.

I still do not see why a conflict matters. Even if there is, the 
"conflicting" NSEC2 name _only_ appears in NSEC2 records, and the other 
name _never_ appears in NSEC2 records.
> 
> These are just some of the complications that needs to be thought out
> documented, coded and tested a few times, before DNSSEC v4 will be ready
> in 2006.

I am working on coding as we speak.

> First lets get the requirements on the table, not the solutions.

I agree we should understand the requirements. However, I am reasonably 
confident that NSEC2 addresses Nominet's requirements, as may other 
solutions. It would be nice to know that we can address _everyone's_ 
requirements.

> As far as I can tell there is only one requirement on the table:
>         NO ZONE walking of TLD's via negative answer records.

Is this what you would like us to include for you in the requirements I-D?

> As for constraints
>         size (number of names)
>         wildcards
>         label depth.
> 
> Add requirements and constraints as you see fit.
> Think about both TLD's and leaf zones.
> Then think about ENUM, a sparse but deep zone, what are the implications
> there.

ENUM is trivially enumerated by trial and error, so I don't see the 
applicability of NSEC2. This could be considered a flaw in ENUM. There 
may be workarounds, but that would be an issue for ENUM and not for 
DNSSEC, IMO.

> We can not keep on solving just one party's problem we need to think 
> forward.

Which "one party" did you have in mind? It has already been made clear 
that this issue is not solely Nominet's. Nominet have, though, 
undertaken to put the work in required to solve it.

> Once we have the requirements we can think about how to best address the
> issue, either by protocol changes, document changes or (maybe) ignore.
> 
> Example: Opt-in was viewed by some as a solution to a "Verisign only" 
> problem,
> in hindsight it might provide what you want/need.

I do not see how it does.

Cheers,

Ben.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Ben Laurie <[email-masked]>
Date: Fri, 16 Jul 2004 16:01:58 +0100

Ben Laurie wrote:

<blah blah>

Apologies - not sure why Olafur's orginal email got recycled, but it 
appeared to be in response to recent stuff, so I mistakenly responded.

Cheers,

Ben.