[dnssec-deployment] Future applications?

[Phil Regnauld]

Dave Piscitello (dave) writes:
> I would be very interested in seeing your presentation.

	So would I in fact.

> I think this is an important issue for DNSSEC advocates. I don't want to 
> appear negative or alarmist and I am certain many of you hear the same 
> chatter I've been hearing, especially lately: "DNSSEC doesn't solve enough 
> problems and the ones it solves can be mitigated using other methods" and 
> "DNSSEC doesn't bring enough to the table to justify the implementation and 
> deployment costs". I'm not saying these are true claims, but they are made 
> loudly and frequently.

	... The only way you can counter that is by doing relentless promotion
	of DNSSEC at conferences, NOG meetings and workshops.

	For instance at the most recent ccTLD workshop organized by NSRC/ISOC/
	ICANN (http://ws.edu.isoc.org/workshops/2007/cctld-amman/agenda.html),
	we had almost a day of DNSSEC (intro + basic hands-on signing), to get
	administrators from the Region familiarized with the concepts, and show
	that it wasn't as complicated (from a technical point of view) as it seemed.

	There's been entire workshops on the topic:

	http://www.interlab.ait.ac.th/training/2006/dnssec.html

	... and some of the materials have been translated to other languages:

	http://ws.edu.isoc.org/workshops/2006/dnssec-dakar/

	So what's missing now is to give people a good argument why they should
	go through with the extra work and administrative overhead that signing
	zones and delegations implies.  I'm a bit stumped on that one :)

> An article that identifies the kinds of applications DNSSEC can support and 
> why those applications are important would be *extremely* valuable.

	A point was made that DNSSEC doesn't function as some kind of PKI that
	you can build on (it's not a signature framework for the rdata), so
	it's not easy to "sell" DNSSEC as an enabler of new applications/features.

	Even the added validation is not visible: if we take the case of typical
	end-users (read: web surfers :), failure to validate the origin of DNS
	answers (and the ensuing failure of resolution, as seen by the
	client) does not automatically generate a warning in the application,
	since there's no vertical mechanism to push a qualified error condition
	back to the application, unless the application actively checks DNS
	data (and that's not its job).  See http://www.dnssec-tools.org/ and
	http://www.dnssec-tools.org/whybad.html for a good example).


> BUT... 
> it must be written in language that average people and executives can 
> understand. I am certain I could get an editor at a quality publication 
> like ENISA Journal, USENIX, or BCR to publish something like this and would 
> be happy to lend my pen to the task.

	Same here, but we've got a silver bullet looking for a werewolf, is
	the perceived attitude.

	Phil	

-- 
  _ _ |_ |
 (_(_||_ | regnauld at catpipe.net - www.catpipe.net
         |