Subject: RE: Scope of discussion (was Re: Proposal to fix NSEC)

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 24 May 2004 09:30:27 -0700

> that's not realistic.  if dnssec-bis takes off and creates an 
> installed base,
> then there will be no incompatible changes to it between 
> PS/DS/FS, and those
> stages will just be used to refine the documents based on 
> implementation and
> deployment experience.  

What is the killer app that would cause it to take off?

> if dnssec-bis fails to take off for 
> ANY reason, then
> getting more funding or development, or being taken seriously 
> when saying "we
> really think we've got it right this time," has a likelihood 
> approaching zero.

That is defeatist thinking. I think that DNSSEC needs a 
killer-app. I don't think that protecting the DNS infrastructure
itself is likely to serve until there is a massive DNS attack
that changes the way the infrastructure is viewed.

But a killer app need not be the intended purpose of even
the main purpose after the system is deployed. The Internet
killer app was the Web, not email. The Web allowed the Internet
to expand rapidly outside academia, but today email is the
app that is most valuable for most people. The killer app for the
microcomputer was the spreadsheet - an app that hardly any PC
user would rate as their most critical today. At that time you
bought a PC for your secretary to do word processing on, no
manager would admit doing that. 

I think that the most likely killer app for DNSSEC is email
accreditation services for anti-spam mechanisms. Of course this
could easily be served by a separate protocol. But reusing
DNS means that it can pull DNS extensions and DNSSEC along
in its wake. Needless to say, stopping trivial enumeration
is critical for this application.

--
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: "Scott Rose" <[email-masked]>
Date: Mon, 24 May 2004 10:07:02 -0400

While talking about some stuff regarding the NSEC and NSEC2.   Is there a
way to proceed with DNSSEC deployment with the option of having NSEC2 coming
later - and have both systems co-exist?

I do not know the answer now, but the first option was to use different
values in the DNSKEY protocol field to indicate status of non-existance
responses in the zone.

3 - uses NSEC as in DNSSECbis docset
4 - uses NSEC2 or something else
5 - etc...

However, the problem here is interoperability with signalling unsigned
delegations.  If a NSEC-DNSSEC sec-aware resolver gets a unsigned delegation
with a NSEC2 RR (proving no DS RR exists), will the resolver could exit with
servfail (protocol error) instead of proceeding with knowledge that the zone
is unsigned.  If the resolver continues, it will see the DNSKEY RR in the
zone having a protocol field of 4 (or whatever) and declare that as invalid.
This could be bad since postive responses could be verified as normal, only
negative response are different.

This is just a possibility.  There might be others, or we could drop the
idea of co-existance of NSEC with NSEC2 (or some other option).  Just
something to keep in mind as a possibilty to allow early adopters to start
using DNSSEC (those that do not believe they have to fear zone enumeration).

Scott