Subject: NSEC+ and NO

From: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 25 May 2004 01:12:55 -0400

<Not as co-chair>

Having read the discussions on namedroppers about this
topic here are my "grumpy old man" personal reactions/responses.
Please take a moment to send me or the list answers to the questions
at the end.

0. It is real frustrating when a bunch of late new comers suddenly say they
	can not deploy DNSSEC for some reason that has nothing
	to do with DNS, just some obsolete whois stuff and some legal mumbo
	jumbo that only applies to about 25 countries.
	
1. I was strongly in favour of exploring NO record and it's implications
    when Simon started that work.
    NO failed to catch on for a combination of reasons including:
	- There was no explicit need to stop zone walking.
	- It was MUCH more expensive than NXT,
		2x names (the real one and hash name)
		2x lookups in authoritative server to answer negative answer
			first the name then the nearest hash
		More expensive to sign a zone as all hash names had to
			generated and sorted.
	- Later on we discovered that NO did not work with empty 
non-terminals		and wildcards.  (more later) (NO complied with
		at-the-time understanding of the issues).

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.

3. Someone said that we can not deploy a protocol that a single TLD's is
	unable to support for local legal reasons.
	Answer: Get over it,  IF you want DNSSEC security, change
		to a name in a different TLD and put a DNAME at the old one.

4. We have known since day ONE that root and TLD's are special and taken
	that into consideration, otherwise the opt-in proposal would have
	not been considered for this long.
	We have known about EU privacy issues but been told publicly
	it was a non issue.	
	Thus any statements of the type:
		"I can not share with you privileged legal opinion"
	must be considered FUD. So unless the position paper (or at
	least relevant sections) is made public, the working group
	MUST ignore the issue.

	Also what is the implication if some EU citizen registers a domain
	in say 	.cn domain does that mean .cn has to follow EU rules?
	Answer: .cn sovereignty tops EU rules.

5. What in DNS makes something like NO++ difficult?
	5.1 Zones with Multiple label names.
	5.2 Zones with wild cards.
	outlaw both and the problem becomes much simpler for any NO-- proposal
	Moral: When there is a DNS problem do not patch it up, address the
		underlying issue.
	If Zone walking is limited to TLD's then restrict the what the
	zones look like to simplify life.
	W/O restrictions on zone depth and wildcards, the number of
	NO++ records server needs/should/may include in an negative
	answer will depend on the query.
	If the burden of discovering this is placed on the resolver
	by requiring label stripping, then time to assert validity of
	an answer is to great.

5.5 On-line signing of negative answers, who signs it
		a master server ?
		a authoritative server ?
			and with what key.
	In any case these servers can now be DoS'ed as the work they need to
	perform is much greater than the effort of the attackers.
	
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.
	There is lots of hot air about the encoding, size of, obfuscating of
	NSEC2 names, these are minor details lets address the first order
	problem:

	For who is zone walking a problem and why?

	I assert: root zone has no problem.

6.1
	Are any TLD's willing to go on the record to say NSEC zone
		walking is a
			non-issue
			show-stopper

6.2			
	For leaf zones same questions ?

6.3
	For enterprise zones same questions ?

	Unless the WG gets some hard facts presented to these questions
	this whole issue should be dropped.

7. Should the co-chair have asked question #4?
	Lets just kill DNSSEC it is to difficult and expensive.

	Olafur (just some bozo who has followed DNSSEC for 9.5 years)

--
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: Masataka Ohta <[email-masked]>
Date: Tue, 25 May 2004 17:18:17 +0900

Olafur;

>         to a name in a different TLD and put a DNAME at the old one.

DNAME?

I'm afraid you are merely making a external problem internal.

>     Olafur (just some bozo who has followed DNSSEC for 9.5 years)

As a person who followed it more than 9.5y, I think it is merely
that DNSSEC was a bad idea good for no real purpose.

						Masataka Ohta

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Tue, 25 May 2004 10:27:08 +0200

> jumbo that only applies to about 25 countries.

I don't know who are you labeling as a "newcomer", exactly what part of 
the whole is "mumbo jumbo" and whether saying "only 25 countries" isn't an 
oxymoron itself. Paraphrasing an authority person: please remain courteous 
and discuss arguments on the quality of the arguments, qualities of the 
author are out of scope.

---

From: Jim Reid <[email-masked]>
Date: Tue, 25 May 2004 11:52:13 +0100

>>>>> "Marcos" == Marcos Sanz/Denic <[email-masked]> writes:

    Marcos> I don't know who are you labeling as a "newcomer", exactly
    Marcos> what part of the whole is "mumbo jumbo" and whether saying
    Marcos> "only 25 countries" isn't an oxymoron itself. 

Olafur's reference to "legal mumbo jumbo" is well made IMO. The lawyers
for Nominet and SIDN appear to be giving conflicting advice about the
imapct of an EU directive on NSEC. We're not lawyers, let alone
lawyers who understand this field. So unless the legal issues can be
explained to namedroppers by an expert, what we have is to all intents
and purposes legal mumbo-jumbo.

---

From: Edward Lewis <[email-masked]>
Date: Tue, 25 May 2004 09:04:51 -0700

>	jumbo that only applies to about 25 countries.

Yes it is frustrating, when you've chased what 
you understood to be a goal, near it, and then 
find the outcome not to be what you expected. 
It's even worse if you find out the goal is 
actually somewhere else, a place you could have 
been if you had made a different decision years 
back.

I can not lay blame at the feet of those who 
raise last minute objections.  The waterfall 
model of engineering (requirements, 
implementations, test, deploy) rarely works in 
that order with some feedback loops.  Things 
change, conditions change as time progresses. 
That and attention to a topic changes over time - 
a lot of folks with limited resources may have 
decided years ago to ignore a research project, 
but now the project draws more attention, a 
broader range of opinion.

I think that we all do get smarter from this broader range of opinion.

For those who have been working on the project 
for years encounter new comments from new 
sources, there are two outcomes.  One is to 
repeat the rationale of why a similar comment in 
the past did not fly, e.g., why there are 
problems with the NO RR proposal.  The other 
outcome is to generate a reaction to the new 
proposal - positively or negatively.

In the case of the NSEC2, we have some past 
experience with the such a proposal, and that's 
been discussed.  (I'm not claiming closure on the 
topic.)

Today, though, the question isn't really whether 
NSEC2 is a good thing or bad thing.  The issue is 
what does the WG do.  That is more determined 
with what the WG is constituted and prepared to 
do.

One way to look at the issue is the WG is 
composed of engineers.  Do the current specs 
represent sound, workable engineering?  If so, we 
should publish them and see what happens.  Maybe 
the current specs will be the next Betamax, but 
they work.

The other way is to expand our roles to being 
"problem solvers in the large."  I.e., that we 
sit down and consider legal opinions as part of 
our input.  IOW, we should hold up all output 
until we have the perfect solution - defined by 
one that makes everyone happy.

If I were to make a decision right now - right 
now because many know I easily change so-called 
sides in a discussion - I would say that we 
should release the documents regardless of 
(perceived, anticipated) legal hassles.  I don't 
think that we are capable of negotiating between 
different legal environments - we are just 
engineers.

Yesterday I made the comment to Rob that I feel 
the documents ought not go forward.  That's 
because I don't see that there's a clean way to 
migrate from NSEC to NSEC2, assuming there's a 
need to.  There are a lot of versions of BIND 
with experimental (and disabled) DNSSEC code in 
them, but hey, that's the cost of doing business 
I guess.

We should continue to listen for more input from 
the external community.  Perhaps there is a need 
to develop NSEC2.  In other messages I concluded 
(personally) that it can express negative 
answers, but at a cost that makes me wonder if it 
is workable (the linear growth of work as 
determined by the client).

>	- Later on we discovered that NO did not 
>work with empty non-terminals		and 
>wildcards.  (more later) (NO complied with

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

Even the voices inside my head are refusing to talk to me anymore.

---

From: Ólafur Guðmundsson<[email-masked]>
Date: Tue, 25 May 2004 23:16:00 -0400

<chair-hat off>
Thanks Ben for sticking to technical issues.

At 11:01 25/05/2004, Ben Laurie wrote:
>Ólafur Guðmundsson wrote:
>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.

>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.

Now, what if I have already registered that name and even gone as
far as trademarking it.
         what happens ?
         how will resolvers react seeing both NS and NSEC-bis at the same 
note?
         what does the denial for my name look like ?

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.
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.

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.

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

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

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.

We can not keep on solving just one party's problem we need to think forward.
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.

         Olafur

---

From: Marcos Sanz/Denic <[email-masked]>
Date: Wed, 26 May 2004 11:40:12 +0200

> Now, what if I have already registered that name and even gone as

RFC2782, for instance, prepended "_" to avoid collisions with natural 
names..

> NO ZONE walking of TLD's via negative answer records.

It's actually not a requirement only applying to TLDs.

Best,
Marcos

---

From: Paul Vixie <[email-masked]>
Date: Wed, 26 May 2004 14:34:17 +0000

> It's actually not a requirement only applying to TLDs.

in my day job, i'm in touch with a lot of enterprise dns users, and they
universally tell me that the data and/or names they consider sensitive
enough to worry about axfr or zonewalking, would also be dangerous for
queries, and so they run "split dns" so that only internal hosts can see
the data.  they've turned off external axfr because it's unnecessary, not
because it would expose data they care deeply about keeping private.  the
data they care deeply about keeping private is only available "internally."

i guess we'll need some kind of formal survey of the user base to get a
handle on exactly who cares about what.  i'm willing to retune the survey
software i wrote for "sitefinder" last year, or we can ask ben edelman if
he'd be interested.  things i'd like to know are:

1. are you concerned about external axfr? for privacy reasons, or resources?
2. are you concerned about zone walking? for privacy reasons, or resources?
3. do you use split-dns to keep sensitive data from being accessed by query?
4. are your axfr/zonewalk concerns based on carefully researched law opinions?
5. are your axfr/zonewalk concerns based on competitive/marketing worries?
6. are you only planning dnssec so your childzones can secure themselves?
7. how many tld's, sld's, 3ld's do these concerns pertain to?

there may be more.  but we can't do engineering without knowing the customer's
requirements, and we can't sit here and make up those requirements, or guess
them, or listen to the subset of customers who subscribe to this mailing list.
if we really want to say that we care about these concerns, we have to find
out what they are, exhaustively and objectively, and then publish the results.