Subject: RE: NSEC+ and NO

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.

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