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.

---

From: Jim Reid <[email-masked]>
Date: Fri, 16 Jul 2004 16:49:42 +0100

>>>>> "Ben" == Ben Laurie <[email-masked]> writes:

    Ben> I make it 4d99aa84d5d72b1b57e56a5b186a0c64.co.uk. (or
    Ben> 873bcdba87401b485022b8dcd4190e3e.co.uk. if the more correct
    Ben> "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 ?

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

Suppose I've just incorporated 873bcdba87401b485022b8dcd4190e3e
Limited and registered that name as a trademark. Oh, and I want to
register my company's name in co.uk. See you in court. :-)

---

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

> register my company's name in co.uk. See you in court. :-)

Sure, but I'm pretty damn sure you'd lose. If you really want to waste a 
lawyer's time on this red herring, I'm sure I can get an opinion.

Cheers,

Ben.

---

From: Roy Badami <[email-masked]>
Date: Fri, 16 Jul 2004 17:13:02 +0100

>>  Suppose I've just incorporated
    >> 873bcdba87401b485022b8dcd4190e3e Limited and registered that
    >> name as a trademark. Oh, and I want to register my company's
    >> name in co.uk. See you in court. :-)

    Ben> Sure, but I'm pretty damn sure you'd lose. If you really want
    Ben> to waste a lawyer's time on this red herring, I'm sure I can
    Ben> get an opinion.

However it would be nice if the NSEC2 record at
873bcdba87401b485022b8dcd4190e3e.co.uk didn't prevent that owner name
from being used as a prefectly normal name for other purposes.  ie
someone _should_ be allowed to register it if they really wanted to.

Whilst a clash of this kind occuring accidentally is improbable, there
may be future applications of the DNS which demand using names that
are derived from MD5 hashes of strings...

    -roy

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 16 Jul 2004 18:19:18 +0200

> register my company's name in co.uk. See you in court. :-)

One solution is to put NSECbis records in a separate namespace, e.g.:

$ORIGIN co.uk.
873bcdba87401b485022b8dcd4190e3e IN NS jim.rfc1035.com ; your delegation
873bcdba87401b485022b8dcd4190e3e._no IN NSECbis 881345... ; for amazon.co.uk.

This has other advantages:

 * There is no special parent/child behaviour for NSECbis that
   complicate resolvers.

 * (Speculative and unbaked:) You could delegate the _no zone to
   separate servers, which might have the computing capacity to
   perform online signing of NSECbis.  Or purely for administrative
   purposes, to perhaps outsource the work of maintaining NSECbis to
   someone else.  There are some synchronization issues that need to
   be studied here, though.

I'm not sure what any obvious disadvantage would be.

Regards,
Simon

---

From: Roy Arends <[email-masked]>
Date: Fri, 16 Jul 2004 19:58:01 +0200

> register my company's name in co.uk. See you in court. :-)

873bcdba87401b485022b8dcd4190e3e  NS
873bcdba87401b485022b8dcd4190e3e  NSEC2

They're unrelated. There is no problem. The NS record has a different 
NSEC2 associated with it. The NSEC2 is associated with a different owner 
name. It is highly unlikely both would appear in a single response (nee 
AXFR).

Roy

---

From: Jim Reid <[email-masked]>
Date: Fri, 16 Jul 2004 19:27:17 +0100

>>>>> "Roy" == Roy Arends <[email-masked]> writes:

    Roy> 873bcdba87401b485022b8dcd4190e3e NS
    Roy> 873bcdba87401b485022b8dcd4190e3e NSEC2

    Roy> They're unrelated. There is no problem. The NS record has a
    Roy> different NSEC2 associated with it. The NSEC2 is associated
    Roy> with a different owner name.

So what?

These two records have the same owner-name. Given that one of the
records is for a delegation, this has to mean complications for the
already far too ugly semantics of a zone cut. Especially wrt backwards
compatibility with the installed base. For example, what happens on an
ANY query for 873bcdba87401b485022b8dcd4190e3e.co.uk? Will it stop at
the NSEC2 in the parent or follow the delegation?

---

From: "Olaf M. Kolkman" <[email-masked]>
Date: Mon, 19 Jul 2004 09:57:08 +0200

Hi Jim(*)

If trademark issues form a requirement than please contact Ben and Rip.

(see: http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01237.html)

-- Olaf

(*) just because Jim brought this up, the message is off course intended for
a broader audience: Bring your implicit and explicit requirements and non-requirements
to Ben and Rip. 

---------------------------------| Olaf M. Kolkman
---------------------------------| RIPE NCC

---

From: Ben Laurie <[email-masked]>
Date: Thu, 22 Jul 2004 15:42:49 +0100

> I'm not sure what any obvious disadvantage would be.

The only one I can think of is that it makes the name longer.

Cheers,

Ben.