Internet DRAFT - draft-guette-ds-generalization
draft-guette-ds-generalization
Network Working Group G. Guette
Internet-Draft IRISA / INRIA
Expires: February 15, 2005 D. Fort
B. Cousin
IRISA / University of Rennes I
August 17, 2004
Generalization of Delegation Signer Resource Record (DS RR) use
draft-guette-ds-generalization-01.txt
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 15, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document generalise the DS RR use in order to reduce the number
of secure entry points in a resolver and in order to create a secure
link between islands of security. This allows to simulate a secure
spanning tree among all secure zones and reduces the number of non
secure name resolutions.
Guette, et al. Expires February 15, 2005 [Page 1]
Internet-Draft DS Generalization August 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The three ways to add a secure zone in the DNS tree . . . . . 3
2.1 The new secure zone is a leaf of an island of security . . 3
2.2 The new secure zone is the new apex of an island of
security . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 The new secure zone is a new island of security . . . . . 4
3. Influence of the three previous topologies on the name
resolution . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 The new secure zone is a leaf of an island of security . . 4
3.2 The new secure zone is the new apex of an island of
security . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.3 The new secure zone is a new island of security . . . . . 4
4. The DS resource record . . . . . . . . . . . . . . . . . . . . 4
4.1 DS RR wire format and its new use . . . . . . . . . . . . 4
5. Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Authentication of a new secure zone and key rollover
problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1 The key rollover problem . . . . . . . . . . . . . . . . . 9
7. Changes on the resolver's resolution algorithm . . . . . . . . 10
8. Pros and cons . . . . . . . . . . . . . . . . . . . . . . . . 10
9. Security considerations . . . . . . . . . . . . . . . . . . . 10
10. Normative References . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 13
Guette, et al. Expires February 15, 2005 [Page 2]
Internet-Draft DS Generalization August 2004
1. Introduction
The DNS security extensions (DNSSEC) [5][2][1][3] uses public-key
cryptography and digital signatures. It stores the public part of
keys in DNSKEY Resource Records (RRs) and signatures in RRSIG RRs.
In order to validate a resource record, a chain of trust is built
from a secure entry point [4] to the RR queried. To allows the build
of a chain of trust, a delegation signer (DS) RR [6] is inserted at a
zone cut (i.e., a delegation point) to indicate that the delegated
zone is digitally signed and that the delegated zone recognizes the
indicated key as a valid zone key for the delegated zone.
Nevertheless, some delegation may remain unsecure and then no DS RR
is stored in the parent zone for this delegation. This implies
islands of security in the DNS tree. From the point of view of
resolvers, secure name resolutions can be performed if and only if
the resolver has a secure entry point and a secure path exists
between this secure entry point and the resource queried (i.e., there
is no unsecure delegation on the path).
In consequence, as a resolver may query any DNS name, a resolver must
have statically configured at least one secure entry point for the
apex of all existing islands of security. This is totally impossible
to manage due to the number of keys needed.
In this document we describe a generalization of DS RR use that
allows to reduce the number of secure entry point configured in the
resolver at the minimum. Section 2 and 3 describe the different
topologies induce by adding a new secure zone and their consequences.
Section 4, 5 and 6 describe the new use of DS RRs and the algorithm
to update/create these DS RRs. Section 7 proposes changes on the
resolver's resolution algorithm and section 8 discusses the pros and
cons of the new use of DS RR.
2. The three ways to add a secure zone in the DNS tree
When a DNS zone deploys DNSSEC, three cases can arise:
o This zone becomes a new leaf of an existing island of security.
o This zone becomes a new apex of at least one existing island of
security.
o This zone becomes a new island of security.
2.1 The new secure zone is a leaf of an island of security
When a DNS zone deploys DNSSEC and becomes a leaf of an existing
island of security, its parent zone must create and deploy the DS RR
for this new secure delegation.
Guette, et al. Expires February 15, 2005 [Page 3]
Internet-Draft DS Generalization August 2004
2.2 The new secure zone is the new apex of an island of security
When a DNS zone deploys DNSSEC and becomes the new apex of an island
of security (i.e., the new zone owns any delegation for an existing
apex of an island of security), the new secure zone must create and
store DS RR for all its secure delegated zones.
2.3 The new secure zone is a new island of security
This topology appears when the new secure zone has no secure parent
and no secure child zone. DS RR for this zone can not be created
because the parent zone is not secure and the new secure zone does
not create DS RR because it does not own any secure delegation.
3. Influence of the three previous topologies on the name resolution
3.1 The new secure zone is a leaf of an island of security
In this case, the new secure zone does not impact on the name
resolution. Either resolvers have already a trust anchor for the
apex of the island of security and the resolver can perform secure
name resolution, or resolvers do not have a trust anchor for the apex
of the island of security and they can not perform a secure name
resolution.
3.2 The new secure zone is the new apex of an island of security
In this case, the apex of the island of security changes and a
resolver that wants to perform secure name resolution about the new
secure zone must have a trust anchor for this new secure zone. Thus,
the new secure zone should publish its public key on various media in
order to notify administrators of resolvers that a new secure zone
exists. A diffusion is needed.
3.3 The new secure zone is a new island of security
The new secure zone is nor a leaf neither an apex of an island of
security, this case is the creation of a new island of security. The
new secure zone has no secure parent and no secure child. This zone
becomes a new apex of an island of security and the diffusion of its
public key is needed.
4. The DS resource record
4.1 DS RR wire format and its new use
All information about the DS wire format can be found in the RFC 3658
[6], the DS RR stores, in the parent zone, some information allowing
Guette, et al. Expires February 15, 2005 [Page 4]
Internet-Draft DS Generalization August 2004
to identify a key of its secure child zone. For example, the zone
"example." has two child zones: "secure.example." which is secure and
"unsecure.example." which is unsecure. Assuming that the zone
"apex.unsecure.example." exists and is secure, the zone "example."
contains at least the following records:
example. SOA <soa stuff>
example. NS ns1.example.
example. DNSKEY <stuff>
example. NSEC secure.example. NS SOA DNSKEY RRSIG NSEC
example. RRSIG(SOA)
example. RRSIG(NS)
example. RRSIG(NSEC)
example. RRSIG(DNSKEY)
secure.example. NS ns1.secure.example.
secure.example. DS tag=12345 alg=3 digest_type=1 <foo>
secure.example. NSEC unsecure.example. NS RRSIG NSEC DS
secure.example. RRSIG(NSEC)
secure.example. RRSIG(DS)
unsecure.example. NS ns1.unsecure.example.
unsecure.example. NSEC example. NS RRSIG NSEC
unsecure.example. RRSIG(NSEC)
There is nothing in the "example." zone file about the secure zone
"apex.unsecure.example.".
In this document, we generalized the use of the DS RR, allowing a
zone that has unsecure delegation(s) to store a DS RR that identifies
a key of the apex of the next island of security in the subdomain of
the unsecure delegation. On the previous example this is:
Guette, et al. Expires February 15, 2005 [Page 5]
Internet-Draft DS Generalization August 2004
example. SOA <soa stuff>
example. NS ns1.example.
example. DNSKEY <stuff>
example. NSEC secure.example. NS SOA DNSKEY RRSIG NSEC
example. RRSIG(SOA)
example. RRSIG(NS)
example. RRSIG(NSEC)
example. RRSIG(DNSKEY)
secure.example. NS ns1.secure.example.
secure.example. DS tag=12345 alg=3 digest_type=1 <foo>
secure.example. NSEC unsecure.example. NS RRSIG NSEC DS
secure.example. RRSIG(NSEC)
secure.example. RRSIG(DS)
unsecure.example. NS ns1.unsecure.example.
unsecure.example. NSEC apex.unsecure.example. NS RRSIG NSEC
unsecure.example. RRSIG(NSEC)
apex.unsecure.example. DS tag=12345 alg=3 digest_type=1 <foo>
apex.unsecure.example. NSEC example. RRSIG NSEC DS
apex.unsecure.example. RRSIG(NSEC)
apex.unsecure.example. RRSIG(DS)
As the zone "unsecure.example." is unsecure, a DS RR identifying the
apex of the next island of security is stored in the "example." zone
file.
Storing DS RR that identifies the apex of the next island of
security, allows to simulate a complete DNSSEC tree containing all
the existing secure DNSSEC zone. As a consequence, the number of
trusted anchors in a resolver is reduced to the upper island(s) of
security keys.
5. Algorithm
In this section, we assume that the generalization of DS RR use is
effective on all islands of security. The problem of authentication
of the new secure zone is discussed in the next section.
When a zone deploys DNSSEC, it firstly creates keys and signs its
zone file and must contact its closest secure ancestor (CSA) in order
to create DS RRs. Then, the CSA creates DS RR for this new secure
zone and must transmit to the new secure zone all the DS RRs
identifying keys of zones contained in the subdomain of the new
secure zone, it owns.
The new secure zone takes the transmitted DS RR and signs them to
create secure delegations. If some of these delegations are already
present in the new secure zone, this means that the new secure zone
has become an apex of another island of security.
Guette, et al. Expires February 15, 2005 [Page 6]
Internet-Draft DS Generalization August 2004
Assuming the following tree with the secure zones "a", "b.a",
"f.e.c.a", "g.e.c.a":
+--------a--------+
| |
| |
b.a +----c.a----+
| |
| |
d.c.a +----e.c.a----+
| |
| |
f.e.c.a g.e.c.a
Zone "a." contains at least the following records:
a. SOA <soa stuff>
a. NS ns1.a.
a. DNSKEY <stuff>
a. NSEC b.a. NS SOA DNSKEY RRSIG NSEC
a. RRSIG(SOA)
a. RRSIG(NS)
a. RRSIG(NSEC)
a. RRSIG(DNSKEY)
b.a. NS ns1.b.a.
b.a. DS tag=12345 alg=3 digest_type=1 <foo>
b.a. NSEC c.a. NS RRSIG NSEC DS
b.a. RRSIG(NSEC)
b.a. RRSIG(DS)
c.a. NS ns1.c.a.
c.a. NSEC f.e.c.a. NS RRSIG NSEC
c.a. RRSIG(NSEC)
f.e.c.a. DS tag=12345 alg=3 digest_type=1 <foo>
f.e.c.a. NSEC g.e.c.a. RRSIG NSEC DS
f.e.c.a. RRSIG(NSEC)
f.e.c.a. RRSIG(DS)
g.e.c.a. DS tag=12345 alg=3 digest_type=1 <foo>
g.e.c.a. NSEC a. RRSIG NSEC DS
g.e.c.a. RRSIG(NSEC)
g.e.c.a. RRSIG(DS)
Zone "e.c.a." contains at least the following records:
Guette, et al. Expires February 15, 2005 [Page 7]
Internet-Draft DS Generalization August 2004
e.c.a. SOA <soa stuff>
e.c.a. NS ns1.e.c.a.
f.e.c.a. NS ns1.f.e.c.a.
g.e.c.a. NS ns1.g.e.c.a.
When the zone "e.c.a." becomes secure, the previous zone file
becomes:
a. SOA <soa stuff>
a. NS ns.a.
a. DNSKEY <stuff>
a. NSEC b.a. NS SOA DNSKEY RRSIG NSEC
a. RRSIG(SOA)
a. RRSIG(NS)
a. RRSIG(NSEC)
a. RRSIG(DNSKEY)
b.a. NS ns1.b.a.
b.a. DS tag=12345 alg=3 digest_type=1 <foo>
b.a. NSEC c.a. NS RRSIG NSEC DS
b.a. RRSIG(NSEC)
b.a. RRSIG(DS)
c.a. NS ns1.c.a.
c.a. NSEC e.c.a. NS RRSIG NSEC
c.a. RRSIG(NSEC)
e.c.a. DS tag=12345 alg=3 digest_type=1 <foo>
e.c.a. NSEC a. NS RRSIG NSEC DS
e.c.a. RRSIG(NSEC)
e.c.a. RRSIG(DS)
and:
Guette, et al. Expires February 15, 2005 [Page 8]
Internet-Draft DS Generalization August 2004
e.c.a. SOA <soa stuff>
e.c.a. NS ns1.e.c.a.
e.c.a. DNSKEY <stuff>
e.c.a. NSEC f.e.c.a. NS SOA DNSKEY RRSIG NSEC
e.c.a. RRSIG(SOA)
e.c.a. RRSIG(NS)
e.c.a. RRSIG(NSEC)
e.c.a. RRSIG(DNSKEY)
f.e.c.a. NS ns1.f.e.c.a.
f.e.c.a. DS tag=12345 alg=3 digest_type=1 <foo>
f.e.c.a. NSEC g.e.c.a. NS RRSIG NSEC DS
f.e.c.a. RRSIG(NSEC)
f.e.c.a. RRSIG(DS)
g.e.c.a. NS ns1.g.e.c.a.
g.e.c.a. DS tag=12345 alg=3 digest_type=1 <foo>
g.e.c.a. NSEC e.c.a. NS RRSIG NSEC DS
g.e.c.a. RRSIG(NSEC)
g.e.c.a. RRSIG(DS)
A secure zone 'X' can store DS RR identifying a key of a non directly
delegated zone 'Y' only if it does not exist a secure zone on the
path between 'X' and 'Y'.
6. Authentication of a new secure zone and key rollover problem
Authentication of a new secure zone is reduced to a DNSSEC bootstrap
problem. When a zone becomes secure with DNSSEC there is no in-band
way to authentify the key of this new zone. Authentication of the
new secure zone, keys of the new secure zone and owner of the new
secure zone must be done by the parent zone administrator with
another method (X.509 certificates, phone call, meeting, etc.).
The generalization of DS RR use implies the generalization of this
authentication. In all cases, the new secure zone must contact its
CSA and the authentication of the new secure zone must be done by the
CSA. Once the authentication is complete, the CSA can create DS
RR(s) for the new secure zone.
6.1 The key rollover problem
At the present time, when a zone creates a new KSK and has a secure
parent zone, the parent zone must create appropriated DS RR(s). If
its parent zone is not secured, no DS is needed.
The generalization of DS RR use implies that a secure link exists
Guette, et al. Expires February 15, 2005 [Page 9]
Internet-Draft DS Generalization August 2004
between islands of security and their closest secure ancestor. Thus,
when a zone creates a new KSK, this zone must notify its closest
secure ancestor. If the zone is inside an island of security (not
the apex), the CSA is its parent zone.
If a secure zone has no CSA, no DS can be created for this secure
zone and no action is needed. This is the case for the root zone.
7. Changes on the resolver's resolution algorithm
Currently, a resolver begins a name resolution from a secure entry
point and follows the delegations to the resource queried. If there
is an unsecured delegation on the path the name resolution is
unsecured.
With the generalization of DS RR use, this case does not exit
anymore. A resolver follows the delegations, if a delegation is
unsecure the resolver continues until the next secure zone is found.
Then, the resolver asks for a DS RR for this zone, the DS RR is
stored in the CSA, the resolver validates the key with this DS and
continues the name resolution until to find the RR queried.
8. Pros and cons
With the generalization of DS RR use, the number of trusted anchors
needed in a single resolver to perform secure name resolution on the
whole DNS tree are largely reduced. Only a secure entry point for
the apex of the highest islands of security for each branch of the
DNS tree are needed. In the best case, if the root zone is secured,
only the root zone key is needed.
Moreover, the generalization of DS RR use ensures that if a resource
record is in a secure zone in a given island of security, all
resolvers can verify the signature of this record.
The generalization of DS RR use implies that zones that have
unsecured delegation stores additional DS resource records for the
apex of the next island of security in the subdomain. In the worst
case, the number of additionnal records for a zone 'A' is equal to
the number of leaves in the domain 'A'.
9. Security considerations
This document describes a generalization of DS RR use. This
generalization ensures that all signatures of resource records
contained in a secure zone can be verified if the resolver trusts
only the apex of the highest island of security. If the root zone is
secured, only the root zone key is needed.
Guette, et al. Expires February 15, 2005 [Page 10]
Internet-Draft DS Generalization August 2004
10 Normative References
[1] Arends, R., "Resource Records for the DNS Security Extensions",
July 2004.
[2] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
"DNS Security Introduction and Requirements", July 2004.
[3] Arends, R., "Protocol Modifications for the DNS Security
Extensions", July 2004.
[4] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
(DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
RFC 3757, May 2004.
[5] Eastlake, D., "Domain Name System Security Extensions", March
1999.
[6] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
December 2003.
Authors' Addresses
Gilles Guette
IRISA / INRIA
Campus de Beaulieu
35042 Rennes CEDEX
FR
EMail: gilles.guette@irisa.fr
URI: http://www.irisa.fr
David Fort
IRISA / University of Rennes I
Campus de Beaulieu
35042 Rennes CEDEX
FR
EMail: david.fort@irisa.fr
URI: http://www.irisa.fr
Guette, et al. Expires February 15, 2005 [Page 11]
Internet-Draft DS Generalization August 2004
Bernard Cousin
IRISA / University of Rennes I
Campus de Beaulieu
35042 RENNES CEDEX
FR
EMail: bernard.cousin@irisa.fr
URI: http://www.irisa.fr
Guette, et al. Expires February 15, 2005 [Page 12]
Internet-Draft DS Generalization August 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
Guette, et al. Expires February 15, 2005 [Page 13]
Internet-Draft DS Generalization August 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Guette, et al. Expires February 15, 2005 [Page 14]
