DNSSEC deployment at the Root.

IAB Chair <iab-chair@ietf.org> Tue, 18 November 2008 17:43 UTC

Return-Path: <ietf-announce-bounces@ietf.org>
X-Original-To: ietf-announce-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-announce-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E0B63A6AB7; Tue, 18 Nov 2008 09:43:28 -0800 (PST)
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 30) id CF1133A6A24; Tue, 18 Nov 2008 09:43:27 -0800 (PST)
From: IAB Chair <iab-chair@ietf.org>
To: IETF Announcement list <ietf-announce@ietf.org>
Subject: DNSSEC deployment at the Root.
Mime-Version: 1.0
Message-Id: <20081118174327.CF1133A6A24@core3.amsl.com>
Date: Tue, 18 Nov 2008 09:43:27 -0800
Cc: IAB@iab.org
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/pipermail/ietf-announce>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ietf-announce-bounces@ietf.org
Errors-To: ietf-announce-bounces@ietf.org




Dear Ms. Alexander,


The IAB appreciates the assistance of NTIA, or any other organization,
in the rapid deployment of DNSSEC.  Hence, we are happy to provide our
feedback to the Notice of Inquiry regarding "Enhancing the Security
and Stability of the Internet's Domain Name And Addressing System" as
published in the Federal Register Vol 73, No 197, d.d. October 9,
2008.

This reply contains a number of observations and statements related to
the questions posed in the inquiry.


=== Expedient deployment of DNSSEC at the Root.===

When people use any Internet service, it almost always involves one or
more DNS lookups. The base DNS is vulnerable to data corruption and
data replacement. DNSSEC is the only standards-track mechanism to
prevent corruption and replacement of the DNS data on its path through
the Internet. As such, DNSSEC is one of the mechanisms needed to
maintain, or even improve, the level of trust with which people use
the Internet.

While the administrators of DNS zones must follow certain technical
standards so that the overall system works, they also maintain a
striking degree of policy autonomy. DSNSSEC has been designed to
respect that.  At the same time, the DNS, in itself, is technically
and operationally hierarchical, and there are many advantages in
aligning the DNSSEC chains of trust with that hierarchy, not least of
which is the global trust that can come from the general acceptance of
a single trust anchor.  In other words, because of the inherently
hierarchical nature of the DNS, the DNSSEC protocol can only be used
efficiently when the protocol is deployed at the root of the DNS
hierarchy. Expedient deployment of DNSSEC in the root zone is expected
to boost the global deployment of DNSSEC. In that same spirit, and
with a reference to appendix A of RFC3172, the IAB is working with
IANA to get the .ARPA zone signed.


=== Trust in the System, Confidence, and DNSSEC.===

Consumers of DNS data actively put their trust in the root DNS
registry through the configuration of root DNS servers that make that
data available. The introduction of DNSSEC provides confidence that
DNS data is not modified while it travels between servers and
consumers. Adding DNSSEC should not change the trust in the domain
name system as a whole, nor in the institutions involved with the
management thereof.

To expand on this point:

The consumers of DNS data are typically the devices of the end-users
e.g. their PCs or smartphones. Those devices send DNS queries to
network components called Recursive Nameservers. These Recursive
Nameservers are typically deployed by operators of IP networks such as
Internet service providers, network services groups within companies,
and sometimes even by individual end-users.

While we do not know the exact number of Recursive Nameservers
deployed in the Internet, estimates place their number well into the
millions. These Recursive Nameservers need to be configured by their
system administrators with the IP addresses of the DNS servers that
make the root of the namespace available: the DNS root-servers. It is
possible for administrators to configure a set of IP addresses for
root-servers that, in fact, do not serve the namespace as administered
by IANA.  This would cause all sorts of issues detrimental to the
stability and security of the Internet, as described in "IAB Technical
Comment on the Unique DNS Root" [RFC2628].  The fact that an
overwhelming majority of Recursive Nameservers point to the DNS
root-servers that serve the root as maintained by the IANA registry is
an indication that the system is trusted by the end-users: Their
experience has been that the institutions involved in the management
of the DNS (the registry and nameserver operators) have provided
domain name mappings that are coherent, stable, and as expected.  With
the introduction of DNSSEC the operators of Recursive Nameservers have
to, in order for validation to occur, configure a public key that
corresponds with the "Key-signing key"(KSK) with which the mapping as
maintained by the registry is signed. This public key is tied to
namespace in much the same way as the IP addresses of the root-servers
are tied to the namespace. That is, trust in the DNS root-servers
depends on administrator configuration, and DNSSEC simply includes a
new parameter to the configuration. Configuration is more likely to
happen if key custodianship is aligned with DNS registry maintenance
in such a way that DNSSEC deployment does not become an issue of
control and ownership but remains a matter of data-integrity and
authenticity.

=== Process flow===


We acknowledge that introducing DNSSEC in a zone without proper
planning and care can involve a new degree of complexity and thereby
bring the risk of parts of the system becoming more fragile. However
this is normal with any new technology and experience is already being
gained with zones which are significantly bigger than the root
zone. However, some of the proposals in the notice of inquiry involve
data travelling around the system and introduce more parties than are
currently involved in the root-zone generation. Initial experience
with DNSSEC operations has indicated that zone-generation and
zone-signing are two functions that are best performed by the same
party, avoiding the need for unsigned zone or key data to change
hands, or the introduction of another security mechanism to protect
the yet-to-be signed zone or key data as it changes hands.

It should also be noted that during initial deployment the number of
customers of DNSSEC data will be relatively small. Because of that the
stakes are relatively low, and the design of the system allows for
relatively simple procedures. These considerations allow for
flexibility, and should be taken into account when designing the key
generation procedures, the storage mechanisms, and disaster recovery
protocols

=== Rolling of the DNSSEC Key Signing Key ===

DNSSEC has been designed with the notion that keys used in the process
are replaced once in a while for security reasons. The deployment of
DNSSEC at the root should take this into account. These key rollovers
should take place regularly so that a clear expectation is built for
the administrators of Recursive Nameservers. A key rollover policy
should be developed and discussed in an appropriate open forum. The
development of that policy does not need to block deployment as long
as it is clear that a KSK rollover will occur.


A system where the change of the KSK custodian does not necessarily
need to result in a roll of the key has preference

=== Summary===

The IAB expects expedient and successful deployment of DNSSEC if the
following points are taken into account:

* Care should be taken that DNSSEC deployment remains about data,
  integrity, and authenticity, and not about control.

* The implementation of DNSSEC in the root can and should align with
  the functions involved in the root-zone maintenance, generation and
  audit. The implementation of DNSSEC, however, need not today nor for
  the foreseeable future be cause to permanently fix the roles
  involved.

* After the main policy decisions have been made, further details
  about the implementation, such as key rollover, in particular the
  rollover of the root "key signing key" pair (KSK-pair), and possible
  key custodianship, should be decided upon within the context of the
  multi-stakeholder process, as currently embodied in ICANN. This
  would ensure involvement of all stakeholders through well
  established mechanisms.

* Regular key rollover should always be part of normal operational
  practice. A key rollover policy for the root should be discussed and
  developed in an appropriate open forum.

* Simplicity of the system should be a design criterion. Aligning zone
  generation and zone signing is one example of such design choice.

The IAB will be happy to answer any further questions you may have.


For the IAB

--Olaf Kolkman
  IAB Chair 



About the IAB

The Internet Architecture Board has a long history but is currently
viewed as a senior committee in the IETF which has both technical
(architectural) functions and oversight functions for the development
of the Internet. The latter include oversight of IANA functions
performed for the IETF. See http://www.iab.org/.
_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce