meeting summary: 12 January 2005

[James M Galvin]

DNSSEC Deployment Working Group
12 January 2005


PRESENT:
    Steve Crocker
    Jim Galvin

    Allison Mankin
    Amy Friedlander
    Bill Manning
    Cathy Murphy
    Ed Lewis
    Jaap Akkerhuis
    Jakob Schlyter
    Johan Ihren
    Olaf Kolkman
    Olafur Gudmundsson
    Ralph Droms
    Rob Austein
    Sam Weiler
    Scott Rose
    Steven Cheung
    Suresh Krishnaswamy
    Suzanne Woolf


REGRETS:
    Geoff Sisson
    Matt Larson
    Mike St. Johns
    Paul Vixie
    Peter Koch


SUMMARY


 -- 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
concerned.

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
occurred.

We discussed what it means to enable applications and which applications
might best make use of the presence of DNSSEC, for example:

   IPSEC
   SECSH

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
  DNS.

* 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
  keys?

* 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
interest.)

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
free.

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.