Subject: RE: Proposal to fix NSEC

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 21 May 2004 20:31:22 -0700

> > So why do we need to specify more than H(dx), (H(dx+1)) ???
> 
> To increase the cost of dictionary attacks.

Ben,

	I think that this risks turning a good proposal into one with a
questionable feature that will distract from the main value. Essentially all
you are arguing for here is an expensive hash function.

	The valud of crypto is that you can introduce asymmetric attack
costs. It is much harder for an attacker to break DES than it is for the
defender to encrypt their message - 2^55.5 times as hard in fact. That is a
real benefit.

	Here you just make the problem harder by an equal factor for
attacker and defender. That is not a core value here.

	Leaving aside that nit, the proposal has real value and adds real
security. The comparative attack analysis that has been offered is totally
bogus:

	The DNS system without DNSSEC provides a lookup function that
returns an answer to the question "is x a member of S" and returns a binary
response.

	With DNSSEC and NSEC you get a response "there are NO members of x
in the range a,b AND a,b are both members of S"

	Sorry, but anyone who claims that there is no security issue raised
here is speaking through their hat. The fact that I publish a binary
response function returning set membership does not mean that I am willing
to reveal the set. That is simply untrue. 

	The number of real world attacks that are made possible by revealing
S is very, very large and very, very significant. I know that there are folk
who dispute this in the IETF, remember however that there are people in the
IETF who have actively discouraged the deployment of firewalls in the past,
and some still do. Regardless of where you stand on that debate please
understand that the fact that if you want to deploy a security protocol it
had better meet the security requirements set by the security establishment.

	In the real world the fact that there is an easy way for an attacker
to discover the names of all my public facing machines is a really really
significant issue. In the real world 95% of attacks are made by people who
are clueless. In the real world security is risk management, not risk
elimination. If you do not believe me on this go talk to Bruce S. or read
Secrets and Lies. 

	In the real world every security incident costs real money. Filters
that catch 95% of the bozos save real money.

	The current NSEC record is bogus. It insists on addressing a
security issue that simply does not exist (securing insecure zones) while
refusing to address a real security issue which is rightly considered by
many to be a showstopper for adoption.

	If there was a logic to the IETF process we would ask people two
questions, first what are the showstoppers that would cause you not to
deploy? second why should we care? I know the IETF lives in a
crypto-communist la-la land where it is impolite to ask such questions but
the failure to do so is the reason that DNSSEC is still a failed spec ten
years on. The canonical texts for my company are Jim Collins, built to last
where facing the brutal facts is considered one key to success.

	My showstoppers are 1) the spec must be incrementally deployable in
large zones and 2) it must address the zone walking issue.

	The reason you should care is that I am one of the very few members
of the security field who has an interest in this group. I am Principal
Scientist of the security division of company that has major influence in
the Security field. I also have personal influence, as the author of XKMS,
and co-editor of SAML and WS-Security I can help convince key constituencies
that they should buy in to DNSSEC.

	The security community is not going to support a spec that
introduces a new security vulnerability that was not previously present and
introduces operational demands that threaten the stability of core DNS. As
the spec stands I cannot recommend it to my colleagues and in fact would
have to recommend that they do NOT deploy.

	With an updated NSEC record that meets the showstopper objections I
describe I will be in a position to recommend DNSSEC. I believe that it is
even possible that with a small amount of appropriate preparation work it
might be possible that MARID and MARID accreditations could serve as a
'killer-app' for DNSSEC. One important political point here is that a MARID
accreditation service would be outside the control of ICANN. Remember that
killer-app means, the app which motivates building the infrastructure, not
necessarily the most important app the infrastructure will serve. Email was
not the Internet killer app, everyone had to be online before it had value,
but now everyone is online email is more important than the web.

			Phill

--
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: Ben Laurie <[email-masked]>
Date: Sat, 22 May 2004 16:15:47 +0100

> attacker and defender. That is not a core value here.

This is true, but neglects the fact that the attacker has to hash far 
more things than the defender. However, an asymmetric solution would be 
even nicer, I'll agree.

Cheers,

Ben.