meeting summary: 14 July 2004

[James M Galvin]

DNSSEC Deployment
14 July 2004


PRESENT:
    Steve Crocker
    Jim Galvin

    Amy Friedlander
    Doug Montgomery
    Jaap Akkerhuis
    Mark Kosters
    Mike St. Johns
    Roy Arends
    Rob Austein
    Rick Wesson
    Russ Mundy
    Scott Rose
    Steven Chueng
    Suresh Krishnaswamy
    Tom McGary


REGRETS:
    Bill Manning
    Doug Barton
    Olafur Gudmundsson
    Ralph Droms


ACTIONS

    Mike St.Johns to write-up description of denial-of-service attack on
    insecure zones in the presence of "piece meal" deployment of DNSSEC.

    Everyone to review the deployment roadmap and send comments to the
    mailing list.

    Steve Crocker and team to continue work on the deployment roadmap.


SUMMARY

  -- DNSSEC Deployment Roadmap

     Steve Crocker, Russ Mundy, and team have been meeting and
     progressing the document.  A version will be distributed for
     discussion at the next meeting.

Steve Crocker described the document as a compendium of the pieces
needed for success as well as the open issues.  The next two things we
need are the roadmap and the "marketing plan".

The "marketing plan" is needed not because we can necessarily make it
happen but so we can track what is happening.  The adoption of DNSSEC
depends on its acceptance and deployment by service providers, vendors,
and IANA (who signs the root zone).  We can layout the natural sequence
of events and track what happens.

The purpose of the roadmap is to fit the pieces and issues together and
then track their progress.


Steve declared Tom McGarry a focus group of one and asked him, in his
role as the registry operator for .US, to indicate what he would need to
make DNSSEC a realistic proposition for him to deploy.

At a high-level, Tom asked for answers to the following.

    What do we need to do to deploy it?

    What do we need to do to support our registrars and customers?

    What do we need from the root zone operators?

    What testing should we do to ensure we are not "harmed" in a way we
    do not expect?

    What do we need to ensure our ongoing maintenance continues as it
    does today?

Russ Mundy asked Tom if he knew what the benefit versus the cost of
operating the .US zone as a signed zone would be.  Tom responded it was
too early to know; they are just getting started in their analysis.

When asked if their considerations were focused more on a business point
of view versus enhancing robustness in general, Tom responded there is
not any one driver.  The obvious "new service", "good for the network",
etc., all apply.

Russ followed up asking if he knew what he needed to convince folks in
general that DNSSEC is a good thing.  Tom jokingly suggested lost of
man-in-the-middle attacks would help.

More seriously, something the consumer sees would be invaluable for
registrars.  As a registry that helps him indirectly, but he needs
something that would be a visible value to registrars.


Steve asked for a description of the interaction that was necessary
between a registrar and a registrant in order to sign a zone.  Rob
Austein noted that the registry can sign its own zone but without the
public key of the registrant it can not sign the registrant's
delegation.

Mark Kosters noted that one point that surfaced during the last
deployment workship is that a child may want to set the signature
lifetime on the DS record.  Although not resolved there was a sense that
if the option is offered it should be optional, not required.  Rob
agreed that in general there needs to be a communication path for a
child to convey any wishes they may have.


Steve asked how a registrant gets their keys uploaded in the first
place?  Rob indicated that the model is you piggyback on top of existing
relationships and processes.

When challenged on whether that is a policy statement it was emphasized
that it is a business statement.  A significant issue is that there is
no standard method nor much uniformity in the way this is done today.
It would be problematic at the very least to suggest doing anything else
and, in fact, would probably wreak havoc.  Most of the non-trivial
registrant interaction is in dealing with the trust relationship.  The
closest thing to standardization in this problem space that can and is
happening today is the XML-based work in EPP.


Steve asked what interactions are necessary when a registrant wants to
move their zone server?  Here again, there are no standards.  You would
work with the "ad hoc" web interface of your registrar.

The keys themselves are almost all communicated using https:// and
copy-and-paste.  There is some potential for some cheap tools that could
do this but why bother?  To do so would add a deployment problem because
of the new tool and frankly virtually everyone already has an https://
application on their desktop.  There would have to be a significantly
compelling reason to do anything different.

Jaap Akkerhuis pointed out that the problem space here is about
bootstrapping DNSSEC given existing relationships.  Russ proposed that
as principle we should state that getting many of things we need can be
done with extensions of existing operations and we should encourage
that.  Jaap noted that that was one of the conclusions of the .NL test.
However, we still have to be careful to be building on a good
foundation.

If a registrar is currently completing its transactions with plaintext
passwords in email that is not a good foundation.  Rick Wesson suggested
we propose a minimum set of requirements for registrars before they
deploy DNSSEC.  Tom cautioned that the bar needs to be relatively low
and Rob added that that's why it will be https://, because it's already
on everybody's desktop.


Steve wondered out loud why we don't let weak-on-the-inside-security
continue to exist?  The issue is that if you say you can not add
security until you have bolstered the rest of the system then you risk
creating a substantial barrier to the initial deployment.

Jaap noted that in the .NL test, whenever there was a problem with a
zone they immediately dropped "back' to declaring the zone verifiably
insecure.

Rob added the real problem is when there are lots of registrars because
then you need minimum standards.  Otherwise it brings down the
credibility of all registrars and by extension the zone as a whole.

Mike St. Johns pointed out that you can add security individually as
registrants, registrars, and registries are ready because you risk a
denial-of-service of the insecure zones.  If a "bad guy" can insert a
key for a child then that zone can be "deleted."  Mike agreed to provide
a more complete write-up of this for the mailing list.


Rick asked which "credential" is the most trusted one?  A registrar has
a set of information about a registrant of which one is the key, but
there is also an auth-code and contact information.  Suppose one piece
of that information is lost and must be replaced.  Which "credential" is
to be trusted more as part of replacing that information?

The discussion noted that the question can not be answered in the
abstract.  Each of the steps and interactions between the registrant,
registrar, and registry need to have some "level of trust."  Each step
will have its own security issues.  DNSSEC will "fix" some issues but
certainly not all.  All parties need to be educated about that trust and
what it provides and does not provide.


Mike St. Johns brought up the issue he raised on the mailing list.  The
document currently states:

    The goal for global DNSSEC deployment can be stated as follows:

    "Every lookup request requires and receives only DNSSEC-validated
    answers, and the process works efficiently."

He proposed instead:

    "Every lookup request that asks for DNSSEC-validated answers gets
    them, and the process works efficiently and without adverse impact
    on the DNS system as a whole."

His point is that the goal is not universal queries, but universal
availability of the responses.  We need the ability to have every
request validated, not to validate every request.

The consensus of the participants was to agree on the intent.