mir/bind
2
0
Fork 0
mirror of https://gitlab.isc.org/isc-projects/bind9 synced 2025-08-31 14:35:26 +00:00
Code Issues Releases Wiki Activity

new draft

Browse Source
This commit is contained in:
Mark Andrews
2005-02-24 03:22:23 +00:00
parent c2a5a4a3cf
commit 4f7f21e50d
21 changed files with 8969 additions and 5332 deletions
Download Patch File Download Diff File Expand all files Collapse all files

91
doc/draft/draft-ietf-dnsext-dhcid-rr-08.txt → doc/draft/draft-ietf-dnsext-dhcid-rr-09.txt
View File

@@ -1,20 +1,22 @@
DNSEXT M. Stapp DNSEXT M. Stapp
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco Systems, Inc.
Expires: January 14, 2005 T. Lemon Expires: August 13, 2005 T. Lemon
A. Gustafsson A. Gustafsson
Nominum, Inc. Nominum, Inc.
July 16, 2004 February 9, 2005
A DNS RR for Encoding DHCP Information (DHCID RR) A DNS RR for Encoding DHCP Information (DHCID RR)
<draft-ietf-dnsext-dhcid-rr-08.txt> <draft-ietf-dnsext-dhcid-rr-09.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
@@ -30,17 +32,17 @@ Status of this Memo
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 14, 2005. This Internet-Draft will expire on August 13, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005).
Abstract Abstract
@@ -48,15 +50,15 @@ Abstract
same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or same DNS FQDN as they obtain DHCP leases. Whether the DHCP server or
the clients themselves perform the DNS updates, conflicts can arise. the clients themselves perform the DNS updates, conflicts can arise.
To resolve such conflicts, "Resolution of DNS Name Conflicts" [1] To resolve such conflicts, "Resolution of DNS Name Conflicts" [1]
proposes storing client identifiers in the DNS to unambiguously
Stapp, et al. Expires January 14, 2005 [Page 1] Stapp, et al. Expires August 13, 2005 [Page 1]
Internet-Draft The DHCID RR July 2004 Internet-Draft The DHCID RR February 2005
proposes storing client identifiers in the DNS to unambiguously
associate domain names with the DHCP clients to which they refer. associate domain names with the DHCP clients to which they refer.
This memo defines a distinct RR type for this purpose for use by DHCP This memo defines a distinct RR type for this purpose for use by DHCP
clients and servers, the "DHCID" RR. clients and servers, the "DHCID" RR.
@@ -79,8 +81,8 @@ Table of Contents
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 8 9.1 Normative References . . . . . . . . . . . . . . . . . . . 8
9.2 Informative References . . . . . . . . . . . . . . . . . . . 8 9.2 Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . 10
@@ -107,10 +109,9 @@ Table of Contents
Stapp, et al. Expires August 13, 2005 [Page 2]
Stapp, et al. Expires January 14, 2005 [Page 2]
Internet-Draft The DHCID RR July 2004 Internet-Draft The DHCID RR February 2005
1. Terminology 1. Terminology
@@ -164,9 +165,9 @@ Internet-Draft The DHCID RR July 2004
Stapp, et al. Expires January 14, 2005 [Page 3] Stapp, et al. Expires August 13, 2005 [Page 3]
Internet-Draft The DHCID RR July 2004 Internet-Draft The DHCID RR February 2005
3.1 DHCID RDATA format 3.1 DHCID RDATA format
@@ -220,9 +221,9 @@ Internet-Draft The DHCID RR July 2004
Stapp, et al. Expires January 14, 2005 [Page 4] Stapp, et al. Expires August 13, 2005 [Page 4]
Internet-Draft The DHCID RR July 2004 Internet-Draft The DHCID RR February 2005
some variable-length identifying data. some variable-length identifying data.
@@ -276,9 +277,9 @@ Internet-Draft The DHCID RR July 2004
Stapp, et al. Expires January 14, 2005 [Page 5] Stapp, et al. Expires August 13, 2005 [Page 5]
Internet-Draft The DHCID RR July 2004 Internet-Draft The DHCID RR February 2005
3.5.1 Example 1 3.5.1 Example 1
@@ -289,8 +290,8 @@ Internet-Draft The DHCID RR July 2004
the client. The DHCID RDATA is composed by setting the two type the client. The DHCID RDATA is composed by setting the two type
bytes to zero, and performing an MD5 hash computation across a buffer bytes to zero, and performing an MD5 hash computation across a buffer
containing the Ethernet MAC type byte, 0x01, the six bytes of MAC containing the Ethernet MAC type byte, 0x01, the six bytes of MAC
address, and the domain name (represented as specified in Section address, and the domain name (represented as specified in
3.4). Section 3.4).
client.example.com. A 10.0.0.1 client.example.com. A 10.0.0.1
client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU client.example.com. DHCID AAAUMru0ZM5OK/PdVAJgZ/HU
@@ -305,8 +306,8 @@ Internet-Draft The DHCID RR July 2004
data as input in forming a DHCID RR. The DHCID RDATA is formed by data as input in forming a DHCID RR. The DHCID RDATA is formed by
setting the two type bytes to the value 0x0001, and performing an MD5 setting the two type bytes to the value 0x0001, and performing an MD5
hash computation across a buffer containing the seven bytes from the hash computation across a buffer containing the seven bytes from the
client-id option and the FQDN (represented as specified in Section client-id option and the FQDN (represented as specified in
3.4). Section 3.4).
chi.example.com. A 10.0.12.99 chi.example.com. A 10.0.12.99
chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012 chi.example.com. DHCID AAHdd5jiQ3kEjANDm82cbObk\012
@@ -332,9 +333,9 @@ Internet-Draft The DHCID RR July 2004
Stapp, et al. Expires January 14, 2005 [Page 6] Stapp, et al. Expires August 13, 2005 [Page 6]
Internet-Draft The DHCID RR July 2004 Internet-Draft The DHCID RR February 2005
that the client desires to use to compute a client identity hash, and that the client desires to use to compute a client identity hash, and
@@ -388,9 +389,9 @@ Internet-Draft The DHCID RR July 2004
Stapp, et al. Expires January 14, 2005 [Page 7] Stapp, et al. Expires August 13, 2005 [Page 7]
Internet-Draft The DHCID RR July 2004 Internet-Draft The DHCID RR February 2005
9. References 9. References
@@ -403,8 +404,8 @@ Internet-Draft The DHCID RR July 2004
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[3] Mockapetris, P., "Domain names - concepts and facilities", STD [3] Mockapetris, P., "Domain names - concepts and facilities",
13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[4] Mockapetris, P., "Domain names - implementation and [4] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
@@ -420,8 +421,8 @@ Internet-Draft The DHCID RR July 2004
[7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[8] Eastlake, D., "Domain Name System Security Extensions", RFC [8] Eastlake, D., "Domain Name System Security Extensions",
2535, March 1999. RFC 2535, March 1999.
[9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [9] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
@@ -431,8 +432,8 @@ Internet-Draft The DHCID RR July 2004
(DHCPv6)", RFC 3315, July 2003. (DHCPv6)", RFC 3315, July 2003.
[11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington, [11] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC "Secret Key Transaction Authentication for DNS (TSIG)",
2845, May 2000. RFC 2845, May 2000.
[12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers [12] Lemon, T. and B. Sommerfeld, "Node-Specific Client Identifiers
for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004. for DHCPv4 (draft-ietf-dhc-3315id-for-v4-*)", February 2004.
@@ -444,9 +445,9 @@ Internet-Draft The DHCID RR July 2004
Stapp, et al. Expires January 14, 2005 [Page 8] Stapp, et al. Expires August 13, 2005 [Page 8]
Internet-Draft The DHCID RR July 2004 Internet-Draft The DHCID RR February 2005
Authors' Addresses Authors' Addresses
@@ -458,7 +459,7 @@ Authors' Addresses
USA USA
Phone: 978.936.1535 Phone: 978.936.1535
EMail: mjs@cisco.com Email: mjs@cisco.com
Ted Lemon Ted Lemon
@@ -467,7 +468,7 @@ Authors' Addresses
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
EMail: mellon@nominum.com Email: mellon@nominum.com
Andreas Gustafsson Andreas Gustafsson
@@ -476,7 +477,7 @@ Authors' Addresses
Redwood City, CA 94063 Redwood City, CA 94063
USA USA
EMail: gson@nominum.com Email: gson@nominum.com
@@ -500,9 +501,9 @@ Authors' Addresses
Stapp, et al. Expires January 14, 2005 [Page 9] Stapp, et al. Expires August 13, 2005 [Page 9]
Internet-Draft The DHCID RR July 2004 Internet-Draft The DHCID RR February 2005
Intellectual Property Statement Intellectual Property Statement
@@ -543,7 +544,7 @@ Disclaimer of Validity
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
@@ -556,6 +557,6 @@ Acknowledgment
Stapp, et al. Expires January 14, 2005 [Page 10] Stapp, et al. Expires August 13, 2005 [Page 10]

841
doc/draft/draft-ietf-dnsext-dnssec-experiments-00.txt Normal file
View File

@@ -0,0 +1,841 @@
Network Working Group D. Blacka
Internet-Draft Verisign, Inc.
Expires: August 3, 2005 February 2, 2005
DNSSEC Experiments
draft-ietf-dnsext-dnssec-experiments-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she 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 August 3, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
In the long history of the development of the DNS security [1]
extensions (DNSSEC), a number of alternate methodologies and
modifications have been proposed and rejected for practical, rather
than strictly technical, reasons. There is a desire to be able to
experiment with these alternate methods in the public DNS. This
document describes a methodology for deploying alternate,
non-backwards-compatible, DNSSEC methodologies in an experimental
fashion without disrupting the deployment of standard DNSSEC.
Blacka Expires August 3, 2005 [Page 1]
Internet-Draft DNSSEC Experiments February 2005
Table of Contents
1. Definitions and Terminology . . . . . . . . . . . . . . . . 3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Defining an Experiment . . . . . . . . . . . . . . . . . . . 8
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . 9
7. Transitions . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . 11
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 12
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1 Normative References . . . . . . . . . . . . . . . . . . . 13
10.2 Informative References . . . . . . . . . . . . . . . . . . 13
Editorial Comments . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . 15
Blacka Expires August 3, 2005 [Page 2]
Internet-Draft DNSSEC Experiments February 2005
1. Definitions and Terminology
Throughout this document, familiarity with the DNS system (RFC 1035
[4]) and the DNS security extensions ([1], [2], and [3].
The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [5].
Blacka Expires August 3, 2005 [Page 3]
Internet-Draft DNSSEC Experiments February 2005
2. Overview
Historically, experimentation with DNSSEC alternatives has been a
problematic endeavor. There has typically been a desire to both
introduce non-backwards-compatible changes to DNSSEC, and to try
these changes on real zones in the public DNS. This creates a
problem when the change to DNSSEC would make all or part of the zone
using those changes appear bogus or otherwise broken to existing
DNSSEC-aware resolvers.
This document describes a standard methodology for setting up public
DNSSEC experiments. This methodology addresses the issue of
co-existence with standard DNSSEC and DNS by using unknown algorithm
identifiers to hide the experimental DNSSEC protocol modifications
from standard DNSSEC-aware resolvers.
Blacka Expires August 3, 2005 [Page 4]
Internet-Draft DNSSEC Experiments February 2005
3. Experiments
When discussing DNSSEC experiments, it is necessary to classify these
experiments into two broad categories:
Backwards-Compatible: describes experimental changes that, while not
strictly adhering to the DNSSEC standard, are nonetheless
interoperable with clients and server that do implement the DNSSEC
standard.
Non-Backwards-Compatible: describes experiments that would cause a
standard DNSSEC-aware resolver to (incorrectly) determine that all
or part of a zone is bogus, or to otherwise not interoperable with
standard DNSSEC clients and servers.
Not included in these terms are experiments with the core DNS
protocol itself.
The methodology described in this document is not necessary for
backwards-compatible experiments, although it certainly could be used
if desired.
Note that, in essence, this metholodolgy would also be used to
introduce a new DNSSEC algorithm, independently from any DNSSEC
experimental protocol change.
Blacka Expires August 3, 2005 [Page 5]
Internet-Draft DNSSEC Experiments February 2005
4. Method
The core of the methodology is the use of only "unknown" algorithms
to sign the experimental zone, and more importantly, having only
unknown algorithm DS records for the delegation to the zone at the
parent.
This technique works because of the way DNSSEC-compliant validators
are expected to work in the presence of a DS set with only unknown
algorithms. From [3], Section 5.2:
If the validator does not support any of the algorithms listed in
an authenticated DS RRset, then the resolver has no supported
authentication path leading from the parent to the child. The
resolver should treat this case as it would the case of an
authenticated NSEC RRset proving that no DS RRset exists, as
described above.
And further:
If the resolver does not support any of the algorithms listed in
an authenticated DS RRset, then the resolver will not be able to
verify the authentication path to the child zone. In this case,
the resolver SHOULD treat the child zone as if it were unsigned.
While this behavior isn't strictly mandatory (as marked by MUST), it
is unlikely that a validator would not implement the behavior, or,
more to the point, it will not violate this behavior in an unsafe way
(see below (Section 6).)
Because we are talking about experiments, it is recommended that
private algorithm numbers be used (see [2], appendix A.1.1
[Comment.1].) Normally, instead of actually inventing new signing
algorithms, the recommended path is to create alternate algorithm
identifiers that are aliases for the existing, known algorithms.
While, strictly speaking, it is only necessary to create an alternate
identifier for the mandatory algorithms (currently, this is only
algorithm 5, RSASHA1), it is RECOMMENDED that all OPTIONAL defined
algorithms be aliased as well.
It is RECOMMENDED that for a particular DNSSEC experiment, a
particular domain name base is chosen for all new algorithms, then
the algorithm number (or name) is prepended to it. For example, for
experiment A, the base name of "dnssec-experiment-a.example.com" is
chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
defined to be "3.dnssec-experiment-a.example.com" and
"5.dnssec-experiment-a.example.com". However, any unique identifier
will suffice.
Blacka Expires August 3, 2005 [Page 6]
Internet-Draft DNSSEC Experiments February 2005
Using this method, resolvers (or, more specificially, DNSSEC
validators) essentially indicate their ability to understand the
DNSSEC experiment's semantics by understanding what the new algorithm
identifiers signify.
This method creates two classes of DNSSEC-aware servers and
resolvers: servers and resolvers that are aware of the experiment
(and thus recognize the experiments algorithm identifiers and
experimental semantics), and servers and resolvers that are unware of
the experiment.
Blacka Expires August 3, 2005 [Page 7]
Internet-Draft DNSSEC Experiments February 2005
5. Defining an Experiment
The DNSSEC experiment must define the particular set of (previously
unknown) algorithms that identify the experiment, and define what
each unknown algorithm identifier means. Typically, unless the
experiment is actually experimenting with a new DNSSEC algorithm,
this will be a mapping of private algorithm identifiers to existing,
known algorithms.
Typically, the experiment will choose a DNS name as the algorithm
identifier base. This DNS name SHOULD be under the control of the
authors of the experiment. Then the experiment will define a mapping
between known mandatory and optional algorithms into this private
algorithm identifier space. Alternately, the experiment MAY use the
OID private algorithm space instead (using algorithm number 254), or
may choose non-private algorithm numbers, although this would require
an IANA allocation (see below (Section 9).)
For example, an experiment might specify in its description the DNS
name "dnssec-experiment-a.example.com" as the base name, and provide
the mapping of "3.dnssec-experiment-a.example.com" is an alias of
DNSSEC algorithm 3 (DSA), and "5.dnssec-experiment-a.example.com" is
an alias of DNSSEC algorithm 5 (RSASHA1).
Resolvers MUST then only recognize the experiment's semantics when
present in a zone signed by one or more of these private algorithms.
In general, however, resolvers involved in the experiment are
expected to understand both standard DNSSEC and the defined
experimental DNSSEC protocol, although this isn't, strictly speaking,
required.
Blacka Expires August 3, 2005 [Page 8]
Internet-Draft DNSSEC Experiments February 2005
6. Considerations
There are a number of considerations with using this methodology.
1. Under some circumstances, it may be that the experiment will not
be sufficiently masked by this technique and may cause resolution
problem for resolvers not aware of the experiment. For instance,
the resolver may look at the not validatable response and
conclude that the response is bogus, either due to local policy
or implementation details. This is not expected to be the common
case, however.
2. It will, in general, not be possible for DNSSEC-aware resolvers
not aware of the experiment to build a chain of trust through an
experimental zone.
Blacka Expires August 3, 2005 [Page 9]
Internet-Draft DNSSEC Experiments February 2005
7. Transitions
If an experiment is successful, there may be a desire to move the
experiment to a standards-track extension. One way to do so would be
to move from private algorithm numbers to IANA allocated algorithm
numbers, with otherwise the same meaning. This would still leave a
divide between resolvers that understood the extension versus
resolvers that did not. It would, in essence, create an additional
version of DNSSEC.
An alternate technique might be to do a typecode rollover, thus
actually creating a definitive new version of DNSSEC. There may be
other transition techniques available, as well.
Blacka Expires August 3, 2005 [Page 10]
Internet-Draft DNSSEC Experiments February 2005
8. Security Considerations
Zones using this methodology will be considered insecure by all
resolvers except those aware of the experiment. It is not generally
possible to create a secure delegation from an experimental zone that
will be followed by resolvers unaware of the experiment.
Blacka Expires August 3, 2005 [Page 11]
Internet-Draft DNSSEC Experiments February 2005
9. IANA Considerations
IANA may need to allocate new DNSSEC algorithm numbers if that
transition approach is taken, or the experiment decides to use
allocated numbers to begin with. No IANA action is required to
deploy an experiment using private algorithm identifiers.
Blacka Expires August 3, 2005 [Page 12]
Internet-Draft DNSSEC Experiments February 2005
10. References
10.1 Normative References
[1] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
"DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
2004.
[2] Arends, R., "Resource Records for the DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-11 (work in progress), October
2004.
[3] Arends, R., "Protocol Modifications for the DNS Security
Extensions", draft-ietf-dnsext-dnssec-protocol-09 (work in
progress), October 2004.
10.2 Informative References
[4] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[5] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Blacka Expires August 3, 2005 [Page 13]
Internet-Draft DNSSEC Experiments February 2005
Editorial Comments
[Comment.1] Note: how private algorithms work in DNSSEC is not well
explained in the DNSSECbis RFCs. In particular, how to
validate that the DS records contain only unknown
algorithms is not explained at all.
Author's Address
David Blacka
Verisign, Inc.
21355 Ridgetop Circle
Dulles, VA 20166
US
Phone: +1 703 948 3200
EMail: davidb@verisign.com
URI: http://www.verisignlabs.com
Blacka Expires August 3, 2005 [Page 14]
Internet-Draft DNSSEC Experiments February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Blacka Expires August 3, 2005 [Page 15]

1177
doc/draft/draft-ietf-dnsext-dnssec-opt-in-06.txt Normal file
View File

File diff suppressed because it is too large Load Diff

784
doc/draft/draft-ietf-dnsext-dnssec-trans-00.txt
View File

@@ -1,784 +0,0 @@
DNS Extensions Working Group R. Arends
Internet-Draft Telematica Instituut
Expires: December 7, 2004 P. Koch
Universitaet Bielefeld
J. Schlyter
NIC-SE
June 8, 2004
Evaluating DNSSEC Transition Mechanisms
draft-ietf-dnsext-dnssec-trans-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 December 7, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document collects and summarizes different proposals for
alternative and additional strategies for authenticated denial in DNS
responses, evaluates these proposals and gives a recommendation for a
way forward.
Arends, et al. Expires December 7, 2004 [Page 1]
Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . 3
2.1 Mechanisms Updating DNSSEC-bis . . . . . . . . . . . . . . . 4
2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . . . . 4
2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . . . . 4
2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . . . . 5
2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . . . . 7
2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . . . . 8
2.2 Mechanisms not Updating DNSSEC-bis . . . . . . . . . . . . . 9
2.2.1 Partial Type-code and Signal Rollover . . . . . . . . . . . 9
2.2.2 A Complete Type-code and Signal Rollover . . . . . . . . . . 9
2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . . . . 10
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . 13
Arends, et al. Expires December 7, 2004 [Page 2]
Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004
1. Introduction
The working group consents on not including NSEC-alt in the
DNSSEC-bis documents. The working group considers to take up
"prevention of zone enumeration" as a work item.
There may be multiple mechanisms to allow for co-existence with
DNSSEC-bis. The chairs allow the working group a little over a week
(up to June 12) to come to consensus on a possible modification to
the document to enable gentle rollover. If that consensus cannot be
reached the DNSSEC-bis documents will go out as-is.
To ease the process of getting consensus, a summary of the proposed
solutions and analysis of the pros and cons were written during the
weekend.
This summary includes:
An inventory of the proposed mechanisms to make a transition to
future work on authenticated denial of existence.
List the known Pros and Cons, possibly provide new arguments, and
possible security considerations of these mechanisms.
Provide a recommendation on a way forward that is least disruptive
to the DNSSEC-bis specifications as they stand and keep an open
path to other methods for authenticated denial existence.
The descriptions of the proposals in this document are coarse and do
not cover every detail necessary for implementation. In any case,
documentation and further study is needed before implementaion and/or
deployment, including those which seem to be solely operational in
nature.
2. Transition Mechanisms
In the light of recent discussions and past proposals, we have found
several ways to allow for transition to future expansion of
authenticated denial. We tried to illuminate the paths and pitfalls
in these ways forward. Some proposals lead to a versioning of DNSSEC,
where DNSSEC-bis may co-exist with DNSSEC-ter, other proposals are
'clean' but may cause delay, while again others may be plain hacks.
Some paths do not introduce versioning, and might require the current
DNSSEC-bis documents to be fully updated to allow for extensions to
authenticated denial mechanisms. Other paths introduce versioning and
do not (or minimally) require DNSSEC-bis documents to be updated,
allowing DNSSEC-bis to be deployed, while future versions can be
drafted independent from or partially depending on DNSSEC-bis.
Arends, et al. Expires December 7, 2004 [Page 3]
Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004
2.1 Mechanisms Updating DNSSEC-bis
2.1.1 Dynamic NSEC Synthesis
This proposal assumes that NSEC RRs and the authenticating RRSIG will
be generated dynamically to just cover the (non existent) query name.
The owner name is (the) one preceding the name queried for, the Next
Owner Name Field has the value of the Query Name Field + 1 (first
successor in canonical ordering). A separate key (the normal ZSK or a
separate ZSK per authoritative server) would be used for RRSIGs on
NSEC RRs. This is a defense against enumeration, though it has the
presumption of online signing.
2.1.1.1 Coexistence and Migration
There is no change in interpretation other then that the next owner
name might or might not exist.
2.1.1.2 Limitations
This introduces an unbalanced cost between query and response
generation due to dynamic generation of signatures.
2.1.1.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents might need to be updated to indicate
that the next owner name might not be an existing name in the zone.
This is not a real change to the spec since implementers have been
warned not to synthesize with previously cached NSEC records. A
specific bit to identify the dynamic signature generating Key might
be useful as well, to prevent it from being used to fake positive
data.
2.1.1.4 Cons
Unbalanced cost is a ground for DDoS. Though this protects against
enumeration, it is not really a path for versioning.
2.1.1.5 Pros
Hardly any amendments to DNSSEC-bis.
2.1.2 Add Versioning/Subtyping to Current NSEC
This proposal introduces versioning for the NSEC RR type (a.k.a.
subtyping) by adding a (one octet) version field to the NSEC RDATA.
Version number 0 is assigned to the current (DNSSEC-bis) meaning,
making this an 'Must Be Zero' (MBZ) for the to be published docset.
Arends, et al. Expires December 7, 2004 [Page 4]
Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004
2.1.2.1 Coexistence and Migration
Since the versioning is done inside the NSEC RR, different versions
may coexist. However, depending on future methods, that may or may
not be useful inside a single zone. Resolvers cannot ask for specific
NSEC versions but may be able to indicate version support by means of
a to be defined EDNS option bit.
2.1.2.2 Limitations
There are no technical limitations, though it will cause delay to
allow testing of the (currently unknown) new NSEC interpretation.
Since the versioning and signaling is done inside the NSEC RR, future
methods will likely be restricted to a single RR type authenticated
denial (as opposed to e.g. NSEC-alt, which currently proposes three
RR types).
2.1.2.3 Amendments to DNSSEC-bis
Full Update of the current DNSSEC-bis documents to provide for new
fields in NSEC, while specifying behavior in case of unknown field
values.
2.1.2.4 Cons
Though this is a clean and clear path without versioning DNSSEC, it
takes some time to design, gain consensus, update the current
dnssec-bis document, test and implement a new authenticated denial
record.
2.1.2.5 Pros
Does not introduce an iteration to DNSSEC while providing a clear and
clean migration strategy.
2.1.3 Type Bit Map NSEC Indicator
Bits in the type-bit-map are reused or allocated to signify the
interpretation of NSEC.
This proposal assumes that future extensions make use of the existing
NSEC RDATA syntax, while it may need to change the interpretation of
the RDATA or introduce an alternative denial mechanism, invoked by
the specific type-bit-map-bits.
Arends, et al. Expires December 7, 2004 [Page 5]
Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004
2.1.3.1 Coexistence and migration
Old and new NSEC meaning could coexist, depending how the signaling
would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR
types are available as well as those covering meta/query types or
types to be specifically allocated.
2.1.3.2 Limitations
This mechanism uses an NSEC field that was not designed for that
purpose. Similar methods were discussed during the Opt-In discussion
and the Silly-State discussion.
2.1.3.3 Amendments to DNSSEC-bis
The specific type-bit-map-bits must be allocated and they need to be
specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
interpretation. Also, behaviour of the resolver and validator must be
documented in case unknown values are encountered for the MBZ field.
Currently the protocol document specifies that the validator MUST
ignore the setting of the NSEC and the RRSIG bits, while other bits
are only used for the specific purpose of the type-bit-map field
2.1.3.4 Cons
The type-bit-map was not designed for this purpose. It is a
straightforward hack. Text in protocol section 5.4 was put in
specially to defend against this usage.
2.1.3.5 Pros
No change needed to the on-the-wire protocol as specified in the
current docset.
2.1.4 New Apex Type
This introduces a new Apex type (parallel to the zone's SOA)
indicating the DNSSEC version (or authenticated denial) used in or
for this zone.
2.1.4.1 Coexistence and Migration
Depending on the design of this new RR type multiple denial
mechanisms may coexist in a zone. Old validators will not understand
and thus ignore the new type, so interpretation of the new NSEC
scheme may fail, negative responses may appear 'bogus'.
Arends, et al. Expires December 7, 2004 [Page 6]
Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004
2.1.4.2 Limitations
A record of this kind is likely to carry additional feature/
versioning indications unrelated to the current question of
authenticated denial.
2.1.4.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents need to be updated to indicate that
the absence of this type indicates dnssec-bis, and that the (mere)
presence of this type indicated unknown versions.
2.1.4.4 Cons
The only other 'zone' or 'apex' record is the SOA record. Though this
proposal is not new, it is yet unknown how it might fulfill
authenticated denial extensions. This new RR type would only provide
for a generalized signaling mechanism, not the new authenticated
denial scheme. Since it is likely to be general in nature, due to
this generality consensus is not to be reached soon.
2.1.4.5 Pros
This approach would allow for a lot of other per zone information to
be transported or signaled to both (slave) servers and resolvers.
2.1.5 NSEC White Lies
This proposal disables one part of NSEC (the pointer part) by means
of a special target (root, apex, owner, ...), leaving intact only the
ability to authenticate denial of existence of RR sets, not denial of
existence of domain names (NXDOMAIN). It may be necessary to have one
working NSEC to prove the absence of a wildcard.
2.1.5.1 Coexistence and Migration
The NSEC target can be specified per RR, so standard NSEC and 'white
lie' NSEC can coexist in a zone. There is no need for migration
because no versioning is introduced or intended.
2.1.5.2 Limitations
This proposal breaks the protocol and is applicable to certain types
of zones only (no wildcard, no deep names, delegation only). Most of
the burden is put on the resolver side and operational consequences
are yet to be studied.
Arends, et al. Expires December 7, 2004 [Page 7]
Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004
2.1.5.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents need to be updated to indicate that
the NXDOMAIN responses may be insecure.
2.1.5.4 Cons
Strictly speaking this breaks the protocol and doesn't fully fulfill
the requirements for authenticated denial of existence. Security
implications need to be carefully documented: search path problems
(forged denial of existence may lead to wrong expansion of non-FQDNs,
cf. RFC 1535); replay attacks to deny existence of records
2.1.5.5 Pros
Hardly any amendments to DNSSEC-bis. Operational "trick" that is
available anyway.
2.1.6 NSEC Optional via DNSSKEY Flag
A new DNSKEY may be defined to declare NSEC optional per zone.
2.1.6.1 Coexistence and Migration
Current resolvers/validators will not understand the Flag bit and
will have to treat negative responses as bogus. Otherwise, no
migration path is needed since NSEC is simply turned off.
2.1.6.2 Limitations
NSEC can only be made completely optional at the cost of being unable
to prove unsecure delegations (absence of DS RR). A next to this
approach would just disable authenticated denial for non-existence of
nodes.
2.1.6.3 Amendments to DNSSEC-bis
New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to
be specified in the light of absence of authenticated denial.
2.1.6.4 Cons
Doesn't fully meet requirements. Operational consequences to be
studied.
2.1.6.5 Pros
Official version of the "trick" presented in (8). Operational
Arends, et al. Expires December 7, 2004 [Page 8]
Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004
problems can be addressed during future work on validators.
2.2 Mechanisms not Updating DNSSEC-bis
2.2.1 Partial Type-code and Signal Rollover
Carefully crafted type code/signal rollover to define a new
authenticated denial space that extends/replaces DNSSEC-bis
authenticated denial space. This particular path is illuminated by
Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com>
posted to <namedroppers@ops.ietf.org> 2004-06-02.
2.2.1.1 Coexistence and Migration
To protect the current resolver for future versions, a new DNSSEC-OK
bit must be allocated to make clear it does or does not understand
the future version. Also, a new DS type needs to be allocated to
allow differentiation between a current signed delegation and a
'future' signed delegation. Also, current NSEC needs to be rolled
into a new authenticated denial type.
2.2.1.2 Limitations
None.
2.2.1.3 Amendments to DNSSEC-bis
None.
2.2.1.4 Cons
It is cumbersome to carefully craft an TCR that 'just fits'. The
DNSSEC-bis protocol has many 'borderline' cases that needs special
consideration. It might be easier to do a full TCR, since a few of
the types and signals need upgrading anyway.
2.2.1.5 Pros
Graceful adoption of future versions of NSEC, while there are no
amendments to DNSSEC-bis.
2.2.2 A Complete Type-code and Signal Rollover
A new DNSSEC space is defined which can exist independent of current
DNSSEC-bis space.
This proposal assumes that all current DNSSEC type-codes (RRSIG/
DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any future
Arends, et al. Expires December 7, 2004 [Page 9]
Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004
versions of DNSSEC. Any future version of DNSSEC has its own types to
allow for keys, signatures, authenticated denial, etcetera.
2.2.2.1 Coexistence and Migration
Both spaces can co-exist. They can be made completely orthogonal.
2.2.2.2 Limitations
None.
2.2.2.3 Amendments to DNSSEC-bis
None.
2.2.2.4 Cons
With this path we abandon the current DNSSEC-bis. Though it is easy
to role specific well-known and well-tested parts into the re-write,
once deployment has started this path is very expensive for
implementers, registries, registrars and registrants as well as
resolvers/users. A TCR is not to be expected to occur frequently, so
while a next generation authenticated denial may be enabled by a TCR,
it is likely that that TCR will only be agreed upon if it serves a
whole basket of changes or additions. A quick introduction of NSEC-ng
should not be expected from this path.
2.2.2.5 Pros
No amendments/changes to current DNSSEC-bis docset needed. It is
always there as last resort.
2.2.3 Unknown Algorithm in RRSIG
This proposal assumes that future extensions make use of the existing
NSEC RDATA syntax, while it may need to change the interpretation of
the RDATA or introduce an alternative denial mechanism, invoked by
the specific unknown signing algorithm. The different interpretation
would be signaled by use of different signature algorithms in the
RRSIG records covering the NSEC RRs.
When an entire zone is signed with a single unknown algorithm, it
will cause implementations that follow current dnssec-bis documents
to treat individual RRsets as unsigned.
2.2.3.1 Coexistence and migration
Old and new NSEC RDATA interpretation or known and unknown Signatures
Arends, et al. Expires December 7, 2004 [Page 10]
Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004
can NOT coexist in a zone since signatures cover complete (NSEC)
RRSets.
2.2.3.2 Limitations
Validating resolvers agnostic of new interpretation will treat the
NSEC RRset as "not signed". This affects wildcard and non-existence
proof, as well as proof for (un)secured delegations. Also, all
positive signatures (RRSIGs on RRSets other than DS, NSEC) appear
insecure/bogus to an old validator.
The algorithm version space is split for each future version of
DNSSEC. Violation of the 'modular components' concept. We use the
'validator' to protect the 'resolver' from unknown interpretations.
2.2.3.3 Amendments to DNSSEC-bis
None.
2.2.3.4 Cons
The algorithm field was not designed for this purpose. This is a
straightforward hack.
2.2.3.5 Pros
No amendments/changes to current DNSSEC-bis docset needed.
3. Recommendation
The authors recommend that the working group commits to and starts
work on a partial TCR, allowing gracefull transition towards a future
version of NSEC. Meanwhile, to accomodate the need for an
immediately, temporary, solution against zone-traversal, we recommend
On-Demand NSEC synthesis.
This approach does not require any mandatory changes to DNSSEC-bis,
does not violate the protocol and fulfills the requirements. As a
side effect, it moves the cost of implementation and deployment to
the users (zone owners) of this mechanism.
Arends, et al. Expires December 7, 2004 [Page 11]
Internet-Draft Evaluating DNSSEC Transition Mechanisms June 2004
Authors' Addresses
Roy Arends
Telematica Instituut
Drienerlolaan 5
Enschede 7522 NB
Netherlands
Phone: +31 534850485
EMail: roy.arends@telin.nl
Peter Koch
Universitaet Bielefeld
Bielefeld 33594
Germany
Phone: +49 521 106 2902
EMail: pk@TechFak.Uni-Bielefeld.DE
Jakob Schlyter
NIC-SE
Box 5774
Stockholm SE-114 87
Sweden
EMail: jakob@nic.se
URI: http://www.nic.se/
Arends, et al. Expires December 7, 2004 [Page 12]
Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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
Arends, et al. Expires December 7, 2004 [Page 13]
Internet-Draft Evaluating DNSSEC Transition Mechanisms June 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.
Arends, et al. Expires December 7, 2004 [Page 14]

839
doc/draft/draft-ietf-dnsext-dnssec-trans-02.txt Normal file
View File

@@ -0,0 +1,839 @@
DNS Extensions Working Group R. Arends
Internet-Draft Telematica Instituut
Expires: August 25, 2005 P. Koch
DENIC eG
J. Schlyter
NIC-SE
February 21, 2005
Evaluating DNSSEC Transition Mechanisms
draft-ietf-dnsext-dnssec-trans-02.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she 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 August 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document collects and summarizes different proposals for
alternative and additional strategies for authenticated denial in DNS
responses, evaluates these proposals and gives a recommendation for a
Arends, et al. Expires August 25, 2005 [Page 1]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
way forward.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Transition Mechanisms . . . . . . . . . . . . . . . . . . . . 3
2.1 Mechanisms With Need of Updating DNSSEC-bis . . . . . . . 4
2.1.1 Dynamic NSEC Synthesis . . . . . . . . . . . . . . . . 4
2.1.2 Add Versioning/Subtyping to Current NSEC . . . . . . . 5
2.1.3 Type Bit Map NSEC Indicator . . . . . . . . . . . . . 6
2.1.4 New Apex Type . . . . . . . . . . . . . . . . . . . . 6
2.1.5 NSEC White Lies . . . . . . . . . . . . . . . . . . . 7
2.1.6 NSEC Optional via DNSSKEY Flag . . . . . . . . . . . . 8
2.1.7 New Answer Pseudo RR Type . . . . . . . . . . . . . . 9
2.1.8 SIG(0) Based Authenticated Denial . . . . . . . . . . 9
2.2 Mechanisms Without Need of Updating DNSSEC-bis . . . . . . 10
2.2.1 Partial Type-code and Signal Rollover . . . . . . . . 10
2.2.2 A Complete Type-code and Signal Rollover . . . . . . . 11
2.2.3 Unknown Algorithm in RRSIG . . . . . . . . . . . . . . 11
3. Recommendation . . . . . . . . . . . . . . . . . . . . . . . . 12
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1 Normative References . . . . . . . . . . . . . . . . . . . 13
5.2 Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
Arends, et al. Expires August 25, 2005 [Page 2]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
1. Introduction
This report shall document the process of dealing with the NSEC
walking problem late in the Last Call for
[I-D.ietf-dnsext-dnssec-intro, I-D.ietf-dnsext-dnssec-protocol,
I-D.ietf-dnsext-dnssec-records]. It preserves some of the discussion
that took place in the DNSEXT WG during the first half of June 2004
as well as some additional ideas that came up subsequently.
This is an edited excerpt of the chairs' mail to the WG:
The working group consents on not including NSEC-alt in the
DNSSEC-bis documents. The working group considers to take up
"prevention of zone enumeration" as a work item.
There may be multiple mechanisms to allow for co-existence with
DNSSEC-bis. The chairs allow the working group a little over a
week (up to June 12, 2004) to come to consensus on a possible
modification to the document to enable gentle rollover. If that
consensus cannot be reached the DNSSEC-bis documents will go out
as-is.
To ease the process of getting consensus, a summary of the proposed
solutions and analysis of the pros and cons were written during the
weekend.
This summary includes:
An inventory of the proposed mechanisms to make a transition to
future work on authenticated denial of existence.
List the known Pros and Cons, possibly provide new arguments, and
possible security considerations of these mechanisms.
Provide a recommendation on a way forward that is least disruptive
to the DNSSEC-bis specifications as they stand and keep an open
path to other methods for authenticated denial of existence.
The descriptions of the proposals in this document are coarse and do
not cover every detail necessary for implementation. In any case,
documentation and further study is needed before implementaion and/or
deployment, including those which seem to be solely operational in
nature.
2. Transition Mechanisms
In the light of recent discussions and past proposals, we have found
several ways to allow for transition to future expansion of
authenticated denial. We tried to illuminate the paths and pitfalls
in these ways forward. Some proposals lead to a versioning of
DNSSEC, where DNSSEC-bis may co-exist with DNSSEC-ter, other
proposals are 'clean' but may cause delay, while again others may be
Arends, et al. Expires August 25, 2005 [Page 3]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
plain hacks.
Some paths do not introduce versioning, and might require the current
DNSSEC-bis documents to be fully updated to allow for extensions to
authenticated denial mechanisms. Other paths introduce versioning
and do not (or minimally) require DNSSEC-bis documents to be updated,
allowing DNSSEC-bis to be deployed, while future versions can be
drafted independent from or partially depending on DNSSEC-bis.
2.1 Mechanisms With Need of Updating DNSSEC-bis
Mechanisms in this category demand updates to the DNSSEC-bis document
set.
2.1.1 Dynamic NSEC Synthesis
This proposal assumes that NSEC RRs and the authenticating RRSIG will
be generated dynamically to just cover the (non existent) query name.
The owner name is (the) one preceding the name queried for, the Next
Owner Name Field has the value of the Query Name Field + 1 (first
successor in canonical ordering). A separate key (the normal ZSK or
a separate ZSK per authoritative server) would be used for RRSIGs on
NSEC RRs. This is a defense against enumeration, though it has the
presumption of online signing.
2.1.1.1 Coexistence and Migration
There is no change in interpretation other then that the next owner
name might or might not exist.
2.1.1.2 Limitations
This introduces an unbalanced cost between query and response
generation due to dynamic generation of signatures.
2.1.1.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents might need to be updated to indicate
that the next owner name might not be an existing name in the zone.
This is not a real change to the spec since implementers have been
warned not to synthesize with previously cached NSEC records. A
specific bit to identify the dynamic signature generating key might
be useful as well, to prevent it from being used to fake positive
data.
2.1.1.4 Cons
Unbalanced cost is a ground for DDoS. Though this protects against
Arends, et al. Expires August 25, 2005 [Page 4]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
enumeration, it is not really a path for versioning.
2.1.1.5 Pros
Hardly any amendments to DNSSEC-bis.
2.1.2 Add Versioning/Subtyping to Current NSEC
This proposal introduces versioning for the NSEC RR type (a.k.a.
subtyping) by adding a (one octet) version field to the NSEC RDATA.
Version number 0 is assigned to the current (DNSSEC-bis) meaning,
making this an 'Must Be Zero' (MBZ) for the to be published docset.
2.1.2.1 Coexistence and Migration
Since the versioning is done inside the NSEC RR, different versions
may coexist. However, depending on future methods, that may or may
not be useful inside a single zone. Resolvers cannot ask for
specific NSEC versions but may be able to indicate version support by
means of a to be defined EDNS option bit.
2.1.2.2 Limitations
There are no technical limitations, though it will cause delay to
allow testing of the (currently unknown) new NSEC interpretation.
Since the versioning and signaling is done inside the NSEC RR, future
methods will likely be restricted to a single RR type authenticated
denial (as opposed to e.g. NSEC-alt, which currently proposes three
RR types).
2.1.2.3 Amendments to DNSSEC-bis
Full Update of the current DNSSEC-bis documents to provide for new
fields in NSEC, while specifying behavior in case of unknown field
values.
2.1.2.4 Cons
Though this is a clean and clear path without versioning DNSSEC, it
takes some time to design, gain consensus, update the current
dnssec-bis document, test and implement a new authenticated denial
record.
2.1.2.5 Pros
Does not introduce an iteration to DNSSEC while providing a clear and
clean migration strategy.
Arends, et al. Expires August 25, 2005 [Page 5]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.3 Type Bit Map NSEC Indicator
Bits in the type-bit-map are reused or allocated to signify the
interpretation of NSEC.
This proposal assumes that future extensions make use of the existing
NSEC RDATA syntax, while it may need to change the interpretation of
the RDATA or introduce an alternative denial mechanism, invoked by
the specific type-bit-map-bits.
2.1.3.1 Coexistence and migration
Old and new NSEC meaning could coexist, depending how the signaling
would be defined. The bits for NXT, NSEC, RRSIG or other outdated RR
types are available as well as those covering meta/query types or
types to be specifically allocated.
2.1.3.2 Limitations
This mechanism uses an NSEC field that was not designed for that
purpose. Similar methods were discussed during the Opt-In discussion
and the Silly-State discussion.
2.1.3.3 Amendments to DNSSEC-bis
The specific type-bit-map-bits must be allocated and they need to be
specified as 'Must Be Zero' (MBZ) when used for standard (dnssec-bis)
interpretation. Also, behaviour of the resolver and validator must
be documented in case unknown values are encountered for the MBZ
field. Currently the protocol document specifies that the validator
MUST ignore the setting of the NSEC and the RRSIG bits, while other
bits are only used for the specific purpose of the type-bit-map field
2.1.3.4 Cons
The type-bit-map was not designed for this purpose. It is a
straightforward hack. Text in protocol section 5.4 was put in
specially to defend against this usage.
2.1.3.5 Pros
No change needed to the on-the-wire protocol as specified in the
current docset.
2.1.4 New Apex Type
This introduces a new Apex type (parallel to the zone's SOA)
indicating the DNSSEC version (or authenticated denial) used in or
Arends, et al. Expires August 25, 2005 [Page 6]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
for this zone.
2.1.4.1 Coexistence and Migration
Depending on the design of this new RR type multiple denial
mechanisms may coexist in a zone. Old validators will not understand
and thus ignore the new type, so interpretation of the new NSEC
scheme may fail, negative responses may appear 'bogus'.
2.1.4.2 Limitations
A record of this kind is likely to carry additional
feature/versioning indications unrelated to the current question of
authenticated denial.
2.1.4.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents need to be updated to indicate that
the absence of this type indicates dnssec-bis, and that the (mere)
presence of this type indicated unknown versions.
2.1.4.4 Cons
The only other 'zone' or 'apex' record is the SOA record. Though
this proposal is not new, it is yet unknown how it might fulfill
authenticated denial extensions. This new RR type would only provide
for a generalized signaling mechanism, not the new authenticated
denial scheme. Since it is likely to be general in nature, due to
this generality consensus is not to be reached soon.
2.1.4.5 Pros
This approach would allow for a lot of other per zone information to
be transported or signaled to both (slave) servers and resolvers.
2.1.5 NSEC White Lies
This proposal disables one part of NSEC (the pointer part) by means
of a special target (root, apex, owner, ...), leaving intact only the
ability to authenticate denial of existence of RR sets, not denial of
existence of domain names (NXDOMAIN). It may be necessary to have
one working NSEC to prove the absence of a wildcard.
2.1.5.1 Coexistence and Migration
The NSEC target can be specified per RR, so standard NSEC and 'white
lie' NSEC can coexist in a zone. There is no need for migration
because no versioning is introduced or intended.
Arends, et al. Expires August 25, 2005 [Page 7]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.5.2 Limitations
This proposal breaks the protocol and is applicable to certain types
of zones only (no wildcard, no deep names, delegation only). Most of
the burden is put on the resolver side and operational consequences
are yet to be studied.
2.1.5.3 Amendments to DNSSEC-bis
The current DNSSEC-bis documents need to be updated to indicate that
the NXDOMAIN responses may be insecure.
2.1.5.4 Cons
Strictly speaking this breaks the protocol and doesn't fully fulfill
the requirements for authenticated denial of existence. Security
implications need to be carefully documented: search path problems
(forged denial of existence may lead to wrong expansion of non-FQDNs
[RFC1535]) and replay attacks to deny existence of records.
2.1.5.5 Pros
Hardly any amendments to DNSSEC-bis. Operational "trick" that is
available anyway.
2.1.6 NSEC Optional via DNSSKEY Flag
A new DNSKEY may be defined to declare NSEC optional per zone.
2.1.6.1 Coexistence and Migration
Current resolvers/validators will not understand the Flag bit and
will have to treat negative responses as bogus. Otherwise, no
migration path is needed since NSEC is simply turned off.
2.1.6.2 Limitations
NSEC can only be made completely optional at the cost of being unable
to prove unsecure delegations (absence of a DS RR [RFC3658]). A next
to this approach would just disable authenticated denial for
non-existence of nodes.
2.1.6.3 Amendments to DNSSEC-bis
New DNSKEY Flag to be defined. Resolver/Validator behaviour needs to
be specified in the light of absence of authenticated denial.
Arends, et al. Expires August 25, 2005 [Page 8]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.6.4 Cons
Doesn't fully meet requirements. Operational consequences to be
studied.
2.1.6.5 Pros
Official version of the "trick" presented in (8). Operational
problems can be addressed during future work on validators.
2.1.7 New Answer Pseudo RR Type
A new pseudo RR type may be defined that will be dynamically created
(and signed) by the responding authoritative server. The RR in the
response will cover the QNAME, QCLASS and QTYPE and will authenticate
both denial of existence of name (NXDOMAIN) or RRset.
2.1.7.1 Coexistence and Migration
Current resolvers/validators will not understand the pseudo RR and
will thus not be able to process negative responses so testified. A
signaling or solicitation method would have to be specified.
2.1.7.2 Limitations
This method can only be used with online keys and online signing
capacity.
2.1.7.3 Amendments to DNSSEC-bis
Signaling method needs to be defined.
2.1.7.4 Cons
Keys have to be held and processed online with all security
implications. An additional flag for those keys identifying them as
online or negative answer only keys should be considered.
2.1.7.5 Pros
Expands DNSSEC authentication to the RCODE.
2.1.8 SIG(0) Based Authenticated Denial
2.1.8.1 Coexistence and Migration
Arends, et al. Expires August 25, 2005 [Page 9]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.1.8.2 Limitations
2.1.8.3 Amendments to DNSSEC-bis
2.1.8.4 Cons
2.1.8.5 Pros
2.2 Mechanisms Without Need of Updating DNSSEC-bis
2.2.1 Partial Type-code and Signal Rollover
Carefully crafted type code/signal rollover to define a new
authenticated denial space that extends/replaces DNSSEC-bis
authenticated denial space. This particular path is illuminated by
Paul Vixie in a Message-Id <20040602070859.0F50913951@sa.vix.com>
posted to <namedroppers@ops.ietf.org> 2004-06-02.
2.2.1.1 Coexistence and Migration
To protect the current resolver for future versions, a new DNSSEC-OK
bit must be allocated to make clear it does or does not understand
the future version. Also, a new DS type needs to be allocated to
allow differentiation between a current signed delegation and a
'future' signed delegation. Also, current NSEC needs to be rolled
into a new authenticated denial type.
2.2.1.2 Limitations
None.
2.2.1.3 Amendments to DNSSEC-bis
None.
2.2.1.4 Cons
It is cumbersome to carefully craft an TCR that 'just fits'. The
DNSSEC-bis protocol has many 'borderline' cases that needs special
consideration. It might be easier to do a full TCR, since a few of
the types and signals need upgrading anyway.
Arends, et al. Expires August 25, 2005 [Page 10]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
2.2.1.5 Pros
Graceful adoption of future versions of NSEC, while there are no
amendments to DNSSEC-bis.
2.2.2 A Complete Type-code and Signal Rollover
A new DNSSEC space is defined which can exist independent of current
DNSSEC-bis space.
This proposal assumes that all current DNSSEC type-codes
(RRSIG/DNSKEY/NSEC/DS) and signals (DNSSEC-OK) are not used in any
future versions of DNSSEC. Any future version of DNSSEC has its own
types to allow for keys, signatures, authenticated denial, etcetera.
2.2.2.1 Coexistence and Migration
Both spaces can co-exist. They can be made completely orthogonal.
2.2.2.2 Limitations
None.
2.2.2.3 Amendments to DNSSEC-bis
None.
2.2.2.4 Cons
With this path we abandon the current DNSSEC-bis. Though it is easy
to role specific well-known and well-tested parts into the re-write,
once deployment has started this path is very expensive for
implementers, registries, registrars and registrants as well as
resolvers/users. A TCR is not to be expected to occur frequently, so
while a next generation authenticated denial may be enabled by a TCR,
it is likely that that TCR will only be agreed upon if it serves a
whole basket of changes or additions. A quick introduction of
NSEC-ng should not be expected from this path.
2.2.2.5 Pros
No amendments/changes to current DNSSEC-bis docset needed. It is
always there as last resort.
2.2.3 Unknown Algorithm in RRSIG
This proposal assumes that future extensions make use of the existing
NSEC RDATA syntax, while it may need to change the interpretation of
Arends, et al. Expires August 25, 2005 [Page 11]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
the RDATA or introduce an alternative denial mechanism, invoked by
the specific unknown signing algorithm. The different interpretation
would be signaled by use of different signature algorithms in the
RRSIG records covering the NSEC RRs.
When an entire zone is signed with a single unknown algorithm, it
will cause implementations that follow current dnssec-bis documents
to treat individual RRsets as unsigned.
2.2.3.1 Coexistence and migration
Old and new NSEC RDATA interpretation or known and unknown Signatures
can NOT coexist in a zone since signatures cover complete (NSEC)
RRSets.
2.2.3.2 Limitations
Validating resolvers agnostic of new interpretation will treat the
NSEC RRset as "not signed". This affects wildcard and non-existence
proof, as well as proof for (un)secured delegations. Also, all
positive signatures (RRSIGs on RRSets other than DS, NSEC) appear
insecure/bogus to an old validator.
The algorithm version space is split for each future version of
DNSSEC. Violation of the 'modular components' concept. We use the
'validator' to protect the 'resolver' from unknown interpretations.
2.2.3.3 Amendments to DNSSEC-bis
None.
2.2.3.4 Cons
The algorithm field was not designed for this purpose. This is a
straightforward hack.
2.2.3.5 Pros
No amendments/changes to current DNSSEC-bis docset needed.
3. Recommendation
The authors recommend that the working group commits to and starts
work on a partial TCR, allowing graceful transition towards a future
version of NSEC. Meanwhile, to accomodate the need for an
immediately, temporary, solution against zone-traversal, we recommend
On-Demand NSEC synthesis.
Arends, et al. Expires August 25, 2005 [Page 12]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
This approach does not require any mandatory changes to DNSSEC-bis,
does not violate the protocol and fulfills the requirements. As a
side effect, it moves the cost of implementation and deployment to
the users (zone owners) of this mechanism.
4. Acknowledgements
The authors would like to thank Sam Weiler and Mark Andrews for their
input and constructive comments.
5. References
5.1 Normative References
[I-D.ietf-dnsext-dnssec-intro]
Arends, R., Austein, R., Massey, D., Larson, M. and S.
Rose, "DNS Security Introduction and Requirements",
Internet-Draft draft-ietf-dnsext-dnssec-intro-13, October
2004.
[I-D.ietf-dnsext-dnssec-protocol]
Arends, R., "Protocol Modifications for the DNS Security
Extensions",
Internet-Draft draft-ietf-dnsext-dnssec-protocol-09,
October 2004.
[I-D.ietf-dnsext-dnssec-records]
Arends, R., "Resource Records for the DNS Security
Extensions",
Internet-Draft draft-ietf-dnsext-dnssec-records-11,
October 2004.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC2931] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
5.2 Informative References
[RFC1535] Gavron, E., "A Security Problem and Proposed Correction
With Widely Deployed DNS Software", RFC 1535, October
1993.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
Arends, et al. Expires August 25, 2005 [Page 13]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
RFC 2535, March 1999.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3658] Gudmundsson, O., "Delegation Signer (DS) Resource Record
(RR)", RFC 3658, December 2003.
Authors' Addresses
Roy Arends
Telematica Instituut
Brouwerijstraat 1
Enschede 7523 XC
The Netherlands
Phone: +31 53 4850485
Email: roy.arends@telin.nl
Peter Koch
DENIC eG
Wiesenh"uttenplatz 26
Frankfurt 60329
Germany
Phone: +49 69 27235 0
Email: pk@DENIC.DE
Jakob Schlyter
NIC-SE
Box 5774
Stockholm SE-114 87
Sweden
Email: jakob@nic.se
URI: http://www.nic.se/
Arends, et al. Expires August 25, 2005 [Page 14]
Internet-Draft Evaluating DNSSEC Transition Mechanisms February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Arends, et al. Expires August 25, 2005 [Page 15]

410
doc/draft/draft-ietf-dnsext-ecc-key-05.txt → doc/draft/draft-ietf-dnsext-ecc-key-06.txt
View File

@@ -1,13 +1,13 @@
<EFBFBD>©À
INTERNET-DRAFT ECC Keys in the DNS INTERNET-DRAFT ECC Keys in the DNS
Expires: February 2005 August 2004 Expires: June 2005 December 2004
Elliptic Curve KEYs in the DNS Elliptic Curve KEYs in the DNS
-------- ----- ---- -- --- --- -------- ----- ---- -- --- ---
<draft-ietf-dnsext-ecc-key-05.txt> <draft-ietf-dnsext-ecc-key-06.txt>
Richard C. Schroeppel Richard C. Schroeppel
Donald Eastlake 3rd Donald Eastlake 3rd
@@ -43,8 +43,8 @@ Status of This Document
Abstract Abstract
The standard method for storing elliptic curve cryptographic keys in The standard method for storing elliptic curve cryptographic keys and
the Domain Name System is specified. signatures in the Domain Name System is specified.
Copyright Notice Copyright Notice
@@ -81,17 +81,17 @@ Table of Contents
2. Elliptic Curve Data in Resource Records.................3 2. Elliptic Curve Data in Resource Records.................3
3. The Elliptic Curve Equation.............................9 3. The Elliptic Curve Equation.............................9
4. How do I Compute Q, G, and Y?..........................10 4. How do I Compute Q, G, and Y?..........................10
5. Performance Considerations.............................11 5. Elliptic Curve SIG Resource Records....................11
6. Security Considerations................................11 6. Performance Considerations.............................13
7. IANA Considerations....................................11 7. Security Considerations................................13
Copyright and Disclaimer..................................12 8. IANA Considerations....................................13
Copyright and Disclaimer..................................14
Informational References..................................13 Informational References..................................15
Normative Refrences.......................................13 Normative Refrences.......................................15
Authors Addresses.........................................14
Expiration and File Name..................................14
Author's Addresses........................................16
Expiration and File Name..................................16
@@ -128,9 +128,9 @@ INTERNET-DRAFT ECC Keys in the DNS
protocol, records]. protocol, records].
This document describes how to store elliptic curve cryptographic This document describes how to store elliptic curve cryptographic
(ECC) keys in the DNS so they can be used for a variety of security (ECC) keys and signatures in the DNS so they can be used for a
purposes. A DNS elliptic curve SIG resource record is not defined. variety of security purposes. Familiarity with ECC cryptography is
Familiarity with ECC cryptography is assumed [Menezes]. assumed [Menezes].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
@@ -141,11 +141,8 @@ INTERNET-DRAFT ECC Keys in the DNS
2. Elliptic Curve Data in Resource Records 2. Elliptic Curve Data in Resource Records
Elliptic curve public keys are stored in the DNS within the RDATA Elliptic curve public keys are stored in the DNS within the RDATA
portions of key RRs with the structure shown below [RFC records]. portions of key RRs, such as RRKEY and KEY [RFC records] RRs, with
the structure shown below.
The period of key validity may not be in the RR with the key but
could be indicated by RR(s) with signatures that authenticates the
RR(s) containing the key.
The research world continues to work on the issue of which is the The research world continues to work on the issue of which is the
best elliptic curve system, which finite field to use, and how to best elliptic curve system, which finite field to use, and how to
@@ -171,6 +168,9 @@ INTERNET-DRAFT ECC Keys in the DNS
R. Schroeppel, et al [Page 3] R. Schroeppel, et al [Page 3]
@@ -373,7 +373,7 @@ INTERNET-DRAFT ECC Keys in the DNS
and the constant term is least important. Coefficients are ordered and the constant term is least important. Coefficients are ordered
by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of by sign-magnitude: 0 < 1 < -1 < 2 < -2 < ... The first polynomial of
degree D is X^D (which is not irreducible). The next is X^D+1, which degree D is X^D (which is not irreducible). The next is X^D+1, which
is sometimes irreducible, followed by X^D-1, which isn‚ÇÖt. Assuming is sometimes irreducible, followed by X^D-1, which isn't. Assuming
odd P, this series continues to X^D - (P-1)/2, and then goes to X^D + odd P, this series continues to X^D - (P-1)/2, and then goes to X^D +
X, X^D + X + 1, X^D + X - 1, etc. X, X^D + X + 1, X^D + X - 1, etc.
@@ -490,7 +490,7 @@ INTERNET-DRAFT ECC Keys in the DNS
of the curve point is given explicitly; the Z-coordinate is of the curve point is given explicitly; the Z-coordinate is
implicit. implicit.
LY,Y is the user‚ÇÖs public signing key, another curve point of LY,Y is the user's public signing key, another curve point of
order Q. The W-coordinate is given explicitly; the Z- order Q. The W-coordinate is given explicitly; the Z-
coordinate is implicit. The LY,Y parameter pair is always coordinate is implicit. The LY,Y parameter pair is always
present. present.
@@ -540,7 +540,7 @@ INTERNET-DRAFT ECC Keys in the DNS
The number of points on the curve is the number of solutions to the The number of points on the curve is the number of solutions to the
curve equation, + 1 (for the "point at infinity"). The prime Q must curve equation, + 1 (for the "point at infinity"). The prime Q must
divide the number of points. Usually the curve is chosen first, then divide the number of points. Usually the curve is chosen first, then
the number of points is determined with Schoof‚ÇÖs algorithm. This the number of points is determined with Schoof's algorithm. This
number is factored, and if it has a large prime divisor, that number number is factored, and if it has a large prime divisor, that number
is taken as Q. is taken as Q.
@@ -567,7 +567,7 @@ INTERNET-DRAFT ECC Keys in the DNS
smaller Z value (the one which does not contain the highest-order 1 smaller Z value (the one which does not contain the highest-order 1
bit of W (or C)) is used in subsequent calculations. bit of W (or C)) is used in subsequent calculations.
Y is specified by giving the W-coordinate of the user‚ÇÖs public Y is specified by giving the W-coordinate of the user's public
signature key. The Z-coordinate value is determined from the curve signature key. The Z-coordinate value is determined from the curve
equation. As with G, there are two possible Z values; the same rule equation. As with G, there are two possible Z values; the same rule
is followed for choosing which Z to use. is followed for choosing which Z to use.
@@ -598,41 +598,41 @@ INTERNET-DRAFT ECC Keys in the DNS
5. Performance Considerations 5. Elliptic Curve SIG Resource Records
Elliptic curve signatures use smaller moduli or field sizes than RSA The signature portion of an RR RDATA area when using the EC
and DSA. Creation of a curve is slow, but not done very often. Key algorithm, for example in the RRSIG and SIG [RFC records] RRs is
generation is faster than RSA or DSA. shown below.
DNS implementations have been optimized for small transfers, 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
typically less than 512 octets including DNS overhead. Larger 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
transfers will perform correctly and and extensions have been +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
standardized to make larger transfers more efficient [RFC 2671]. | R, (length determined from LQ) .../
However, it is still advisable at this time to make reasonable +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
efforts to minimize the size of RR sets stored within the DNS | S, (length determined from LQ) .../
consistent with adequate security. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R and S are integers (mod Q). Their length is specified by the LQ
field of the corresponding KEY RR and can also be calculated from the
SIG RR's RDLENGTH. They are right justified, high-order-octet first.
The same conditional formula for calculating the length from LQ is
used as for all the other length fields above.
The data signed is determined as specified in [RFC 2535]. Then the
following steps are taken where Q, P, G, and Y are as specified in
the public key [Schneier]:
6. Security Considerations hash = SHA-1 ( data )
Keys retrieved from the DNS should not be trusted unless (1) they Generate random [RFC 1750] K such that 0 < K < Q. (Never sign two
have been securely obtained from a secure resolver or independently different messages with the same K. K should be chosen from a
verified by the user and (2) this secure resolver and secure very large space: If an opponent learns a K value for a single
obtainment or independent verification conform to security policies signature, the user's signing key is compromised, and a forger
acceptable to the user. As with all cryptographic algorithms, can sign arbitrary messages. There is no harm in signing the
evaluating the necessary strength of the key is essential and same message multiple times with the same key or different
dependent on local policy. keys.)
Some specific key generation considerations are given in the body of R = (the W-coordinate of ( K*G on the elliptic curve )) interpreted
this document.
7. IANA Considerations
Assignment of meaning to the remaining ECC data flag bits or to
values of ECC fields outside the ranges for which meaning in defined
R. Schroeppel, et al [Page 11] R. Schroeppel, et al [Page 11]
@@ -641,56 +641,56 @@ R. Schroeppel, et al [Page 11]
INTERNET-DRAFT ECC Keys in the DNS INTERNET-DRAFT ECC Keys in the DNS
in this document requires an IETF consensus as defined in [RFC 2434]. as an integer, and reduced (mod Q). (R must not be 0. In
this astronomically unlikely event, generate a new random K
and recalculate R.)
Copyright and Disclaimer
Copyright (C) The Internet Society 2004. This document is subject to
the rights, licenses and restrictions contained in BCP 78 and except
as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
S = ( K^(-1) * (hash + X*R) ) mod Q.
S must not be 0. In this astronomically unlikely event, generate a
new random K and recalculate R and S.
If S > Q/2, set S = Q - S.
The pair (R,S) is the signature.
Another party verifies the signature as follows:
Check that 0 < R < Q and 0 < S < Q/2. If not, it can not be a
valid EC sigature.
hash = SHA-1 ( data )
Sinv = S^(-1) mod Q.
U1 = (hash * Sinv) mod Q.
U2 = (R * Sinv) mod Q.
(U1 * G + U2 * Y) is computed on the elliptic curve.
V = (the W-coordinate of this point) interpreted as an integer
and reduced (mod Q).
The signature is valid if V = R.
The reason for requiring S < Q/2 is that, otherwise, both (R,S) and
(R,Q-S) would be valid signatures for the same data. Note that a
signature that is valid for hash(data) is also valid for
hash(data)+Q or hash(data)-Q, if these happen to fall in the range
[0,2^160-1]. It's believed to be computationally infeasible to
find data that hashes to an assigned value, so this is only a
cosmetic blemish. The blemish can be eliminated by using Q >
2^160, at the cost of having slightly longer signatures, 42 octets
instead of 40.
We must specify how a field-element E ("the W-coordinate") is to be
interpreted as an integer. The field-element E is regarded as a
radix-P integer, with the digits being the coefficients in the
polynomial basis representation of E. The digits are in the ragne
[0,P-1]. In the two most common cases, this reduces to "the
obvious thing". In the (mod P) case, E is simply a residue mod P,
and is taken as an integer in the range [0,P-1]. In the GF[2^D]
R. Schroeppel, et al [Page 12] R. Schroeppel, et al [Page 12]
@@ -699,53 +699,53 @@ R. Schroeppel, et al [Page 12]
INTERNET-DRAFT ECC Keys in the DNS INTERNET-DRAFT ECC Keys in the DNS
Informational References case, E is in the D-bit polynomial basis representation, and is
simply taken as an integer in the range [0,(2^D)-1]. For other
[RFC 1034] - P. Mockapetris, "Domain names - concepts and fields GF[P^D], it's necessary to do some radix conversion
facilities", 11/01/1987. arithmetic.
[RFC 1035] - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987.
[RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", 12/29/1994.
[RFC intro] - "DNS Security Introduction and Requirements", R.
Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in progress,
draft-ietf-dnsext-dnssec-intro-*.txt.
[RFC protocol] - "Protocol Modifications for the DNS Security
Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose,
work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt.
[RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)", August
1999.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons
[Menezes] - Alfred Menezes, "Elliptic Curve Public Key
Cryptosystems", 1993 Kluwer.
[Silverman] - Joseph Silverman, "The Arithmetic of Elliptic Curves",
1986, Springer Graduate Texts in mathematics #106.
Normative Refrences 6. Performance Considerations
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate Elliptic curve signatures use smaller moduli or field sizes than
Requirement Levels", March 1997. RSA and DSA. Creation of a curve is slow, but not done very often.
Key generation is faster than RSA or DSA.
[RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an DNS implementations have been optimized for small transfers,
IANA Considerations Section in RFCs", October 1998. typically less than 512 octets including DNS overhead. Larger
transfers will perform correctly and and extensions have been
[RFC records] - "Resource Records for the DNS Security Extensions", standardized to make larger transfers more efficient [RFC 2671].
R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in However, it is still advisable at this time to make reasonable
progress, draft-ietf-dnsext-dnssec-records- *.txt. efforts to minimize the size of RR sets stored within the DNS
consistent with adequate security.
7. Security Considerations
Keys retrieved from the DNS should not be trusted unless (1) they
have been securely obtained from a secure resolver or independently
verified by the user and (2) this secure resolver and secure
obtainment or independent verification conform to security policies
acceptable to the user. As with all cryptographic algorithms,
evaluating the necessary strength of the key is essential and
dependent on local policy.
Some specific key generation considerations are given in the body
of this document.
8. IANA Considerations
The key and signature data structures defined herein correspond to
the value 4 in the Algorithm number field of the IANA registry
Assignment of meaning to the remaining ECC data flag bits or to
values of ECC fields outside the ranges for which meaning in
defined in this document requires an IETF consensus as defined in
[RFC 2434].
@@ -757,33 +757,33 @@ R. Schroeppel, et al [Page 13]
INTERNET-DRAFT ECC Keys in the DNS INTERNET-DRAFT ECC Keys in the DNS
Authors Addresses Copyright and Disclaimer
Copyright (C) The Internet Society 2004. This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Rich Schroeppel
500 S. Maple Drive
Woodland Hills, UT 84653 USA
Telephone: 1-801-423-7998(h)
1-505-844-9079(w)
Email: rschroe@sandia.gov
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1 508-634-2066 (h)
+1 508-786-7554 (w)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in February 2004.
Its file name is draft-ietf-dnsext-ecc-key-05.txt.
@@ -812,3 +812,119 @@ Expiration and File Name
R. Schroeppel, et al [Page 14] R. Schroeppel, et al [Page 14]
INTERNET-DRAFT ECC Keys in the DNS
Informational References
[RFC 1034] - P. Mockapetris, "Domain names - concepts and
facilities", 11/01/1987.
[RFC 1035] - P. Mockapetris, "Domain names - implementation and
specification", 11/01/1987.
[RFC 1750] - D. Eastlake, S. Crocker, J. Schiller, "Randomness
Recommendations for Security", 12/29/1994.
[RFC intro] - "DNS Security Introduction and Requirements", R.
Arends, M. Larson, R. Austein, D. Massey, S. Rose, work in
progress, draft-ietf-dnsext-dnssec-intro-*.txt.
[RFC protocol] - "Protocol Modifications for the DNS Security
Extensions", R. Arends, M. Larson, R. Austein, D. Massey, S. Rose,
work in progress, draft-ietf-dnsext-dnssec-protocol-*.txt.
[RFC 2671] - P. Vixie, "Extension Mechanisms for DNS (EDNS0)",
August 1999.
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
Algorithms, and Source Code in C", 1996, John Wiley and Sons
[Menezes] - Alfred Menezes, "Elliptic Curve Public Key
Cryptosystems", 1993 Kluwer.
[Silverman] - Joseph Silverman, "The Arithmetic of Elliptic
Curves", 1986, Springer Graduate Texts in mathematics #106.
Normative Refrences
[RFC 2119] - S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC 2434] - T. Narten, H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", October 1998.
[RFC records] - "Resource Records for the DNS Security Extensions",
R. Arends, R. Austein, M. Larson, D. Massey, S. Rose, work in
progress, draft-ietf-dnsext-dnssec-records- *.txt.
R. Schroeppel, et al [Page 15]
INTERNET-DRAFT ECC Keys in the DNS
Author's Addresses
Rich Schroeppel
500 S. Maple Drive
Woodland Hills, UT 84653 USA
Telephone: +1-505-844-9079(w)
+1-801-423-7998(h)
Email: rschroe@sandia.gov
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street
Milford, MA 01757 USA
Telephone: +1 508-786-7554 (w)
+1 508-634-2066 (h)
EMail: Donald.Eastlake@motorola.com
Expiration and File Name
This draft expires in June 2004.
Its file name is draft-ietf-dnsext-ecc-key-06.txt.
R. Schroeppel, et al [Page 16]

1336
doc/draft/draft-ietf-dnsext-insensitive-04.txt → doc/draft/draft-ietf-dnsext-insensitive-05.txt
View File

File diff suppressed because it is too large Load Diff

730
doc/draft/draft-ietf-dnsext-mdns-37.txt → doc/draft/draft-ietf-dnsext-mdns-38.txt
View File

File diff suppressed because it is too large Load Diff

427
doc/draft/draft-ietf-dnsext-nsec3-00.txt → doc/draft/draft-ietf-dnsext-nsec3-01.txt
View File

@@ -1,13 +1,15 @@
Network Working Group B. Laurie Network Working Group B. Laurie
Internet-Draft G. Sisson Internet-Draft G. Sisson
Expires: July 2, 2005 Nominet Expires: August 2, 2005 Nominet
R. Arends R. Arends
Telematica Instituut Telematica Instituut
january 2005 february 2005
DNSSEC Hash Authenticated Denial of Existence DNSSEC Hash Authenticated Denial of Existence
draft-ietf-dnsext-nsec3-00 draft-ietf-dnsext-nsec3-01
Status of this Memo Status of this Memo
@@ -34,7 +36,7 @@ Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 2, 2005. This Internet-Draft will expire on August 2, 2005.
Copyright Notice Copyright Notice
@@ -48,8 +50,12 @@ Abstract
a listing of all ownernames. a listing of all ownernames.
Laurie, et al. Expires July 2, 2005 [Page 1]
Internet-Draft nsec3 january 2005
Laurie, et al. Expires August 2, 2005 [Page 1]
Internet-Draft nsec3 february 2005
A complete zone file can be used either directly as a source of A complete zone file can be used either directly as a source of
probable e-mail addresses for spam, or indirectly as a key for probable e-mail addresses for spam, or indirectly as a key for
@@ -64,28 +70,6 @@ Internet-Draft nsec3 january 2005
names. Non-authoritative delegation point NS RR types may be names. Non-authoritative delegation point NS RR types may be
excluded. excluded.
Laurie, et al. Expires July 2, 2005 [Page 2]
Internet-Draft nsec3 january 2005
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
@@ -104,26 +88,35 @@ Table of Contents
2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 8 2.2 The NSEC3 RR Presentation Format . . . . . . . . . . . . . 8
3. Creating Additional NSEC3 RR for Empty Non Terminals . . . . . 9 3. Creating Additional NSEC3 RR for Empty Non Terminals . . . . . 9
4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 9 4. Calculation of the Hash . . . . . . . . . . . . . . . . . . . 9
5. Special Considerations . . . . . . . . . . . . . . . . . . . . 9 5. Including NSEC3 RRs in a Zone . . . . . . . . . . . . . . . . 9
5.1 delegation points . . . . . . . . . . . . . . . . . . . . 10 6. Special Considerations . . . . . . . . . . . . . . . . . . . . 10
5.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 10 6.1 delegation points . . . . . . . . . . . . . . . . . . . . 10
5.2 Additional Complexity Caused by Wildcards . . . . . . . . 11 6.1.1 Unsigned Delegations . . . . . . . . . . . . . . . . . 11
5.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2 Additional Complexity Caused by Wildcards . . . . . . . . 11
5.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 11 6.3 Salting . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4.1 Avoiding Hash Collisions during generation . . . . . . 11 6.4 Hash Collision . . . . . . . . . . . . . . . . . . . . . . 12
5.4.2 Second Preimage Requirement Analysis . . . . . . . . . 11 6.4.1 Avoiding Hash Collisions during generation . . . . . . 12
5.4.3 Possible Hash Value Truncation Method . . . . . . . . 12 6.4.2 Second Preimage Requirement Analysis . . . . . . . . . 12
6. Performance Considerations . . . . . . . . . . . . . . . . . . 12 6.4.3 Possible Hash Value Truncation Method . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7. Performance Considerations . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9. Requirements notation . . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . 13 10. Requirements notation . . . . . . . . . . . . . . . . . . . 14
A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . 14
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 A. Example Zone . . . . . . . . . . . . . . . . . . . . . . . . . 14
11.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.2 Informative References . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 17
Laurie, et al. Expires August 2, 2005 [Page 2]
Internet-Draft nsec3 february 2005
12.1 Normative References . . . . . . . . . . . . . . . . . . . . 15
12.2 Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . 18
@@ -131,8 +124,50 @@ Table of Contents
Laurie, et al. Expires July 2, 2005 [Page 3]
Internet-Draft nsec3 january 2005
Laurie, et al. Expires August 2, 2005 [Page 3]
Internet-Draft nsec3 february 2005
1. Introduction 1. Introduction
@@ -184,10 +219,13 @@ Internet-Draft nsec3 january 2005
ownername. Because this proposal uses the result of a hash function ownername. Because this proposal uses the result of a hash function
Laurie, et al. Expires July 2, 2005 [Page 4]
Internet-Draft nsec3 january 2005
over the original (unmodified) ownername, this result is refered to Laurie, et al. Expires August 2, 2005 [Page 4]
Internet-Draft nsec3 february 2005
over the original (unmodified) ownername, this result is referred to
as "hashed ownername". as "hashed ownername".
2. The NSEC3 Resource Record 2. The NSEC3 Resource Record
@@ -235,8 +273,13 @@ Internet-Draft nsec3 january 2005
Laurie, et al. Expires July 2, 2005 [Page 5]
Internet-Draft nsec3 january 2005
Laurie, et al. Expires August 2, 2005 [Page 5]
Internet-Draft nsec3 february 2005
2.1.1 The Authoritative Only Flag Field 2.1.1 The Authoritative Only Flag Field
@@ -258,7 +301,7 @@ Internet-Draft nsec3 january 2005
ownername MUST be set if the NSEC3 covers a delegation, even though ownername MUST be set if the NSEC3 covers a delegation, even though
the NS RR itself is not authoritative. This implies that all the NS RR itself is not authoritative. This implies that all
delegations, signed or unsigned, have an NSEC3 record associated. delegations, signed or unsigned, have an NSEC3 record associated.
This behavior is identical to NSEC behavior. This behaviour is identical to NSEC behaviour.
2.1.2 The Hash Function Field 2.1.2 The Hash Function Field
@@ -288,8 +331,11 @@ Internet-Draft nsec3 january 2005
of 0. of 0.
Laurie, et al. Expires July 2, 2005 [Page 6]
Internet-Draft nsec3 january 2005 Laurie, et al. Expires August 2, 2005 [Page 6]
Internet-Draft nsec3 february 2005
The salt field is prepended to the original ownername before hashing The salt field is prepended to the original ownername before hashing
in order to defend against precalculated dictionary attacks. in order to defend against precalculated dictionary attacks.
@@ -340,8 +386,12 @@ Internet-Draft nsec3 january 2005
Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) + Type Bit Map(s) Field = ( Window Block # | Bitmap Length | Bitmap ) +
Laurie, et al. Expires July 2, 2005 [Page 7]
Internet-Draft nsec3 january 2005
Laurie, et al. Expires August 2, 2005 [Page 7]
Internet-Draft nsec3 february 2005
Each bitmap encodes the low-order 8 bits of RR types within the Each bitmap encodes the low-order 8 bits of RR types within the
window block, in network bit order. The first bit is bit 0. For window block, in network bit order. The first bit is bit 0. For
@@ -373,7 +423,7 @@ Internet-Draft nsec3 january 2005
bitmap is determined by the type code with the largest numerical bitmap is determined by the type code with the largest numerical
value, within that block, among the set of RR types present at the value, within that block, among the set of RR types present at the
NSEC3 RR's actual ownername. Trailing zero octets not specified MUST NSEC3 RR's actual ownername. Trailing zero octets not specified MUST
be interpretted as zero octets. be interpreted as zero octets.
2.2 The NSEC3 RR Presentation Format 2.2 The NSEC3 RR Presentation Format
@@ -393,8 +443,11 @@ Internet-Draft nsec3 january 2005
hexadecimal digits. Whitespace is not allowed within the sequence. hexadecimal digits. Whitespace is not allowed within the sequence.
Laurie, et al. Expires July 2, 2005 [Page 8]
Internet-Draft nsec3 january 2005 Laurie, et al. Expires August 2, 2005 [Page 8]
Internet-Draft nsec3 february 2005
The Salt Field is represented as 00 when the Salt Length field has The Salt Field is represented as 00 when the Salt Length field has
value 0. value 0.
@@ -409,7 +462,7 @@ Internet-Draft nsec3 january 2005
3. Creating Additional NSEC3 RR for Empty Non Terminals 3. Creating Additional NSEC3 RR for Empty Non Terminals
In order to prove the nonexistence of a record that might be covered In order to prove the non-existence of a record that might be covered
by a wildcard, it is necessary to prove the existence of its closest by a wildcard, it is necessary to prove the existence of its closest
encloser. A closest encloser might be an Empty Non Terminal. encloser. A closest encloser might be an Empty Non Terminal.
@@ -441,27 +494,82 @@ Internet-Draft nsec3 january 2005
original unexpanded form, including the "*" label (no wildcard original unexpanded form, including the "*" label (no wildcard
substitution); substitution);
5. Special Considerations 5. Including NSEC3 RRs in a Zone
The following paragraphs clarify specific behavior explain special Each owner name in the zone which has authoritative data or a secured
Laurie, et al. Expires July 2, 2005 [Page 9]
Internet-Draft nsec3 january 2005
Laurie, et al. Expires August 2, 2005 [Page 9]
Internet-Draft nsec3 february 2005
delegation point NS RRset MUST have an NSEC3 resource record.
An unsecured delegation point NS RRset MAY have an NSEC3 resource
record. This is different from NSEC records where an unsecured
delegation point NS RRset MUST have an NSEC record.
The TTL value for any NSEC3 RR SHOULD be the same as the minimum TTL
value field in the zone SOA RR.
The type bitmap of every NSEC3 resource record in a signed zone MUST
indicate the presence of both the NSEC3 record itself and its
corresponding RRSIG record.
The bitmap for the NSEC3 RR at a delegation point requires special
attention. Bits corresponding to the delegation NS RRset and any
RRsets for which the parent zone has authoritative data MUST be set;
bits corresponding to any non-NS RRset for which the parent is not
authoritative MUST be clear.
The following steps describe the proper construction of NSEC3
records.
1. Sort the zone in canonical order.
2. For each unique original owner name, add a NSEC3 RRset, where the
ownername of the NSEC3 RR is the hashed equivalent of the
original owner name, prepended to the zone name.
3. For each RRset at the original owner, set the corresponding bit
in the type bit map. If the RRset signifies an unsecured
delegation point, and the policy is to have Authoritative Only
RRsets, mark this NSEC3 RR.
4. If the difference in labels between the apex and the original
ownername is greater then 1, additional NSEC3 need to be added
for every intermediate label level between the apex and the
original ownername.
5. sort the set of NSEC3 RRs.
6. In each NSEC3 RR, insert the Next Hashed Ownername. If the next
hashed ownername is a marked NSEC3 (from step 3), delete the
marked NSEC3 from the zone, set the Authoritative Only bit in the
current NSEC3 RRs, and repeat this step. The last NSEC3 in the
zone will contain the value of the first NSEC3 in the zone.
6. Special Considerations
The following paragraphs clarify specific behaviour explain special
considerations for implementations. considerations for implementations.
5.1 delegation points 6.1 delegation points
This proposal introduces the Authoritative Only Flag which indicates This proposal introduces the Authoritative Only Flag which indicates
Laurie, et al. Expires August 2, 2005 [Page 10]
Internet-Draft nsec3 february 2005
whether non authoritative delegation point NS records are included in whether non authoritative delegation point NS records are included in
the type bit Maps. As discussed in paragraph 2.1.1, a flag value of the type bit Maps. As discussed in paragraph 2.1.1, a flag value of
0 indicates that the interpretation of the type bit maps is identical 0 indicates that the interpretation of the type bit maps is identical
to NSEC records. to NSEC records.
The following subsections describe behavior when the flag value is 1. The following subsections describe behaviour when the flag value is
1.
5.1.1 Unsigned Delegations 6.1.1 Unsigned Delegations
Delegation point NS records are not authoritative. They are Delegation point NS records are not authoritative. They are
authoritative in the delegated zone. No other data exists at the authoritative in the delegated zone. No other data exists at the
@@ -498,13 +606,17 @@ Internet-Draft nsec3 january 2005
The only possible mitigation is to either not use this method, hence The only possible mitigation is to either not use this method, hence
proving absence of unsigned delegations. proving absence of unsigned delegations.
6.2 Additional Complexity Caused by Wildcards
Laurie, et al. Expires July 2, 2005 [Page 10]
Internet-Draft nsec3 january 2005
5.2 Additional Complexity Caused by Wildcards
If a wildcard ownername appears in a zone, the wildcard label ("*") If a wildcard ownername appears in a zone, the wildcard label ("*")
Laurie, et al. Expires August 2, 2005 [Page 11]
Internet-Draft nsec3 february 2005
is treated as a literal symbol and is treated in the same way as any is treated as a literal symbol and is treated in the same way as any
other ownername for purposes of generating NSEC3 RRs. RFC 2535 other ownername for purposes of generating NSEC3 RRs. RFC 2535
[RFC2525] describes the impact of wildcards on authenticated denial [RFC2525] describes the impact of wildcards on authenticated denial
@@ -512,10 +624,10 @@ Internet-Draft nsec3 january 2005
In order to prove there are no wildcards for a domain, as well as no In order to prove there are no wildcards for a domain, as well as no
RRs that match directly, an RR must be shown for the closest RRs that match directly, an RR must be shown for the closest
encloser, and nonexistence must be shown for all enclosers that could encloser, and non-existence must be shown for all enclosers that
be closer. could be closer.
5.3 Salting 6.3 Salting
Augmenting original ownernames with salt before hashing increases the Augmenting original ownernames with salt before hashing increases the
cost of a dictionary of pre-generated hash-values. For every bit of cost of a dictionary of pre-generated hash-values. For every bit of
@@ -525,7 +637,7 @@ Internet-Draft nsec3 january 2005
The salt value for each NSEC3 RR MUST be equal for a single version The salt value for each NSEC3 RR MUST be equal for a single version
of the zone. of the zone.
5.4 Hash Collision 6.4 Hash Collision
Hash collisions occur when different messages have the same hash Hash collisions occur when different messages have the same hash
value. The expected number of domain names needed to give a 1 in 2 value. The expected number of domain names needed to give a 1 in 2
@@ -534,30 +646,33 @@ Internet-Draft nsec3 january 2005
collisions and assessing possible damage in the event of an attack collisions and assessing possible damage in the event of an attack
using Hash collisions. using Hash collisions.
5.4.1 Avoiding Hash Collisions during generation 6.4.1 Avoiding Hash Collisions during generation
During generation of NSEC3 RRs, hash values are supposedly unique. During generation of NSEC3 RRs, hash values are supposedly unique.
In the (academic) case of a collision occuring, an alternative salt In the (academic) case of a collision occurring, an alternative salt
SHOULD be chosen and all hash values SHOULD be regenerated. SHOULD be chosen and all hash values SHOULD be regenerated.
If hash values are not regenerated on collision, the NSEC3 RR MUST If hash values are not regenerated on collision, the NSEC3 RR MUST
list all authoritative RR types that exist for both owners, to avoid list all authoritative RR types that exist for both owners, to avoid
a replay attack, spoofing an existing type as non-existent. a replay attack, spoofing an existing type as non-existent.
5.4.2 Second Preimage Requirement Analysis 6.4.2 Second Preimage Requirement Analysis
A collision resistant hash function has a second-preimage resistance A collision resistant hash function has a second-preimage resistance
property. The second-preimage resistance property means that it is property. The second-preimage resistance property means that it is
computationally infeasible to find another message with the same hash computationally infeasible to find another message with the same hash
value as a given message, i.e. given preimage X, to find a second value as a given message, i.e. given preimage X, to find a second
Laurie, et al. Expires July 2, 2005 [Page 11]
Internet-Draft nsec3 january 2005
preimage X' <> X such that hash(X) = hash(X'). The probability of preimage X' <> X such that hash(X) = hash(X'). The probability of
finding a second preimage is 1 in 2^160 for SHA-1 on average. To finding a second preimage is 1 in 2^160 for SHA-1 on average. To
mount an attack using an existing NSEC3 RR, an adversary needs to mount an attack using an existing NSEC3 RR, an adversary needs to
Laurie, et al. Expires August 2, 2005 [Page 12]
Internet-Draft nsec3 february 2005
find a second preimage. find a second preimage.
Assuming an adversary is capable of mounting such an extreme attack, Assuming an adversary is capable of mounting such an extreme attack,
@@ -569,7 +684,7 @@ Internet-Draft nsec3 january 2005
adversary can't mount this attack on an existing name but only on a adversary can't mount this attack on an existing name but only on a
name that the adversary can't choose and does not yet exist. name that the adversary can't choose and does not yet exist.
5.4.3 Possible Hash Value Truncation Method 6.4.3 Possible Hash Value Truncation Method
The previous sections outlined the low probability and low impact of The previous sections outlined the low probability and low impact of
a second-preimage attack. When impact and probability are low, while a second-preimage attack. When impact and probability are low, while
@@ -593,25 +708,28 @@ Internet-Draft nsec3 january 2005
and limited space in DNS messages, the balance between truncation and limited space in DNS messages, the balance between truncation
profit and collision damage may be determined by local policy. profit and collision damage may be determined by local policy.
6. Performance Considerations 7. Performance Considerations
Iterated hashes will obviously impose a performance penalty on both Iterated hashes will obviously impose a performance penalty on both
authoritative servers and resolvers. Therefore, the number of authoritative servers and resolvers. Therefore, the number of
iterations should be carefully chosen. iterations should be carefully chosen.
7. IANA Considerations 8. IANA Considerations
IANA has to create a new registry for NSEC3 Hash Functions. The IANA has to create a new registry for NSEC3 Hash Functions. The
range for this registry is 0-127. Value 1 is marked as SHA-1. range for this registry is 0-127. Value 1 is marked as SHA-1.
Laurie, et al. Expires July 2, 2005 [Page 12]
Internet-Draft nsec3 january 2005
Values 0, 2-126 are marked as Reserved For Future Use. Value 127 is Values 0, 2-126 are marked as Reserved For Future Use. Value 127 is
marked as Experimental. marked as Experimental.
8. Security Considerations
Laurie, et al. Expires August 2, 2005 [Page 13]
Internet-Draft nsec3 february 2005
9. Security Considerations
The NSEC3 records are still susceptible to dictionary attacks (i.e. The NSEC3 records are still susceptible to dictionary attacks (i.e.
the attacker retrieves all the NSEC3 records, then calculates the the attacker retrieves all the NSEC3 records, then calculates the
@@ -635,17 +753,17 @@ Internet-Draft nsec3 january 2005
found. found.
Hash collisions may occur. If they do, it will be impossible to Hash collisions may occur. If they do, it will be impossible to
prove the nonexistence of the colliding domain - however, this is prove the non-existence of the colliding domain - however, this is
fantastically unlikely, and, in any case, DNSSEC already relies on fantastically unlikely, and, in any case, DNSSEC already relies on
SHA-1 to not collide. SHA-1 to not collide.
9. Requirements notation 10. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
10. Security Considerations 11. Security Considerations
Appendix A. Example Zone Appendix A. Example Zone
@@ -655,48 +773,58 @@ Appendix A. Example Zone
Laurie, et al. Expires July 2, 2005 [Page 13]
Internet-Draft nsec3 january 2005
example.com. 1000 IN SOA localhost.
postmaster.localhost.example.com. (
1 ; serial
3600 ; refresh (1 hour)
1800 ; retry (30 minutes)
604800 ; expire (1 week)
3600 ; minimum (1 hour) Laurie, et al. Expires August 2, 2005 [Page 14]
)
1000 NS ns1.example.com. Internet-Draft nsec3 february 2005
1000 NS ns2.example.com.
example.com. 1000 IN SOA localhost.
postmaster.localhost.example.com. (
1 ; serial
3600 ; refresh (1 hour)
1800 ; retry (30 minutes)
604800 ; expire (1 week)
3600 ; minimum (1 hour)
)
1000 NS ns1.example.com.
1000 NS ns2.example.com.
f519593e82969842a136e0f47814c881fa163833.example.com. 3600 IN NSEC3 \ f519593e82969842a136e0f47814c881fa163833.example.com. 3600 IN NSEC3 \
SHA-1 200 31323334 4EF8239D95C18403A509D7C336A5D0FA48FD1107 \ SHA-1 200 31323334 4EF8239D95C18403A509D7C336A5D0FA48FD1107 \
NS SOA RRSIG DNSKEY NSEC3 NS SOA RRSIG DNSKEY NSEC3
a.example.com. 1000 IN A 1.2.3.4 a.example.com. 1000 IN A 1.2.3.4
1000 IN A 1.2.3.5 1000 IN A 1.2.3.5
1000 TXT "An example" 1000 TXT "An example"
bfe6ea21dee9d228889ae11fa58c4bd551d15801.example.com. 3600 IN NSEC3 \ bfe6ea21dee9d228889ae11fa58c4bd551d15801.example.com. 3600 IN NSEC3 \
SHA-1 200 31323334 F519593E82969842A136E0F47814C881FA163833 \ SHA-1 200 31323334 F519593E82969842A136E0F47814C881FA163833 \
A TXT RRSIG NSEC3 A TXT RRSIG NSEC3
b.example.com. 1000 IN A 1.2.3.7 b.example.com. 1000 IN A 1.2.3.7
83c06d3b7d01fbc9576c71af2bec1a1163435153.example.com. 3600 IN NSEC3 \ 83c06d3b7d01fbc9576c71af2bec1a1163435153.example.com. 3600 IN NSEC3 \
SHA-1 200 31323334 A33559360EECB02F36B5C1B72C109126CA4F5A0D \ SHA-1 200 31323334 A33559360EECB02F36B5C1B72C109126CA4F5A0D \
A RRSIG NSEC3 A RRSIG NSEC3
a.b.c.example.com. 1000 IN A 1.2.3.6 a.b.c.example.com. 1000 IN A 1.2.3.6
a33559360eecb02f36b5c1b72c109126ca4f5a0d.example.com. 3600 IN NSEC3 \ a33559360eecb02f36b5c1b72c109126ca4f5a0d.example.com. 3600 IN NSEC3 \
SHA-1 200 31323334 BFE6EA21DEE9D228889AE11FA58C4BD551D15801 \ SHA-1 200 31323334 BFE6EA21DEE9D228889AE11FA58C4BD551D15801 \
A RRSIG NSEC3 A RRSIG NSEC3
ns1.example.com. 1000 IN A 1.2.3.8 ns1.example.com. 1000 IN A 1.2.3.8
4ef8239d95c18403a509d7c336a5d0fa48fd1107.example.com. 3600 IN NSEC3 \ 4ef8239d95c18403a509d7c336a5d0fa48fd1107.example.com. 3600 IN NSEC3 \
SHA-1 200 31323334 50016B56FD2F0FFC7B563C50FAF0E34259763BBB \ SHA-1 200 31323334 50016B56FD2F0FFC7B563C50FAF0E34259763BBB \
A RRSIG NSEC3 A RRSIG NSEC3
ns2.example.com. 1000 IN A 1.2.3.9 ns2.example.com. 1000 IN A 1.2.3.9
50016b56fd2f0ffc7b563c50faf0e34259763bbb.example.com. 3600 IN NSEC3 \ 50016b56fd2f0ffc7b563c50faf0e34259763bbb.example.com. 3600 IN NSEC3 \
SHA-1 200 31323334 83C06D3B7D01FBC9576C71AF2BEC1A1163435153 \ SHA-1 200 31323334 83C06D3B7D01FBC9576C71AF2BEC1A1163435153 \
A RRSIG NSEC3 A RRSIG NSEC3
11. References
11.1 Normative References 12. References
12.1 Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
@@ -707,8 +835,11 @@ Internet-Draft nsec3 january 2005
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Laurie, et al. Expires July 2, 2005 [Page 14]
Internet-Draft nsec3 january 2005 Laurie, et al. Expires August 2, 2005 [Page 15]
Internet-Draft nsec3 february 2005
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
@@ -725,7 +856,7 @@ Internet-Draft nsec3 january 2005
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999. RFC 2535, March 1999.
11.2 Informative References 12.2 Informative References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision [RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996. 3", BCP 9, RFC 2026, October 1996.
@@ -738,6 +869,7 @@ Internet-Draft nsec3 january 2005
Rollover Algorithm and a Out-Of-Band Priming Method for Rollover Algorithm and a Out-Of-Band Priming Method for
DNS Trust Anchors.", July 2004. DNS Trust Anchors.", July 2004.
Authors' Addresses Authors' Addresses
Ben Laurie Ben Laurie
@@ -749,14 +881,21 @@ Authors' Addresses
Phone: +44 (20) 8735 0686 Phone: +44 (20) 8735 0686
EMail: ben@algroup.co.uk EMail: ben@algroup.co.uk
Geoffrey Sisson Geoffrey Sisson
Nominet Nominet
Laurie, et al. Expires July 2, 2005 [Page 15]
Internet-Draft nsec3 january 2005
Laurie, et al. Expires August 2, 2005 [Page 16]
Internet-Draft nsec3 february 2005
Roy Arends Roy Arends
Telematica Instituut Telematica Instituut
@@ -788,8 +927,31 @@ Internet-Draft nsec3 january 2005
Laurie, et al. Expires July 2, 2005 [Page 16]
Internet-Draft nsec3 january 2005
Laurie, et al. Expires August 2, 2005 [Page 17]
Internet-Draft nsec3 february 2005
Intellectual Property Statement Intellectual Property Statement
@@ -815,6 +977,7 @@ Intellectual Property Statement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity Disclaimer of Validity
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
@@ -825,16 +988,22 @@ Disclaimer of Validity
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
Laurie, et al. Expires July 2, 2005 [Page 17]
Laurie, et al. Expires August 2, 2005 [Page 18]

253
doc/draft/draft-ietf-dnsext-rfc2538bis-00.txt → doc/draft/draft-ietf-dnsext-rfc2538bis-01.txt
View File

@@ -1,11 +1,12 @@
Network Working Group S. Josefsson Network Working Group S. Josefsson
Internet-Draft January 24, 2005 Internet-Draft January 2005
Expires: July 25, 2005 Expires: July 2, 2005
Storing Certificates in the Domain Name System (DNS) Storing Certificates in the Domain Name System (DNS)
draft-ietf-dnsext-rfc2538bis-00 draft-ietf-dnsext-rfc2538bis-01
Status of this Memo Status of this Memo
@@ -32,7 +33,7 @@ Status of this Memo
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 25, 2005. This Internet-Draft will expire on July 2, 2005.
Copyright Notice Copyright Notice
@@ -51,7 +52,7 @@ Abstract
Josefsson Expires July 25, 2005 [Page 1] Josefsson Expires July 2, 2005 [Page 1]
Internet-Draft Storing Certificates in the DNS January 2005 Internet-Draft Storing Certificates in the DNS January 2005
@@ -62,23 +63,24 @@ Table of Contents
2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3 2. The CERT Resource Record . . . . . . . . . . . . . . . . . . . 3
2.1 Certificate Type Values . . . . . . . . . . . . . . . . . 4 2.1 Certificate Type Values . . . . . . . . . . . . . . . . . 4
2.2 Text Representation of CERT RRs . . . . . . . . . . . . . 5 2.2 Text Representation of CERT RRs . . . . . . . . . . . . . 5
2.3 X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 X.509 OIDs . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6 3. Appropriate Owner Names for CERT RRs . . . . . . . . . . . . . 6
3.1 Content-based X.509 CERT RR Names . . . . . . . . . . . . 7 3.1 Content-based X.509 CERT RR Names . . . . . . . . . . . . 7
3.2 Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8 3.2 Purpose-based X.509 CERT RR Names . . . . . . . . . . . . 8
3.3 Content-based OpenPGP CERT RR Names . . . . . . . . . . . 8 3.3 Content-based OpenPGP CERT RR Names . . . . . . . . . . . 8
3.4 Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9 3.4 Purpose-based OpenPGP CERT RR Names . . . . . . . . . . . 9
3.5 Owner names for IPKIX, ISPKI, and IPGP . . . . . . . . . . 9
4. Performance Considerations . . . . . . . . . . . . . . . . . . 9 4. Performance Considerations . . . . . . . . . . . . . . . . . . 9
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11 8. Changes since RFC 2538 . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 11
9.2 Informative References . . . . . . . . . . . . . . . . . . . 12 9.2 Informative References . . . . . . . . . . . . . . . . . . . 12
A. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 12 A. Copying conditions . . . . . . . . . . . . . . . . . . . . . . 12
Intellectual Property and Copyright Statements . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14
@@ -106,8 +108,7 @@ Table of Contents
Josefsson Expires July 2, 2005 [Page 2]
Josefsson Expires July 25, 2005 [Page 2]
Internet-Draft Storing Certificates in the DNS January 2005 Internet-Draft Storing Certificates in the DNS January 2005
@@ -163,7 +164,7 @@ Internet-Draft Storing Certificates in the DNS January 2005
Josefsson Expires July 25, 2005 [Page 3] Josefsson Expires July 2, 2005 [Page 3]
Internet-Draft Storing Certificates in the DNS January 2005 Internet-Draft Storing Certificates in the DNS January 2005
@@ -190,7 +191,10 @@ Internet-Draft Storing Certificates in the DNS January 2005
1 PKIX X.509 as per PKIX 1 PKIX X.509 as per PKIX
2 SPKI SPKI certificate 2 SPKI SPKI certificate
3 PGP OpenPGP packet 3 PGP OpenPGP packet
4-252 available for IANA assignment 4 IPKIX The URL of an X.509 data object
5 ISPKI The URL of an SPKI certificate
6 IPGP The URL of an OpenPGP packet
7-252 available for IANA assignment
253 URI URI private 253 URI URI private
254 OID OID private 254 OID OID private
255-65534 available for IANA assignment 255-65534 available for IANA assignment
@@ -213,17 +217,25 @@ Internet-Draft Storing Certificates in the DNS January 2005
transferable public keys as described in section 10.1 of [5], but it transferable public keys as described in section 10.1 of [5], but it
MAY handle additional OpenPGP packets. MAY handle additional OpenPGP packets.
The URI private type indicates a certificate format defined by an
absolute URI. The certificate portion of the CERT RR MUST begin with
a null terminated URI [4] and the data after the null is the private
Josefsson Expires July 25, 2005 [Page 4] Josefsson Expires July 2, 2005 [Page 4]
Internet-Draft Storing Certificates in the DNS January 2005 Internet-Draft Storing Certificates in the DNS January 2005
The IPKIX, ISPKI and IPGP types indicate a URL which will serve the
content that would have been in the "certificate, CRL or URL" field
of the corresponding (PKIX, SPKI or PGP) packet types. These types
are known as "indirect". These packet types MUST be used when the
content is too large to fit in the CERT RR, and MAY be used at the
implementations discretion. They SHOULD NOT be used where the entire
UDP packet would have fit in 512 bytes.
The URI private type indicates a certificate format defined by an
absolute URI. The certificate portion of the CERT RR MUST begin with
a null terminated URI [4] and the data after the null is the private
format certificate itself. The URI SHOULD be such that a retrieval format certificate itself. The URI SHOULD be such that a retrieval
from it will lead to documentation on the format of the certificate. from it will lead to documentation on the format of the certificate.
Recognition of private certificate types need not be based on URI Recognition of private certificate types need not be based on URI
@@ -261,6 +273,14 @@ Internet-Draft Storing Certificates in the DNS January 2005
Note that the certificate / CRL portion may have internal sub-fields Note that the certificate / CRL portion may have internal sub-fields
but these do not appear in the master file representation. For but these do not appear in the master file representation. For
example, with type 254, there will be an OID size, an OID, and then example, with type 254, there will be an OID size, an OID, and then
Josefsson Expires July 2, 2005 [Page 5]
Internet-Draft Storing Certificates in the DNS January 2005
the certificate / CRL proper. But only a single logical base 64 the certificate / CRL proper. But only a single logical base 64
string will appear in the text representation. string will appear in the text representation.
@@ -272,14 +292,6 @@ Internet-Draft Storing Certificates in the DNS January 2005
The following table lists the OIDs, their BER encoding, and their The following table lists the OIDs, their BER encoding, and their
length prefixed hex format for use in CERT RRs: length prefixed hex format for use in CERT RRs:
Josefsson Expires July 25, 2005 [Page 5]
Internet-Draft Storing Certificates in the DNS January 2005
id-at-userCertificate id-at-userCertificate
= { joint-iso-ccitt(2) ds(5) at(4) 36 } = { joint-iso-ccitt(2) ds(5) at(4) 36 }
== 0x 03 55 04 24 == 0x 03 55 04 24
@@ -315,8 +327,16 @@ Internet-Draft Storing Certificates in the DNS January 2005
key. Further, the client might only know the hostname of a service key. Further, the client might only know the hostname of a service
that uses X.509 certificates or the Key ID of an OpenPGP key. that uses X.509 certificates or the Key ID of an OpenPGP key.
This motivate describing two different owner name guidelines. We This motivates describing two different owner name guidelines. We
call the two rules content-based owner names and purpose-based owner call the two rules content-based owner names and purpose-based owner
Josefsson Expires July 2, 2005 [Page 6]
Internet-Draft Storing Certificates in the DNS January 2005
names. A content-based owner name is derived from the content of the names. A content-based owner name is derived from the content of the
CERT RR data; for example the Subject field in an X.509 certificate CERT RR data; for example the Subject field in an X.509 certificate
or the User ID field in OpenPGP keys. A purpose-based owner name is or the User ID field in OpenPGP keys. A purpose-based owner name is
@@ -328,14 +348,6 @@ Internet-Draft Storing Certificates in the DNS January 2005
incoming e-mail. incoming e-mail.
Implementations SHOULD use the purpose-based owner name guidelines Implementations SHOULD use the purpose-based owner name guidelines
Josefsson Expires July 25, 2005 [Page 6]
Internet-Draft Storing Certificates in the DNS January 2005
described in this document, and MAY use CNAMEs at content-based owner described in this document, and MAY use CNAMEs at content-based owner
names (or other names), pointing to the purpose-based owner name. names (or other names), pointing to the purpose-based owner name.
@@ -368,11 +380,19 @@ Internet-Draft Storing Certificates in the DNS January 2005
3. If neither of the above it used but a URI containing a domain 3. If neither of the above it used but a URI containing a domain
name is present, that domain name should be used. name is present, that domain name should be used.
4. If none of the above is included but a character string name is 4. If none of the above is included but a character string name is
included, then it should be treated as described for PGP names included, then it should be treated as described for OpenPGP
below. names below.
5. If none of the above apply, then the distinguished name (DN) 5. If none of the above apply, then the distinguished name (DN)
should be mapped into a domain name as specified in [3]. should be mapped into a domain name as specified in [3].
Josefsson Expires July 2, 2005 [Page 7]
Internet-Draft Storing Certificates in the DNS January 2005
Example 1: Assume that an X.509v3 certificate is issued to /CN=John Example 1: Assume that an X.509v3 certificate is issued to /CN=John
Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative Doe/DC=Doe/DC=com/DC=xy/O=Doe Inc/C=XY/ with Subject Alternative
names of (a) string "John (the Man) Doe", (b) domain name john- names of (a) string "John (the Man) Doe", (b) domain name john-
@@ -384,14 +404,6 @@ Internet-Draft Storing Certificates in the DNS January 2005
Example 2: Assume that an X.509v3 certificate is issued to /CN=James Example 2: Assume that an X.509v3 certificate is issued to /CN=James
Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names
Josefsson Expires July 25, 2005 [Page 7]
Internet-Draft Storing Certificates in the DNS January 2005
of (a) domain name widget.foo.example, (b) IPv4 address of (a) domain name widget.foo.example, (b) IPv4 address
10.251.13.201, and (c) string "James Hacker 10.251.13.201, and (c) string "James Hacker
<hacker@mail.widget.foo.example>". Then the storage locations <hacker@mail.widget.foo.example>". Then the storage locations
@@ -424,12 +436,19 @@ Internet-Draft Storing Certificates in the DNS January 2005
IPSEC Certificate Hostname of the IPSEC machine, and/or IPSEC Certificate Hostname of the IPSEC machine, and/or
for the in-addr.arpa reverse lookup IP address. for the in-addr.arpa reverse lookup IP address.
CRLs Hostname of the issuing CA. An alternative approach for IPSEC is to store raw public keys [12].
3.3 Content-based OpenPGP CERT RR Names 3.3 Content-based OpenPGP CERT RR Names
OpenPGP signed keys (certificates) use a general character string OpenPGP signed keys (certificates) use a general character string
Josefsson Expires July 2, 2005 [Page 8]
Internet-Draft Storing Certificates in the DNS January 2005
User ID [5]. However, it is recommended by OpenPGP that such names User ID [5]. However, it is recommended by OpenPGP that such names
include the RFC 2822 [7] email address of the party, as in "Leslie include the RFC 2822 [7] email address of the party, as in "Leslie
Example <Leslie@host.example>". If such a format is used, the CERT Example <Leslie@host.example>". If such a format is used, the CERT
@@ -441,13 +460,6 @@ Internet-Draft Storing Certificates in the DNS January 2005
If a user has more than one email address, the CNAME type can be used If a user has more than one email address, the CNAME type can be used
to reduce the amount of data stored in the DNS. For example: to reduce the amount of data stored in the DNS. For example:
Josefsson Expires July 25, 2005 [Page 8]
Internet-Draft Storing Certificates in the DNS January 2005
$ORIGIN example.org. $ORIGIN example.org.
smith IN CERT PGP 0 0 <OpenPGP binary> smith IN CERT PGP 0 0 <OpenPGP binary>
john.smith IN CNAME smith john.smith IN CNAME smith
@@ -456,15 +468,15 @@ Internet-Draft Storing Certificates in the DNS January 2005
3.4 Purpose-based OpenPGP CERT RR Names 3.4 Purpose-based OpenPGP CERT RR Names
Applications that receive an OpenPGP packet but do not know the email Applications that receive an OpenPGP packet containing encrypted or
address of the sender will have difficulties constructing the correct signed data but do not know the email address of the sender will have
owner name, and cannot use the content-based owner name guidelines. difficulties constructing the correct owner name and cannot use the
However, these clients commonly know the key fingerprint or the Key content-based owner name guidelines. However, these clients commonly
ID. The key ID is found in OpenPGP packets, and the key fingerprint know the key fingerprint or the Key ID. The key ID is found in
is commonly found in auxilliary data that may be available. For OpenPGP packets, and the key fingerprint is commonly found in
these situations, it is recommended to use an owner name identical to auxilliary data that may be available. For these situations, it is
the key fingerprint and key ID expressed in hexadecimal [11]. For recommended to use an owner name identical to the key fingerprint and
example: key ID expressed in hexadecimal [11]. For example:
$ORIGIN example.org. $ORIGIN example.org.
0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ... 0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
@@ -477,9 +489,22 @@ Internet-Draft Storing Certificates in the DNS January 2005
purposes, and this may be sub-optimal when two keys with the same Key purposes, and this may be sub-optimal when two keys with the same Key
ID are stored. ID are stored.
3.5 Owner names for IPKIX, ISPKI, and IPGP
These types are stored under the same owner names, both purpose- and
content-based, as the PKIX, SPKI and PGP types, respectively.
4. Performance Considerations 4. Performance Considerations
Current Domain Name System (DNS) implementations are optimized for Current Domain Name System (DNS) implementations are optimized for
Josefsson Expires July 2, 2005 [Page 9]
Internet-Draft Storing Certificates in the DNS January 2005
small transfers, typically not more than 512 bytes including small transfers, typically not more than 512 bytes including
overhead. While larger transfers will perform correctly and work is overhead. While larger transfers will perform correctly and work is
underway to make larger transfers more efficient, it is still underway to make larger transfers more efficient, it is still
@@ -493,16 +518,7 @@ Internet-Draft Storing Certificates in the DNS January 2005
octets (64kb) or less. This means that each CERT RR cannot contain octets (64kb) or less. This means that each CERT RR cannot contain
more than 64kb worth of payload, even if the corresponding more than 64kb worth of payload, even if the corresponding
certificate or certificate revocation list is larger. This document certificate or certificate revocation list is larger. This document
do not address this limitation. address this by defining "indirect" data types for each normal type.
Josefsson Expires July 25, 2005 [Page 9]
Internet-Draft Storing Certificates in the DNS January 2005
5. Acknowledgements 5. Acknowledgements
@@ -513,10 +529,9 @@ Internet-Draft Storing Certificates in the DNS January 2005
contributions to the earlier work that motivated this revised contributions to the earlier work that motivated this revised
document. document.
Florian Weimer suggested to clarify wording regarding what data can This document was improved by suggestions and comments from Olivier
be stored in RRDATA portion of OpenPGP CERT RRs, and that the URI Dubuisson, Ben Laurie, Samuel Weiler, and Florian Weimer. No doubt
type may include hashes to secure the indirection. Olivier Dubuisson the list is incomplete. We apologize to anyone we left out.
confirmed that the X.509 OID were indeed correct.
6. Security Considerations 6. Security Considerations
@@ -533,33 +548,36 @@ Internet-Draft Storing Certificates in the DNS January 2005
verifying the certificate chain if this conforms with the user's verifying the certificate chain if this conforms with the user's
security policy. security policy.
When the URI type is used, it should be understood that is introduce When the URI type is used, it should be understood that it introduces
an additional indirection that may allow for a new attack vector. an additional indirection that may allow for a new attack vector.
One method to secure that indirection is to include a hash of the One method to secure that indirection is to include a hash of the
certificate in the URI itself. certificate in the URI itself.
CERT RRs are not used in connection with securing the DNS security
additions so there are no security considerations related to CERT RRs
and securing the DNS itself.
Josefsson Expires July 2, 2005 [Page 10]
Internet-Draft Storing Certificates in the DNS January 2005
CERT RRs are not used by DNSSEC [8] so there are no security
considerations related to CERT RRs and securing the DNS itself.
If DNSSEC [8] is used then the non-existence of a CERT RR, and
consequently certificates or revocation lists, can be securely
asserted. Without DNSSEC, this is not possible.
7. IANA Considerations 7. IANA Considerations
Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
only be assigned by an IETF standards action [6]. This document only be assigned by an IETF standards action [6]. This document
assigns 0x0001 through 0x0003 and 0x00FD and 0x00FE. Certificate assigns 0x0001 through 0x0006 and 0x00FD and 0x00FE. Certificate
types 0x0100 through 0xFEFF are assigned through IETF Consensus [6] types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]
based on RFC documentation of the certificate type. The availability based on RFC documentation of the certificate type. The availability
of private types under 0x00FD and 0x00FE should satisfy most of private types under 0x00FD and 0x00FE should satisfy most
requirements for proprietary or private types. requirements for proprietary or private types.
Josefsson Expires July 25, 2005 [Page 10]
Internet-Draft Storing Certificates in the DNS January 2005
8. Changes since RFC 2538 8. Changes since RFC 2538
1. Editorial changes to conform with new document requirements, 1. Editorial changes to conform with new document requirements,
@@ -582,6 +600,7 @@ Internet-Draft Storing Certificates in the DNS January 2005
for purpose-based X.509 CERT owner names, and section 3.4 for for purpose-based X.509 CERT owner names, and section 3.4 for
purpose-based OpenPGP CERT owner names. purpose-based OpenPGP CERT owner names.
8. Added size considerations. 8. Added size considerations.
9. Added indirect types IPKIX, ISPKI, and IPGP.
9. References 9. References
@@ -590,6 +609,14 @@ Internet-Draft Storing Certificates in the DNS January 2005
[1] Mockapetris, P., "Domain names - concepts and facilities", STD [1] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987. 13, RFC 1034, November 1987.
Josefsson Expires July 2, 2005 [Page 11]
Internet-Draft Storing Certificates in the DNS January 2005
[2] Mockapetris, P., "Domain names - implementation and [2] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
@@ -608,14 +635,6 @@ Internet-Draft Storing Certificates in the DNS January 2005
[7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
Josefsson Expires July 25, 2005 [Page 11]
Internet-Draft Storing Certificates in the DNS January 2005
[8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose, [8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
"DNS Security Introduction and Requirements", "DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-13 (work in progress), October draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
@@ -633,6 +652,9 @@ Internet-Draft Storing Certificates in the DNS January 2005
[11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", [11] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
RFC 3548, July 2003. RFC 3548, July 2003.
[12] Richardson, M., "A method for storing IPsec keying material in
DNS", draft-ietf-ipseckey-rr-11 (work in progress), July 2004.
Author's Address Author's Address
@@ -643,6 +665,14 @@ Author's Address
Appendix A. Copying conditions Appendix A. Copying conditions
Regarding the portion of this document that was written by Simon Regarding the portion of this document that was written by Simon
Josefsson Expires July 2, 2005 [Page 12]
Internet-Draft Storing Certificates in the DNS January 2005
Josefsson ("the author", for the remainder of this section), the Josefsson ("the author", for the remainder of this section), the
author makes no guarantees and is not responsible for any damage author makes no guarantees and is not responsible for any damage
resulting from its use. The author grants irrevocable permission to resulting from its use. The author grants irrevocable permission to
@@ -667,7 +697,34 @@ Appendix A. Copying conditions
Josefsson Expires July 25, 2005 [Page 12]
Josefsson Expires July 2, 2005 [Page 13]
Internet-Draft Storing Certificates in the DNS January 2005 Internet-Draft Storing Certificates in the DNS January 2005
@@ -723,6 +780,6 @@ Acknowledgment
Josefsson Expires July 25, 2005 [Page 13] Josefsson Expires July 2, 2005 [Page 14]

729
doc/draft/draft-ietf-dnsext-trustupdate-timers-00.txt Normal file
View File

@@ -0,0 +1,729 @@
Network Working Group M. StJohns
Internet-Draft Nominum, Inc.
Expires: April 14, 2005 October 14, 2004
Automated Updates of DNSSEC Trust Anchors
draft-ietf-dnsext-trustupdate-timers-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she 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 April 14, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes a means for automated, authenticated and
authorized updating of DNSSEC "trust anchors". The method provides
protection against single key compromise of a key in the trust point
key set. Based on the trust established by the presence of a current
anchor, other anchors may be added at the same place in the
hierarchy, and, ultimately, supplant the existing anchor.
This mechanism, if adopted, will require changes to resolver
StJohns Expires April 14, 2005 [Page 1]
Internet-Draft trustanchor-update October 2004
management behavior (but not resolver resolution behavior), and the
addition of a single flag bit to the DNSKEY record.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Compliance Nomenclature . . . . . . . . . . . . . . . . . 3
1.2 Changes since -00 . . . . . . . . . . . . . . . . . . . . 3
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 4
2.1 Revocation . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 Add Hold-Down . . . . . . . . . . . . . . . . . . . . . . 5
2.3 Remove Hold-down . . . . . . . . . . . . . . . . . . . . . 5
2.4 Active Refresh . . . . . . . . . . . . . . . . . . . . . . 6
2.5 Resolver Parameters . . . . . . . . . . . . . . . . . . . 6
2.5.1 Add Hold-Down Time . . . . . . . . . . . . . . . . . . 6
2.5.2 Remove Hold-Down Time . . . . . . . . . . . . . . . . 6
2.5.3 Minimum Trust Anchors per Trust Point . . . . . . . . 6
3. Changes to DNSKEY RDATA Wire Format . . . . . . . . . . . . . 6
4. State Table . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 States . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1 Adding A Trust Anchor . . . . . . . . . . . . . . . . . . 8
5.2 Deleting a Trust Anchor . . . . . . . . . . . . . . . . . 9
5.3 Key Roll-Over . . . . . . . . . . . . . . . . . . . . . . 9
5.4 Active Key Compromised . . . . . . . . . . . . . . . . . . 9
5.5 Stand-by Key Compromised . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1 Key Ownership vs Acceptance Policy . . . . . . . . . . . . 10
6.2 Multiple Key Compromise . . . . . . . . . . . . . . . . . 10
6.3 Dynamic Updates . . . . . . . . . . . . . . . . . . . . . 10
7. Normative References . . . . . . . . . . . . . . . . . . . . . 10
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
StJohns Expires April 14, 2005 [Page 2]
Internet-Draft trustanchor-update October 2004
1. Introduction
As part of the reality of fielding DNSSEC (Domain Name System
Security Extensions) [RFC2535][DSINTRO][DSPROT][DSREC], the community
has come to the realization that there will not be one signed name
space, but rather islands of signed name space each originating from
specific points (i.e. 'trust points') in the DNS tree. Each of
those islands will be identified by the trust point name, and
validated by at least one associated public key. For the purpose of
this document we'll call the association of that name and a
particular key a 'trust anchor'. A particular trust point can have
more than one key designated as a trust anchor.
For a DNSSEC-aware resolver to validate information in a DNSSEC
protected branch of the hierarchy, it must have knowledge of a trust
anchor applicable to that branch. It may also have more than one
trust anchor for any given trust point. Under current rules, a chain
of trust for DNSSEC-protected data that chains its way back to ANY
known trust anchor is considered 'secure'.
Because of the probable balkanization of the DNSSEC tree due to
signing voids at key locations, a resolver may need to know literally
thousands of trust anchors to perform its duties. (e.g. Consider an
unsigned ".COM".) Requiring the owner of the resolver to manually
manage this many relationships is problematic. It's even more
problematic when considering the eventual requirement for key
replacement/update for a given trust anchor. The mechanism described
herein won't help with the initial configuration of the trust anchors
in the resolvers, but should make trust point key
replacement/rollover more viable.
As mentioned above, this document describes a mechanism whereby a
resolver can update the trust anchors for a given trust point, mainly
without human intervention at the resolver. There are some corner
cases discussed (e.g. multiple key compromise) that may require
manual intervention, but they should be few and far between. This
document DOES NOT discuss the general problem of the initial
configuration of trust anchors for the resolver.
1.1 Compliance Nomenclature
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, [RFC2119].
1.2 Changes since -00
Resubmitted draft-stjohns-dnssec-trustupdate as a working group
StJohns Expires April 14, 2005 [Page 3]
Internet-Draft trustanchor-update October 2004
draft.
Added the concept of timer triggered resolver queries to refresh the
resolvers view of the trust anchor key RRSet.
2. Theory of Operation
The general concept of this mechanism is that existing trust anchors
can be used to authenticate new trust anchors at the same point in
the DNS hierarchy. When a new SEP key is added to a trust point
DNSKEY RRSet, and when that RRSet is validated by an existing trust
anchor, then the new key can be added to the set of trust anchors.
There are some issues with this approach which need to be mitigated.
For example, a compromise of one of the existing keys could allow an
attacker to add their own 'valid' data. This implies a need for a
method to revoke an existing key regardless of whether or not that
key is compromised. As another example assuming a single key
compromise, an attacker could add a new key and revoke all the other
old keys.
2.1 Revocation
Assume two trust anchor keys A and B. Assume that B has been
compromised. Without a specific revocation bit, B could invalidate A
simply by sending out a signed trust point key set which didn't
contain A. To fix this, we add a mechanism which requires knowledge
of the private key of a DNSKEY to revoke that DNSKEY.
A key is considered revoked when the resolver sees the key in a
self-signed RRSet and the key has the REVOKE bit set to '1'. Once
the resolver sees the REVOKE bit, it MUST NOT use this key as a trust
anchor or for any other purposes except validating the RRSIG over the
DNSKEY RRSet specifically for the purpose of validating the
revocation. Unlike the 'Add' operation below, revocation is
immediate and permanent upon receipt of a valid revocation at the
resolver.
N.B. A DNSKEY with the REVOKE bit set has a different fingerprint
than one without the bit set. This affects the matching of a DNSKEY
to DS records in the parent, or the fingerprint stored at a resolver
used to configure a trust point. [msj3]
In the given example, the attacker could revoke B because it has
knowledge of B's private key, but could not revoke A.
StJohns Expires April 14, 2005 [Page 4]
Internet-Draft trustanchor-update October 2004
2.2 Add Hold-Down
Assume two trust point keys A and B. Assume that B has been
compromised. An attacker could generate and add a new trust anchor
key - C (by adding C to the DNSKEY RRSet and signing it with B), and
then invalidate the compromised key. This would result in the both
the attacker and owner being able to sign data in the zone and have
it accepted as valid by resolvers.
To mitigate, but not completely solve, this problem, we add a
hold-down time to the addition of the trust anchor. When the
resolver sees a new SEP key in a validated trust point DNSKEY RRSet,
the resolver starts an acceptance timer, and remembers all the keys
that validated the RRSet. If the resolver ever sees the DNSKEY RRSet
without the new key but validly signed, it stops the acceptance
process and resets the acceptance timer. If all of the keys which
were originally used to validate this key are revoked prior to the
timer expiring, the resolver stops the acceptance process and resets
the timer.
Once the timer expires, the new key will be added as a trust anchor
the next time the validated RRSet with the new key is seen at the
resolver. The resolver MUST NOT treat the new key as a trust anchor
until the hold down time expires AND it has retrieved and validated a
DNSKEY RRSet after the hold down time which contains the new key.
N.B.: Once the resolver has accepted a key as a trust anchor, the key
MUST be considered a valid trust anchor by that resolver until
explictly revoked as described above.
In the given example, the zone owner can recover from a compromise by
revoking B and adding a new key D and signing the DNSKEY RRSet with
both A and B.
The reason this does not completely solve the problem has to do with
the distributed nature of DNS. The resolver only knows what it sees.
A determined attacker who holds one compromised key could keep a
single resolver from realizing that key had been compromised by
intercepting 'real' data from the originating zone and substituting
their own (e.g. using the example, signed only by B). This is no
worse than the current situation assuming a compromised key.
2.3 Remove Hold-down
A new key which has been seen by the resolver, but hasn't reached
it's add hold-down time, MAY be removed from the DNSKEY RRSet by the
zone owner. If the resolver sees a validated DNSKEY RRSet without
this key, it waits for the remove hold-down time and then, if the key
StJohns Expires April 14, 2005 [Page 5]
Internet-Draft trustanchor-update October 2004
hasn't reappeared, SHOULD discard any information about the key.
2.4 Active Refresh
A resolver which has been configured for automatic update of keys
from a particular trust point MUST query that trust point (e.g. do a
lookup for the DNSKEY RRSet and related RRSIG records) no less often
than the lesser of 15 days or half the original TTL for the DNSKEY
RRSet or half the RRSIG expiration interval. The expiration interval
is the amount of time from when the RRSIG was last retrieved until
the expiration time in the RRSIG.
If the query fails, the resolver MUST repeat the query until
satisfied no more often than once an hour and no less often than the
lesser of 1 day or 10% of the original TTL or 10% of the original
expiration interval.
2.5 Resolver Parameters
2.5.1 Add Hold-Down Time
The add hold-down time is 30 days or the expiration time of the TTL
of the first trust point DNSKEY RRSet which contained the key,
whichever is greater. This ensures that at least two validated
DNSKEY RRSets which contain the new key MUST be seen by the resolver
prior to the key's acceptance.
2.5.2 Remove Hold-Down Time
The remove hold-down time is 30 days.
2.5.3 Minimum Trust Anchors per Trust Point
A compliant resolver MUST be able to manage at least five SEP keys
per trust point.
3. Changes to DNSKEY RDATA Wire Format
Bit n [msj2] of the DNSKEY Flags field is designated as the 'REVOKE'
flag. If this bit is set to '1', AND the resolver sees an
RRSIG(DNSKEY) signed by the associated key, then the resolver MUST
consider this key permanently invalid for all purposes except for
validing the revocation.
4. State Table
The most important thing to understand is the resolver's view of any
key at a trust point. The following state table describes that view
StJohns Expires April 14, 2005 [Page 6]
Internet-Draft trustanchor-update October 2004
at various points in the key's lifetime. The table is a normative
part of this specification. The initial state of the key is 'Start'.
The resolver's view of the state of the key changes as various events
occur.
[msj1] This is the state of a trust point key as seen from the
resolver. The column on the left indicates the current state. The
header at the top shows the next state. The intersection of the two
shows the event that will cause the state to transition from the
current state to the next.
NEXT STATE
--------------------------------------------------
FROM |Start |AddPend |Valid |Missing|Revoked|Removed|
----------------------------------------------------------
Start | |NewKey | | | | |
----------------------------------------------------------
AddPend |KeyRem | |AddTime| | |
----------------------------------------------------------
Valid | | | |KeyRem |Revbit | |
----------------------------------------------------------
Missing | | |KeyPres| |Revbit | |
----------------------------------------------------------
Revoked | | | | | |RemTime|
----------------------------------------------------------
Removed | | | | | | |
----------------------------------------------------------
4.1 Events
NewKey The resolver sees a valid DNSKEY RRSet with a new SEP key.
That key will become a new trust anchor for the named trust point
after its been present in the RRSet for at least 'add time'.
KeyPres The key has returned to the valid DNSKEY RRSet.
KeyRem The resolver sees a valid DNSKEY RRSet that does not contain
this key.
AddTime The key has been in every valid DNSKEY RRSet seen for at
least the 'add time'.
RemTime A revoked key has been missing from the trust point DNSKEY
RRSet for sufficient time to be removed from the trust set.
RevBit The key has appeared in the trust anchor DNSKEY RRSet with its
"REVOKED" bit set, and there is an RRSig over the DNSKEY RRSet
signed by this key.
4.2 States
StJohns Expires April 14, 2005 [Page 7]
Internet-Draft trustanchor-update October 2004
Start The key doesn't yet exist as a trust anchor at the resolver.
It may or may not exist at the zone server, but hasn't yet been
seen at the resolver.
AddPend The key has been seen at the resolver, has its 'SEP' bit set,
and has been included in a validated DNSKEY RRSet. There is a
hold-down time for the key before it can be used as a trust
anchor.
Valid The key has been seen at the resolver and has been included in
all validated DNSKEY RRSets from the time it was first seen up
through the hold-down time. It is now valid for verifying RRSets
that arrive after the hold down time. Clarification: The DNSKEY
RRSet does not need to be continuously present at the resolver
(e.g. its TTL might expire). If the RRSet is seen, and is
validated (i.e. verifies against an existing trust anchor), this
key MUST be in the RRSet otherwise a 'KeyRem' event is triggered.
Missing This is an abnormal state. The key remains as a valid trust
point key, but was not seen at the resolver in the last validated
DNSKEY RRSet. This is an abnormal state because the zone operator
should be using the REVOKE bit prior to removal. [Discussion
item: Should a missing key be considered revoked after some
period of time?]
Revoked This is the state a key moves to once the resolver sees an
RRSIG(DNSKEY) signed by this key where that DNSKEY RRSet contains
this key with its REVOKE bit set to '1'. Once in this state, this
key MUST permanently be considered invalid as a trust anchor.
Removed After a fairly long hold-down time, information about this
key may be purged from the resolver. A key in the removed state
MUST NOT be considered a valid trust anchor.
5. Scenarios
The suggested model for operation is to have one active key and one
stand-by key at each trust point. The active key will be used to
sign the DNSKEY RRSet. The stand-by key will not normally sign this
RRSet, but the resolver will accept it as a trust anchor if/when it
sees the signature on the trust point DNSKEY RRSet.
Since the stand-by key is not in active signing use, the associated
private key may (and SHOULD) be provided with additional protections
not normally available to a key that must be used frequently. E.g.
locked in a safe, split among many parties, etc. Notionally, the
stand-by key should be less subject to compromise than an active key,
but that will be dependent on operational concerns not addressed
here.
5.1 Adding A Trust Anchor
Assume an existing trust anchor key 'A'.
StJohns Expires April 14, 2005 [Page 8]
Internet-Draft trustanchor-update October 2004
1. Generate a new key pair.
2. Create a DNSKEY record from the key pair and set the SEP and Zone
Key bits.
3. Add the DNSKEY to the RRSet.
4. Sign the DNSKEY RRSet ONLY with the existing trust anchor key -
'A'.
5. Wait a while.
5.2 Deleting a Trust Anchor
Assume existing trust anchors 'A' and 'B' and that you want to revoke
and delete 'A'.
1. Set the revolcation bit on key 'A'.
2. Sign the DNSKEY RRSet with both 'A' and 'B'.
'A' is now revoked. The operator SHOULD include the revoked 'A' in
the RRSet for at least the remove hold-down time, but then may remove
it from the DNSKEY RRSet.
5.3 Key Roll-Over
Assume existing keys A and B. 'A' is actively in use (i.e. has been
signing the DNSKEY RRSet.) 'B' was the stand-by key. (i.e. has
been in the DNSKEY RRSet and is a valid trust anchor, but wasn't
being used to sign the RRSet.)
1. Generate a new key pair 'C'.
2. Add 'C' to the DNSKEY RRSet.
3. Set the revocation bit on key 'A'.
4. Sign the RRSet with 'A' and 'B'.
'A' is now revoked, 'B' is now the active key, and 'C' will be the
stand-by key once the hold-down expires. The operator SHOULD include
the revoked 'A' in the RRSet for at least the remove hold-down time,
but may then remove it from the DNSKEY RRSet.
5.4 Active Key Compromised
This is the same as the mechanism for Key Roll-Over (Section 5.3)
above assuming 'A' is the active key.
5.5 Stand-by Key Compromised
Using the same assumptions and naming conventions as Key Roll-Over
(Section 5.3) above:
1. Generate a new key pair 'C'.
2. Add 'C' to the DNSKEY RRSet.
3. Set the revocation bit on key 'B'.
4. Sign the RRSet with 'A' and 'B'.
'B' is now revoked, 'A' remains the active key, and 'C' will be the
stand-by key once the hold-down expires. 'B' SHOULD continue to be
StJohns Expires April 14, 2005 [Page 9]
Internet-Draft trustanchor-update October 2004
included in the RRSet for the remove hold-down time.
6. Security Considerations
6.1 Key Ownership vs Acceptance Policy
The reader should note that, while the zone owner is responsible
creating and distributing keys, it's wholly the decision of the
resolver owner as to whether to accept such keys for the
authentication of the zone information. This implies the decision
update trust anchor keys based on trust for a current trust anchor
key is also the resolver owner's decision.
The resolver owner (and resolver implementers) MAY choose to permit
or prevent key status updates based on this mechanism for specific
trust points. If they choose to prevent the automated updates, they
will need to establish a mechanism for manual or other out-of-band
updates outside the scope of this document.
6.2 Multiple Key Compromise
This scheme permits recovery as long as at least one valid trust
anchor key remains uncompromised. E.g. if there are three keys, you
can recover if two of them are compromised. The zone owner should
determine their own level of comfort with respect to the number of
active valid trust anchors in a zone and should be prepared to
implement recovery procedures once they detect a compromise. A
manual or other out-of-band update of all resolvers will be required
if all trust anchor keys at a trust point are compromised.
6.3 Dynamic Updates
Allowing a resolver to update its trust anchor set based in-band key
information is potentially less secure than a manual process.
However, given the nature of the DNS, the number of resolvers that
would require update if a trust anchor key were compromised, and the
lack of a standard management framework for DNS, this approach is no
worse than the existing situation.
7 Normative References
[DSINTRO] Arends, R., "DNS Security Introduction and Requirements",
ID draft-ietf-dnsext-dnssec-intro-09.txt, October 2004,
<http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns
sec-intro-13.txt>.
[DSPROT] Arends, R., "Protocol Modifications for the DNS Security
Extensions", ID draft-ietf-dnsext-dnssec-protocol-05.txt,
StJohns Expires April 14, 2005 [Page 10]
Internet-Draft trustanchor-update October 2004
October 2004,
<http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns
sec-protocol-09.txt>.
[DSREC] Arends, R., "Resource Records for the DNS Security
Extensions", ID draft-ietf-dnsext-dnssec-records-07.txt,
October 2004,
<http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dns
sec-records-11.txt>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
Editorial Comments
[msj1] msj: N.B. This table is preliminary and will be revised to
match implementation experience. For example, should there
be a state for "Add hold-down expired, but haven't seen the
new RRSet"?
[msj2] msj: To be assigned.
[msj3] msj: For discussion: What's the implementation guidance for
resolvers currently with respect to the non-assigned flag
bits? If they consider the flag bit when doing key matching
at the trust anchor, they won't be able to match.
Author's Address
Michael StJohns
Nominum, Inc.
2385 Bay Road
Redwood City, CA 94063
USA
Phone: +1-301-528-4729
EMail: Mike.StJohns@nominum.com
URI: www.nominum.com
StJohns Expires April 14, 2005 [Page 11]
Internet-Draft trustanchor-update October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed in
regard to some or all of the specification contained in this
document. For more information consult the online list of claimed
rights.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
StJohns Expires April 14, 2005 [Page 12]
Internet-Draft trustanchor-update October 2004
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
StJohns Expires April 14, 2005 [Page 13]

83
doc/draft/draft-ietf-dnsext-tsig-sha-00.txt → doc/draft/draft-ietf-dnsext-tsig-sha-01.txt
View File

@@ -1,13 +1,12 @@
INTERNET-DRAFT Donald E. Eastlake 3rd INTERNET-DRAFT Donald E. Eastlake 3rd
UPDATES RFC 2845 Motorola Laboratories UPDATES RFC 2845 Motorola Laboratories
Expires: February 2005 August 2004 Expires: August 2005 February 2005
HMAC SHA TSIG Algorithm Identifiers HMAC SHA TSIG Algorithm Identifiers
---- --- ---- --------- ----------- ---- --- ---- --------- -----------
<draft-ietf-dnsext-tsig-sha-00.txt> <draft-ietf-dnsext-tsig-sha-01.txt>
Status of This Document Status of This Document
@@ -43,14 +42,14 @@ Abstract
Use of the TSIG DNS resource record requires specification of a Use of the TSIG DNS resource record requires specification of a
cryptographic message authentication code. Currently identifiers cryptographic message authentication code. Currently identifiers
have been specified only for the HMAC-MD5 and GSS TSIG algorithms. have been specified only for the HMAC-MD5 and GSS TSIG algorithms.
This document standardizes identifiers for additional HMAC SHA TSIG This document standardizes identifiers and implementation
algorithms and standardizes how to specify the truncation of HMAC requirements for additional HMAC SHA TSIG algorithms and standardizes
values. how to specify the truncation of HMAC values.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society 2004. All Rights Reserved. Copyright (C) The Internet Society 2005. All Rights Reserved.
@@ -82,7 +81,7 @@ Table of Contents
7. Normative References....................................7 7. Normative References....................................7
8. Informative References..................................7 8. Informative References..................................7
Authors Address............................................8 Author's Address...........................................8
Expiration and File Name...................................8 Expiration and File Name...................................8
@@ -131,7 +130,8 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
are delegated to GSS [RFC 3645]. are delegated to GSS [RFC 3645].
In section 2, this document specifies additional names for TSIG In section 2, this document specifies additional names for TSIG
authentication algorithms based on US NIST SHA algorithms and HMAC. authentication algorithms based on US NIST SHA algorithms and HMAC
and specifies the implementation requirements for those algorithms.
In section 3, this document specifies the meaning of inequality In section 3, this document specifies the meaning of inequality
between the normal output size of the specified hash function and the between the normal output size of the specified hash function and the
@@ -168,7 +168,6 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
D. Eastlake 3rd [Page 3] D. Eastlake 3rd [Page 3]
@@ -190,21 +189,23 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
The use of SHA-1 [FIPS 180-1, RFC 3174], which is a 160 bit hash, as The use of SHA-1 [FIPS 180-1, RFC 3174], which is a 160 bit hash, as
compared with the 128 bits for MD5, and additional hash algorithms in compared with the 128 bits for MD5, and additional hash algorithms in
the SHA family [FIPS 180-2, RFC sha224] with 224, 256, 384, and 512 the SHA family [FIPS 180-2, RFC 3874] with 224, 256, 384, and 512
bits, may be preferred in some case. Use of TSIG between a DNS bits, may be preferred in some case particularly since increasingly
resolver and server is by mutual agreement. That agreement can successful cryptanalytic attacks are being made on the shorter
include the support of additional algorithms. hashes. Use of TSIG between a DNS resolver and server is by mutual
agreement. That agreement can include the support of additional
algorithms and may specify policies as to which algorithms are
acceptable.
For completeness in relation to HMAC based algorithms, the current The current HMAC-MD5.SIG-ALG.REG.INT identifier is included in the
HMAC-MD5.SIG-ALG.REG.INT identifier is included in the table below. table below for convenience. Implementations which support TSIG MUST
Implementations which support TSIG MUST implement HMAC MD5, SHOULD also implement HMAC SHA1 and HMAC SHA256 and MAY implement gss-tsig
implement HMAC SHA-1, and MAY implement gss-tsig and the other and the other algorithms listed below.
algorithms listed below.
Mandatory HMAC-MD5.SIG-ALG.REG.INT Mandatory HMAC-MD5.SIG-ALG.REG.INT
Recommended hmac-sha1 Mandatory hmac-sha1
Optional hmac-sha224 Optional hmac-sha224
Optional hmac-sha256 Mandatory hmac-sha256
Optional hamc-sha384 Optional hamc-sha384
Optional hmac-sha512 Optional hmac-sha512
@@ -225,8 +226,6 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
D. Eastlake 3rd [Page 4] D. Eastlake 3rd [Page 4]
@@ -309,16 +308,21 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
MAC by reducing the information available to an attacker, excessive MAC by reducing the information available to an attacker, excessive
truncation clearly weakens authentication by reducing the number of truncation clearly weakens authentication by reducing the number of
bits an attacker has to try to force. See [RFC 2104] which recommends bits an attacker has to try to force. See [RFC 2104] which recommends
that ah HMAC never be truncated to less than half its length nor to that an HMAC never be truncated to less than half its length nor to
less than 80 bits (10 octets). less than 80 bits (10 octets).
Significant progress has been made recently in cryptanalysis of hash
function of the type used herein. While the results so far should not
effect HMAC, the stronger SHA-1 and SHA-256 algorithms are being made
mandatory due to caution.
See also the Security Considerations section of [RFC 2845]. See also the Security Considerations section of [RFC 2845].
6. Copyright and Disclaimer 6. Copyright and Disclaimer
Copyright (C) The Internet Society 2004. This document is subject to Copyright (C) The Internet Society 2005. This document is subject to
the rights, licenses and restrictions contained in BCP 78 and except the rights, licenses and restrictions contained in BCP 78 and except
as set forth therein, the authors retain all their rights. as set forth therein, the authors retain all their rights.
@@ -340,11 +344,6 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
D. Eastlake 3rd [Page 6] D. Eastlake 3rd [Page 6]
@@ -353,8 +352,9 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
7. Normative References 7. Normative References
[FIPS 180-2] - "Secure Hash Standard", (SHA-1/256/384/512) US Federal [FIPS 180-2] - "Secure Hash Standard", (SHA-1/224/256/384/512) US
Information Processing Standard, Draft, 1 August 2002. Federal Information Processing Standard, with Change Notice 1,
February 2004.
[RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC [RFC 1321] - Rivest, R., "The MD5 Message-Digest Algorithm ", RFC
1321, April 1992. 1321, April 1992.
@@ -369,17 +369,10 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", Wellington, "Secret Key Transaction Authentication for DNS (TSIG)",
RFC 2845, May 2000. RFC 2845, May 2000.
[RFC sha224] - "A 224-bit One-way Hash Function: SHA-224", R.
Housley, December 2003, work in progress, draft-ietf-pkix-
sha224-*.txt.
8. Informative References. 8. Informative References.
[FIPS 180-1] - Secure Hash Standard, (SHA-1) US Federal Information
Processing Standard, 17 April 1995.
[RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction [RFC 2931] - Eastlake 3rd, D., "DNS Request and Transaction
Signatures ( SIG(0)s )", RFC 2931, September 2000. Signatures ( SIG(0)s )", RFC 2931, September 2000.
@@ -391,6 +384,12 @@ INTERNET-DRAFT HMAC-SHA TSIG Identifiers
Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, October
2003. 2003.
[RFC 3874] - "A 224-bit One-way Hash Function: SHA-224", R. Housley,
September 2004,
@@ -409,7 +408,7 @@ D. Eastlake 3rd [Page 7]
INTERNET-DRAFT HMAC-SHA TSIG Identifiers INTERNET-DRAFT HMAC-SHA TSIG Identifiers
Authors Address Author's Address
Donald E. Eastlake 3rd Donald E. Eastlake 3rd
Motorola Laboratories Motorola Laboratories
@@ -424,9 +423,9 @@ Authors Address
Expiration and File Name Expiration and File Name
This draft expires in February 2005. This draft expires in August 2005.
Its file name is draft-ietf-dnsext-tsig-sha-00.txt Its file name is draft-ietf-dnsext-tsig-sha-01.txt

818
doc/draft/draft-ietf-dnsext-wcard-clarify-03.txt
View File

@@ -1,818 +0,0 @@
DNSEXT Working Group E. Lewis
INTERNET DRAFT NeuStar
Expiration Date: April 2005 October 2004
Clarifying the Role of Wild Card Domains
in the Domain Name System
draft-ietf-dnsext-wcard-clarify-03.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 April 11, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
The definition of wild cards is recast from the original in RFC 1034,
in words that are more specific and in line with RFC 2119. This
document is meant to supplement the definition in RFC 1034 and not to
significantly alter the spirit or intent of that definition.
1 Introduction
In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the synthesis
of answers from special records called wildcards. The original
definitions are incomplete. This document clarifies and describes
the wildcard synthesis by adding to the discussion and making
limited modifications. Modifications are made only where necessary
to close inconsistencies that have led to interoperability issues.
1.1 Motivation
Over time many implementations have diverged in different ways from
the original definition, or at least what had been intended. Although
there is clearly a need to clarify the original documents in light
of this, the impetus for this document lay in the engineering of
the DNS security extensions [RFC TBD]. With an unclear definition
of wildcards the design of authenticated denial became entangled.
Although this document is motivated by DNSSEC and the need to
have a separate document passed for the sake of DNSSEC, other
motivations have risen. The renewed understanding of wildcards gained
is worthy of being documented.
1.2 The Original Definition
This document is intended to not make changes. To reinforce
this, sections of RFC 1034 are repeated verbatim for convenience
of the reader, to help in comparison of old and new text.
There are a few passages which are changed. This may seem to
contradict the goal of not changing the original specification,
but the changes herein are required because of inconsistencies
with the wording in RFC 1034.
The beginning of the discussion ought to start with the definition
of the term "wildcard" as it appears in RFC 1034, section 4.3.3.
# In the previous algorithm, special treatment was given to RRs with owner
# names starting with the label "*". Such RRs are called wildcards.
# Wildcard RRs can be thought of as instructions for synthesizing RRs.
# When the appropriate conditions are met, the name server creates RRs
# with an owner name equal to the query name and contents taken from the
# wildcard RRs.
This passage appears after the algorithm in which they are used is
presented. The terminology is not consistent, the word "wildcard"
is clearly defined to be a resource record. In the next sentence
the term is shifted to be an adjective, the first step on the
path to overloading the term. Wildcard has also been used to
refer to domain names that begin with a "*".
1.3 The Clarification
The clarification effort can be divided into three sections. One
is the use of new terminology to better describe wildcards. Changes
to words in RFC 1034 that have resulted by discovering conflicting
concepts are presented. Descriptions of special type records in the
context of being wildcards is discussed.
1.3.1 New Terms
The term "wildcard" has become so overloaded it is virtually useless
as a description. A few new terms will be introduced to be more
descriptive. The new terms that will be introduced are:
Asterisk Label - a label consisting of an asterisk ("*") and no
other characters.
Wild Card Domain Name - a domain name whose least significant
label (first when reading left to right) is an asterisk label.
Other labels might also be asterisk labels.
Source of Synthesis - a Wild Card Domain Name when it is consulted in
the final paragraph of step 3, part c of RFC 1034's 4.3.2 algorithm.
Closest Encloser - in RFC 1034's 4.3.2 algorithm, the name at which
the last match was possible in step 3, part c. This is the longest
sequence of exactly matching labels from the root downward in both the
sought name (QNAME) and in the zone being examined.
Label Match - two labels are equivalent if the label type and label
length are the same bit sequence and if the name is the label is
equivalent bit wise after down casing all of the ASCII characters.
[Ed note: do we still call them ASCII?]
These terms will be more fully described as needed later. These
terms will be used to describe a few changes to the words in RFC
1034. A summary of the changes appear next and will be fully
covered in later sections.
1.3.2 Changed Text
The definition of "existence" is changed, superficially, to exclude
empty domains that have no subdomains with resource records. This
change will not be apparent to implementations, it is needed to
make descriptions more concise.
In RFC 1034, there is text that seems to bar having two Asterisk
Labels in a Wild Card Domain Name. There is no further discussion,
no prescribed error handling, nor enforcement described. In this
document, the use of such names will be discouraged, but implementations
will have to account for the possibility of such a name's use.
The actions when a Source of Synthesis owns a CNAME RR are changed to
mirror the actions if an exact match name owns a CNAME RR. This
is an addition to the words in RFC 1034, section 4.3.2, step 3,
part c.
1.3.3 Considerations with Special Types
This clarification will describe in some detail the semantics of
wildcard CNAME RRs, wildcard NS RRs, wildcard SOA RR's,
wildcard DNAME RRs [RFC wxyz], and empty, non-terminal wildcards.
Understanding these types in the context of wildcards has been
clouded because these types incur special processing if they
are the result of an exact match.
By the definition in RFC 1034, there can be no empty, non-terminal
"wildcards", but in the algorithm, it is possible that an empty
non-terminal is sought as the potential owner of a "wildcard." This
is one example of why the ordering of the discussion in RFC 1034 is
confusing.
1.4 Standards Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in the document entitled
"Key words for use in RFCs to Indicate Requirement Levels." [RFC2119]
Quotations of RFC 1034 (as has already been done once above) are
denoted by a '#' in the leftmost column.
2 "Wildcard"
The context of the wildcard concept involves the algorithm by which
a name server prepares a response (in RFC 1034's section 4.3.2) and
the way in which a resource record (set) is identified as being a
source of synthetic data (section 4.3.3).
Tackling the latter first, there are two objectives in defining a
means to identify a resource record set as a source of synthesis.
First is the desire to maintain all DNS data in a consistent manner.
Avoiding the need for implementations to have many internal data
structures is a good thing. Not that this means limiting quantity,
but rather types of data. The second objective impacts interoperability,
that is a master server of one implementation has to be able to
send the synthesis instructions to the slaves. Although there are
alternatives to the use of zone transfers via port 53, a truly
interoperable record synthesis approach has to be able to insert the
synthesis instructions into a zone transfer.
The objectives in describing the synthesis of records in the context
of the name server algorithm include knowing when to employ the
process of synthesis and how the synthesis is carried out.
2.1 Identifying a wildcard
To provide a more accurate description of "wildcards", the definition
has to start with a discussion of the domain names that appear as
owners.
2.1.1 Wild Card Domain Name and Asterisk Label
A "Wild Card Domain Name" is defined by having its initial label be:
0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
The first octet is the normal label type and length for a 1 octet
long label, the second octet is the ASCII representation [RFC 20] for
the '*' character. In RFC 1034, ASCII encoding is assumed to be the
character encoding.
A descriptive name of a label equaling that value is an "Asterisk
Label."
RFC 1034's definition of wildcard would be "a resource record owned
by a Wild Card Domain Name." This is mentioned to help maintain some
orientation between this clarification and RFC 1034. Keep in mind,
that in "Clarifications to the DNS Specification" [RFC 2181] the name
of the basic unit of DNS data became the resource record set (RRSet) and
not the resource record.
2.1.2 Variations on Wild Card Domain Names
RFC 1034 and RFC 1035 do not explicitly mention the case in which a
domain name might be something like "the*.example.com." The
interpretation is that this domain name in a zone would only match
queries for "the*.example.com" and not have any other role. An
asterisk ('*') occurring other than as the sole character in
a label is simply a character forming part of the label and has no
special meaning. This is not an Asterisk Label, simply a label
an asterisk in it. The same is true for "**.example.com." and
"*the.example.com."
[Ed note: the above paragraph reads too strong. The intent ought to
be that such names do not fall under the rules of wildcards. The
intent is not to bar any future attempts to define other forms of
synthesis - nor is the intent to encourage them.]
The interpretation of a wild card domain specification which is not a
leaf domain is not clearly defined in RFC 1034. E.g., sub.*.example.,
is not discussed, not barred. In wanting to minimize changes from
the original specification, such names are permitted. Although
"sub.*.example." is not a Wild Card Domain Name, "*.example." is.
RRSets used to synthesize records can be owned by a Wild Card Domain
Name that has subdomains.
2.1.3 Non-terminal Wild Card Domain Names
In section 4.3.3, the following is stated:
# .......................... The owner name of the wildcard RRs is of
# the form "*.<anydomain>", where <anydomain> is any domain name.
# <anydomain> should not contain other * labels......................
This covers names like "*.foo.*.example." The pre-RFC2119 wording uses
"should not" which has an ambiguous meaning. The specification does not
proscribe actions upon seeing such a name, such as whether or not a
zone containing the name should fail to be served. What if a dynamic
update (RFC2136) requested to add the name to the zone? The failure
semantics are not defined.
The recommendation is that implementations ought to anticipate the
appearance of such names but generally discourage their use in
operations. No standards statement, such as "MAY NOT" or "SHOULD NOT"
is made here.
The interpretation of this is, when seeking a Wild Card Domain Name
for the purposes of record synthesis, an implementation ought not to
check the domain name for subdomains.
It is possible that a Wild Card Domain Name is an empty non-terminal.
(See the upcoming sections on empty non-terminals.) In this case,
the lookup will terminate as would any empty non-terminal match.
2.2 Existence Rules
The notion that a domain name 'exists' arises numerous times in
discussions about the wildcard concept. RFC 1034 raises the issue
of existence in a number of places, usually in reference to
non-existence and in reference to processing involving wildcards.
RFC 1034 contains algorithms that describe how domain names impact
the preparation of an answer and does define wildcards as a means of
synthesizing answers. Because of this a discussion on wildcards
needs to cover a definition of existence.
To help clarify the topic of wild cards, a positive definition of
existence is needed. Complicating matters, though, is the
realization that existence is relative. To an authoritative server,
a domain name exists if the domain name plays a role following the
algorithms of preparing a response. To a resolver, a domain name
exists if there is any data available corresponding to the name. The
difference between the two is the synthesis of records according to a
wildcard.
For the purposes of this document, the point of view of an
authoritative server is more interesting. A domain name is said to
exist if it plays a role in the execution of the algorithms in RFC 1034.
2.2.1. An Example
To illustrate what is meant by existence consider this complete zone:
$ORIGIN example.
example. 3600 IN SOA <SOA RDATA>
example. 3600 NS ns.example.com.
example. 3600 NS ns.example.net.
*.example. 3600 TXT "this is a wild card"
*.example. 3600 MX 10 host1.example.
host1.example. 3600 A 192.0.4.1
_ssh._tcp.host1.example. 3600 SRV <SRV RDATA>
_ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
subdel.example. 3600 NS ns.example.com.
subdel.example. 3600 NS ns.example.net.
A look at the domain names in a tree structure is helpful:
|
-------------example------------
/ / \ \
/ / \ \
/ / \ \
* host1 host2 subdel
| |
| |
_tcp _tcp
| |
| |
_ssh _ssh
The following queries would be synthesized from the wild card:
QNAME=host3.example. QTYPE=MX, QCLASS=IN
the answer will be a "host3.example. IN MX ..."
QNAME=host3.example. QTYPE=A, QCLASS=IN
the answer will reflect "no error, but no data"
because there is no A RR set at '*.example.'
QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
the answer will be "foo.bar.example. IN TXT ..."
because bar.example. does not exist, but the wildcard does.
The following queries would not be synthesized from the wild card:
QNAME=host1.example., QTYPE=MX, QCLASS=IN
because host1.example. exists
QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
because *.example. exists
QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
because _tcp.host1.example. exists (without data)
QNAME=_telnet._tcp.host2.example., QTYPE=SRV, QCLASS=IN
because host2.example. exists (without data)
QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
because subdel.example. exists (and is a zone cut)
To the server, all of the domains in the tree exist. The resolver will
get answers to some names off the tree, thanks to synthesis.
2.2.2 Empty Non-terminals
Empty non-terminals are domain names that own no resource records but
have subdomains which do. This is defined in section 3.1 of RFC 1034:
# The domain name space is a tree structure. Each node and leaf on the
# tree corresponds to a resource set (which may be empty). The domain
# system makes no distinctions between the uses of the interior nodes and
# leaves, and this memo uses the term "node" to refer to both.
The parenthesized "which may be empty" specifies that empty non-
terminals are explicitly recognized. According to the definition of
existence in this document, empty non-terminals do exist at the
server.
Pedantically reading the above paragraph can lead to an
interpretation that all possible domains exist - up to the suggested
limit of 255 octets for a domain name [RFC 1035]. For example,
www.example. may have an A RR, and as far as is practically
concerned, is a leaf of the domain tree. But the definition can be
taken to mean that sub.www.example. also exists, albeit with no data.
By extension, all possible domains exist, from the root on down. As
RFC 1034 also defines "an authoritative name error indicating that
the name does not exist" in section 4.3.1, this is not the intent of
the original document.
2.2.3 Yet Another Definition of Existence
RFC1034's wording is clarified by the following paragraph:
A node is considered to have an impact on the algorithms of
4.3.2 if it is a leaf node with any resource sets or an interior
node (with or without a resource set) that has a subdomain that
is a leaf node with a resource set. A QNAME and QCLASS matching
an existing node never results in a response code of
authoritative name error (RCODE==3).
The terminology in the above paragraph is chosen to remain as close
to that in the original document. The term "with" is a alternate
form for "owning" in this case, hence "a leaf node owning resources
sets, or an interior node, owning or not owning any resource set,
that has a leaf node owning a resource set as a subdomain," is the
proper interpretation of the middle sentence.
As an aside, an "authoritative name error", response code (RCODE) 3,
has been called NXDOMAIN in some RFCs, such as RFC 2136 [RFC 2136].
NXDOMAIN is the mnemonic assigned to such an error by at least one
implementation of DNS.
Summarizing the discussion on existence in non-RFC1034 words:
An authoritative server is to treat a domain name as existing
during the execution of the algorithms in RFC 1034 when the
domain name conforms to the following definition. A domain name
is defined to exist if the domain name owns data or has a
subdomain that exists, or both.
Note that at a zone boundary, the domain name owns data, including
the NS RR set. At the delegating server, the NS RR set is not
authoritative, but that is of no consequence here. The domain name
owns data, therefore, it exists.
2.3 When does a Wild Card Domain Name not own a wildcard (record)
When a Wild Card Domain Name appears in a message's query section,
no special processing occurs. Asterisk Labels in such a context
only Label Matches other Asterisk Labels in the existing zone tree
when the 4.3.2 algorithm is being followed.
When a Wild Card Domain Name appears in the resource data of a
record, no special processing occurs. An Asterisk Label in that
context literally means just an asterisk.
3. Impact of a Wild Card Domain On a Response
The description of how wild cards impact response generation is in
RFC 1034, section 4.3.2. That passage contains the algorithm
followed by a server in constructing a response. Within that
algorithm, step 3, part 'c' defines the behavior of the wild card.
The algorithm is directly quoted in lines that begin with a '#' sign.
Commentary is interleaved.
There is a documentation issue deserving some explanation. The
algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo
code, i.e., it's steps are not intended to be followed in strict
order. The "algorithm" is a suggestion. As such, in step 3, parts
a, b, and c, do not have to be implemented in that order.
Another issue needing explanation is that RFC 1034 is a full
standard. There is another RFC, RFC 2672, which makes, or proposes
an adjustment to RFC 1034's section 4.3.2 for the sake of the DNAME
RR. RFC 2672 is a proposed standard. The dilemma in writing these
clarifications is knowing which document is the one being clarified.
Fortunately, the difference between RFC 1034 and RFC 2672 is not
significant with respect to wild card synthesis, so this document
will continue to state that it is clarifying RFC 1034. If RFC 2672
progresses along the standards track, it will need to refer to
modifying RFC 1034's algorithm as amended here.
3.1 Step 2
Step 2 of the RFC 1034's section 4.3.2 reads:
# 2. Search the available zones for the zone which is the nearest
# ancestor to QNAME. If such a zone is found, go to step 3,
# otherwise step 4.
In this step, the most appropriate zone for the response is chosen.
There are two reasons to repeat this. One is that this means all
of step 3 is done within the context of a zone, which will constrain
the discussion. The other is the though behind synthesizing entire
zones and the use of Wild Card Domain Names to do so.
3.2 Step 3
Step 3 is dominated by three parts, labelled a, b, and c. But the
beginning of the Step is important and needs explanation.
# 3. Start matching down, label by label, in the zone. The
# matching process can terminate several ways:
The word matching in this care refers to Label Matching. The concept
is based in the view of the zone as the tree of existing names. The
Query Name is considered to be an ordered sequence of labels - as
if the name were a path from the root to the owner of the desired
data.
The process of Label Matching ends in one of three choices, the parts
a, b, and c. Once one of the parts is chosen, the other parts are
not considered. (E.g., do not execute part c and then change the
execution path to finish in part b.) The process of Label Matching
is also done independent of the Query Type.
Parts a and b are not an issue for this clarification as they do not
relate to record synthesis. Part a generally covers a situation in
which all of the labels in the search (query) name have been matched
down the tree, e.g., the sought name exists as an exact Label Match.
Part b generally covers a situation in which any label in the sought
name Label Matches a tree label and the tree label has a NS RRSet.
3.3 Part 'c'
The context of part 'c' is that the process of Label Matching the
labels in the sought name has resulted in a situation in which there
is nothing corresponding in the tree. It is as if the lookup has
"fallen off the tree."
# c. If at some label, a match is impossible (i.e., the
# corresponding label does not exist), look to see if a
# the "*" label exists.
To help describe the process of looking "to see is a the [sic]
label exists" a term has been coined to describe the last label
matched. The term is "Closest Encloser."
3.3.1 Closest Encloser and the Source of Synthesis
The "Closest Encloser" is the node in the zone's tree of existing
domain names that is has the most matching labels with the sought
name. Each match is a "Label Match" and the order of the labels
is also the same. The Closest Encloser is an existing name in the
zone, it may be an empty non-terminal, it may even be a Wild Card
Domain Name itself. In no circumstances is the Closest Encloser
the used to synthesize records though.
A "Source of Synthesis" is defined in the context of a lookup
process as the Wild Card Domain Name immediately descending from
the Closest Encloser provided the Wild Card Domain Name exists.
A Source of Synthesis does not guarantee having a RRSet to use
for synthesis, a Source of Synthesis may even be an empty
non-terminal.
If a Source of Synthesis exists, it will be the Wild Card Domain Name
that is identified by an Asterisk Label below the Closest Encloser.
E.g., "<Asterisk Label>.<Closest Encloser> or "*.<Closest Encloser>."
If the Source of Synthesis does not exist (not on the domain tree),
there will be no wildcard synthesis
The important concept is that for any given lookup process, there
is at most one place at which wildcard synthetic records can be
obtained. If the Source of Synthesis does not exist, the lookup
terminates, the lookup does not look for other wildcard records.
Other terms have been coined on the mailing list in the past. E.g.,
it has been said that existing names block the application of
wildcard records. This is still an appropriate viewpoint, but
replacing this notion with the Closest Encloser and Source of
Synthesis the depiction of the wildcard process is clearer.
3.3.2 Closest Encloser and Source of Synthesis Examples
To illustrate, using the example zone in section 2.2.1 of this document,
the following chart shows QNAMEs and the closest enclosers.
QNAME Closest Encloser Source of Synthesis
host3.example. example. *.example.
_telnet._tcp.host1.example. _tcp.host1.example. no source
_telnet._tcp.host2.example. host2.example. no source
_telnet._tcp.host3.example. example. *.example.
_chat._udp.host3.example. example. *.example.
The fact that a closest encloser will be the only superdomain that
can have a candidate wild card will have an impact when it comes to
designing pre-calculated authenticated denial of existence proofs.
3.3.3 Non-existent Source of Synthesis
In RFC 1034:
# If the "*" label does not exist, check whether the name
# we are looking for is the original QNAME in the query
# or a name we have followed due to a CNAME. If the name
# is original, set an authoritative name error in the
# response and exit. Otherwise just exit.
The above passage is clear, evidenced by the lack of discussion and
mis-implementation of it over the years. It is included for
completeness only. (No attempt is made to re-interpret it lest
a mistake in editing leads to confusion.)
3.3.4 Type Matching
RFC 1034 concludes part c with this:
# If the "*" label does exist, match RRs at that node
# against QTYPE. If any match, copy them into the answer
# section, but set the owner of the RR to be QNAME, and
# not the node with the "*" label. Go to step 6.
This final paragraph covers the role of the QTYPE in the lookup process.
Based on implementation feedback and similarities between step a and
step c a change to this passage a change has been made.
The change is to add the following text:
If the data at the source of synthesis is a CNAME, and
QTYPE doesn't match CNAME, copy the CNAME RR into the
answer section of the response changing the owner name
to the QNAME, change QNAME to the canonical name in the
CNAME RR, and go back to step 1.
This is essentially the same text in step a covering the processing of
CNAME RRSets.
4. Considerations with Special Types
Five types of RRSets owned by a Wild Card Domain Name have caused
confusion. Four explicit types causing confusion are SOA, NS, CNAME,
DNAME, and the fifth type - "none."
4.1. SOA RR's at a Wild Card Domain Name
A Wild Card Domain Name owning an SOA RRSet means that the domain
is at the root of the zone (apex). The domain can not be a Source of
Synthesis because that is, but definition, a descendent node (of
the Closest Encloser) and a zone apex is at the top of the zone.
Although a Wild Card Domain Name can not be a Source of Synthesis,
there is no reason to forbid the ownership of an SOA RRSet. This
means that zones with names like "*.<Parent Zone>.", and even
"*.<Parent Sublabels>.<Parent Zone>."
Step 2 (section 3.1) does not provide a means to specify a means to
synthesize a zone. Therefore, according to the rules there, the
only way in which a zone that has a name which is a Wild Card
Domain Name is if the QNAME is in a domain below the zone's name.
E.g., if *.example. has an SOA record, then only a query like
QNAME=*.example., QTYPE=A, QCLASS=IN would see it. As another
example, a QNAME of www.*.example. would also result in passing
through the zone.
4.2. NS RR's at a Wild Card Domain Name
The semantics of a Wild Card Domain Name ownership of a NS RRSet
has been unclear. Looking through RFC 1034, the recommendation
is to have the NS RRSet act the same a any non-special type, e.g.,
like an A RR.
If the NS RRSet in question is at the top of the zone, i.e., the
name also owns an SOA RRSet, the QNAME equals the zone name. This
would trigger part 'a' of Step 3.
In any other case, the Wild Card Domain Name owned NS RRSet would
be the only RRSet (prior to changes instituted by DNSSEC) at the
node by DNS rules. If the QNAME equals the Wild Card Domain Name
or is a subdomain of it, then the node would be considered in part
'b' of Step 3.
Note that there is no synthesis of records in the authority section
because part 'b' does not account for synthesis. The referral
returned would have the Wild Card Domain Name in the authority section,
unchanged.
If the QNAME is not the same as the Wild Card Domain Name nor a
subdomain of it, then part 'c' of Step 3 has been triggered. Once
part 'c' is entered, there is no reverting to part 'b' - i.e.,
once an NS RRSet is synthesized it does not mean that the server has
to consider the name delegated away. I.e., the server is not
synthesizing a record (the NS RRSet) that means the server does not
have the right to synthesize.
4.3. CNAME RR's at a Wild Card Domain Name
The issue of CNAME RR's owned by wild card domain names has prompted
a suggested change to the last paragraph of step 3c of the algorithm
in 4.3.2. The changed text appears in section 3.3.4 of this document.
4.4. DNAME RR's at a Wild Card Domain Name
The specification of the DNAME RR, which is at the proposed level of
standardization, is not as mature as the full standard in RFC 1034.
Because of this, or the reason for this is, there appears to be a
a number of issues with that definition and it's rewrite of the algorithm
in 4.3.2. For the time being, when it comes to wild card processing
issues, a DNAME can be considered to be a CNAME synthesizer. A DNAME
at a wild card domain name is effectively the same as a CNAME at a
wild card domain name.
4.5 Empty Non-terminal Wild Card Domain Name
If a Source of Synthesis is an empty non-terminal, then the response
will be one of no error in the return code and no RRSet in the answer
section.
5. Security Considerations
This document is refining the specifications to make it more likely
that security can be added to DNS. No functional additions are being
made, just refining what is considered proper to allow the DNS,
security of the DNS, and extending the DNS to be more predictable.
6. References
Normative References
[RFC 20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969
[RFC 1034] Domain Names - Concepts and Facilities, P.V. Mockapetris,
Nov-01-1987
[RFC 1035] Domain Names - Implementation and Specification, P.V
Mockapetris, Nov-01-1987
[RFC 2119] Key Words for Use in RFCs to Indicate Requirement Levels, S
Bradner, March 1997
Informative References
[RFC 2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P.
Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997
[RFC 2535] Domain Name System Security Extensions, D. Eastlake, March 1999
[RFC 2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999
7. Others Contributing to This Document
Others who have been editors of this document: Bob Halley and Robert Elz.
Others who have directly caused text to appear in the document: Paul
Vixie and Olaf Kolkman. Many others have indirect influences on the
content.
8. Editor
Name: Edward Lewis
Affiliation: NeuStar
Address: tbd
Phone: tbd
Email: tbd (please send comments to namedroppers)
Comments on this document can be sent to the editors or the mailing
list for the DNSEXT WG, namedroppers@ops.ietf.org.
9. Trailing Boilerplate
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. The IETF invites any interested party to
bring to its attention any copyrights, patents or patent
applications, or other proprietary rights that may cover technology
that may be required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Expiration
This document expires on or about 11 April 2005.

842
doc/draft/draft-ietf-dnsext-wcard-clarify-05.txt Normal file
View File

@@ -0,0 +1,842 @@
DNSEXT Working Group E. Lewis
INTERNET DRAFT NeuStar
Expiration Date: August 10, 2005 February 2005
The Role of Wildcard Domains
in the Domain Name System
draft-ietf-dnsext-wcard-clarify-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 August 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This is an update to the wildcard definition of RFC 1034. The
interaction with wildcards and CNAME is changed, an error
condition removed, and the words defining some concepts central to
wildcards are changed. The overall goal is not to change wildcards,
but to refine the definition of RFC 1034.
1 Introduction
In RFC 1034 [RFC1034], sections 4.3.2 and 4.3.3 describe the synthesis
of answers from special resource records called wildcards. The definition
in RFC 1034 is incomplete and has proven to be confusing. This document
describes the wildcard synthesis by adding to the discussion and making
limited modifications. Modifications are made to close inconsistencies
that have led to interoperability issues. This description does not
expand the service intended by the original definition.
Staying within the spirit and style of the original documents, this
document avoids specifying rules for DNS implementations regarding
wildcards. The intention is to only describe what is needed for
interoperability, not restrict implementation choices. In addition,
consideration has been given to minimize any backwards compatibility
with implementations that have complied with RFC 1034's definition.
This document is focused on the concept of wildcards as defined in RFC
1034. Nothing is implied regarding alternative approaches, nor are
alternatives discussed.
[Note to the WG - this draft is not complete, it is presented as fodder
for the upcoming meeting. Sections 4.2.3, 4.6, 3.7, and 4.8 are
particularly incomplete. I wanted to make sure there was something
recent in the draft repository before setting out on more travel.
For 4.2.3, refer to the threads for the most recent discussions...
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01601.html
http://ops.ietf.org/lists/namedroppers/namedroppers.2004/msg01603.html
And you might want to check out the minutes from the last IETF meeting
as well as http://www.ietf.org/proceedings/03nov/131.htm.]
1.1 Motivation
Many DNS implementations have diverged with respect to wildcards in
different ways from the original definition, or at from least what
had been intended. Although there is clearly a need to clarify the
original documents in light of this alone, the impetus for this document
lay in the engineering of the DNS security extensions [RFC TBD]. With
an unclear definition of wildcards the design of authenticated denial
became entangled.
This document is intended to limit changes, only those based on
implementation experience, and to remain as close to the original
document as possible. To reinforce this, relevant sections of RFC
1034 are repeated verbatim to help compare the old and new text.
1.2 The Original Definition
The context of the wildcard concept involves the algorithm by which
a name server prepares a response (in RFC 1034's section 4.3.2) and
the way in which a resource record (set) is identified as being a
source of synthetic data (section 4.3.3).
The beginning of the discussion ought to start with the definition
of the term "wildcard" as it appears in RFC 1034, section 4.3.3.
# In the previous algorithm, special treatment was given to RRs with owner
# names starting with the label "*". Such RRs are called wildcards.
# Wildcard RRs can be thought of as instructions for synthesizing RRs.
# When the appropriate conditions are met, the name server creates RRs
# with an owner name equal to the query name and contents taken from the
# wildcard RRs.
This passage appears after the algorithm in which the term wildcard
is first used. In this definition, wildcard refers to resource
records. In other usage, wildcard has referred to domain names, and
it has been used to describe the operational practice of relying on
wildcards to generate answers. It is clear from this that there is
a need to define clear and unambiguous terminology in the process of
discussing wildcards.
The mention of the use of wildcards in the preparation of a response
is contained in step 3c of RFC 1034's section 4.3.2 entitled "Algorithm."
Note that "wildcard" does not appear in the algorithm, instead references
are made to the "*" label. The portion of the algorithm relating to
wildcards is deconstructed in detail in section 3 of this document,
this is the beginning of the passage.
# c. If at some label, a match is impossible (i.e., the
# corresponding label does not exist), look to see if a
# the "*" label exists.
The scope of this document is the RFC 1034 definition of wildcards and
the implications of updates to those documents, such as DNSSEC. Alternate
schemes for synthesizing answers are not considered. (Note that there
is no reference listed. No document is known to describe any alternate
schemes, although there has been some mention of them in mailing lists.)
1.3 This Document
This document accomplishes these three items.
o Defines new terms
o Makes minor changes to avoid conflicting concepts
o Describe the actions of certain resource records as wildcards
1.3.1 New Terms
To help in discussing what resource records are wildcards, two terms
will be defined - "asterisk label" and "wild card domain name". These
are defined in section 2.1.1.
To assist in clarifying the role of wildcards in the name server algorithm
in RFC 1034, 4.3.2, "source of synthesis" and "closest encloser" are
defined. These definitions are in section 3.3.2. "Label match" is
defined in section 3.2.
The introduction of new terms ought not have an impact on any existing
implementations. The new terms are used only to make discussions of
wildcards clearer.
1.3.2 Changed Text
The definition of "existence" is changed, superficially. This
change will not be apparent to implementations; it is needed to
make descriptions more precise. The change appears in section 2.2.3.
RFC 1034, section 4.3.3., seems to prohibit having two asterisk
labels in a wildcard owner name. With this document the restriction
is removed entirely. This change and its implications are in
section 2.1.3.
The actions when a source of synthesis owns a CNAME RR are changed to
mirror the actions if an exact match name owns a CNAME RR. This
is an addition to the words in RFC 1034, section 4.3.2, step 3,
part c. The discussion of this is in section 3.3.3.
Only the latter change represents an impact to implementations. The
definition of existence is not a protocol impact. The change to the
restriction on names is unlikely to have an impact, as there was no
discussion of how to enforce the restriction.
1.3.3 Considerations with Special Types
This document describes semantics of wildcard CNAME RRSets [RFC2181],
wildcard NS RRSets, wildcard SOA RRSets, wildcard DNAME RRSets
[RFC2672], wildcard DS RRSets [RFC TBD], and empty non-terminal
wildcards. Understanding these types in the context of wildcards
has been clouded because these types incur special processing if they
are the result of an exact match. This discussion is in section 4.
These discussions do not have an implementation impact, they cover
existing knowledge of the types, but to a greater level of detail.
1.4 Standards Terminology
This document does not use terms as defined in "Key words for use in
RFCs to Indicate Requirement Levels." [RFC2119]
Quotations of RFC 1034 are denoted by a '#' in the leftmost column.
2 Wildcard Syntax
The syntax of a wildcard is the same as any other DNS resource record,
across all classes and types. The only significant feature is the
owner name.
Because wildcards are encoded as resource records with special names,
they are included in zone transfers and incremental zone transfers.
[RFC1995]. This feature has been underappreciated until discussions
on alternative approaches to wildcards appeared on mailing lists.
2.1 Identifying a wildcard
To provide a more accurate description of "wildcards", the definition
has to start with a discussion of the domain names that appear as
owners. Two new terms are needed, "Asterisk Label" and "Wild Card
Domain Name."
2.1.1 Wild Card Domain Name and Asterisk Label
A "wild card domain name" is defined by having its initial
(i.e., left-most or least significant) label be, in binary format:
0000 0001 0010 1010 (binary) = 0x01 0x2a (hexadecimal)
The first octet is the normal label type and length for a 1 octet
long label, the second octet is the ASCII representation [RFC20] for
the '*' character.
A descriptive name of a label equaling that value is an "asterisk
label."
RFC 1034's definition of wildcard would be "a resource record owned
by a wild card domain name."
2.1.2 Asterisks and Other Characters
No label values other than that in section 2.1.1 are asterisk labels,
hence names beginning with other labels are never wild card domain
names. Labels such as 'the*' and '**' are not asterisk labels,
they do not start wild card domain names.
2.1.3 Non-terminal Wild Card Domain Names
In section 4.3.3, the following is stated:
# .......................... The owner name of the wildcard RRs is of
# the form "*.<anydomain>", where <anydomain> is any domain name.
# <anydomain> should not contain other * labels......................
This restriction is lifted because the original documentation of it
is incomplete and the restriction does not serve any purpose given
years of operational experience.
Indirectly, the above passage raises questions about wild card domain
names having subdomains and possibly being an empty non-terminal. By
thinking of domain names such as "*.example.*.example." and
"*.*.example." and focusing on the right-most asterisk label in each,
the issues become apparent.
Although those example names have been restricted per RFC 1034, a name
such as "example.*.example." illustrates the same problems. The
sticky issue of subdomains and empty non-terminals is not removed by
the restriction. With that conclusion, the restriction appears to
be meaningless, worse yet, it implies that an implementation would have
to perform checks that do little more than waste CPU cycles.
A wild card domain name can have subdomains. There is no need to
inspect the subdomains to see if there is another asterisk label in
any subdomain.
A wild card domain name can be an empty non-terminal. (See the upcoming
sections on empty non-terminals.) In this case, any lookup encountering
it will terminate as would any empty non-terminal match.
2.2 Existence Rules
The notion that a domain name 'exists' is mentioned in the definition
of wildcards. In section 4.3.3 of RFC 1034:
# Wildcard RRs do not apply:
#
...
# - When the query name or a name between the wildcard domain and
# the query name is know[n] to exist. For example, if a wildcard
RFC 1034 also refers to non-existence in the process of generating
a response that results in a return code of "name error." NXDOMAIN
is introduced in RFC 2308, section 2.1 says "In this case the domain
... does not exist." The overloading of the term "existence" is
confusing.
For the purposes of this document, a domain name is said to exist if
it plays a role in the execution of the algorithms in RFC 1034. This
document avoids discussion determining when an authoritative name
error has occurred.
2.2.1 An Example
To illustrate what is meant by existence consider this complete zone:
$ORIGIN example.
example. 3600 IN SOA <SOA RDATA>
example. 3600 NS ns.example.com.
example. 3600 NS ns.example.net.
*.example. 3600 TXT "this is a wild card"
*.example. 3600 MX 10 host1.example.
sub.*.example. 3600 TXT "this is not a wild card"
host1.example. 3600 A 192.0.4.1
_ssh._tcp.host1.example. 3600 SRV <SRV RDATA>
_ssh._tcp.host2.example. 3600 SRV <SRV RDATA>
subdel.example. 3600 NS ns.example.com.
subdel.example. 3600 NS ns.example.net.
A look at the domain names in a tree structure is helpful:
|
-------------example------------
/ / \ \
/ / \ \
/ / \ \
* host1 host2 subdel
| | |
| | |
sub _tcp _tcp
| |
| |
_ssh _ssh
The following queries would be synthesized from one of the wildcards:
QNAME=host3.example. QTYPE=MX, QCLASS=IN
the answer will be a "host3.example. IN MX ..."
QNAME=host3.example. QTYPE=A, QCLASS=IN
the answer will reflect "no error, but no data"
because there is no A RR set at '*.example.'
QNAME=foo.bar.example. QTYPE=TXT, QCLASS=IN
the answer will be "foo.bar.example. IN TXT ..."
because bar.example. does not exist, but the wildcard does.
The following queries would not be synthesized from any of the wildcards:
QNAME=host1.example., QTYPE=MX, QCLASS=IN
because host1.example. exists
QNAME=ghost.*.example., QTYPE=MX, QCLASS=IN
because *.example. exists
QNAME=sub.*.example., QTYPE=MX, QCLASS=IN
because sub.*.example. exists
QNAME=_telnet._tcp.host1.example., QTYPE=SRV, QCLASS=IN
because _tcp.host1.example. exists (without data)
QNAME=host.subdel.example., QTYPE=A, QCLASS=IN
because subdel.example. exists (and is a zone cut)
2.2.2 Empty Non-terminals
Empty non-terminals [RFC2136, Section 7.16] are domain names that own
no resource records but have subdomains that do. In section 2.2.1,
"_tcp.host1.example." is an example of a empty non-terminal name.
Empty non-terminals are introduced by this text in section 3.1 of RFC
1034:
# The domain name space is a tree structure. Each node and leaf on the
# tree corresponds to a resource set (which may be empty). The domain
# system makes no distinctions between the uses of the interior nodes and
# leaves, and this memo uses the term "node" to refer to both.
The parenthesized "which may be empty" specifies that empty non-
terminals are explicitly recognized, and that empty non-terminals
"exist."
Pedantically reading the above paragraph can lead to an
interpretation that all possible domains exist - up to the suggested
limit of 255 octets for a domain name [RFC1035]. For example,
www.example. may have an A RR, and as far as is practically
concerned, is a leaf of the domain tree. But the definition can be
taken to mean that sub.www.example. also exists, albeit with no data.
By extension, all possible domains exist, from the root on down. As
RFC 1034 also defines "an authoritative name error indicating that
the name does not exist" in section 4.3.1, this is not the intent of
the original document.
2.2.3 Yet Another Definition of Existence
RFC1034's wording is fixed by the following paragraph:
The domain name space is a tree structure. Nodes in the tree either
own at least one RRSet and/or have descendants that collectively own at
least on RRSet. A node may have no RRSets if it has descendents that
do, this node is a empty non-terminal. A node may have its own RRSets
and have descendants with RRSets too.
A node with no descendants is a leaf node. Empty leaf nodes do not
exist.
Note that at a zone boundary, the domain name owns data, including
the NS RR set. At the delegating server, the NS RR set is not
authoritative, but that is of no consequence here. The domain name
owns data, therefore, it exists.
2.3 When does a Wild Card Domain Name is not Special
When a wild card domain name appears in a message's query section,
no special processing occurs. An asterisk label in a query name
only (label) matches an asterisk label in the existing zone tree
when the 4.3.2 algorithm is being followed.
When a wild card domain name appears in the resource data of a
record, no special processing occurs. An asterisk label in that
context literally means just an asterisk.
3. Impact of a Wild Card Domain Name On a Response
The description of how wildcards impact response generation is in
RFC 1034, section 4.3.2. That passage contains the algorithm
followed by a server in constructing a response. Within that
algorithm, step 3, part 'c' defines the behavior of the wild card.
The algorithm in RFC 1034, section 4.3.2. is not intended to be pseudo
code, i.e., its steps are not intended to be followed in strict
order. The "algorithm" is a suggestion. As such, in step 3, parts
a, b, and c, do not have to be implemented in that order.
3.1 Step 2
Step 2 of the RFC 1034's section 4.3.2 reads:
# 2. Search the available zones for the zone which is the nearest
# ancestor to QNAME. If such a zone is found, go to step 3,
# otherwise step 4.
In this step, the most appropriate zone for the response is chosen.
The significance of this step is that it means all of step 3 is being
performed within one zone. This has significance when considering
whether or not an SOA RR can be ever be used for synthesis.
3.2 Step 3
Step 3 is dominated by three parts, labelled 'a', 'b', and 'c'. But the
beginning of the step is important and needs explanation.
# 3. Start matching down, label by label, in the zone. The
# matching process can terminate several ways:
The word 'matching' refers to label matching. The concept
is based in the view of the zone as the tree of existing names. The
query name is considered to be an ordered sequence of labels - as
if the name were a path from the root to the owner of the desired
data. (Which it is - 3rd paragraph of RFC 1034, section 3.1.)
The process of label matching a query name ends in exactly one of three
choices, the parts 'a', 'b', and 'c'. Either the name is found, the
name is below a cut point, or the name is not found.
Once one of the parts is chosen, the other parts are not considered.
(E.g., do not execute part 'c' and then change the execution path to
finish in part 'b'.) The process of label matching is also done
independent of the query type (QTYPE).
Parts 'a' and 'b' are not an issue for this clarification as they do not
relate to record synthesis. Part 'a' is an exact match that results in
an answer, part 'b' is a referral. It is possible, from the description
given, that a query might fit into both part a and part b, this is
not within the scope of this document.
3.3 Part 'c'
The context of part 'c' is that the process of label matching the
labels of the query name has resulted in a situation in which there
is no corresponding label in the tree. It is as if the lookup has
"fallen off the tree."
# c. If at some label, a match is impossible (i.e., the
# corresponding label does not exist), look to see if a
# the "*" label exists.
To help describe the process of looking 'to see if a [sic] the "*"
label exists' a term has been coined to describe the last label
matched. The term is "closest encloser."
3.3.1 Closest Encloser and the Source of Synthesis
The closest encloser is the node in the zone's tree of existing
domain names that has the most labels matching the query name
(consecutively, counting from the root label downward). Each match
is a "label match" and the order of the labels is the same.
The closest encloser is, by definition, an existing name in the zone. The
closest encloser might be an empty non-terminal or even be a wild card
domain name itself. In no circumstances is the closest encloser
the used to synthesize records for the current query.
The source of synthesis is defined in the context of a query process
as that wild card domain name immediately descending from the
closest encloser, provided that this wild card domain name exists.
"Immediately descending" means that the source of synthesis has a name
of the form <asterisk label>.<closest encloser>. A source of synthesis
does not guarantee having a RRSet to use for synthesis. The source of
synthesis could be an empty non-terminal.
If the source of synthesis does not exist (not on the domain tree),
there will be no wildcard synthesis. There is no search for an alternate.
The important concept is that for any given lookup process, there
is at most one place at which wildcard synthetic records can be
obtained. If the source of synthesis does not exist, the lookup
terminates, the lookup does not look for other wildcard records.
3.3.2 Closest Encloser and Source of Synthesis Examples
To illustrate, using the example zone in section 2.2.1 of this document,
the following chart shows QNAMEs and the closest enclosers.
QNAME Closest Encloser Source of Synthesis
host3.example. example. *.example.
_telnet._tcp.host1.example. _tcp.host1.example. no source
_telnet._tcp.host2.example. host2.example. no source
_telnet._tcp.host3.example. example. *.example.
_chat._udp.host3.example. example. *.example.
foobar.*.example. *.example. no source
3.3.3 Type Matching
RFC 1034 concludes part 'c' with this:
# If the "*" label does not exist, check whether the name
# we are looking for is the original QNAME in the query
# or a name we have followed due to a CNAME. If the name
# is original, set an authoritative name error in the
# response and exit. Otherwise just exit.
#
# If the "*" label does exist, match RRs at that node
# against QTYPE. If any match, copy them into the answer
# section, but set the owner of the RR to be QNAME, and
# not the node with the "*" label. Go to step 6.
The final paragraph covers the role of the QTYPE in the lookup process.
Based on implementation feedback and similarities between step 'a' and
step 'c' a change to this passage a change has been made.
The change is to add the following text to step 'c':
If the data at the source of synthesis is a CNAME, and
QTYPE doesn't match CNAME, copy the CNAME RR into the
answer section of the response changing the owner name
to the QNAME, change QNAME to the canonical name in the
CNAME RR, and go back to step 1.
This is essentially the same text in step a covering the processing of
CNAME RRSets.
4. Considerations with Special Types
Sections 2 and 3 of this document discuss wildcard synthesis with
respect to names in the domain tree and ignore the impact of types.
In this section, the implication of wildcards of specific types are
discussed. The types covered are those that have proven to be the
most difficult to understand. The types are SOA, NS, CNAME, DNAME,
SRV, DS, NSEC, RRSIG and "none," i.e., empty non-terminal wild card
domain names.
4.1 SOA RRSet at a Wild Card Domain Name
A wild card domain name owning an SOA RRSet means that the domain
is at the root of the zone (apex). The domain can not be a source of
synthesis because that is, by definition, a descendent node (of
the closest encloser) and a zone apex is at the top of the zone.
Although a wild card domain name owning an SOA RRSet can never be a
source of synthesis, there is no reason to forbid the ownership of
an SOA RRSet.
E.g., given this zone:
$ORIGIN *.example.
@ 3600 IN SOA <SOA RDATA>
3600 NS ns1.example.com.
3600 NS ns1.example.net.
www 3600 TXT "the www txt record"
A query for www.*.example.'s TXT record would still find the "the www txt
record" answer. The reason is that the asterisk label only becomes
significant when RFC 1034's 4.3.2, step 3 part 'c' in in effect.
Of course, there would need to be a delegation in the parent zone,
"example." for this to work too. This is covered in the next section.
4.2 NS RRSet at a Wild Card Domain Name
The semantics of a wild card domain name's ownership of a NS RRSet
has been unclear. There are three considerations to cover. One is
is that if the query processing lands in part 'a' or part 'b' of
RFC 1034's 4.3.2, step 3, the incidence of the wild card domain name
owning an NS RRset has no special meaning. Second, synthesized
records never appear in the authority section of a response, meaning
that referrals are never synthesized. And finally, DNSSEC validators
will have to be aware of a quirk in ownership rules.
4.2.1 NS, *, and answers
If the NS RRSet in question is at the top of the zone, i.e., the
name also owns an SOA RRSet, the QNAME equals the zone name. This
would trigger part 'a' of step 3.
4.2.2 NS, *, and referrals
If the NS RRset is not at the top of the zone and part 'b' is triggered,
this implies that the labels being matched are an asterisk label in
the QNAME and the asterisk label owning the NS RRset. In either case,
what is copied to the response will have the asterisk label in it - no
synthesis, no name substitution.
E.g., consider the parent zone for the example in section 4.1.
$ORIGIN example.
@ 3600 IN SOA <SOA RDATA>
3600 NS ns0.example.com.
3600 NS ns0.example.net.
* 3600 NS ns1.example.com.
3600 NS ns1.example.net.
If the query for www.*.example.'s TXT set arrived here, the response
would be a referral as in part 'b'.
Response, non-authoritative, no error rcode
ANSWER: (empty)
AUTHORITY:
* 3600 NS ns1.example.com.
3600 NS ns1.example.net.
ADDITIIONAL: (empty, or with OPT RR)
The same response message would be sent to a query for *.example.'s NS
set. Note that the NS records in the response are not expanded, simply
copied verbatim. (Compare this the case where "*" is "star".)
There is no synthesis of records in the authority section because part
'b' does not specify synthesis. The referral returned would have the
wild card domain name in the authority section unchanged.
4.2.3 NS, *, and synthesis
If the QNAME is not the same as the wild card domain name nor a
subdomain of it, then part 'c' of step 3 has been triggered. Assuming
that "a match is impossible" a source of synthesis is sought. If
the source of synthesis owns an NS RRset and the QTYPE is NS, then
a NS RRset is synthesized and put into the answer section and marked
as an authoritative answer. If the QTYPE is not NS, then the NS RRset
is ignored, as it would have been if it were an A RR and the QTYPE was
AAAA. An NS RRSet at a wild card domain name will not result in
the generation of referral messages for non-existent domains because
part 'c' does not write anything into the authority section.
(If we choose this, then we have to have a section 4.2.4 on DNSSEC
implications.)
OR
If the QNAME is not the same as the wild card domain name nor a
subdomain of it, then part 'c' of step 3 has been triggered. Assuming
that "a match is impossible" a source of synthesis is sought. If
the source of synthesis owns an NS RRset and the QTYPE is NS, then
no synthesis happens. A NS RRset is never synthesized. The proper
response is, what, no error/no data? Name error?
OR
If the QNAME is not the same as the wild card domain name nor a
subdomain of it, then part 'c' of step 3 has been triggered. Assuming
that "a match is impossible" a source of synthesis is sought. If
the source of synthesis owns an NS RRset then no synthesis happens.
A cut point is never a source of synthesis. The proper response is,
what, no error/no data? Name error?
4.3 CNAME RRSet at a Wild Card Domain Name
The issue of a CNAME RRSet owned by wild card domain names has prompted
a suggested change to the last paragraph of step 3c of the algorithm
in 4.3.2. The changed text appears in section 3.3.3 of this document.
4.4 DNAME RRSet at a Wild Card Domain Name
A DNAME RRset at a wild card domain name is effectively the same
as a CNAME at a wild card domain name.
4.5 SRV RRSet at a Wild Card Domain Name
The definition of the SRV RRset is RFC 2782 [RFC2782]. In the
definition of the record, there is some confusion over the term
"Name." The definition reads as follows:
# The format of the SRV RR
...
# _Service._Proto.Name TTL Class SRV Priority Weight Port Target
...
# Name
# The domain this RR refers to. The SRV RR is unique in that the
# name one searches for is not this name; the example near the end
# shows this clearly.
Do not confuse the definition "Name" with a domain name. I.e., once
removing the _Service and _Proto labels from the owner name of the
SRV RRSet, what remains could be a wild card domain name but this is
immaterial to the SRV RRSet.
E.g., If an SRV record is:
_foo._udp.*.example. 10800 IN SRV 0 1 9 old-slow-box.example.
*.example is a wild card domain name and although it it the Name of
the SRV RR, it is not the owner (domain name). The owner domain name
is "_foo._udp.*.example." which is not a wild card domain name.
The confusion is likely based on the mixture of the specification of
the SRV RR and the description of a "use case."
4.6 DS RRSet at a Wild Card Domain Name
...probably harmless...
4.7 NSEC RRSet at a Wild Card Domain Name
...will be present, don't know if it should be synthesized...
4.8 RRSIG at a Wild Card Domain Name
...need to cross check with DNSSECbis to see what is said about querying
for RRSIG...
4.9 Empty Non-terminal Wild Card Domain Name
If a source of synthesis is an empty non-terminal, then the response
will be one of no error in the return code and no RRSet in the answer
section.
5. Security Considerations
This document is refining the specifications to make it more likely
that security can be added to DNS. No functional additions are being
made, just refining what is considered proper to allow the DNS,
security of the DNS, and extending the DNS to be more predictable.
6. References
Normative References
[RFC20] ASCII Format for Network Interchange, V.G. Cerf, Oct-16-1969
[RFC1034] Domain Names - Concepts and Facilities, P.V. Mockapetris,
Nov-01-1987
[RFC1035] Domain Names - Implementation and Specification, P.V
Mockapetris, Nov-01-1987
[RFC1995] IXFR ... Ohta
[RFC2119] Key Words for Use in RFCs to Indicate Requirement Levels, S
Bradner, March 1997
[RFC2181] Clarifications to the DNS Specification, R. Elz and R. Bush,
July 1997.
[RFC2782] A DNS RR for specifying the location of services (DNS SRV),
A. Gulbrandsen, et.al., February 2000.
Informative References
[RFC2136] Dynamic Updates in the Domain Name System (DNS UPDATE), P.
Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound, April 1997
[RFC2535] Domain Name System Security Extensions, D. Eastlake, March 1999
[RFC2672] Non-Terminal DNS Name Redirection, M. Crawford, August 1999
7. Others Contributing to This Document
Others who have been editors of this document: Bob Halley.
Others who have directly caused text to appear in the document: Alex
Bligh, Robert Elz, Paul Vixie, David Blacka and Olaf Kolkman.
Many others have indirect influences on the content.
8. Editor
Name: Edward Lewis
Affiliation: NeuStar
Address: 46000 Center Oak Plaza, Sterling, VA, 20166, US
Phone: +1-571-434-5468
Email: ed.lewis@neustar.biz
Comments on this document can be sent to the editor or the mailing
list for the DNSEXT WG, namedroppers@ops.ietf.org.
9. Trailing Boilerplate
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78 and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. The IETF invites any interested party to
bring to its attention any copyrights, patents or patent
applications, or other proprietary rights that may cover technology
that may be required to implement this standard. Please address the
information to the IETF at ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Expiration
This document expires on or about August 10, 2005.

1120
doc/draft/draft-ietf-dnsop-bad-dns-res-02.txt
View File

File diff suppressed because it is too large Load Diff

1123
doc/draft/draft-ietf-dnsop-bad-dns-res-03.txt Normal file
View File

File diff suppressed because it is too large Load Diff

1193
doc/draft/draft-ietf-dnsop-dnssec-operational-practices-02.txt → doc/draft/draft-ietf-dnsop-dnssec-operational-practices-03.txt
View File

File diff suppressed because it is too large Load Diff

301
doc/draft/draft-ietf-dnsop-inaddr-required-05.txt
View File

@@ -1,301 +0,0 @@
INTERNET-DRAFT D. Senie
Category: BCP Amaranth Networks Inc.
Expires in six months April 2004
Encouraging the use of DNS IN-ADDR Mapping
draft-ietf-dnsop-inaddr-required-05.txt
Status of this Memo
This draft, is intended to be become a Best Current Practice RFC.
Distribution of this document is unlimited. Comments should be sent
to the Domain Name Server Operations working group mailing list
<dnsop@cafax.se> or to the author.
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of [RFC2026].
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."
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2000-2002). All Rights Reserved.
Abstract
Mapping of addresses to names has been a feature of DNS. Many sites,
implement it, many others don’t. Some applications attempt to use it
as a part of a security strategy. The goal of this document is to
encourage proper deployment of address to name mappings, and provide
guidance for their use.
1. Introduction
The Domain Name Service has provision for providing mapping of IP
addresses to host names. It is common practice to ensure both name to
address, and address to name mappings are provided for networks. This
practice, while documented, has never been documented as a
requirement placed upon those who control address blocks. This
Senie [Page 1]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping April 2004
document fills this gap.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Discussion
From the early days of the Domain Name Service [RFC 883] a special
domain has been set aside for resolving mappings of IP addresses to
domain names. This was refined in [RFC1035], describing the .IN-
ADDR.ARPA in use today.
The assignment of blocks of IP Address space was delegated to three
regional registries. Guidelines for the registries are specified in
[RFC2050], which requires regional registries to maintain IN-ADDR
records on the large blocks of space issued to ISPs and others.
ARIN’s policy requires ISPs to maintain IN-ADDR for /16 or larger
allocations. For smaller allocations, ARIN can provide IN-ADDR for
/24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to
update IN-ADDR, however the present version of its policy document
for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
copies of this document. As of this writing, it appears APNIC has no
actual policy on IN-ADDR. RIPE appears to have the strongest policy
in this area [ripe-185] indicating Local Internet Registries are
required to perform IN-ADDR services, and delegate those as
appropriate when address blocks are delegated.
As we can see, the regional registries have their own policies for
requirements for IN-ADDR maintenance. It should be noted, however,
that many address blocks were allocated before the creation of the
regional registries, and thus it is unclear whether any of the
policies of the registries are binding on those who hold blocks from
that era.
Registries allocate address blocks on CIDR [RFC1519] boundaries.
Unfortunately the IN-ADDR zones are based on classful allocations.
Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
exist, but are not always implemented.
3. Effects of missing IN-ADDR
Many applications use DNS lookups for security checks. To ensure
validity of claimed names, some applications will look up IN-ADDR
records to get names, and then look up the resultant name to see if
it maps back to the address originally known. Failure to resolve
matching names is seen as a potential security concern.
Senie [Page 2]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping April 2004
Some popular FTP sites will flat-out reject users, even for anonymous
FTP, if the IN-ADDR lookup fails or if the result of the IN-ADDR
lookup when itself resolved, does not match. Some Telnet servers also
implement this check.
Web sites are in some cases using IN-ADDR checks to verify whether
the client is located within a certain geopolitical entity. This is
being employed for downloads of crypto software, for example, where
export of that software is prohibited to some locales. Credit card
anti-fraud systems also use these methods for geographic placement
purposes.
The popular TCP Wrappers program found on most Unix and Linux systems
has options to enforce IN-ADDR checks and to reject any client that
does not resolve.
Wider-scale implementation of IN-ADDR on dialup, CDPD and other such
client-oriented portions of the Internet would result in lower
latency for queries (due to lack of negative caching), and lower name
server load and DNS traffic.
Some anti-spam (anti junk email) systems use IN-ADDR to verify return
addresses before accepting email.
Many web servers look up the IN-ADDR of visitors to be used in log
analysis. This adds to the server load, but in the case of IN-ADDR
unavailability, it can lead to delayed responses for users.
Traceroutes with descriptive IN-ADDR naming proves useful when
debugging problems spanning large areas. When this information is
missing, the traceroutes take longer, and it takes additional steps
to determine that network is the cause of problems.
4. Requirements
4.1 Delegation Requirements
Regional Registries and any Local Registries to whom they delegate
SHOULD establish and convey a policy to those to whom they delegate
blocks that IN-ADDR mappings are required. Policies SHOULD require
those receiving delegations to provide IN-ADDR service and/or
delegate to downstream customers.
Network operators SHOULD define and implement policies and procedures
which delegate IN-ADDR to their clients who wish to run their own IN-
ADDR DNS services, and provide IN-ADDR services for those who do not
have the resources to do it themselves. Delegation mechanisms MUST
permit the downstream customer to implement and comply with IETF
Senie [Page 3]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping April 2004
recommendations application of IN-ADDR to CIDR [RFC2317].
All IP address space assigned and in use SHOULD be resolved by IN-
ADDR records. All PTR records MUST use canonical names.
All IP addresses in use within a block SHOULD have an IN-ADDR
mapping. Those addresses not in use, and those that are not valid for
use (zeros or ones broadcast addresses within a CIDR block) need not
have mappings.
It should be noted that due to CIDR, many addresses that appear to be
otherwise valid host addresses may actually be zeroes or ones
broadcast addresses. As such, attempting to audit a site’s degree of
compliance can only be done with knowledge of the internal routing
structure of the site. However, any host that originates an IP packet
necessarily will have a valid host address, and must therefore have
an IN-ADDR mapping.
4.2 Application Requirements
Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
of IN-ADDR, sometimes in conjunction with a lookup of the name
resulting from the PTR record provides no real security, can lead to
erroneous results and generally just increases load on DNS servers.
Further, in cases where address block holders fail to properly
configure IN-ADDR, users of those blocks are penalized.
5. Security Considerations
This document has no negative impact on security. While it could be
argued that lack of PTR record capabilities provides a degree of
anonymity, this is really not valid. Trace routes, whois lookups and
other sources will still provide methods for discovering identity.
By recommending applications avoid using IN-ADDR as a security
mechanism this document points out that this practice, despite its
use by many applications, is an ineffective form of security.
Applications should use better mechanisms of authentication.
6. References
[RFC883] P.V. Mockapetris, "Domain names: Implementation
specification," RFC883, November 1983.
[RFC1035] P.V. Mockapetris, "Domain Names: Implementation
Specification," RFC 1035, November 1987.
[RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
Senie [Page 4]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping April 2004
an Address Assignment and Aggregation Strategy," RFC 1519, September
1993.
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
RFC 2026, BCP 9, October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
Guidelines", RFC2050, BCP 12, Novebmer 1996.
[RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
RFC 2317, March 1998.
[ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
unknown, http://www.arin.net/regserv/initial-isp.html
[APNIC] "Policies For IPv4 Address Space Management in the Asia
Pacific Region," APNIC-086, 13 January 2003.
[RIPE185] "European Internet Registry Policies and Procedures,"
ripe-185, October 26, 1998. http://www.ripe.net/docs/ripe-185.html
7. Acknowledgements
Thanks to Peter Koch and Gary Miller for their input, and to many
people who encouraged me to write this document.
8. Author’s Address
Daniel Senie
Amaranth Networks Inc.
324 Still River Road
Bolton, MA 01740
Phone: (978) 779-5100
EMail: dts@senie.com
Senie [Page 5]

424
doc/draft/draft-ietf-dnsop-inaddr-required-06.txt Normal file
View File

@@ -0,0 +1,424 @@
draft-ietf-dnsop-inaddr-required-06.txt
INTERNET-DRAFT D. Senie
Category: BCP Amaranth Networks Inc.
Expires in six months February 2005
Encouraging the use of DNS IN-ADDR Mapping
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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>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>http://www.ietf.org/shadow.html
Abstract
Mapping of addresses to names has been a feature of DNS. Many sites,
implement it, many others don't. Some applications attempt to use it
as a part of a security strategy. The goal of this document is to
encourage proper deployment of address to name mappings, and provide
guidance for their use.
Copyright Notice
Copyright (C) The Internet Society. (2005)
1. Introduction
The Domain Name Service has provision for providing mapping of IP
addresses to host names. It is common practice to ensure both name to
address, and address to name mappings are provided for networks. This
practice, while documented, has never been required, though it is
generally encouraged. This document both encourages the presence of
Senie [Page 1]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
these mappings and discourages reliance on such mappings for security
checks.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
2. Discussion
From the early days of the Domain Name Service [RFC883] a special
domain has been set aside for resolving mappings of IP addresses to
domain names. This was refined in [RFC1035], describing the .IN-
ADDR.ARPA in use today. For the in the IPv6 address space, .IP6.ARPA
was added [RFC3152]. This document uses IPv4 CIDR block sizes and
allocation strategy where there are differences and uses IPv4
terminology. Aside from these differences, this document can and
should be applied to both address spaces.
The assignment of blocks of IP address space was delegated to three
regional registries. Guidelines for the registries are specified in
[RFC2050], which requires regional registries to maintain IN-ADDR
records on the large blocks of space issued to ISPs and others.
ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger
allocations. For smaller allocations, ARIN can provide IN-ADDR for
/24 and shorter prefixes. [ARIN]. APNIC provides methods for ISPs to
update IN-ADDR, however the present version of its policy document
for IPv4 [APNIC] dropped the IN-ADDR requirements that were in draft
copies of this document. As of this writing, it appears APNIC has no
actual policy on IN-ADDR. RIPE appears to have the strongest policy
in this area [RIPE302] indicating Local Internet Registries should
provide IN-ADDR services, and delegate those as appropriate when
address blocks are delegated.
As we can see, the regional registries have their own policies for
recommendations and/or requirements for IN-ADDR maintenance. It
should be noted, however, that many address blocks were allocated
before the creation of the regional registries, and thus it is
unclear whether any of the policies of the registries are binding on
those who hold blocks from that era.
Registries allocate address blocks on CIDR [RFC1519] boundaries.
Unfortunately the IN-ADDR zones are based on classful allocations.
Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
exist, but are not always implemented.
3. Examples of impact of missing IN-ADDR
Senie [Page 2]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
These are some examples of problems that may be introduced by
reliance on IN-ADDR.
Some applications use DNS lookups for security checks. To ensure
validity of claimed names, some applications will look up IN-ADDR
records to get names, and then look up the resultant name to see if
it maps back to the address originally known. Failure to resolve
matching names is seen as a potential security concern.
Some FTP sites will flat-out reject users, even for anonymous FTP, if
the IN-ADDR lookup fails or if the result of the IN-ADDR lookup when
itself resolved, does not match. Some Telnet servers also implement
this check.
Web sites are in some cases using IN-ADDR checks to verify whether
the client is located within a certain geopolitical entity. This
approach has been employed for downloads of crypto software, for
example, where export of that software is prohibited to some locales.
Credit card anti-fraud systems also use these methods for geographic
placement purposes.
The popular TCP Wrappers program found on most Unix and Linux systems
has options to enforce IN-ADDR checks and to reject any client that
does not resolve. This program also has a way to check to see that
the name given by a PTR record then resolves back to the same IP
address. This method provdes more comfort but no appreciable
additional security.
Some anti-spam (anti junk email) systems use IN-ADDR to verify the
presence of a PTR record, or validate the PTR value points back to
the same address.
Many web servers look up the IN-ADDR of visitors to be used in log
analysis. This adds to the server load, but in the case of IN-ADDR
unavailability, it can lead to delayed responses for users.
Traceroutes with descriptive IN-ADDR naming proves useful when
debugging problems spanning large areas. When this information is
missing, the traceroutes take longer, and it takes additional steps
to determine that network is the cause of problems.
Wider-scale implementation of IN-ADDR on dialup, wireless access and
other such client-oriented portions of the Internet would result in
lower latency for queries (due to lack of negative caching), and
lower name server load and DNS traffic.
4. Recommendations
Senie [Page 3]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
4.1 Delegation Recommendations
Regional Registries and any Local Registries to whom they delegate
should establish and convey a policy to those to whom they delegate
blocks that IN-ADDR mappings are recommended. Policies should
recommend those receiving delegations to provide IN-ADDR service
and/or delegate to downstream customers.
Network operators should define and implement policies and procedures
which delegate IN-ADDR to their clients who wish to run their own IN-
ADDR DNS services, and provide IN-ADDR services for those who do not
have the resources to do it themselves. Delegation mechanisms should
permit the downstream customer to implement and comply with IETF
recommendations application of IN-ADDR to CIDR [RFC2317].
All IP address space assigned and in use should be resolved by IN-
ADDR records. All PTR records must use canonical names.
All IP addresses in use within a block should have an IN-ADDR
mapping. Those addresses not in use, and those that are not valid for
use (zeros or ones broadcast addresses within a CIDR block) need not
have mappings.
It should be noted that due to CIDR, many addresses that appear to be
otherwise valid host addresses may actually be zeroes or ones
broadcast addresses. As such, attempting to audit a site's degree of
compliance may only be done with knowledge of the internal subnet
architecture of the site. It can be assumed, however, any host that
originates an IP packet necessarily will have a valid host address,
and must therefore have an IN-ADDR mapping.
4.2 Application Recommendations
Applications SHOULD NOT rely on IN-ADDR for proper operation. The use
of IN-ADDR, sometimes in conjunction with a lookup of the name
resulting from the PTR record provides no real security, can lead to
erroneous results and generally just increases load on DNS servers.
Further, in cases where address block holders fail to properly
configure IN-ADDR, users of those blocks are penalized.
5. Security Considerations
This document has no negative impact on security. While it could be
argued that lack of PTR record capabilities provides a degree of
anonymity, this is really not valid. Trace routes, whois lookups and
other sources will still provide methods for discovering identity.
Senie [Page 4]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
By recommending applications avoid using IN-ADDR as a security
mechanism this document points out that this practice, despite its
use by many applications, is an ineffective form of security.
Applications should use better mechanisms of authentication.
6. IANA Considerations
There are no IANA considerations for this document.
7. References
7.1 Normative References
[RFC883] P.V. Mockapetris, "Domain names: Implementation
specification," RFC883, November 1983.
[RFC1035] P.V. Mockapetris, "Domain Names: Implementation
Specification," RFC 1035, November 1987.
[RFC1519] V. Fuller, et. al., "Classless Inter-Domain Routing (CIDR):
an Address Assignment and Aggregation Strategy," RFC 1519, September
1993.
[RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3",
RFC 2026, BCP 9, October 1996.
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2050] K. Hubbard, et. al., "Internet Registry IP Allocation
Guidelines", RFC2050, BCP 12, Novebmer 1996.
[RFC2317] H. Eidnes, et. al., "Classless IN-ADDR.ARPA delegation,"
RFC 2317, March 1998.
[RFC3152] R. Bush, "Delegation of IP6.ARPA," RFC 3152, BCP 49, August
2001.
7.2 Informative References
[ARIN] "ISP Guidelines for Requesting Initial IP Address Space," date
unknown,
<http://www.arin.net/regserv/initial-isp.html>http://www.arin.net/regserv/initial-isp.html
[APNIC] "Policies For IPv4 Address Space Management in the Asia
Pacific Region," APNIC-086, 13 January 2003.
[RIPE302] "Policy for Reverse Address Delegation of IPv4 and IPv6
Address Space in the RIPE NCC Service Region", RIPE-302, April 26,
Senie [Page 5]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
2004.
<http://www.ripe.net//ripe/docs/rev-del.html>http://www.ripe.net//ripe/docs/rev-del.html
8. Acknowledgements
Thanks to Peter Koch and Gary Miller for their input, and to many
people who encouraged me to write this document.
9. Author's Address
Daniel Senie
Amaranth Networks Inc.
324 Still River Road
Bolton, MA 01740
Phone: (978) 779-5100
EMail: <mailto:dts@senie.com>dts@senie.com
10. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in
BCP 78 and except as set forth therein, the authors retain
all their rights.
This document and the information contained herein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to
rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
Senie [Page 6]
Internet-Draft Encouraging the use of DNS IN-ADDR Mapping February 2005
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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at <http://www.ietf.org/ipr>http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at <mailto:ietf-ipr@ietf.org>ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Senie [Page 7]

391
doc/draft/draft-ietf-dnsop-key-rollover-requirements-01.txt
View File

@@ -1,391 +0,0 @@
DNSOP G. Guette
Internet-Draft IRISA / INRIA
Expires: February 5, 2005 O. Courtay
Thomson R&D
August 7, 2004
Requirements for Automated Key Rollover in DNSSEC
draft-ietf-dnsop-key-rollover-requirements-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 5, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes problems that appear during an automated
rollover and gives the requirements for the design of communication
between parent zone and child zone in an automated rollover process.
This document is essentially about key rollover, the rollover of
another Resource Record present at delegation point (NS RR) is also
discussed.
Guette & Courtay Expires February 5, 2005 [Page 1]
Internet-Draft Automated Rollover Requirements August 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
4. Messages authentication and information exchanged . . . . . . 4
5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
6. Other Resource Record concerned by automatic rollover . . . . 5
7. Security consideration . . . . . . . . . . . . . . . . . . . . 5
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
9. Normative References . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6
Intellectual Property and Copyright Statements . . . . . . . . 7
Guette & Courtay Expires February 5, 2005 [Page 2]
Internet-Draft Automated Rollover Requirements August 2004
1. Introduction
The DNS security extensions (DNSSEC) [4][8][7][9] uses public-key
cryptography and digital signatures. It stores the public part of
keys in DNSKEY Resource Records (RRs). Because old keys and
frequently used keys are vulnerable, they must be renewed
periodically. In DNSSEC, this is the case for Zone Signing Keys
(ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key
rollover process is necessary for large zones because there are too
many changes to handle a manual administration.
Let us consider for example a zone with 100000 secure delegations.
If the child zones change their keys once a year on average, that
implies 300 changes per day for the parent zone. This amount of
changes are hard to manage manually.
Automated rollover is optional and resulting from an agreement
between the administrator of the parent zone and the administrator of
the child zone. Of course, key rollover can also be done manually by
administrators.
This document describes the requirements for the design of messages
of automated key rollover process and focusses on interaction between
parent and child zone.
2. The Key Rollover Process
Key rollover consists in renewing the DNSSEC keys used to sign
resource records in a given DNS zone file. There are two types of
rollover, ZSK rollovers and KSK rollovers.
In a ZSK rollover, all changes are local to the zone that renews its
key: there is no need to contact other zones (e.g., parent zone) to
propagate the performed changes because a ZSK has no associated DS
record in the parent zone.
In a KSK rollover, new DS RR(s) must be created and stored in the
parent zone. In consequence, the child zone must contact its parent
zone and must notify it about the KSK change(s).
Manual key rollover exists and works [3]. The key rollover is built
from two parts of different nature:
o An algorithm that generates new keys and signs the zone file. It
could be local to the zone
o The interaction between parent and child zones
One example of manual key rollover is:
Guette & Courtay Expires February 5, 2005 [Page 3]
Internet-Draft Automated Rollover Requirements August 2004
o The child zone creates a new KSK
o The child zone waits for the creation of the DS RR in its parent
zone
o The child zone deletes the old key.
In manual rollover, communications are managed by the zone
administrators and the security of these communications is out of
scope of DNSSEC.
Automated key rollover should use a secure communication between
parent and child zones. This document concentrates on defining
interactions between entities present in key rollover process.
3. Basic Requirements
The main constraint to respect during a key rollover is that the
chain of trust MUST be preserved, even if a resolver retrieves some
RRs from recursive cache server. Every RR MUST be verifiable at any
time, every RRs exchanged during the rollover should be authenticated
and their integrity should be guaranteed.
Two entities act during a KSK rollover: the child zone and its parent
zone. These zones are generally managed by different administrators.
These administrators should agree on some parameters like
availability of automated rollover, the maximum delay between
notification of changes in the child zone and the resigning of the
parent zone. The child zone needs to know this delay to schedule its
changes.
4. Messages authentication and information exchanged
Every exchanged message MUST be authenticated and the authentication
tool MUST be a DNSSEC tool such as TSIG [6], SIG(0) [5] or DNSSEC
request with verifiable SIG records.
Once the changes related to a KSK are made in a child zone, this zone
MUST notify its parent zone in order to create the new DS RR and
store this DS RR in parent zone file.
The parent zone MUST receive all the child keys that needs the
creation of associated DS RRs in the parent zone.
Some errors could occur during transmission between child zone and
parent zone. Key rollover solution MUST be fault tolerant, i.e. at
any time the rollover MUST be in a consistent state and all RRs MUST
be verifiable, even if an error occurs. That is to say that it MUST
remain a valid chain of trust.
Guette & Courtay Expires February 5, 2005 [Page 4]
Internet-Draft Automated Rollover Requirements August 2004
5. Emergency Rollover
A key of a zone might be compromised and this key MUST be changed as
soon as possible. Fast changes could break the chain of trust. The
part of DNS tree having this zone as apex can become unverifiable,
but the break of the chain of trust is necessary if we want to no one
can use the compromised key to spoof DNS data.
In case of emergency rollover, the administrators of parent and child
zones should create new key(s) and DS RR(s) as fast as possible in
order to reduce the time the chain of trust is broken.
6. Other Resource Record concerned by automatic rollover
NS records are also present at delegation point, so when the child
zone renews some NS RR, the corresponding records at delegation point
in parent zone (glue) MUST be updated. NS records are concerned by
rollover and this rollover could be automated too. In this case,
when the child zone notifies its parent zone that some NS records
have been changed, the parent zone MUST verify that these NS records
are present in child zone before doing any changes in its own zone
file. This allows to avoid inconsistency between NS records at
delegation point and NS records present in the child zone.
7. Security consideration
This document describes requirements to design an automated key
rollover in DNSSEC based on DNSSEC security. In the same way, as
plain DNSSEC, the automatic key rollover contains no mechanism
protecting against denial of service (DoS). The security level
obtain after an automatic key rollover, is the security level
provided by DNSSEC.
8. Acknowledgments
The authors want to acknowledge Francis Dupont, Mohsen Souissi,
Bernard Cousin, Bertrand L<>onard and members of IDsA project for
their contribution to this document.
9 Normative References
[1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
RFC 3658, December 2003.
[2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
(DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
RFC 3757, May 2004.
Guette & Courtay Expires February 5, 2005 [Page 5]
Internet-Draft Automated Rollover Requirements August 2004
[3] Kolkman, O., "DNSSEC Operational Practices",
draft-ietf-dnsop-dnssec-operational-practice-01 (work in
progress), May 2004.
[4] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[5] Eastlake, D., "DNS Request and Transaction Signatures (
SIG(0)s)", RFC 2931, September 2000.
[6] Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)", RFC
2845, May 2000.
[7] Arends, R., "Resource Records for the DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-09 (work in progress), July
2004.
[8] Arends, R., Austein, R., Massey, D., Larson, M. and S. Rose,
"DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-11 (work in progress), July 2004.
[9] Arends, R., "Protocol Modifications for the DNS Security
Extensions", draft-ietf-dnsext-dnssec-protocol-07 (work in
progress), July 2004.
Authors' Addresses
Gilles Guette
IRISA / INRIA
Campus de Beaulieu
35042 Rennes CEDEX
FR
EMail: gilles.guette@irisa.fr
URI: http://www.irisa.fr
Olivier Courtay
Thomson R&D
1, avenue Belle Fontaine
35510 Cesson S<>vign<67> CEDEX
FR
EMail: olivier.courtay@thomson.net
Guette & Courtay Expires February 5, 2005 [Page 6]
Internet-Draft Automated Rollover Requirements August 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights 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; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Guette & Courtay Expires February 5, 2005 [Page 7]

389
doc/draft/draft-ietf-dnsop-key-rollover-requirements-02.txt Normal file
View File

@@ -0,0 +1,389 @@
DNSOP G. Guette
Internet-Draft IRISA / INRIA
Expires: July 19, 2005 O. Courtay
Thomson R&D
January 18, 2005
Requirements for Automated Key Rollover in DNSSEC
draft-ietf-dnsop-key-rollover-requirements-02.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 July 19, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved.
Abstract
This document describes problems that appear during an automated
rollover and gives the requirements for the design of communication
between parent zone and child zone during an automated rollover
process. This document is essentially about in-band key rollover.
Guette & Courtay Expires July 19, 2005 [Page 1]
Internet-Draft Automated Rollover Requirements January 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Key Rollover Process . . . . . . . . . . . . . . . . . . . 3
3. Basic Requirements . . . . . . . . . . . . . . . . . . . . . . 4
4. Messages authentication and information exchanged . . . . . . 5
5. Emergency Rollover . . . . . . . . . . . . . . . . . . . . . . 5
6. Security consideration . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
8. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
A. Documents details and changes . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
Guette & Courtay Expires July 19, 2005 [Page 2]
Internet-Draft Automated Rollover Requirements January 2005
1. Introduction
The DNS security extensions (DNSSEC) [4][6][5][7] uses public-key
cryptography and digital signatures. It stores the public part of
keys in DNSKEY Resource Records (RRs). Because old keys and
frequently used keys are vulnerable, they must be renewed
periodically. In DNSSEC, this is the case for Zone Signing Keys
(ZSKs) and Key Signing Keys (KSKs) [1][2]. Automation of key
exchanges between parents and children is necessary for large zones
because there are too many changes to handle.
Let us consider for example a zone with 100000 secure delegations.
If the child zones change their keys once a year on average, that
implies 300 changes per day for the parent zone. This amount of
changes is hard to manage manually.
Automated rollover is optional and resulting from an agreement
between the administrator of the parent zone and the administrator of
the child zone. Of course, key rollover can also be done manually by
administrators.
This document describes the requirements for a protocol to perform
the automated key rollover process and focusses on interaction
between parent and child zone.
2. The Key Rollover Process
Key rollover consists of renewing the DNSSEC keys used to sign
resource records in a given DNS zone file. There are two types of
rollover, ZSK rollovers and KSK rollovers.
During a ZSK rollover, all changes are local to the zone that renews
its key: there is no need to contact other zones administrators to
propagate the performed changes because a ZSK has no associated DS
record in the parent zone.
During a KSK rollover, new DS RR(s) must be created and stored in the
parent zone. In consequence, data must be exchanged between child
and parent zones.
The key rollover is built from two parts of different nature:
o An algorithm that generates new keys and signs the zone file. It
can be local to the zone,
o the interaction between parent and child zones.
One example of manual key rollover [3] is:
o The child zone creates a new KSK,
Guette & Courtay Expires July 19, 2005 [Page 3]
Internet-Draft Automated Rollover Requirements January 2005
o the child zone waits for the creation of the DS RR in its parent
zone,
o the child zone deletes the old key,
o the parent zone deletes the old DS RR.
This document concentrates on defining interactions between entities
present in key rollover process.
3. Basic Requirements
This section provides the requirements for automated key rollover in
case of normal use. Exceptional case like emergency rollover is
specifically described later in this document.
The main condition during a key rollover is that the chain of trust
must be preserved to every validating DNS client. No matter if this
client retrieves some of the RRs from recursive caching name server
or from the authoritative servers for the zone involved in the
rollover.
Automated key rollover solution may be interrupted by a manual
intervention. This manual intervention should not compromise the
security state of the chain of trust. If the chain is safe before
the manual intervention, the chain of trust must remain safe during
and after the manual intervention
Two entities act during a KSK rollover: the child zone and its parent
zone. These zones are generally managed by different administrators.
These administrators should agree on some parameters like
availability of automated rollover, the maximum delay between
notification of changes in the child zone and the resigning of the
parent zone. The child zone needs to know this delay to schedule its
changes and/or to verify that the changes had been taken into account
in the parent zone. Hence, the child zone can also avoid some
critical cases where all child key are changed prior to the DS RR
creation.
By keeping some resource records during a given time, the recursive
cache servers can act on the automated rollover. The existence of
recursive cache servers must be taken into account by automated
rollover solution.
Indeed, during an automated key rollover a name server could have to
retrieve some DNSSEC data. An automated key rollover solution must
ensure that these data are not old DNSSEC material retrieved from a
recursive name server.
Guette & Courtay Expires July 19, 2005 [Page 4]
Internet-Draft Automated Rollover Requirements January 2005
4. Messages authentication and information exchanged
This section addresses in-band rollover, security of out-of-band
mechanisms is out of scope of this document.
The security provided by DNSSEC must not be compromised by the key
rollover, thus every exchanged message must be authenticated to avoid
fake rollover messages from malicious parties.
Once the changes related to a KSK are made in a child zone, there are
two ways for the parent zone to take this changes into account:
o the child zone notify directly or not directly its parent zone in
order to create the new DS RR and store this DS RR in parent zone
file,
o or the parent zone poll the child zone.
In both cases, the parent zone must receive all the child keys that
need the creation of associated DS RRs in the parent zone.
Because errors could occur during the transmission of keys between
child and parent, the key exchange protocol must be fault tolerant.
Should an error occured during the automated key rollover, an
automated key rollover solution must be able to keep the zone files
in a consistent state.
5. Emergency Rollover
Emergency key rollover is a special case of rollover decided by the
zone administrator generally for security reasons. In consequence,
emergency key rollover can break some of the requirement described
above.
A zone key might be compromised and an attacker can use the
compromised key to create and sign fake records. To avoid this, the
zone administrator may change the compromised key or all its keys as
soon as possible, without waiting for the creation of new DS RRs in
its parent zone.
Fast changes may break the chain of trust. The part of DNS tree
having this zone as apex can become unverifiable, but the break of
the chain of trust is necessary if the administrator wants to prevent
the compromised key from being used (to spoof DNS data).
Parent and child zones sharing an automated rollover mechanism,
should have an out-of-band way to re-establish a consistent state at
the delegation point (DS and DNSKEY RRs). This allows to avoid that
a malicious party uses the compromised key to roll the zone keys.
Guette & Courtay Expires July 19, 2005 [Page 5]
Internet-Draft Automated Rollover Requirements January 2005
6. Security consideration
The automated key rollover process in DNSSEC allows automated renewal
of any kind of DNS key (ZSK or KSK). It is essential that parent
side and child side can do mutual authentication. Moreover,
integrity of the material exchanged between the parent and child zone
must be provided to ensure the right DS are created.
As in any application using public key cryptography, in DNSSEC a key
may be compromised. What to do in such a case can be describe in the
zone local policy and can violate some requirements described in this
draft. The emergency rollover can break the chain of trust in order
to protect the zone against the use of the compromised key.
7. Acknowledgments
The authors want to thank members of IDsA project for their
contribution to this document.
8 Normative References
[1] Gudmundsson, O., "Delegation Signer (DS) Resource Record (RR)",
RFC 3658, December 2003.
[2] Kolkman, O., Schlyter, J. and E. Lewis, "Domain Name System KEY
(DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag",
RFC 3757, May 2004.
[3] Kolkman, O., "DNSSEC Operational Practices",
draft-ietf-dnsop-dnssec-operational-practice-01 (work in
progress), May 2004.
[4] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[5] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"Resource Records for the DNS Security Extensions",
draft-ietf-dnsext-dnssec-records-11 (work in progress), October
2004.
[6] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"DNS Security Introduction and Requirements",
draft-ietf-dnsext-dnssec-intro-13 (work in progress), October
2004.
[7] Arends, R., Austein, R., Larson, M., Massey, D. and S. Rose,
"Protocol Modifications for the DNS Security Extensions",
draft-ietf-dnsext-dnssec-protocol-09 (work in progress), October
Guette & Courtay Expires July 19, 2005 [Page 6]
Internet-Draft Automated Rollover Requirements January 2005
2004.
Authors' Addresses
Gilles Guette
IRISA / INRIA
Campus de Beaulieu
35042 Rennes CEDEX
FR
EMail: gilles.guette@irisa.fr
URI: http://www.irisa.fr
Olivier Courtay
Thomson R&D
1, avenue Belle Fontaine
35510 Cesson S?vign? CEDEX
FR
EMail: olivier.courtay@thomson.net
Appendix A. Documents details and changes
This section is to be removed by the RFC editor if and when the
document is published.
Section about NS RR rollover has been removed
Remarks from Samuel Weiler and Rip Loomis added
Clarification about in-band rollover and in emergency section
Section 3, details about recursive cache servers added
Guette & Courtay Expires July 19, 2005 [Page 7]
Internet-Draft Automated Rollover Requirements January 2005
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
IETF Documents can be found in BCP 78 and 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
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 implement this standard. Please address the information to the
IETF at ietf-ipr.org.
Full Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION 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 & Courtay Expires July 19, 2005 [Page 8]