meeting summary: 5 January 2005

[James M Galvin]

DNSSEC Deployment Working Group
5 January 2005


PRESENT:
    Steve Crocker
    Jim Galvin

    Allison Mankin
    Amy Friedlander
    Bill Manning
    Cathy Murphy
    Doug Barton
    Jaap Akkerhuis
    Jon Peterson
    Olaf Kolkman
    Peter Koch
    Ralph Droms
    Russ Mundy
    Sam Weiler
    Scott Rose
    Steven Cheung
    Suresh Krishnaswamy
    Suzanne Woolf


REGRETS:
    Ed Lewis
    Geoffrey Sisson
    Mike St. Johns


SUMMARY

  -- South Africa Reports

     Jon Peterson and Johan Ihren both gave DNSSEC related presentations
     in South Africa.  If available they will distribute their slides to
     the mailing list and we will have a brief discussion of their
     experience.

Jon Peterson distributed his slides to the mailing list.  He gave his
presentation to the ccNSO group.

There is also the ad hoc group of mostly Asian ccTLDs that call
themselves the wwTLD group.  They are more or less anti-ICANN but they
have not been able to get themselves organized enough over the past
couple years to accomplish anything significant.  They meet and tend to
help each other but otherwise have no agenda and do not make any forward
progress.  Johan Ihren gave his presentation to this group.


Among other things, Jon's presentation builds from pointing out that the
certificate business is a monopoly controlled by the browser vendors.
He then suggests that with DNSSEC the DNS is a de facto certification
authority and key distribution system that could supplant the
certificate business.

This makes sense to most people and they quickly recognize the political
significance of the "power" shift when DNS becomes the "root of
security."  What remains to be affirmed is that this could be a business
for which those who deploy DNSSEC could make money, i.e., see a return
on their investment.  It is notable that the return does not need to be
immediate, just in the foreseeable future.


Steve Crocker noted that what we need to, at least in part, is create
the right balance between DNSSEC securing DNS and DNSSEC enable new
"things".

Allison Mankin suggested that using the DNS as a trust anchor is
probably a concept that could be leveraged by applications.  We should
engage browser vendors so we can better understand what they want and
need.

Doug Barton insisted we need a compelling case for DNSSEC if we want
deployment.  He still believes that the "killer app" for DNSSEC will be
the "lock icon" on a browser.  If it's locked and gold now with TLS/SSL,
then it will need be locked and gold and sparkly with DNSSEC (or
something similar).

Jon argued that the browser vendors would have no interest in DNSSEC.
The difference betweeen the browser market and say email, for example,
is that browsers have a solution that works, i.e., TLS/SSL.  It works
just fine without DNSSEC whereas DNSSEC does not stand alone.

Doug responded that even so, DNSSEC is an easier, lower cost, less
monopolistic way of assuring the users of browsers that they get the
site they wanted to get.  There may be other things down the road that
might take the "killer app" label away but that's okay.  The path to
deployment is getting a "hook" or extension into Mozilla or Firefox.


Allison asked what the potential was for DNSSEC "helping" reverse
lookups.  Olaf noted that the "power" comes from the fact that the
reverse space follows the infrastructure and it is most useful for
ensuring a VPN is properly setup (opportunistic key relationships).


Jon continued that DNSSEC adds very little value on top of
certificates.  Therefore, to really be successful it is goint to have to
supplant the certificate system.

Doug disagreed arguing that certificates and DNSSEC protect different
elements of a transaction.  DNSSEC ensures you get the correct server
while certificates protect the actual transaction.  Jon agreed but the
fact is SSL/TLS do not need DNSSEC whereas DNSSEC still needs SSL/TLS.
There are some corner cases where a phishing attack using a forged or
misleading certificate could probably be avoided with DNSSEC, but that's
not a reason to deploy DNSSEC.

Doug suggested that what we need is to change SSL/TLS to support the use
of DNSSEC as the key distribution system.  Jon agreed but noted that he
actually sees that as an impediment.

There was tacit agreement once there was motivation to support DNSSEC, a
highly motivated engineer could upgrade SSL/TLS in a couple weeks of
dedicated effort.



  -- DNSSEC Deployment Roadmap

     Amy Friedlander distributed revised diagrams/pictures to the
     mailing list.

Steve Crocker asked for comments or discussion on the revised pictures.
There was very little discussion.  If you have comments please do send
them to the list as soon as possible.

Allison Mankin believes the changes remaining to be done to the document
are editorial.  There is some new text to prepare to go with the revised
documents but after that we should be ready for public distribution of
the document.

There is the question of whether or not .ARPA should be called out
explicitly.  Doug Barton suggested it should be because the community
sees .ARPA as being distinctly different from other TLDs.


Last call for comments is right now.