[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NSEC+ and NO

Ó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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>