meeting summary: 7 December 2005

[James M Galvin]

DNSSEC Deployment Working Group
7 December 2005


PRESENT:
    Steve Crocker
    Allison Mankin
    Russ Mundy
    Jim Galvin

    Bill Manning
    David Blacka
    Ed Lewis
    Jaap Akkerhuis
    Matt Larson
    Mike St. Johns
    Neil McBurnett
    Olafur Gudmundsson
    Olaf Kolkman
    Peter Koch
    Scott Rose
    Shigeya Suzuki
    Stuart Schechter
    Suresh Krishnaswamy
    Suzanne Woolf
    Hilarie Orman
    Sam Weiler
    Amy Friedlander
    Thierry Moreau


REGRETS
    Geoff Sisson


SUMMARY

Allison Mankin will be Shinkuro before the end of the year.  She
plans to remain involved in DNSSEC deployment activities but to a
lesser extent than she is now.


Regarding the article noted by Ram Mohan:

    Secure DNS faces resistance
    1st December 2005
    By CBR Staff Writer

    The deployment of DNSsec, an enhancement to the domain name
    system that could protect against certain types of phishing and
    pharming attacks, is still facing skepticism and resistance from
    those who would be involved in implementing it

    http://www.cbronline.com/
    article_news.asp?guid=5CB02292-1149-4657-BA91-3F67AA4C91B5

Russ Mundy called attention to a comment posted in response to the
article that noted, "DNSSEC is simple.  It's just folks trying to
sell something that is useless."

Steve Crocker added that the person who made that comment was
Russian.  He is an experienced guy that probably did not learn
anything new from the article, although he did have an attitude.


Kudos to Program Committee who put together the DNSSEC Workshop at
ICANN Vancouver.  Allison led the effort of many folks, particularly
Bruce Tonkin, Ram Mohan, and Tim Cole who had specific speaker
suggestions that worked out well.  All of the presentations were
good as was the selection of speakers.

One specific bit of feedback that was received from Maxine Appleby
was that we need to "sharpen" the business proposition.  We should
bring in more people involved in day-to-day operations as opposed to
the developers and technical people we are using now.

  [[ Broad agreement on phone and in jabber room. ]]

We need to improve the business and value benefits story, perhaps by
engaging some marketing folks to draft the "3-page brochure."

Steve proposed looking at the problem in terms of what has to come
together.  There are a handful of implementation environments to
consider, for example:

  large enterprises - typically self sufficient

  outsourced operations - technically competent but do not control
  the software

  probably a few others

There is probably a business case story for each of them.

Andy Osman suggested adding "registrar-in-a-box" versus
"roll-their-own" businesses.  Olaf Kolkman noted that we need
registries to participate.


The various arguments suggesting we "must have" DNSSEC are dubious
at best.  There appear to be only two cases that will ensure such
arguments result in the broad deployment of DNSSEC: either you must
have DNSSEC because a critical application requires it or you have
DNSSEC because there is a "seal of approval" that requires it.

We really need to describe what drives the deployment of DNSSEC in a
compelling way; we need a "killer app."

Allison recalled that Peter Koch had a good "sales pitch" in his
slides: "I want to be ready before DNS is under attack."


Allison reported that Paul Diaz felt that overall the presentations
were still not at the right level for the average person involved.
They are still too technology oriented and not simple enough.  A
related comment is that as long as we keep call this "DNSSEC" it
will always be a technology.  It needs a different name so it is
part of something that is important and is welcoming to people.

    [[ General agreement that it needs a new name but there were not
    suggestions forthcoming. ]]


One case in point regarding deployment, Steve and Andy both spoke
with the registrar-in-a-box folks (DirectI) regarding when they
would include DNSSEC.  The answer was simply that it would be
included as soon as their customers demanded it.  It is worth noting
that these guys are pretty responsive to the priority of their
customers.  They expected they could deploy DNSSEC in at most 2-3
months after their customers started asking for it.


Moving on to a root signing update, Steve Crocker reported that he
is on the hook to do some writing.  ICANN and the US Government have
been discussing what each needs to do, and Steve needs to draft some
process and technical details.

There is still the question of whether to proceed without a key
rollover or to wait for a key rollover.  As a practical matter,
proceeding without it is preferred because there is no key rollover
solution on the horizon.

Hilarie Orman emphasized the point and called the question, "Is key
rollover a gating item for signing the root?"  Russ Mundy did not
think it should be.  Olafur Gudmundsson suggested that it was the
wrong question.  A better question would be to admit that we need a
key rollover mechanism and ask, "When does key rollover need to be
there?"  The point is we do not need it to be ready right away.

Steve believes that we need to get all this working in some kind of
"soft way" so that when we are ready to say it is all working it
really will have been working for some time.

Olafur asked what we need on day 1 and what we need in year 5?  Year
5 may be too far into the future but on day 1 we need to create and
distribute the root key, and the private key needs to be held and
protected by someone in a reasonably secure manner.  It could be in
a "sock drawer" at this point in time.  At some point in the future
we need a vault for the private key with appropriate procedures and
mechanisms in place, broad confidence in the generation and
protection of the private key, and a ribbon cutting ceremony to
announce it all.

Olafur clarified that he is not concerned about key rollover, per
se.  He is concerned that we are using it as a reason to delay
getting started.  Let us just tell people that the first key will
only be valid for 2 years (or whatever is a sensible amount of time)
and get started.

But that suggests we are depending on key rollover; it will have to
come into existence at some point.  On the other hand, it only
matters to the people who use it and that number is likely to be
small.  Well, perhaps small in percentage but it could be quite
large in absolute numbers.

Worse, if the public key is distributed with software and people
start using DNSSEC, they will simply stop using it when it stops
working.  Suzanne Woolf asserted that any scheme that assume people
will upgrade software on any kind of predictable schedule will
fail.  Sam Weiler added that if people are unwilling to update trust
anchors on a schedule they are unlikely to update them in an
emergency, in which case they should not be doing validation nor
should we be encouraging it.


Moving on to performance topics Scott Rose noted that NIST is
reviewing the possibility of repeating the RIPE tests with the .GOV
servers.


Russ Mundy reported for the applications group that a draft API
should be coming out soon.

Jim Galvin added that it was also suggested we deploy DNSSEC at the
next IETF.  It was agreed that there was no action to take until
just after the new year.


Olaf Kolkman still plans to do an NSEC3 workshop but we need a
stable draft first.  So, they are not making any specific plans yet.