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: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 25 May 2004 10:06:04 -0700

> 	jumbo that only applies to about 25 countries.

Hold it right there. This issue has been raised repeatedly, but I
have yet to hear a substantive answer. All I have seen or heard is
pointers to claims that it has been answered before.

This is a classic agenda denial tactic. Don't address the substance
of the argument, attack the standing of the person making it.

The reason that this process is taking so long is that instead of
facing the real challenges for deployment these are mau-maued off
the table, then when they inevitably return the process is repeated.

It would hardly be surprising if people had been slow comming forward
with issues. The treatment they have received in this group has
hardly been wellcoming. I get hissed by the then AD and future chair
the first time I try to say a word in a DNSEXT meeting. The mode of
argument is always 'your experience, knowledge and business interests
are irrelevant to this group', followed by 'my understanding of 
the complexities of DNS means that my statements cannot be disputed'.

The fact is however that every issue that has come out at the "last 
minute" has been raised repeatedly and ignored. Now we are told that
the only options are between doing it according to the current specs
and abandoning DNSSEC entirely. This is a false choice, we do not
need to delay or abandon the DNSSEC specs, we do not need to define a
new NSEC record. All we need to do is to make NSEC optional.

Making NSEC optional reduces but does not eliminate the security
benefit of DNSSEC. Since we are talking about an infrastructure that
is currently insecure and will take many years to deploy a security
infrastructure for there it makes no sense to make NSEC a show stopper.

IF DNSSEC is deployed you will discover FAR more problems than just
NSEC.

I don't think that at the time proving non-existence of domains was
accepted as a showstopper 9 years ago that the implications for 
the present day Internet could have been understood. Over that time
the number of users has gone from a few million college students to 
a billion.

There has also been a radical change in the understanding of the 
security problem over that time. When I started doing Web security 
in 1992 the security field was still centered on the problem of
securing multiple user access to a single, non networked computer.
The role cryptography might play in a network environment was
poorly understood.

Since then there has been a radical reassesment of the appropriate 
application of cryptography in the field. Much of this is the 
result of extensive and painful experience trying to deploy
cryptographic systems.

>From a pure security perspective NSEC buys you very little of value.
This is because DNS is not just a protocol, it is a component in
a system. In a system there is no useful distinction between
a subsystem that replies 'It does not exist' and one that says 
'I cannot find it'.

---

From: [email-masked]
Date: Wed, 26 May 2004 16:37:48 +1200

>	Are any TLD's willing to go on the record to say NSEC zone

I'm not the policy guru for NZ, just the guy who gets asked DNS stuff.
However, it's very clear to me that there would need to be a major
change in view among NZ registry stakeholders for NSEC to be accepted
because of the zone walking problem.

The ability to walk the zone would have to viewed in the same light as
for zone downloads, given that the for the most part, the same policy
issues are exposed.  It's possible that the rate of such walking could
be restricted in the simple cases, but I don't think I could put my hand
on my heart and say that such throttling would stop those even mildly
determined to get a copy of a zone, nor that it would not potentially
negatively impact the performance of the name servers in responding to
legitimate queries.

Current zone transfer policy[1] is basically "no zone transfers unless
authorised and conditions met". The new draft policy[2], likely to be
accepted very shortly, is more restrictive, basically denies access to
zone files unless an "exceptional reason" for access to the zone can be
demonstrated.  

There is a clear trend towards becoming more protective of the registry
database, and the index to the WHOIS data it represents.  

That said, DNSSEC is quite clearly on the NZ registry radar; we would
very much like to be on the leading (but perhaps not bleeding) edge of
DNSSEC deployment.  

Getting a little more pragmatic, I think the real question is, can we
have our cake and eat it too?  Or, can we break NSEC walking without
breaking NSEC?

Consider...

Authenticated denial relies on there being am authenticatable "space"
between each record, thus if I have:

	a.example.	NSEC	c.example. ...
	c.example.	...

then I know that there are no records between a.example and c.example. 

But if I instead inserted:

	a.example.	NSEC	a_.example.  ...	
	a_.example.	NSEC	a__.example. ... ; booby-trap
	a__.example.	NSEC	c.example.   ...
	c.example.	...

What if an explicit query to a_.example. triggered some kind of
defensive response, such as a complete refusal to return the NSEC
record?  In this example, because of the third NSEC, you would never get
the booby-trap record except as the result of an attempt to walk the
NSEC chain.

-- don

[1] http://www.dnc.org.nz/content/zone_transfer.pdf
[2] http://www.dnc.org.nz/content/proposed_new_zone_transfer_policy.pdf

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 25 May 2004 11:25:56 -0700

> I strongly disagree with this.  From an application 
> designer's perspective,
> getting back a *trustable* "this does not exist" is very 
> different from getting
> "I cannot find it".  You may be thinking in terms of human 
> driven activities
> like browsing, in which there is a human to apply heuristics 
> to an error
> code; in some of those the human tends to apply the same guesses
> to what to do next in response to both.  But this is not the 
> only class
> of applications, and for many of the discovery elements of those,
> I believe reliable data for non-existence is required.

Your argument would only support the statement "reliable data 
for non-existence is required FOR CERTAIN APPLICATIONS".

Given that the choice being asserted is between a DNSSEC as
is, and no DNSSEC at all, ever I think it is reasonable to
point out that there is a wide range of Internet USE that is
addressed without NSEC.

If DNSSEC v1 is only sufficient to provide security for
Web browsing that is more than enough to justify the effort.

It is exactly the same as in MARID, don't insist on solving
the entire problem in the first go. MARID will not provide the 
solution to spam, but it does provide me with one of the tools 
I need.

The big fallacy we fell into ten years ago was beleiving that
imperfect security was worse than no security at all. SSL
disproved that, SSL v1 was so bad I broke it fifteen minutes
into Marc A's presentation, and not in a small way either.
SSL v2 was a bit better but has plenty of holes. Yet these did
not stop SSL v3 being the most successful cryptographic protocol
of all time.

In the WiFi area WEP was a disaster, but fixes soon appeared.
If it wasn't for the fact that WiFi systems tend to be in hardware
it would not have been such a serious problem.

We can make as much fun of the SSL and WEP groups as we like, but
the fact is that they deployed a real solution that is now both
secure and widely used. This group has not, despite having tried
for longer.

Delivering a cryptographic system that delivers real security
for an important class of applications is a very worthwhile
project, even if a limitation in the protocol means that it
does not protect other applications. In this case we are far
better off than with SSL or WEP because we know what the problem
is and there is even a fix for the problem.

All that is being said is that the fix should not be mandatory,
nor should inability to come up with an acceptable fix in the
next few days mean that the entire scheme is scrapped.

Some people are saying delay the specs, I am not. I am saying publish
the @&$*@!! things and start deployment today. Just do not force
anyone to use a part of the specs that many believe to be broken.

All my experience of deploying real world cryptographic protocols
tells me that we are nowhere close to having a legacy issue here.
There will be more than enough time to fix this. The only question
is whether we leave ourselves an acceptable way to deploy a new
NSEC without having to revise all the existing RRs and clobber
the deployed base yet again.

---

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

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

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

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

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

Best,
Marcos

---

From: Ted Hardie <[email-masked]>
Date: Wed, 26 May 2004 06:15:26 -0700

>for non-existence is required FOR CERTAIN APPLICATIONS".

How do you propose to let the DNS resolver know what application
has requested a record?

<snip>

>anyone to use a part of the specs that many believe to be broken.

To quote one of my colleagues, "The mailing list has no guns".

>the deployed base yet again.

I do not have the same experience with cryptographic protocols,
but I fairly sure that we have to aim at the target we
want to hit.  Even if it takes several iterations to get it right,
if we are not aiming at a protocol that allows for reliable
data for non-existence, I believe we are aiming at the wrong target.
			regards,
				Ted Hardie

---

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

> "NSEC" walking would usually not be done with explicit queries for NSEC RRs
> (because that's too easy to answer with REFUSED, since there's probably no
> need for those queries) ...

actually i was planning on using ANY queries starting at @, the answers to
which would include NSEC.  that way i can gather all the data in the same
pass where i gather all the names.

in the scenario, booby traps would be quite effective.

the trouble with booby traps is, since udp source addresses are spoofworthy,
it would possible to make an authority server generate and hold a huge amount
of state just by forging a boobytrap-o-gram from a zillion different addresses.
if there's a quota, you can make them overrun it, thus making room for your
real zonewalk queries.  if there's no quota, you can make them run out of
state-memory.

---

From: [email-masked]
Date: Thu, 27 May 2004 19:49:54 +1200

Paul Vixie <[email-masked]> wrote:
>this isn't practical.  if the .org people did this, then isc.org would be
>subject to downgrade attacks wherein an attacker could insert unsecured
>responses into the transaction stream making folks believe that isc.org
>did not exist, and the querier would not be able to tell that it had been
>spoofed.  i want both positive and negative responses about my parent domain
>to be signed and verifiable.

Can you explain to me the difference, from a security enabled resolver's
point of view, between the following three cases:

(1) A non security enabled name server returning NXDOMAIN for a name
that doesn't exist;

(2) A security enabled name server returning NXDOMAIN for a name that
doesn't exist (but which would return signed data or an appropriately
signed NSEC if the name did exist), as per my previous post; and

(3) A man in the middle intercepting a request and responding to it with
NXDOMAIN.

-- don

---

From: Paul Vixie <[email-masked]>
Date: Thu, 27 May 2004 14:06:11 +0000

> > ...

assuming that case (2) does not include an NSEC covering the query name,
then among those three there is no visible difference from a validator's
point of view.  however, there's a fourth case, which i'm interested in:

  (4) A secure negative response including a covering NSEC, signed with the
  zone's key, indicating the nonexistence of the name.

if a validator has a reason to expect security, such as a static trusted-key
for the zone or a parent DS learned during delegation, then cases (1), (2)
and (3) would all be treated as a possible instance of (3), and only case
(4) would be taken seriously or considered to be useful for subsequent
processing (such as giving up on the forwarding of email to that domain, or
giving up on contacting a jabber server at that domain, or whatever.)

in your previous post you proposed a signalling method that would make us
treat all negative responses as temporary failures.  that's not a value add.

---

From: Paul Vixie <[email-masked]>
Date: Sun, 30 May 2004 17:30:44 +0000

I mean of course..

> it's now the end of june.

...that it's now the end of may.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 31 May 2004 02:18:56 +0000

> So the real question in my mind is, will DNSSECbis be deployed on the
> root?  Or will it have to wait for DNSSECter.

the root zone is ftp'able, axfr'able, and otherwise not considered a matter
of confidential record.  therefore i don't think enumerability will be an
obstacle to signing the root.  all of the rootops can now support dnssec-bis.
therefore, it's down to the political problems like "who will know the signing
key" and none of those depend on the presumed delta between -bis and -ter.

> If the root zone is going to be signed using DNSSECbis, then NZ
> will want to be doing *something* with DNSSECbis.  Which means some form
> of option (3).

if you're willing to tolerate another type code roll ("TCR++" for short) then
option 3 is on the table.  if you think, for some reason, that some other
form of extensibilty is necessary, then "option (3)" means "dnssec after 2004"
which would seem like a really painful last minute course change after all
the compromises and hard work that have gone into the "dnssec in 2004" effort.

> > ... you should study auto-msj, auto-johani, dlv, and any possible
> > other island-of-trust brokerage mechanism that could be used for
> > early deployment by your subdomainholders.
> 
> Islands of trust is not DNSSEC deployment as far as a TLD is concerned.
> Sub-domain holders can do what they like; that's why we call it delegation.

i think you need to study it more closely.  your conclusions don't match the
facts as i know them.  i'm always willing to take this up 1x1, even by phone,
if that seems palatable.

> In terms of specifications, I agree that trying to change DNSSECbis at
> this stage is probably pointless.  We might as well get -bis out now, so
> that enterprise deployment can occur -- for the most part, enterprises
> don't have the same privacy concerns as registries for their internal
> networks and DNS, yet could still benefit from DNSSEC. 

as the prime mover between one of the early deployment aids ("dlv") that
creates islands of trust, i can tell you that my scope is far beyond my own
local "enterprise".  i think that msj and johani would say the same.  so,
please study these alternatives more closely before you conclude about them.

> Meanwhile, lets get on with DNSSECter for deployment on the public
> Internet.

agreed.  and hopefully, because you said that, you'll be hearing from
jim reid about dns-moda.