Subject: RE: Proposed NSEC/NSEC3 transition mechanism

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 18 May 2006 06:57:17 -0700

> [mailto:[email-masked]] On Behalf Of Edward Lewis

> For the sake of registries that have or will have DNSSEC 
> running prior to the publication of the possible NSEC3 
> specification, I claim that a means to have a smooth 
> transition from NSEC to NSEC3 and back is essential.

I do not see such a need. 

In the first place one of the the original premises for NSEC3 was that a walkable zone would be in breach of EU privacy regulations the only transitions required would be between NSEC3 and a successor or NSEC3 and no DNSSEC.

Secondly as a security specialist I think that Ed vastly over states the degree of dependency that is likely to be created within the scope of the early deployment.

I think DNSSEC is important as a security specialist but it is going to take a huge effort to convince the world of that. Premature reliance has never been a problem in previous deployments.

It may be important to create such documents for specific deployment instances but there is a vast difference between operational documents relating to a specific deployment and a standards document. I see neither use nor justification for developing a document that describes a transition between every possible configuration of two schemes in the absence of any stated interest in making such a transition.

--
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: Edward Lewis <[email-masked]>
Date: Thu, 18 May 2006 10:37:52 -0400

At 6:57 -0700 5/18/06, Hallam-Baker, Phillip wrote:

>In the first place one of the the original premises for NSEC3 was that a
>walkable zone would be in breach of EU privacy regulations the only
>transitions required would be between NSEC3 and a successor or NSEC3 and no
>DNSSEC.

This may be the case, but "original premises" often become historical 
footnotes.  (Recall my presentation about DNS to the MARID interim 
meeting where I was told to stop telling the amassed audience why 
things in DNS are the way they are - blaming it on original premises.)

Looking at what NSEC3 offers, it goes beyond EU privacy regulations. 
If it were just that, why hack the DNS when whois is the real culprit 
(in the disclosure of identifying information)?  (Yes, I know that 
NSEC's point a miner to the data in whois, but the data *is* in 
whois.)  The Brazilian registry is (alleged come to think of it) also 
interested in NSEC3.  One of the points made by Nominet engineers is 
that they are concerned by the traffic load zone walking attempts 
would engender.  I mention this because I think it would be foolhardy 
to restrict an analysis of NSEC3 to the context of the original 
premises.

I go further to say that NSEC3 may wind up being used in ENUM and the 
like zones.

>Secondly as a security specialist I think that Ed vastly over states the
>degree of dependency that is likely to be created within the scope of the
>early deployment.

Would you clarify what you mean by this comment?  I hope the 
"security specialist" doesn't apply to me, nor an I sure what you 
mean by "vastly over stat[ing]...dependency."

>I think DNSSEC is important as a security specialist but it is going to take a
>huge effort to convince the world of that. Premature reliance has never been a
>problem in previous deployments.

I am at a loss to respond to that too.  I would think that premature 
reliance has been a real pain in many arenas, I recall a lament that 
one vendor shipped DHCP code based on a draft, forcing a WG into 
sticking with a bad solution in 1999.  Not to demean the involved 
parties then, but it's the most descriptive example of premature 
reliance I know of.

>It may be important to create such documents for specific deployment instances
>but there is a vast difference between operational documents relating to a
>specific deployment and a standards document. I see neither use nor
>justification for developing a document that describes a transition between
>every possible configuration of two schemes in the absence of any stated
>interest in making such a transition.

Since the SiteFinder incident and fallout is that IETF protocols do 
not stand on their own.  IETF defined protocols assume a carefully 
crafted operational environment.  Although the introduction of the 
wild card into COM and NET back then fell well within DNS protocol 
design and specification, there was a huge operational backlash, with 
misaddressed mail suddenly getting delivered as if it were corrent, 
spam blockers failing to find names as not in DNS, etc.

An example of not considering operstions -  RFC 2065 and 2535.  These 
two earlier attempts at DNSSEC had no and then just some operations 
input.  RFC 403[345] are said to be improvements based on operational 
input.

My raising this issue now could be seen as a means to delay NSEC3, in 
the sense that asking for "one more thing to be defined."  The 
"victims" of this are zones that have reasons to not deploy NSEC, but 
not discussing this will cause problems for zones that are under 
pressure to deploy NSEC now and in the coming time - and then may be 
told to transition later.  Because I think such considerations are 
distasteful, I've held back from making comments, but I'm also tired 
of seeing history repeat itself.

Meaning - we need to consider operations.  Might as well be now.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

Nothin' more exciting than going to the printer to watch the toner drain...

---

From: Alex Bligh <[email-masked]>
Date: Thu, 18 May 2006 15:58:17 +0100

--On 18 May 2006 10:37 -0400 Edward Lewis <[email-masked]> wrote:

>> transitions required would be between NSEC3 and a successor or NSEC3 and
>> no DNSSEC.
>
> meeting where I was told to stop telling the amassed audience why things
> in DNS are the way they are - blaming it on original premises.)
>

I agree with Ed here in as much as I think having a path between NSEC2 and
NSEC3 (and possibly vice-versa) that does not at any time make the zone
less secure/functional than the least secure of the start point and end
point of the transition is probably a requirement. In practice I think that
boils down to a transition between NSEC2 and NSEC3 (and possibly
vice-versa) not making the zone return bogus or insecure results where it
would not have done so as a "pure" NSEC2 or NSEC3 zone ab initio (obviously
taking an NSEC2 zone and making it NSEC3 only is at some point going to
cause NSEC2 only resolvers to fail).

Similarly between no DNSSEC and NSEC3.

But I'm not sure the requirement goes a long way beyond that, does it?

I also agree that if we are looking for wide adoption, our security
yardstick should be the protocol itself, not merely looking at the
likely use-cases of those who advanced it.

Alex