meeting summary: 12 January 2005
James M Galvin
galvin at elistx.com
Tue Jan 18 17:24:33 EST 2005
DNSSEC Deployment Working Group
12 January 2005
Mike St. Johns
-- Update on Kyoto Meeting Plans
Plans are moving forward.
-- Update on wwTLD
Johan Ihren gave a presentation to about 30 people from wwTLD.
In discussions following the presentation, the argument against DNSSEC
that surfaced was the need for registries to justify the huge investment
by proving that DNSSEC was really needed. The counter-argument made by
Johan was that you would probably never get that proof until you
actually needed DNSSEC, at which time it would be too late. And, of
course, it is always possible you may never *need* DNSSEC. A working
analogy is to consider DNSSEC similar to insurance: one really does not
know if your home will be burgled but you still lock your door.
Steve Crocker asked Johan if he had any additional information on the
group itself to whom he gave his presentation but there was none. Johan
noted that the person convening the session was busy elsewhere. In any
case, she was clearly there just to get speakers and manage the agenda.
It was a vacuum as far as wwTLD structure and organization was
Jaap Akkerhuis offered that their web site is: <http://www.wwtld.org>.
Johan also participated in some training sessions. The number of new
TLD registries that have been exposed to DNSSEC was increased and that
is always good. Steve asked for records regarding who had been exposed
and Johan noted that Bill Manning keeps pretty good records. He
estimated that about 1/3 of all the TLDs have been exposed.
-- Business Case for DNSSEC
An open discussion (brainstorming) of possible business cases for DNSSEC
We discussed what it means to enable applications and which applications
might best make use of the presence of DNSSEC, for example:
Allison Mankin asked if using DNSSEC as a means to distribute keys could
be used as a selling point of DNSSEC?
Points from the discussion:
* Using DNSSEC for key distribution helps application security but not
* Doing so means the default trust structure would be coming from ICANN,
unless you decide to structure it from a public key distributed from
some other trust anchor, for example, a TLD.
* Is this really what DNSSEC deployment is all about, i.e., loading up
DNSSEC with all this stuff?
* DNSSEC as a key distribution is most appropriate when the "identity"
associated with the key depends on the domain name. Opportunistic
encryption is a good example, for example, "I have this IP address,
what is the key I should."
* Once you leave the context of the DNS, trusting keys from there is
problematic. Why should SIP or IM trust keys in the DNS? On the
other hand, is it about user keys being in the DNS or about server
* We need to avoid the perception that those who deploy DNSSEC are
liable because of the presence of the keys. If we market DNSSEC as a
PKI there is the risk that people will pull out because they do not
want the liability.
* Keys associated with IP addresses and delegations are appropriate.
Keys for other purposes, e.g., confirming the identity of a "bank",
increase the risk, even if it is only a perception. On the other
hand, the domain name is already part of the "equation" since it is
included in the altSubjectName in certificates today.
* It is true that CA infrastructures today do not work very well, so
there is a business case to be made to use DNSSEC as a PKI. However,
we should not begin with this application because we need experience
with a stable DNSSEC infrastructure first.
* Can we write a policy for what it means when DNSSEC is present? Olaf
Kolkman noted that he has tried writing a policy for the reverse
lookup tree, thinking it would be straightforward, but he found
himself writing disclaimer text. This is not good.
Jakob Schlyter noted that he had a policy for when DNSSEC was present,
which was different from their non-DNSSEC policy. Those who make use
of DNSSEC are required to explicit acknowledge their acceptance of
this policy, in contrast to the generic service policy that applies
just for being a customer. It is currently in Swedish but he would
see if he could get it translated and made available.
Steve Crocker asked, "What will make DNSSEC go? Does it require
applications on top of it? Are we saying that DNSSEC as designed (to
protect DNS itself) is insufficient?"
If we can find the "killer app" for DNSSEC that is great. But if not,
we need something outside of DNSSEC to push it forward.
Ralph Droms suggested there was a time when DHCP authentication
considered using DNSSEC. (It was later abandoned due to lack of
Allison Mankin suggested there were quite a few uses of SRV that would
be extremely damaged if there is a rogue out there. There is the
possibility of inserting a man-in-the-middle in some TLS servers.
Olafur Gudmudsson suggested we gather together a number of "smaller"
applications to make use of DNSSEC. We could have one "large"
application and then a bunch of "smaller" ones.
Olaf Kolkman suggested that perhaps we stick to the line "DNSSEC secures
DNS." But, by the way, if you do DNSSEC you get a number of things for
Allison took the action to draft some slides to characterize this
discussion. She noted that IESG has been putting the
"man-in-the-middle" warning in SRV documents for quite a while.
More information about the Dnssec-deployment