Compare commits
7 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
9bf72603fc | ||
|
|
44473da351 | ||
|
64f1feb817 | ||
|
|
48f408365c | ||
|
|
15108d191a | ||
|
|
600305bf9b | ||
|
|
2ea4703dbe |
5
CHANGES
5
CHANGES
@@ -1,4 +1,9 @@
|
||||
|
||||
--- 9.4.1 released ---
|
||||
|
||||
2172. [bug] query_addsoa() was being called with a non zone db.
|
||||
[RT #16834]
|
||||
|
||||
--- 9.4.0 released ---
|
||||
|
||||
2138. [bug] Lock order reversal in resolver.c. [RT #16653]
|
||||
|
||||
5
README
5
README
@@ -43,6 +43,11 @@ BIND 9
|
||||
Nominum, Inc.
|
||||
|
||||
|
||||
BIND 9.4.1
|
||||
|
||||
BIND 9.4.1 is a security release, containing a fix for a
|
||||
security bug in 9.4.0.
|
||||
|
||||
BIND 9.4.0
|
||||
|
||||
BIND 9.4.0 has a number of new features over 9.3,
|
||||
|
||||
@@ -15,7 +15,7 @@
|
||||
* PERFORMANCE OF THIS SOFTWARE.
|
||||
*/
|
||||
|
||||
/* $Id: query.c,v 1.257.18.36 2007/01/08 02:41:59 marka Exp $ */
|
||||
/* $Id: query.c,v 1.257.18.36.12.1 2007/04/30 01:10:19 marka Exp $ */
|
||||
|
||||
/*! \file */
|
||||
|
||||
@@ -4209,6 +4209,21 @@ query_find(ns_client_t *client, dns_fetchevent_t *event, dns_rdatatype_t qtype)
|
||||
* an error unless we were searching for
|
||||
* glue. Ugh.
|
||||
*/
|
||||
if (!is_zone) {
|
||||
authoritative = ISC_FALSE;
|
||||
dns_rdatasetiter_destroy(&rdsiter);
|
||||
if (RECURSIONOK(client)) {
|
||||
result = query_recurse(client,
|
||||
qtype,
|
||||
NULL,
|
||||
NULL);
|
||||
if (result == ISC_R_SUCCESS)
|
||||
client->query.attributes |=
|
||||
NS_QUERYATTR_RECURSING;
|
||||
else
|
||||
QUERY_ERROR(DNS_R_SERVFAIL); }
|
||||
goto addauth;
|
||||
}
|
||||
/*
|
||||
* We were searching for SIG records in
|
||||
* a nonsecure zone. Send a "no error,
|
||||
|
||||
@@ -1,840 +0,0 @@
|
||||
|
||||
|
||||
|
||||
DNSEXT D. Blacka
|
||||
Internet-Draft VeriSign, Inc.
|
||||
Intended status: Standards Track April 7, 2006
|
||||
Expires: October 9, 2006
|
||||
|
||||
|
||||
DNSSEC Experiments
|
||||
draft-ietf-dnsext-dnssec-experiments-03
|
||||
|
||||
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 BCP 79.
|
||||
|
||||
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 October 9, 2006.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 1]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes a methodology for deploying alternate, non-
|
||||
backwards-compatible, DNSSEC methodologies in an experimental fashion
|
||||
without disrupting the deployment of standard DNSSEC.
|
||||
|
||||
|
||||
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. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 10
|
||||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
|
||||
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
|
||||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
|
||||
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
|
||||
10.2. Informative References . . . . . . . . . . . . . . . . . 13
|
||||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
|
||||
Intellectual Property and Copyright Statements . . . . . . . . . . 15
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 2]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
1. Definitions and Terminology
|
||||
|
||||
Throughout this document, familiarity with the DNS system (RFC 1035
|
||||
[5]) and the DNS security extensions ([2], [3], and [4] is assumed.
|
||||
|
||||
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 [1].
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 3]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
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 (bad) or otherwise broken to existing security-
|
||||
aware resolvers.
|
||||
|
||||
This document describes a standard methodology for setting up 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
|
||||
security-aware resolvers.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 4]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
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 servers that do implement the
|
||||
DNSSEC standard.
|
||||
|
||||
Non-Backwards-Compatible: describes experiments that would cause a
|
||||
standard security-aware resolver to (incorrectly) determine that
|
||||
all or part of a zone is bogus, or to otherwise not interoperate
|
||||
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 may be used
|
||||
if desired.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 5]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
4. Method
|
||||
|
||||
The core of the methodology is the use of strictly unknown algorithm
|
||||
identifiers when signing the experimental zone, and more importantly,
|
||||
having only unknown algorithm identifiers in the 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
|
||||
algorithm identifiers. From [4], 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 likely that a validator would implement this behavior, or, more to
|
||||
the point, it would handle this situation in a safe way (see below
|
||||
(Section 6).)
|
||||
|
||||
Because we are talking about experiments, it is RECOMMENDED that
|
||||
private algorithm numbers be used (see [3], appendix A.1.1. Note
|
||||
that secure handling of private algorithms requires special handing
|
||||
by the validator logic. See [6] for further details.) 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, it is suggested 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
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 6]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
will suffice.
|
||||
|
||||
Using this method, resolvers (or, more specifically, 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 security-aware servers and
|
||||
resolvers: servers and resolvers that are aware of the experiment
|
||||
(and thus recognize the experiment's algorithm identifiers and
|
||||
experimental semantics), and servers and resolvers that are unaware
|
||||
of the experiment.
|
||||
|
||||
This method also precludes any zone from being both in an experiment
|
||||
and in a classic DNSSEC island of security. That is, a zone is
|
||||
either in an experiment and only experimentally validatable, or it is
|
||||
not.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 7]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
5. Defining an Experiment
|
||||
|
||||
The DNSSEC experiment MUST define the particular set of (previously
|
||||
unknown) algorithm identifiers 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.
|
||||
|
||||
Normally 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.
|
||||
|
||||
For example, an experiment might specify in its description the DNS
|
||||
name "dnssec-experiment-a.example.com" as the base name, and declare
|
||||
that "3.dnssec-experiment-a.example.com" is an alias of DNSSEC
|
||||
algorithm 3 (DSA), and that "5.dnssec-experiment-a.example.com" is an
|
||||
alias of DNSSEC algorithm 5 (RSASHA1).
|
||||
|
||||
Resolvers MUST only recognize the experiment's semantics when present
|
||||
in a zone signed by one or more of these algorithm identifiers. This
|
||||
is necessary to isolate the semantics of one experiment from any
|
||||
others that the resolver might understand.
|
||||
|
||||
In general, resolvers involved in the experiment are expected to
|
||||
understand both standard DNSSEC and the defined experimental DNSSEC
|
||||
protocol, although this isn't required.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 8]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
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 a non-validatable response and conclude
|
||||
that the response is bogus, either due to local policy or
|
||||
implementation details. This is not expected to be a common
|
||||
case, however.
|
||||
|
||||
2. It will not be possible for security-aware resolvers unaware of
|
||||
the experiment to build a chain of trust through an experimental
|
||||
zone.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 9]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
7. Use in Non-Experiments
|
||||
|
||||
This general methodology MAY be used for non-backwards compatible
|
||||
DNSSEC protocol changes that start out as or become standards. In
|
||||
this case:
|
||||
|
||||
o The protocol change SHOULD use public IANA allocated algorithm
|
||||
identifiers instead of private algorithm identifiers. This will
|
||||
help identify the protocol change as a standard, rather than an
|
||||
experiment.
|
||||
|
||||
o Resolvers MAY recognize the protocol change in zones not signed
|
||||
(or not solely signed) using the new algorithm identifiers.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 10]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
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 October 9, 2006 [Page 11]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
9. IANA Considerations
|
||||
|
||||
This document has no IANA actions.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 12]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
10. References
|
||||
|
||||
10.1. Normative References
|
||||
|
||||
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||||
Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"DNS Security Introduction and Requirements", RFC 4033,
|
||||
March 2005.
|
||||
|
||||
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
[4] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Protocol Modifications for the DNS Security Extensions",
|
||||
RFC 4035, March 2005.
|
||||
|
||||
10.2. Informative References
|
||||
|
||||
[5] Mockapetris, P., "Domain names - implementation and
|
||||
specification", STD 13, RFC 1035, November 1987.
|
||||
|
||||
[6] Austein, R. and S. Weiler, "Clarifications and Implementation
|
||||
Notes for DNSSECbis", draft-ietf-dnsext-dnssec-bis-updates-02
|
||||
(work in progress), January 2006.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 13]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
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 October 9, 2006 [Page 14]
|
||||
|
||||
Internet-Draft DNSSEC Experiments April 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
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.
|
||||
|
||||
|
||||
Acknowledgment
|
||||
|
||||
Funding for the RFC Editor function is provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Blacka Expires October 9, 2006 [Page 15]
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,464 +0,0 @@
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
OBSOLETES: RFC 2536 Donald E. Eastlake 3rd
|
||||
Motorola Laboratories
|
||||
Expires: September 2006 March 2006
|
||||
|
||||
|
||||
DSA Keying and Signature Information in the DNS
|
||||
--- ------ --- --------- ----------- -- --- ---
|
||||
<draft-ietf-dnsext-rfc2536bis-dsa-07.txt>
|
||||
Donald E. Eastlake 3rd
|
||||
|
||||
|
||||
Status of This Document
|
||||
|
||||
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 BCP 79.
|
||||
|
||||
Distribution of this document is unlimited. Comments should be sent
|
||||
to the DNS extensions working group mailing list
|
||||
<namedroppers@ops.ietf.org>.
|
||||
|
||||
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/1id-abstracts.html
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html
|
||||
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
The standard method of encoding US Government Digital Signature
|
||||
Algorithm keying and signature information for use in the Domain Name
|
||||
System is specified.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 1]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
Status of This Document....................................1
|
||||
Abstract...................................................1
|
||||
|
||||
Table of Contents..........................................2
|
||||
|
||||
1. Introduction............................................3
|
||||
2. DSA Keying Information..................................3
|
||||
3. DSA Signature Information...............................4
|
||||
4. Performance Considerations..............................4
|
||||
5. Security Considerations.................................5
|
||||
6. IANA Considerations.....................................5
|
||||
Copyright, Disclaimer, and Additional IPR Provisions.......5
|
||||
|
||||
Normative References.......................................7
|
||||
Informative References.....................................7
|
||||
|
||||
Author's Address...........................................8
|
||||
Expiration and File Name...................................8
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 2]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Domain Name System (DNS) is the global hierarchical replicated
|
||||
distributed database system for Internet addressing, mail proxy, and
|
||||
other information [RFC 1034, 1035]. The DNS has been extended to
|
||||
include digital signatures and cryptographic keys as described in
|
||||
[RFC 4033, 4034, 4035] and additional work is underway which would
|
||||
require the storage of keying and signature information in the DNS.
|
||||
|
||||
This document describes how to encode US Government Digital Signature
|
||||
Algorithm (DSA) keys and signatures in the DNS. Familiarity with the
|
||||
US Digital Signature Algorithm is assumed [FIPS 186-2, Schneier].
|
||||
|
||||
|
||||
|
||||
2. DSA Keying Information
|
||||
|
||||
When DSA public keys are stored in the DNS, the structure of the
|
||||
relevant part of the RDATA part of the RR being used is the fields
|
||||
listed below in the order given.
|
||||
|
||||
The period of key validity is not included in this data but is
|
||||
indicated separately, for example by an RR such as RRSIG which signs
|
||||
and authenticates the RR containing the keying information.
|
||||
|
||||
Field Size
|
||||
----- ----
|
||||
T 1 octet
|
||||
Q 20 octets
|
||||
P 64 + T*8 octets
|
||||
G 64 + T*8 octets
|
||||
Y 64 + T*8 octets
|
||||
|
||||
As described in [FIPS 186-2] and [Schneier], T is a key size
|
||||
parameter chosen such that 0 <= T <= 8. (The meaning if the T octet
|
||||
is greater than 8 is reserved and the remainder of the data may have
|
||||
a different format in that case.) Q is a prime number selected at
|
||||
key generation time such that 2**159 < Q < 2**160. Thus Q is always
|
||||
20 octets long and, as with all other fields, is stored in "big-
|
||||
endian" network order. P, G, and Y are calculated as directed by the
|
||||
[FIPS 186-2] key generation algorithm [Schneier]. P is in the range
|
||||
2**(511+64T) < P < 2**(512+64T) and thus is 64 + 8*T octets long. G
|
||||
and Y are quantities modulo P and so can be up to the same length as
|
||||
P and are allocated fixed size fields with the same number of octets
|
||||
as P.
|
||||
|
||||
During the key generation process, a random number X must be
|
||||
generated such that 1 <= X <= Q-1. X is the private key and is used
|
||||
in the final step of public key generation where Y is computed as
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 3]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
Y = G**X mod P
|
||||
|
||||
|
||||
|
||||
3. DSA Signature Information
|
||||
|
||||
The portion of the RDATA area used for US Digital Signature Algorithm
|
||||
signature information is shown below with fields in the order they
|
||||
are listed and the contents of each multi-octet field in "big-endian"
|
||||
network order.
|
||||
|
||||
Field Size
|
||||
----- ----
|
||||
T 1 octet
|
||||
R 20 octets
|
||||
S 20 octets
|
||||
|
||||
First, the data signed must be determined. Then the following steps
|
||||
are taken, as specified in [FIPS 186-2], where Q, P, G, and Y are as
|
||||
specified in the public key [Schneier]:
|
||||
|
||||
hash = SHA-1 ( data )
|
||||
|
||||
Generate a random K such that 0 < K < Q.
|
||||
|
||||
R = ( G**K mod P ) mod Q
|
||||
|
||||
S = ( K**(-1) * (hash + X*R) ) mod Q
|
||||
|
||||
For information on the SHA-1 hash function see [FIPS 180-2] and [RFC
|
||||
3174].
|
||||
|
||||
Since Q is 160 bits long, R and S can not be larger than 20 octets,
|
||||
which is the space allocated.
|
||||
|
||||
T is copied from the public key. It is not logically necessary in
|
||||
the SIG but is present so that values of T > 8 can more conveniently
|
||||
be used as an escape for extended versions of DSA or other algorithms
|
||||
as later standardized.
|
||||
|
||||
|
||||
|
||||
4. Performance Considerations
|
||||
|
||||
General signature generation speeds are roughly the same for RSA [RFC
|
||||
3110] and DSA. With sufficient pre-computation, signature generation
|
||||
with DSA is faster than RSA. Key generation is also faster for DSA.
|
||||
However, signature verification is an order of magnitude slower than
|
||||
RSA when the RSA public exponent is chosen to be small, as is
|
||||
recommended for some applications.
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 4]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
Current DNS implementations are optimized for small transfers,
|
||||
typically less than 512 bytes including DNS overhead. Larger
|
||||
transfers will perform correctly and extensions have been
|
||||
standardized [RFC 2671] to make larger transfers more efficient, it
|
||||
is still advisable at this time to make reasonable efforts to
|
||||
minimize the size of RR sets containing keying and/or signature
|
||||
inforamtion consistent with adequate security.
|
||||
|
||||
|
||||
|
||||
5. 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.
|
||||
|
||||
The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
|
||||
current DSA standard may limit the security of DSA. For particular
|
||||
applications, implementors are encouraged to consider the range of
|
||||
available algorithms and key sizes.
|
||||
|
||||
DSA assumes the ability to frequently generate high quality random
|
||||
numbers. See [random] for guidance. DSA is designed so that if
|
||||
biased rather than random numbers are used, high bandwidth covert
|
||||
channels are possible. See [Schneier] and more recent research. The
|
||||
leakage of an entire DSA private key in only two DSA signatures has
|
||||
been demonstrated. DSA provides security only if trusted
|
||||
implementations, including trusted random number generation, are
|
||||
used.
|
||||
|
||||
|
||||
|
||||
6. IANA Considerations
|
||||
|
||||
Allocation of meaning to values of the T parameter that are not
|
||||
defined herein (i.e., > 8 ) requires an IETF standards actions. It
|
||||
is intended that values unallocated herein be used to cover future
|
||||
extensions of the DSS standard.
|
||||
|
||||
|
||||
|
||||
Copyright, Disclaimer, and Additional IPR Provisions
|
||||
|
||||
Copyright (C) The Internet Society (2006). 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.
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 5]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 6]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
Normative References
|
||||
|
||||
[FIPS 186-2] - U.S. Federal Information Processing Standard: Digital
|
||||
Signature Standard, 27 January 2000.
|
||||
|
||||
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
|
||||
|
||||
Informative References
|
||||
|
||||
[RFC 1034] - "Domain names - concepts and facilities", P.
|
||||
Mockapetris, 11/01/1987.
|
||||
|
||||
[RFC 1035] - "Domain names - implementation and specification", P.
|
||||
Mockapetris, 11/01/1987.
|
||||
|
||||
[RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
|
||||
1999.
|
||||
|
||||
[RFC 3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System
|
||||
(DNS)", D. Eastlake 3rd. May 2001.
|
||||
|
||||
[RFC 3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P.
|
||||
Jones, September 2001.
|
||||
|
||||
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
|
||||
2005.
|
||||
|
||||
[RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
|
||||
4035, March 2005.
|
||||
|
||||
[RFC 4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker,
|
||||
"Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
|
||||
|
||||
[Schneier] - "Applied Cryptography Second Edition: protocols,
|
||||
algorithms, and source code in C" (second edition), Bruce Schneier,
|
||||
1996, John Wiley and Sons, ISBN 0-471-11709-9.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 7]
|
||||
|
||||
|
||||
INTERNET-DRAFT DSA Information in the DNS
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Donald E. Eastlake 3rd
|
||||
Motorola Labortories
|
||||
155 Beaver Street
|
||||
Milford, MA 01757 USA
|
||||
|
||||
Telephone: +1-508-786-7554(w)
|
||||
EMail: Donald.Eastlake@motorola.com
|
||||
|
||||
|
||||
|
||||
Expiration and File Name
|
||||
|
||||
This draft expires in September 2006.
|
||||
|
||||
Its file name is draft-ietf-dnsext-rfc2536bis-dsa-07.txt.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 8]
|
||||
|
||||
@@ -1,580 +0,0 @@
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
OBSOLETES: RFC 2539 Donald E. Eastlake 3rd
|
||||
Motorola Laboratories
|
||||
Expires: September 2006 March 2006
|
||||
|
||||
|
||||
|
||||
|
||||
Storage of Diffie-Hellman Keying Information in the DNS
|
||||
------- -- -------------- ------ ----------- -- --- ---
|
||||
<draft-ietf-dnsext-rfc2539bis-dhk-07.txt>
|
||||
|
||||
|
||||
|
||||
Status of This Document
|
||||
|
||||
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 BCP 79.
|
||||
|
||||
Distribution of this document is unlimited. Comments should be sent
|
||||
to the DNS extensions working group mailing list
|
||||
<namedroppers@ops.ietf.org>.
|
||||
|
||||
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/1id-abstracts.html
|
||||
|
||||
The list of Internet-Draft Shadow Directories can be accessed at
|
||||
http://www.ietf.org/shadow.html
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
The standard method for encoding Diffie-Hellman keys in the Domain
|
||||
Name System is specified.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 1]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
Acknowledgements
|
||||
|
||||
Part of the format for Diffie-Hellman keys and the description
|
||||
thereof was taken from a work in progress by Ashar Aziz, Tom Markson,
|
||||
and Hemma Prafullchandra. In addition, the following persons
|
||||
provided useful comments that were incorporated into the predecessor
|
||||
of this document: Ran Atkinson, Thomas Narten.
|
||||
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
Status of This Document....................................1
|
||||
Abstract...................................................1
|
||||
|
||||
Acknowledgements...........................................2
|
||||
Table of Contents..........................................2
|
||||
|
||||
1. Introduction............................................3
|
||||
1.1 About This Document....................................3
|
||||
1.2 About Diffie-Hellman...................................3
|
||||
2. Encoding Diffie-Hellman Keying Information..............4
|
||||
3. Performance Considerations..............................5
|
||||
4. IANA Considerations.....................................5
|
||||
5. Security Considerations.................................5
|
||||
Copyright, Disclaimer, and Additional IPR Provisions.......5
|
||||
|
||||
Normative References.......................................7
|
||||
Informative Refences.......................................7
|
||||
|
||||
Author's Address...........................................8
|
||||
Expiration and File Name...................................8
|
||||
|
||||
Appendix A: Well known prime/generator pairs...............9
|
||||
A.1. Well-Known Group 1: A 768 bit prime..................9
|
||||
A.2. Well-Known Group 2: A 1024 bit prime.................9
|
||||
A.3. Well-Known Group 3: A 1536 bit prime................10
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 2]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
The Domain Name System (DNS) is the global hierarchical replicated
|
||||
distributed database system for Internet addressing, mail proxy, and
|
||||
similar information [RFC 1034, 1035]. The DNS has been extended to
|
||||
include digital signatures and cryptographic keys as described in
|
||||
[RFC 4033, 4034, 4035] and additonal work is underway which would use
|
||||
the storage of keying information in the DNS.
|
||||
|
||||
|
||||
|
||||
1.1 About This Document
|
||||
|
||||
This document describes how to store Diffie-Hellman keys in the DNS.
|
||||
Familiarity with the Diffie-Hellman key exchange algorithm is assumed
|
||||
[Schneier, RFC 2631].
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
1.2 About Diffie-Hellman
|
||||
|
||||
Diffie-Hellman requires two parties to interact to derive keying
|
||||
information which can then be used for authentication. Thus Diffie-
|
||||
Hellman is inherently a key agreement algorithm. As a result, no
|
||||
format is defined for Diffie-Hellman "signature information". For
|
||||
example, assume that two parties have local secrets "i" and "j".
|
||||
Assume they each respectively calculate X and Y as follows:
|
||||
|
||||
X = g**i ( mod p )
|
||||
|
||||
Y = g**j ( mod p )
|
||||
|
||||
They exchange these quantities and then each calculates a Z as
|
||||
follows:
|
||||
|
||||
Zi = Y**i ( mod p )
|
||||
|
||||
Zj = X**j ( mod p )
|
||||
|
||||
Zi and Zj will both be equal to g**(i*j)(mod p) and will be a shared
|
||||
secret between the two parties that an adversary who does not know i
|
||||
or j will not be able to learn from the exchanged messages (unless
|
||||
the adversary can derive i or j by performing a discrete logarithm
|
||||
mod p which is hard for strong p and g).
|
||||
|
||||
The private key for each party is their secret i (or j). The public
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 3]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
key is the pair p and g, which is the same for both parties, and
|
||||
their individual X (or Y).
|
||||
|
||||
For further information about Diffie-Hellman and precautions to take
|
||||
in deciding on a p and g, see [RFC 2631].
|
||||
|
||||
|
||||
|
||||
2. Encoding Diffie-Hellman Keying Information
|
||||
|
||||
When Diffie-Hellman keys appear within the RDATA portion of a RR,
|
||||
they are encoded as shown below.
|
||||
|
||||
The period of key validity is not included in this data but is
|
||||
indicated separately, for example by an RR such as RRSIG which signs
|
||||
and authenticates the RR containing the keying information.
|
||||
|
||||
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
|
||||
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
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| KEY flags | protocol | algorithm=2 |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| prime length (or flag) | prime (p) (or special) /
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
/ prime (p) (variable length) | generator length |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| generator (g) (variable length) |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| public value length | public value (variable length)/
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
/ public value (g^i mod p) (variable length) |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
|
||||
Prime length is the length of the Diffie-Hellman prime (p) in bytes
|
||||
if it is 16 or greater. Prime contains the binary representation of
|
||||
the Diffie-Hellman prime with most significant byte first (i.e., in
|
||||
network order). If "prime length" field is 1 or 2, then the "prime"
|
||||
field is actually an unsigned index into a table of 65,536
|
||||
prime/generator pairs and the generator length SHOULD be zero. See
|
||||
Appedix A for defined table entries and Section 4 for information on
|
||||
allocating additional table entries. The meaning of a zero or 3
|
||||
through 15 value for "prime length" is reserved.
|
||||
|
||||
Generator length is the length of the generator (g) in bytes.
|
||||
Generator is the binary representation of generator with most
|
||||
significant byte first. PublicValueLen is the Length of the Public
|
||||
Value (g**i (mod p)) in bytes. PublicValue is the binary
|
||||
representation of the DH public value with most significant byte
|
||||
first.
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 4]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
3. Performance Considerations
|
||||
|
||||
Current DNS implementations are optimized for small transfers,
|
||||
typically less than 512 bytes including DNS overhead. Larger
|
||||
transfers will perform correctly and extensions have been
|
||||
standardized [RFC 2671] to make larger transfers more efficient. But
|
||||
it is still advisable at this time to make reasonable efforts to
|
||||
minimize the size of RR sets containing keying information consistent
|
||||
with adequate security.
|
||||
|
||||
|
||||
|
||||
4. IANA Considerations
|
||||
|
||||
Assignment of meaning to Prime Lengths of 0 and 3 through 15 requires
|
||||
an IETF consensus as defined in [RFC 2434].
|
||||
|
||||
Well known prime/generator pairs number 0x0000 through 0x07FF can
|
||||
only be assigned by an IETF standards action. [RFC 2539], the
|
||||
Proposed Standard predecessor of this document, assigned 0x0001
|
||||
through 0x0002. This document additionally assigns 0x0003. Pairs
|
||||
number 0s0800 through 0xBFFF can be assigned based on RFC
|
||||
documentation. Pairs number 0xC000 through 0xFFFF are available for
|
||||
private use and are not centrally coordinated. Use of such private
|
||||
pairs outside of a closed environment may result in conflicts and/or
|
||||
security failures.
|
||||
|
||||
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
Keying information retrieved from the DNS should not be trusted
|
||||
unless (1) it has 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 important
|
||||
and dependent on security policy.
|
||||
|
||||
In addition, the usual Diffie-Hellman key strength considerations
|
||||
apply. (p-1)/2 SHOULD also be prime, g SHOULD be primitive mod p, p
|
||||
SHOULD be "large", etc. See [RFC 2631, Schneier].
|
||||
|
||||
|
||||
|
||||
Copyright, Disclaimer, and Additional IPR Provisions
|
||||
|
||||
Copyright (C) The Internet Society (2006). 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.
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 5]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 6]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
Normative References
|
||||
|
||||
[RFC 2119] - Bradner, S., "Key words for use in RFCs to Indicate
|
||||
Requirement Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[RFC 2434] - "Guidelines for Writing an IANA Considerations Section
|
||||
in RFCs", T. Narten, H. Alvestrand, October 1998.
|
||||
|
||||
[RFC 2631] - "Diffie-Hellman Key Agreement Method", E. Rescorla, June
|
||||
1999.
|
||||
|
||||
[RFC 4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
|
||||
|
||||
Informative Refences
|
||||
|
||||
[RFC 1034] - "Domain names - concepts and facilities", P.
|
||||
Mockapetris, November 1987.
|
||||
|
||||
[RFC 1035] - "Domain names - implementation and specification", P.
|
||||
Mockapetris, November 1987.
|
||||
|
||||
[RFC 2539] - "Storage of Diffie-Hellman Keys in the Domain Name
|
||||
System (DNS)", D. Eastlake, March 1999, obsoleted by this RFC.
|
||||
|
||||
[RFC 2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August
|
||||
1999.
|
||||
|
||||
[RFC 4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "DNS Security Introduction and Requirements", RFC 4033, March
|
||||
2005.
|
||||
|
||||
[RFC 4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S.
|
||||
Rose, "Protocol Modifications for the DNS Security Extensions", RFC
|
||||
4035, March 2005.
|
||||
|
||||
[Schneier] - Bruce Schneier, "Applied Cryptography: Protocols,
|
||||
Algorithms, and Source Code in C" (Second Edition), 1996, John Wiley
|
||||
and Sons.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 7]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
Author's Address
|
||||
|
||||
Donald E. Eastlake 3rd
|
||||
Motorola Laboratories
|
||||
155 Beaver Street
|
||||
Milford, MA 01757 USA
|
||||
|
||||
Telephone: +1-508-786-7554
|
||||
EMail: Donald.Eastlake@motorola.com
|
||||
|
||||
|
||||
|
||||
Expiration and File Name
|
||||
|
||||
This draft expires in September 2006.
|
||||
|
||||
Its file name is draft-ietf-dnsext-rfc2539bis-dhk-07.txt.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 8]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
Appendix A: Well known prime/generator pairs
|
||||
|
||||
These numbers are copied from the IPSEC effort where the derivation
|
||||
of these values is more fully explained and additional information is
|
||||
available. Richard Schroeppel performed all the mathematical and
|
||||
computational work for this appendix.
|
||||
|
||||
|
||||
|
||||
A.1. Well-Known Group 1: A 768 bit prime
|
||||
|
||||
The prime is 2^768 - 2^704 - 1 + 2^64 * { [2^638 pi] + 149686 }. Its
|
||||
decimal value is
|
||||
155251809230070893513091813125848175563133404943451431320235
|
||||
119490296623994910210725866945387659164244291000768028886422
|
||||
915080371891804634263272761303128298374438082089019628850917
|
||||
0691316593175367469551763119843371637221007210577919
|
||||
|
||||
Prime modulus: Length (32 bit words): 24, Data (hex):
|
||||
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
|
||||
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
|
||||
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
|
||||
E485B576 625E7EC6 F44C42E9 A63A3620 FFFFFFFF FFFFFFFF
|
||||
|
||||
Generator: Length (32 bit words): 1, Data (hex): 2
|
||||
|
||||
|
||||
|
||||
A.2. Well-Known Group 2: A 1024 bit prime
|
||||
|
||||
The prime is 2^1024 - 2^960 - 1 + 2^64 * { [2^894 pi] + 129093 }.
|
||||
Its decimal value is
|
||||
179769313486231590770839156793787453197860296048756011706444
|
||||
423684197180216158519368947833795864925541502180565485980503
|
||||
646440548199239100050792877003355816639229553136239076508735
|
||||
759914822574862575007425302077447712589550957937778424442426
|
||||
617334727629299387668709205606050270810842907692932019128194
|
||||
467627007
|
||||
|
||||
Prime modulus: Length (32 bit words): 32, Data (hex):
|
||||
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
|
||||
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
|
||||
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
|
||||
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
|
||||
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE65381
|
||||
FFFFFFFF FFFFFFFF
|
||||
|
||||
Generator: Length (32 bit words): 1, Data (hex): 2
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 9]
|
||||
|
||||
|
||||
INTERNET-DRAFT Diffie-Hellman Information in the DNS
|
||||
|
||||
|
||||
A.3. Well-Known Group 3: A 1536 bit prime
|
||||
|
||||
The prime is 2^1536 - 2^1472 - 1 + 2^64 * { [2^1406 pi] + 741804 }.
|
||||
Its decimal value is
|
||||
241031242692103258855207602219756607485695054850245994265411
|
||||
694195810883168261222889009385826134161467322714147790401219
|
||||
650364895705058263194273070680500922306273474534107340669624
|
||||
601458936165977404102716924945320037872943417032584377865919
|
||||
814376319377685986952408894019557734611984354530154704374720
|
||||
774996976375008430892633929555996888245787241299381012913029
|
||||
459299994792636526405928464720973038494721168143446471443848
|
||||
8520940127459844288859336526896320919633919
|
||||
|
||||
Prime modulus Length (32 bit words): 48, Data (hex):
|
||||
FFFFFFFF FFFFFFFF C90FDAA2 2168C234 C4C6628B 80DC1CD1
|
||||
29024E08 8A67CC74 020BBEA6 3B139B22 514A0879 8E3404DD
|
||||
EF9519B3 CD3A431B 302B0A6D F25F1437 4FE1356D 6D51C245
|
||||
E485B576 625E7EC6 F44C42E9 A637ED6B 0BFF5CB6 F406B7ED
|
||||
EE386BFB 5A899FA5 AE9F2411 7C4B1FE6 49286651 ECE45B3D
|
||||
C2007CB8 A163BF05 98DA4836 1C55D39A 69163FA8 FD24CF5F
|
||||
83655D23 DCA3AD96 1C62F356 208552BB 9ED52907 7096966D
|
||||
670C354E 4ABC9804 F1746C08 CA237327 FFFFFFFF FFFFFFFF
|
||||
|
||||
Generator: Length (32 bit words): 1, Data (hex): 2
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
D. Eastlake 3rd [Page 10]
|
||||
|
||||
@@ -1,640 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
DNSOP Working Group Paul Vixie, ISC
|
||||
INTERNET-DRAFT Akira Kato, WIDE
|
||||
<draft-ietf-dnsop-respsize-06.txt> August 2006
|
||||
|
||||
DNS Referral Response Size Issues
|
||||
|
||||
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 BCP 79.
|
||||
|
||||
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.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006). All Rights Reserved.
|
||||
|
||||
|
||||
|
||||
|
||||
Abstract
|
||||
|
||||
With a mandated default minimum maximum message size of 512 octets,
|
||||
the DNS protocol presents some special problems for zones wishing to
|
||||
expose a moderate or high number of authority servers (NS RRs). This
|
||||
document explains the operational issues caused by, or related to
|
||||
this response size limit, and suggests ways to optimize the use of
|
||||
this limited space. Guidance is offered to DNS server implementors
|
||||
and to DNS zone operators.
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 1]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
1 - Introduction and Overview
|
||||
|
||||
1.1. The DNS standard (see [RFC1035 4.2.1]) limits message size to 512
|
||||
octets. Even though this limitation was due to the required minimum IP
|
||||
reassembly limit for IPv4, it became a hard DNS protocol limit and is
|
||||
not implicitly relaxed by changes in transport, for example to IPv6.
|
||||
|
||||
1.2. The EDNS0 protocol extension (see [RFC2671 2.3, 4.5]) permits
|
||||
larger responses by mutual agreement of the requester and responder.
|
||||
The 512 octet message size limit will remain in practical effect until
|
||||
there is widespread deployment of EDNS0 in DNS resolvers on the
|
||||
Internet.
|
||||
|
||||
1.3. Since DNS responses include a copy of the request, the space
|
||||
available for response data is somewhat less than the full 512 octets.
|
||||
Negative responses are quite small, but for positive and delegation
|
||||
responses, every octet must be carefully and sparingly allocated. This
|
||||
document specifically addresses delegation response sizes.
|
||||
|
||||
2 - Delegation Details
|
||||
|
||||
2.1. RELEVANT PROTOCOL ELEMENTS
|
||||
|
||||
2.1.1. A delegation response will include the following elements:
|
||||
|
||||
Header Section: fixed length (12 octets)
|
||||
Question Section: original query (name, class, type)
|
||||
Answer Section: empty, or a CNAME/DNAME chain
|
||||
Authority Section: NS RRset (nameserver names)
|
||||
Additional Section: A and AAAA RRsets (nameserver addresses)
|
||||
|
||||
2.1.2. If the total response size exceeds 512 octets, and if the data
|
||||
that does not fit was "required", then the TC bit will be set
|
||||
(indicating truncation). This will usually cause the requester to retry
|
||||
using TCP, depending on what information was desired and what
|
||||
information was omitted. For example, truncation in the authority
|
||||
section is of no interest to a stub resolver who only plans to consume
|
||||
the answer section. If a retry using TCP is needed, the total cost of
|
||||
the transaction is much higher. See [RFC1123 6.1.3.2] for details on
|
||||
the requirement that UDP be attempted before falling back to TCP.
|
||||
|
||||
2.1.3. RRsets are never sent partially unless TC bit set to indicate
|
||||
truncation. When TC bit is set, the final apparent RRset in the final
|
||||
non-empty section must be considered "possibly damaged" (see [RFC1035
|
||||
6.2], [RFC2181 9]).
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 2]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
2.1.4. With or without truncation, the glue present in the additional
|
||||
data section should be considered "possibly incomplete", and requesters
|
||||
should be prepared to re-query for any damaged or missing RRsets. Note
|
||||
that truncation of the additional data section might not be signalled
|
||||
via the TC bit since additional data is often optional (see discussion
|
||||
in [RFC4472 B]).
|
||||
|
||||
2.1.5. DNS label compression allows a domain name to be instantiated
|
||||
only once per DNS message, and then referenced with a two-octet
|
||||
"pointer" from other locations in that same DNS message (see [RFC1035
|
||||
4.1.4]). If all nameserver names in a message share a common parent
|
||||
(for example, all ending in ".ROOT-SERVERS.NET"), then more space will
|
||||
be available for incompressable data (such as nameserver addresses).
|
||||
|
||||
2.1.6. The query name can be as long as 255 octets of network data. In
|
||||
this worst case scenario, the question section will be 259 octets in
|
||||
size, which would leave only 240 octets for the authority and additional
|
||||
sections (after deducting 12 octets for the fixed length header.)
|
||||
|
||||
2.2. ADVICE TO ZONE OWNERS
|
||||
|
||||
2.2.1. Average and maximum question section sizes can be predicted by
|
||||
the zone owner, since they will know what names actually exist, and can
|
||||
measure which ones are queried for most often. Note that if the zone
|
||||
contains any wildcards, it is possible for maximum length queries to
|
||||
require positive responses, but that it is reasonable to expect
|
||||
truncation and TCP retry in that case. For cost and performance
|
||||
reasons, the majority of requests should be satisfied without truncation
|
||||
or TCP retry.
|
||||
|
||||
2.2.2. Some queries to non-existing names can be large, but this is not
|
||||
a problem because negative responses need not contain any answer,
|
||||
authority or additional records. See [RFC2308 2.1] for more information
|
||||
about the format of negative responses.
|
||||
|
||||
2.2.3. The minimum useful number of name servers is two, for redundancy
|
||||
(see [RFC1034 4.1]). A zone's name servers should be reachable by all
|
||||
IP transport protocols (e.g., IPv4 and IPv6) in common use.
|
||||
|
||||
2.2.4. The best case is no truncation at all. This is because many
|
||||
requesters will retry using TCP immediately, or will automatically re-
|
||||
query for RRsets that are possibly truncated, without considering
|
||||
whether the omitted data was actually necessary.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 3]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
2.3. ADVICE TO SERVER IMPLEMENTORS
|
||||
|
||||
2.3.1. In case of multi-homed name servers, it is advantageous to
|
||||
include an address record from each of several name servers before
|
||||
including several address records for any one name server. If address
|
||||
records for more than one transport (for example, A and AAAA) are
|
||||
available, then it is advantageous to include records of both types
|
||||
early on, before the message is full.
|
||||
|
||||
2.3.2. Each added NS RR for a zone will add 12 fixed octets (name, type,
|
||||
class, ttl, and rdlen) plus 2 to 255 variable octets (for the NSDNAME).
|
||||
Each A RR will require 16 octets, and each AAAA RR will require 28
|
||||
octets.
|
||||
|
||||
2.3.3. While DNS distinguishes between necessary and optional resource
|
||||
records, this distinction is according to protocol elements necessary to
|
||||
signify facts, and takes no official notice of protocol content
|
||||
necessary to ensure correct operation. For example, a nameserver name
|
||||
that is in or below the zone cut being described by a delegation is
|
||||
"necessary content," since there is no way to reach that zone unless the
|
||||
parent zone's delegation includes "glue records" describing that name
|
||||
server's addresses.
|
||||
|
||||
2.3.4. It is also necessary to distinguish between "explicit truncation"
|
||||
where a message could not contain enough records to convey its intended
|
||||
meaning, and so the TC bit has been set, and "silent truncation", where
|
||||
the message was not large enough to contain some records which were "not
|
||||
required", and so the TC bit was not set.
|
||||
|
||||
2.3.5. A delegation response should prioritize glue records as follows.
|
||||
|
||||
first
|
||||
All glue RRsets for one name server whose name is in or below the
|
||||
zone being delegated, or which has multiple address RRsets (currently
|
||||
A and AAAA), or preferably both;
|
||||
|
||||
second
|
||||
Alternate between adding all glue RRsets for any name servers whose
|
||||
names are in or below the zone being delegated, and all glue RRsets
|
||||
for any name servers who have multiple address RRsets (currently A
|
||||
and AAAA);
|
||||
|
||||
thence
|
||||
All other glue RRsets, in any order.
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 4]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
Whenever there are multiple candidates for a position in this priority
|
||||
scheme, one should be chosen on a round-robin or fully random basis.
|
||||
|
||||
The goal of this priority scheme is to offer "necessary" glue first,
|
||||
avoiding silent truncation for this glue if possible.
|
||||
|
||||
2.3.6. If any "necessary content" is silently truncated, then it is
|
||||
advisable that the TC bit be set in order to force a TCP retry, rather
|
||||
than have the zone be unreachable. Note that a parent server's proper
|
||||
response to a query for in-child glue or below-child glue is a referral
|
||||
rather than an answer, and that this referral MUST be able to contain
|
||||
the in-child or below-child glue, and that in outlying cases, only EDNS
|
||||
or TCP will be large enough to contain that data.
|
||||
|
||||
3 - Analysis
|
||||
|
||||
3.1. An instrumented protocol trace of a best case delegation response
|
||||
follows. Note that 13 servers are named, and 13 addresses are given.
|
||||
This query was artificially designed to exactly reach the 512 octet
|
||||
limit.
|
||||
|
||||
;; flags: qr rd; QUERY: 1, ANS: 0, AUTH: 13, ADDIT: 13
|
||||
;; QUERY SECTION:
|
||||
;; [23456789.123456789.123456789.\
|
||||
123456789.123456789.123456789.com A IN] ;; @80
|
||||
|
||||
;; AUTHORITY SECTION:
|
||||
com. 86400 NS E.GTLD-SERVERS.NET. ;; @112
|
||||
com. 86400 NS F.GTLD-SERVERS.NET. ;; @128
|
||||
com. 86400 NS G.GTLD-SERVERS.NET. ;; @144
|
||||
com. 86400 NS H.GTLD-SERVERS.NET. ;; @160
|
||||
com. 86400 NS I.GTLD-SERVERS.NET. ;; @176
|
||||
com. 86400 NS J.GTLD-SERVERS.NET. ;; @192
|
||||
com. 86400 NS K.GTLD-SERVERS.NET. ;; @208
|
||||
com. 86400 NS L.GTLD-SERVERS.NET. ;; @224
|
||||
com. 86400 NS M.GTLD-SERVERS.NET. ;; @240
|
||||
com. 86400 NS A.GTLD-SERVERS.NET. ;; @256
|
||||
com. 86400 NS B.GTLD-SERVERS.NET. ;; @272
|
||||
com. 86400 NS C.GTLD-SERVERS.NET. ;; @288
|
||||
com. 86400 NS D.GTLD-SERVERS.NET. ;; @304
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 5]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
;; ADDITIONAL SECTION:
|
||||
A.GTLD-SERVERS.NET. 86400 A 192.5.6.30 ;; @320
|
||||
B.GTLD-SERVERS.NET. 86400 A 192.33.14.30 ;; @336
|
||||
C.GTLD-SERVERS.NET. 86400 A 192.26.92.30 ;; @352
|
||||
D.GTLD-SERVERS.NET. 86400 A 192.31.80.30 ;; @368
|
||||
E.GTLD-SERVERS.NET. 86400 A 192.12.94.30 ;; @384
|
||||
F.GTLD-SERVERS.NET. 86400 A 192.35.51.30 ;; @400
|
||||
G.GTLD-SERVERS.NET. 86400 A 192.42.93.30 ;; @416
|
||||
H.GTLD-SERVERS.NET. 86400 A 192.54.112.30 ;; @432
|
||||
I.GTLD-SERVERS.NET. 86400 A 192.43.172.30 ;; @448
|
||||
J.GTLD-SERVERS.NET. 86400 A 192.48.79.30 ;; @464
|
||||
K.GTLD-SERVERS.NET. 86400 A 192.52.178.30 ;; @480
|
||||
L.GTLD-SERVERS.NET. 86400 A 192.41.162.30 ;; @496
|
||||
M.GTLD-SERVERS.NET. 86400 A 192.55.83.30 ;; @512
|
||||
|
||||
;; MSG SIZE sent: 80 rcvd: 512
|
||||
|
||||
3.2. For longer query names, the number of address records supplied will
|
||||
be lower. Furthermore, it is only by using a common parent name (which
|
||||
is GTLD-SERVERS.NET in this example) that all 13 addresses are able to
|
||||
fit, due to the use of DNS compression pointers in the last 12
|
||||
occurances of the parent domain name. The following output from a
|
||||
response simulator demonstrates these properties.
|
||||
|
||||
% perl respsize.pl a.dns.br b.dns.br c.dns.br d.dns.br
|
||||
a.dns.br requires 10 bytes
|
||||
b.dns.br requires 4 bytes
|
||||
c.dns.br requires 4 bytes
|
||||
d.dns.br requires 4 bytes
|
||||
# of NS: 4
|
||||
For maximum size query (255 byte):
|
||||
only A is considered: # of A is 4 (green)
|
||||
A and AAAA are considered: # of A+AAAA is 3 (yellow)
|
||||
preferred-glue A is assumed: # of A is 4, # of AAAA is 3 (yellow)
|
||||
For average size query (64 byte):
|
||||
only A is considered: # of A is 4 (green)
|
||||
A and AAAA are considered: # of A+AAAA is 4 (green)
|
||||
preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 6]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
% perl respsize.pl ns-ext.isc.org ns.psg.com ns.ripe.net ns.eu.int
|
||||
ns-ext.isc.org requires 16 bytes
|
||||
ns.psg.com requires 12 bytes
|
||||
ns.ripe.net requires 13 bytes
|
||||
ns.eu.int requires 11 bytes
|
||||
# of NS: 4
|
||||
For maximum size query (255 byte):
|
||||
only A is considered: # of A is 4 (green)
|
||||
A and AAAA are considered: # of A+AAAA is 3 (yellow)
|
||||
preferred-glue A is assumed: # of A is 4, # of AAAA is 2 (yellow)
|
||||
For average size query (64 byte):
|
||||
only A is considered: # of A is 4 (green)
|
||||
A and AAAA are considered: # of A+AAAA is 4 (green)
|
||||
preferred-glue A is assumed: # of A is 4, # of AAAA is 4 (green)
|
||||
|
||||
(Note: The response simulator program is shown in Section 5.)
|
||||
|
||||
Here we use the term "green" if all address records could fit, or
|
||||
"yellow" if two or more could fit, or "orange" if only one could fit, or
|
||||
"red" if no address record could fit. It's clear that without a common
|
||||
parent for nameserver names, much space would be lost. For these
|
||||
examples we use an average/common name size of 15 octets, befitting our
|
||||
assumption of GTLD-SERVERS.NET as our common parent name.
|
||||
|
||||
We're assuming a medium query name size of 64 since that is the typical
|
||||
size seen in trace data at the time of this writing. If
|
||||
Internationalized Domain Name (IDN) or any other technology which
|
||||
results in larger query names be deployed significantly in advance of
|
||||
EDNS, then new measurements and new estimates will have to be made.
|
||||
|
||||
4 - Conclusions
|
||||
|
||||
4.1. The current practice of giving all nameserver names a common parent
|
||||
(such as GTLD-SERVERS.NET or ROOT-SERVERS.NET) saves space in DNS
|
||||
responses and allows for more nameservers to be enumerated than would
|
||||
otherwise be possible, since the common parent domain name only appears
|
||||
once in a DNS message and is referred to via "compression pointers"
|
||||
thereafter.
|
||||
|
||||
4.2. If all nameserver names for a zone share a common parent, then it
|
||||
is operationally advisable to make all servers for the zone thus served
|
||||
also be authoritative for the zone of that common parent. For example,
|
||||
the root name servers (?.ROOT-SERVERS.NET) can answer authoritatively
|
||||
for the ROOT-SERVERS.NET. This is to ensure that the zone's servers
|
||||
always have the zone's nameservers' glue available when delegating, and
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 7]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
will be able to respond with answers rather than referrals if a
|
||||
requester who wants that glue comes back asking for it. In this case
|
||||
the name server will likely be a "stealth server" -- authoritative but
|
||||
unadvertised in the glue zone's NS RRset. See [RFC1996 2] for more
|
||||
information about stealth servers.
|
||||
|
||||
4.3. Thirteen (13) is the effective maximum number of nameserver names
|
||||
usable traditional (non-extended) DNS, assuming a common parent domain
|
||||
name, and given that implicit referral response truncation is
|
||||
undesirable in the average case.
|
||||
|
||||
4.4. Multi-homing of name servers within a protocol family is
|
||||
inadvisable since the necessary glue RRsets (A or AAAA) are atomically
|
||||
indivisible, and will be larger than a single resource record. Larger
|
||||
RRsets are more likely to lead to or encounter truncation.
|
||||
|
||||
4.5. Multi-homing of name servers across protocol families is less
|
||||
likely to lead to or encounter truncation, partly because multiprotocol
|
||||
clients are more likely to speak EDNS which can use a larger response
|
||||
size limit, and partly because the resource records (A and AAAA) are in
|
||||
different RRsets and are therefore divisible from each other.
|
||||
|
||||
4.6. Name server names which are at or below the zone they serve are
|
||||
more sensitive to referral response truncation, and glue records for
|
||||
them should be considered "less optional" than other glue records, in
|
||||
the assembly of referral responses.
|
||||
|
||||
4.7. If a zone is served by thirteen (13) name servers having a common
|
||||
parent name (such as ?.ROOT-SERVERS.NET) and each such name server has a
|
||||
single address record in some protocol family (e.g., an A RR), then all
|
||||
thirteen name servers or any subset thereof could multi-home in a second
|
||||
protocol family by adding a second address record (e.g., an AAAA RR)
|
||||
without reducing the reachability of the zone thus served.
|
||||
|
||||
5 - Source Code
|
||||
|
||||
#!/usr/bin/perl
|
||||
#
|
||||
# SYNOPSIS
|
||||
# repsize.pl [ -z zone ] fqdn_ns1 fqdn_ns2 ...
|
||||
# if all queries are assumed to have a same zone suffix,
|
||||
# such as "jp" in JP TLD servers, specify it in -z option
|
||||
#
|
||||
use strict;
|
||||
use Getopt::Std;
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 8]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
my ($sz_msg) = (512);
|
||||
my ($sz_header, $sz_ptr, $sz_rr_a, $sz_rr_aaaa) = (12, 2, 16, 28);
|
||||
my ($sz_type, $sz_class, $sz_ttl, $sz_rdlen) = (2, 2, 4, 2);
|
||||
my (%namedb, $name, $nssect, %opts, $optz);
|
||||
my $n_ns = 0;
|
||||
|
||||
getopt('z', %opts);
|
||||
if (defined($opts{'z'})) {
|
||||
server_name_len($opts{'z'}); # just register it
|
||||
}
|
||||
|
||||
foreach $name (@ARGV) {
|
||||
my $len;
|
||||
$n_ns++;
|
||||
$len = server_name_len($name);
|
||||
print "$name requires $len bytes\n";
|
||||
$nssect += $sz_ptr + $sz_type + $sz_class + $sz_ttl
|
||||
+ $sz_rdlen + $len;
|
||||
}
|
||||
print "# of NS: $n_ns\n";
|
||||
arsect(255, $nssect, $n_ns, "maximum");
|
||||
arsect(64, $nssect, $n_ns, "average");
|
||||
|
||||
sub server_name_len {
|
||||
my ($name) = @_;
|
||||
my (@labels, $len, $n, $suffix);
|
||||
|
||||
$name =~ tr/A-Z/a-z/;
|
||||
@labels = split(/\./, $name);
|
||||
$len = length(join('.', @labels)) + 2;
|
||||
for ($n = 0; $#labels >= 0; $n++, shift @labels) {
|
||||
$suffix = join('.', @labels);
|
||||
return length($name) - length($suffix) + $sz_ptr
|
||||
if (defined($namedb{$suffix}));
|
||||
$namedb{$suffix} = 1;
|
||||
}
|
||||
return $len;
|
||||
}
|
||||
|
||||
sub arsect {
|
||||
my ($sz_query, $nssect, $n_ns, $cond) = @_;
|
||||
my ($space, $n_a, $n_a_aaaa, $n_p_aaaa, $ansect);
|
||||
$ansect = $sz_query + 1 + $sz_type + $sz_class;
|
||||
$space = $sz_msg - $sz_header - $ansect - $nssect;
|
||||
$n_a = atmost(int($space / $sz_rr_a), $n_ns);
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 9]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
$n_a_aaaa = atmost(int($space
|
||||
/ ($sz_rr_a + $sz_rr_aaaa)), $n_ns);
|
||||
$n_p_aaaa = atmost(int(($space - $sz_rr_a * $n_ns)
|
||||
/ $sz_rr_aaaa), $n_ns);
|
||||
printf "For %s size query (%d byte):\n", $cond, $sz_query;
|
||||
printf " only A is considered: ";
|
||||
printf "# of A is %d (%s)\n", $n_a, &judge($n_a, $n_ns);
|
||||
printf " A and AAAA are considered: ";
|
||||
printf "# of A+AAAA is %d (%s)\n",
|
||||
$n_a_aaaa, &judge($n_a_aaaa, $n_ns);
|
||||
printf " preferred-glue A is assumed: ";
|
||||
printf "# of A is %d, # of AAAA is %d (%s)\n",
|
||||
$n_a, $n_p_aaaa, &judge($n_p_aaaa, $n_ns);
|
||||
}
|
||||
|
||||
sub judge {
|
||||
my ($n, $n_ns) = @_;
|
||||
return "green" if ($n >= $n_ns);
|
||||
return "yellow" if ($n >= 2);
|
||||
return "orange" if ($n == 1);
|
||||
return "red";
|
||||
}
|
||||
|
||||
sub atmost {
|
||||
my ($a, $b) = @_;
|
||||
return 0 if ($a < 0);
|
||||
return $b if ($a > $b);
|
||||
return $a;
|
||||
}
|
||||
|
||||
6 - Security Considerations
|
||||
|
||||
The recommendations contained in this document have no known security
|
||||
implications.
|
||||
|
||||
7 - IANA Considerations
|
||||
|
||||
This document does not call for changes or additions to any IANA
|
||||
registry.
|
||||
|
||||
8 - Acknowledgement
|
||||
|
||||
The authors thank Peter Koch, Rob Austein, Joe Abley, and Mark Andrews
|
||||
for their valuable comments and suggestions.
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 10]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
This work was supported by the US National Science Foundation (research
|
||||
grant SCI-0427144) and DNS-OARC.
|
||||
|
||||
9 - References
|
||||
|
||||
[RFC1034] Mockapetris, P.V., "Domain names - Concepts and Facilities",
|
||||
RFC1034, November 1987.
|
||||
|
||||
[RFC1035] Mockapetris, P.V., "Domain names - Implementation and
|
||||
Specification", RFC1035, November 1987.
|
||||
|
||||
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
|
||||
Application and Support", RFC1123, October 1989.
|
||||
|
||||
[RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone
|
||||
Changes (DNS NOTIFY)", RFC1996, August 1996.
|
||||
|
||||
[RFC2181] Elz, R., Bush, R., "Clarifications to the DNS Specification",
|
||||
RFC2181, July 1997.
|
||||
|
||||
[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS NCACHE)",
|
||||
RFC2308, March 1998.
|
||||
|
||||
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC2671,
|
||||
August 1999.
|
||||
|
||||
[RFC4472] Durand, A., Ihren, J., Savola, P., "Operational Consideration
|
||||
and Issues with IPV6 DNS", April 2006.
|
||||
|
||||
10 - Authors' Addresses
|
||||
|
||||
Paul Vixie
|
||||
Internet Systems Consortium, Inc.
|
||||
950 Charter Street
|
||||
Redwood City, CA 94063
|
||||
+1 650 423 1301
|
||||
vixie@isc.org
|
||||
|
||||
Akira Kato
|
||||
University of Tokyo, Information Technology Center
|
||||
2-11-16 Yayoi Bunkyo
|
||||
Tokyo 113-8658, JAPAN
|
||||
+81 3 5841 2750
|
||||
kato@wide.ad.jp
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 11]
|
||||
|
||||
INTERNET-DRAFT August 2006 RESPSIZE
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
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 provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
Expires January 2007 [Page 12]
|
||||
|
||||
|
||||
@@ -1,955 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group S. Josefsson
|
||||
Request for Comments: 4398 March 2006
|
||||
Obsoletes: 2538
|
||||
Category: Standards Track
|
||||
|
||||
|
||||
Storing Certificates in the Domain Name System (DNS)
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
Cryptographic public keys are frequently published, and their
|
||||
authenticity is demonstrated by certificates. A CERT resource record
|
||||
(RR) is defined so that such certificates and related certificate
|
||||
revocation lists can be stored in the Domain Name System (DNS).
|
||||
|
||||
This document obsoletes RFC 2538.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 1]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................3
|
||||
2. The CERT Resource Record ........................................3
|
||||
2.1. Certificate Type Values ....................................4
|
||||
2.2. Text Representation of CERT RRs ............................6
|
||||
2.3. X.509 OIDs .................................................6
|
||||
3. Appropriate Owner Names for CERT RRs ............................7
|
||||
3.1. Content-Based X.509 CERT RR Names ..........................8
|
||||
3.2. Purpose-Based X.509 CERT RR Names ..........................9
|
||||
3.3. Content-Based OpenPGP CERT RR Names ........................9
|
||||
3.4. Purpose-Based OpenPGP CERT RR Names .......................10
|
||||
3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX ...........10
|
||||
4. Performance Considerations .....................................11
|
||||
5. Contributors ...................................................11
|
||||
6. Acknowledgements ...............................................11
|
||||
7. Security Considerations ........................................12
|
||||
8. IANA Considerations ............................................12
|
||||
9. Changes since RFC 2538 .........................................13
|
||||
10. References ....................................................14
|
||||
10.1. Normative References .....................................14
|
||||
10.2. Informative References ...................................15
|
||||
Appendix A. Copying Conditions ...................................16
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 2]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
1. Introduction
|
||||
|
||||
Public keys are frequently published in the form of a certificate,
|
||||
and their authenticity is commonly demonstrated by certificates and
|
||||
related certificate revocation lists (CRLs). A certificate is a
|
||||
binding, through a cryptographic digital signature, of a public key,
|
||||
a validity interval and/or conditions, and identity, authorization,
|
||||
or other information. A certificate revocation list is a list of
|
||||
certificates that are revoked, and of incidental information, all
|
||||
signed by the signer (issuer) of the revoked certificates. Examples
|
||||
are X.509 certificates/CRLs in the X.500 directory system or OpenPGP
|
||||
certificates/revocations used by OpenPGP software.
|
||||
|
||||
Section 2 specifies a CERT resource record (RR) for the storage of
|
||||
certificates in the Domain Name System [1] [2].
|
||||
|
||||
Section 3 discusses appropriate owner names for CERT RRs.
|
||||
|
||||
Sections 4, 7, and 8 cover performance, security, and IANA
|
||||
considerations, respectively.
|
||||
|
||||
Section 9 explains the changes in this document compared to RFC 2538.
|
||||
|
||||
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 [3].
|
||||
|
||||
2. The CERT Resource Record
|
||||
|
||||
The CERT resource record (RR) has the structure given below. Its RR
|
||||
type code is 37.
|
||||
|
||||
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
|
||||
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
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| type | key tag |
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||||
| algorithm | /
|
||||
+---------------+ certificate or CRL /
|
||||
/ /
|
||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
|
||||
|
||||
The type field is the certificate type as defined in Section 2.1
|
||||
below.
|
||||
|
||||
The key tag field is the 16-bit value computed for the key embedded
|
||||
in the certificate, using the RRSIG Key Tag algorithm described in
|
||||
Appendix B of [12]. This field is used as an efficiency measure to
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 3]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
pick which CERT RRs may be applicable to a particular key. The key
|
||||
tag can be calculated for the key in question, and then only CERT RRs
|
||||
with the same key tag need to be examined. Note that two different
|
||||
keys can have the same key tag. However, the key MUST be transformed
|
||||
to the format it would have as the public key portion of a DNSKEY RR
|
||||
before the key tag is computed. This is only possible if the key is
|
||||
applicable to an algorithm and complies to limits (such as key size)
|
||||
defined for DNS security. If it is not, the algorithm field MUST be
|
||||
zero and the tag field is meaningless and SHOULD be zero.
|
||||
|
||||
The algorithm field has the same meaning as the algorithm field in
|
||||
DNSKEY and RRSIG RRs [12], except that a zero algorithm field
|
||||
indicates that the algorithm is unknown to a secure DNS, which may
|
||||
simply be the result of the algorithm not having been standardized
|
||||
for DNSSEC [11].
|
||||
|
||||
2.1. Certificate Type Values
|
||||
|
||||
The following values are defined or reserved:
|
||||
|
||||
Value Mnemonic Certificate Type
|
||||
----- -------- ----------------
|
||||
0 Reserved
|
||||
1 PKIX X.509 as per PKIX
|
||||
2 SPKI SPKI certificate
|
||||
3 PGP OpenPGP packet
|
||||
4 IPKIX The URL of an X.509 data object
|
||||
5 ISPKI The URL of an SPKI certificate
|
||||
6 IPGP The fingerprint and URL of an OpenPGP packet
|
||||
7 ACPKIX Attribute Certificate
|
||||
8 IACPKIX The URL of an Attribute Certificate
|
||||
9-252 Available for IANA assignment
|
||||
253 URI URI private
|
||||
254 OID OID private
|
||||
255 Reserved
|
||||
256-65279 Available for IANA assignment
|
||||
65280-65534 Experimental
|
||||
65535 Reserved
|
||||
|
||||
These values represent the initial content of the IANA registry; see
|
||||
Section 8.
|
||||
|
||||
The PKIX type is reserved to indicate an X.509 certificate conforming
|
||||
to the profile defined by the IETF PKIX working group [8]. The
|
||||
certificate section will start with a one-octet unsigned OID length
|
||||
and then an X.500 OID indicating the nature of the remainder of the
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 4]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
certificate section (see Section 2.3, below). (NOTE: X.509
|
||||
certificates do not include their X.500 directory-type-designating
|
||||
OID as a prefix.)
|
||||
|
||||
The SPKI and ISPKI types are reserved to indicate the SPKI
|
||||
certificate format [15], for use when the SPKI documents are moved
|
||||
from experimental status. The format for these two CERT RR types
|
||||
will need to be specified later.
|
||||
|
||||
The PGP type indicates an OpenPGP packet as described in [5] and its
|
||||
extensions and successors. This is used to transfer public key
|
||||
material and revocation signatures. The data is binary and MUST NOT
|
||||
be encoded into an ASCII armor. An implementation SHOULD process
|
||||
transferable public keys as described in Section 10.1 of [5], but it
|
||||
MAY handle additional OpenPGP packets.
|
||||
|
||||
The ACPKIX type indicates an Attribute Certificate format [9].
|
||||
|
||||
The IPKIX and IACPKIX types indicate a URL that will serve the
|
||||
content that would have been in the "certificate, CRL, or URL" field
|
||||
of the corresponding type (PKIX or ACPKIX, respectively).
|
||||
|
||||
The IPGP type contains both an OpenPGP fingerprint for the key in
|
||||
question, as well as a URL. The certificate portion of the IPGP CERT
|
||||
RR is defined as a one-octet fingerprint length, followed by the
|
||||
OpenPGP fingerprint, followed by the URL. The OpenPGP fingerprint is
|
||||
calculated as defined in RFC 2440 [5]. A zero-length fingerprint or
|
||||
a zero-length URL are legal, and indicate URL-only IPGP data or
|
||||
fingerprint-only IPGP data, respectively. A zero-length fingerprint
|
||||
and a zero-length URL are meaningless and invalid.
|
||||
|
||||
The IPKIX, ISPKI, IPGP, and IACPKIX types are known as "indirect".
|
||||
These types MUST be used when the content is too large to fit in the
|
||||
CERT RR and MAY be used at the implementer's discretion. They SHOULD
|
||||
NOT be used where the DNS message is 512 octets or smaller and could
|
||||
thus be expected to fit a UDP packet.
|
||||
|
||||
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 [10], and the data after the null is the
|
||||
private format certificate itself. The URI SHOULD be such that a
|
||||
retrieval from it will lead to documentation on the format of the
|
||||
certificate. Recognition of private certificate types need not be
|
||||
based on URI equality but can use various forms of pattern matching
|
||||
so that, for example, subtype or version information can also be
|
||||
encoded into the URI.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 5]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
The OID private type indicates a private format certificate specified
|
||||
by an ISO OID prefix. The certificate section will start with a
|
||||
one-octet unsigned OID length and then a BER-encoded OID indicating
|
||||
the nature of the remainder of the certificate section. This can be
|
||||
an X.509 certificate format or some other format. X.509 certificates
|
||||
that conform to the IETF PKIX profile SHOULD be indicated by the PKIX
|
||||
type, not the OID private type. Recognition of private certificate
|
||||
types need not be based on OID equality but can use various forms of
|
||||
pattern matching such as OID prefix.
|
||||
|
||||
2.2. Text Representation of CERT RRs
|
||||
|
||||
The RDATA portion of a CERT RR has the type field as an unsigned
|
||||
decimal integer or as a mnemonic symbol as listed in Section 2.1,
|
||||
above.
|
||||
|
||||
The key tag field is represented as an unsigned decimal integer.
|
||||
|
||||
The algorithm field is represented as an unsigned decimal integer or
|
||||
a mnemonic symbol as listed in [12].
|
||||
|
||||
The certificate/CRL portion is represented in base 64 [16] and may be
|
||||
divided into any number of white-space-separated substrings, down to
|
||||
single base-64 digits, which are concatenated to obtain the full
|
||||
signature. These substrings can span lines using the standard
|
||||
parenthesis.
|
||||
|
||||
Note that the certificate/CRL portion may have internal sub-fields,
|
||||
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
|
||||
the certificate/CRL proper. However, only a single logical base-64
|
||||
string will appear in the text representation.
|
||||
|
||||
2.3. X.509 OIDs
|
||||
|
||||
OIDs have been defined in connection with the X.500 directory for
|
||||
user certificates, certification authority certificates, revocations
|
||||
of certification authority, and revocations of user certificates.
|
||||
The following table lists the OIDs, their BER encoding, and their
|
||||
length-prefixed hex format for use in CERT RRs:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 6]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
id-at-userCertificate
|
||||
= { joint-iso-ccitt(2) ds(5) at(4) 36 }
|
||||
== 0x 03 55 04 24
|
||||
id-at-cACertificate
|
||||
= { joint-iso-ccitt(2) ds(5) at(4) 37 }
|
||||
== 0x 03 55 04 25
|
||||
id-at-authorityRevocationList
|
||||
= { joint-iso-ccitt(2) ds(5) at(4) 38 }
|
||||
== 0x 03 55 04 26
|
||||
id-at-certificateRevocationList
|
||||
= { joint-iso-ccitt(2) ds(5) at(4) 39 }
|
||||
== 0x 03 55 04 27
|
||||
|
||||
3. Appropriate Owner Names for CERT RRs
|
||||
|
||||
It is recommended that certificate CERT RRs be stored under a domain
|
||||
name related to their subject, i.e., the name of the entity intended
|
||||
to control the private key corresponding to the public key being
|
||||
certified. It is recommended that certificate revocation list CERT
|
||||
RRs be stored under a domain name related to their issuer.
|
||||
|
||||
Following some of the guidelines below may result in DNS names with
|
||||
characters that require DNS quoting as per Section 5.1 of RFC 1035
|
||||
[2].
|
||||
|
||||
The choice of name under which CERT RRs are stored is important to
|
||||
clients that perform CERT queries. In some situations, the clients
|
||||
may not know all information about the CERT RR object it wishes to
|
||||
retrieve. For example, a client may not know the subject name of an
|
||||
X.509 certificate, or the email address of the owner of an OpenPGP
|
||||
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.
|
||||
|
||||
Therefore, two owner name guidelines are defined: content-based owner
|
||||
names and purpose-based owner 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 or the User ID field in OpenPGP
|
||||
keys. A purpose-based owner name is a name that a client retrieving
|
||||
CERT RRs ought to know already; for example, the host name of an
|
||||
X.509 protected service or the Key ID of an OpenPGP key. The
|
||||
content-based and purpose-based owner name may be the same; for
|
||||
example, when a client looks up a key based on the From: address of
|
||||
an incoming email.
|
||||
|
||||
Implementations SHOULD use the purpose-based owner name guidelines
|
||||
described in this document and MAY use CNAME RRs at content-based
|
||||
owner names (or other names), pointing to the purpose-based owner
|
||||
name.
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 7]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
Note that this section describes an application-based mapping from
|
||||
the name space used in a certificate to the name space used by DNS.
|
||||
The DNS does not infer any relationship amongst CERT resource records
|
||||
based on similarities or differences of the DNS owner name(s) of CERT
|
||||
resource records. For example, if multiple labels are used when
|
||||
mapping from a CERT identifier to a domain name, then care must be
|
||||
taken in understanding wildcard record synthesis.
|
||||
|
||||
3.1. Content-Based X.509 CERT RR Names
|
||||
|
||||
Some X.509 versions, such as the PKIX profile of X.509 [8], permit
|
||||
multiple names to be associated with subjects and issuers under
|
||||
"Subject Alternative Name" and "Issuer Alternative Name". For
|
||||
example, the PKIX profile has such Alternate Names with an ASN.1
|
||||
specification as follows:
|
||||
|
||||
GeneralName ::= CHOICE {
|
||||
otherName [0] OtherName,
|
||||
rfc822Name [1] IA5String,
|
||||
dNSName [2] IA5String,
|
||||
x400Address [3] ORAddress,
|
||||
directoryName [4] Name,
|
||||
ediPartyName [5] EDIPartyName,
|
||||
uniformResourceIdentifier [6] IA5String,
|
||||
iPAddress [7] OCTET STRING,
|
||||
registeredID [8] OBJECT IDENTIFIER }
|
||||
|
||||
The recommended locations of CERT storage are as follows, in priority
|
||||
order:
|
||||
|
||||
1. If a domain name is included in the identification in the
|
||||
certificate or CRL, that ought to be used.
|
||||
2. If a domain name is not included but an IP address is included,
|
||||
then the translation of that IP address into the appropriate
|
||||
inverse domain name ought to be used.
|
||||
3. If neither of the above is used, but a URI containing a domain
|
||||
name is present, that domain name ought to be used.
|
||||
4. If none of the above is included but a character string name is
|
||||
included, then it ought to be treated as described below for
|
||||
OpenPGP names.
|
||||
5. If none of the above apply, then the distinguished name (DN)
|
||||
ought to be mapped into a domain name as specified in [4].
|
||||
|
||||
Example 1: An X.509v3 certificate is issued to /CN=John 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-doe.com, and (c)
|
||||
URI <https://www.secure.john-doe.com:8080/>. The storage locations
|
||||
recommended, in priority order, would be
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 8]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
1. john-doe.com,
|
||||
2. www.secure.john-doe.com, and
|
||||
3. Doe.com.xy.
|
||||
|
||||
Example 2: An X.509v3 certificate is issued to /CN=James Hacker/
|
||||
L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a)
|
||||
domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and
|
||||
(c) string "James Hacker <hacker@mail.widget.foo.example>". The
|
||||
storage locations recommended, in priority order, would be
|
||||
|
||||
1. widget.foo.example,
|
||||
2. 201.13.251.10.in-addr.arpa, and
|
||||
3. hacker.mail.widget.foo.example.
|
||||
|
||||
3.2. Purpose-Based X.509 CERT RR Names
|
||||
|
||||
Due to the difficulty for clients that do not already possess a
|
||||
certificate to reconstruct the content-based owner name,
|
||||
purpose-based owner names are recommended in this section.
|
||||
Recommendations for purpose-based owner names vary per scenario. The
|
||||
following table summarizes the purpose-based X.509 CERT RR owner name
|
||||
guidelines for use with S/MIME [17], SSL/TLS [13], and IPsec [14]:
|
||||
|
||||
Scenario Owner name
|
||||
------------------ ----------------------------------------------
|
||||
S/MIME Certificate Standard translation of an RFC 2822 email
|
||||
address. Example: An S/MIME certificate for
|
||||
"postmaster@example.org" will use a standard
|
||||
hostname translation of the owner name,
|
||||
"postmaster.example.org".
|
||||
|
||||
TLS Certificate Hostname of the TLS server.
|
||||
|
||||
IPsec Certificate Hostname of the IPsec machine and/or, for IPv4
|
||||
or IPv6 addresses, the fully qualified domain
|
||||
name in the appropriate reverse domain.
|
||||
|
||||
An alternate approach for IPsec is to store raw public keys [18].
|
||||
|
||||
3.3. Content-Based OpenPGP CERT RR Names
|
||||
|
||||
OpenPGP signed keys (certificates) use a general character string
|
||||
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
|
||||
Example <Leslie@host.example>". If such a format is used, the CERT
|
||||
ought to be under the standard translation of the email address into
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 9]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
a domain name, which would be leslie.host.example in this case. If
|
||||
no RFC 2822 name can be extracted from the string name, no specific
|
||||
domain name is recommended.
|
||||
|
||||
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:
|
||||
|
||||
$ORIGIN example.org.
|
||||
smith IN CERT PGP 0 0 <OpenPGP binary>
|
||||
john.smith IN CNAME smith
|
||||
js IN CNAME smith
|
||||
|
||||
3.4. Purpose-Based OpenPGP CERT RR Names
|
||||
|
||||
Applications that receive an OpenPGP packet containing encrypted or
|
||||
signed data but do not know the email address of the sender will have
|
||||
difficulties constructing the correct owner name and cannot use the
|
||||
content-based owner name guidelines. However, these clients commonly
|
||||
know the key fingerprint or the Key ID. The key ID is found in
|
||||
OpenPGP packets, and the key fingerprint is commonly found in
|
||||
auxiliary data that may be available. In this case, use of an owner
|
||||
name identical to the key fingerprint and the key ID expressed in
|
||||
hexadecimal [16] is recommended. For example:
|
||||
|
||||
$ORIGIN example.org.
|
||||
0424D4EE81A0E3D119C6F835EDA21E94B565716F IN CERT PGP ...
|
||||
F835EDA21E94B565716F IN CERT PGP ...
|
||||
B565716F IN CERT PGP ...
|
||||
|
||||
If the same key material is stored for several owner names, the use
|
||||
of CNAME may help avoid data duplication. Note that CNAME is not
|
||||
always applicable, because it maps one owner name to the other for
|
||||
all purposes, which may be sub-optimal when two keys with the same
|
||||
Key ID are stored.
|
||||
|
||||
3.5. Owner Names for IPKIX, ISPKI, IPGP, and IACPKIX
|
||||
|
||||
These types are stored under the same owner names, both purpose- and
|
||||
content-based, as the PKIX, SPKI, PGP, and ACPKIX types.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 10]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
4. Performance Considerations
|
||||
|
||||
The Domain Name System (DNS) protocol was designed for small
|
||||
transfers, typically below 512 octets. While larger transfers will
|
||||
perform correctly and work is underway to make larger transfers more
|
||||
efficient, it is still advisable at this time that every reasonable
|
||||
effort be made to minimize the size of certificates stored within the
|
||||
DNS. Steps that can be taken may include using the fewest possible
|
||||
optional or extension fields and using short field values for
|
||||
necessary variable-length fields.
|
||||
|
||||
The RDATA field in the DNS protocol may only hold data of size 65535
|
||||
octets (64kb) or less. This means that each CERT RR MUST NOT contain
|
||||
more than 64kb of payload, even if the corresponding certificate or
|
||||
certificate revocation list is larger. This document addresses this
|
||||
by defining "indirect" data types for each normal type.
|
||||
|
||||
Deploying CERT RRs to support digitally signed email changes the
|
||||
access patterns of DNS lookups from per-domain to per-user. If
|
||||
digitally signed email and a key/certificate lookup based on CERT RRs
|
||||
are deployed on a wide scale, this may lead to an increased DNS load,
|
||||
with potential performance and cache effectiveness consequences.
|
||||
Whether or not this load increase will be noticeable is not known.
|
||||
|
||||
5. Contributors
|
||||
|
||||
The majority of this document is copied verbatim from RFC 2538, by
|
||||
Donald Eastlake 3rd and Olafur Gudmundsson.
|
||||
|
||||
6. Acknowledgements
|
||||
|
||||
Thanks to David Shaw and Michael Graff for their contributions to
|
||||
earlier works that motivated, and served as inspiration for, this
|
||||
document.
|
||||
|
||||
This document was improved by suggestions and comments from Olivier
|
||||
Dubuisson, Scott Hollenbeck, Russ Housley, Peter Koch, Olaf M.
|
||||
Kolkman, Ben Laurie, Edward Lewis, John Loughney, Allison Mankin,
|
||||
Douglas Otis, Marcos Sanz, Pekka Savola, Jason Sloderbeck, Samuel
|
||||
Weiler, and Florian Weimer. No doubt the list is incomplete. We
|
||||
apologize to anyone we left out.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 11]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
7. Security Considerations
|
||||
|
||||
By definition, certificates contain their own authenticating
|
||||
signatures. Thus, it is reasonable to store certificates in
|
||||
non-secure DNS zones or to retrieve certificates from DNS with DNS
|
||||
security checking not implemented or deferred for efficiency. The
|
||||
results may be trusted if the certificate chain is verified back to a
|
||||
known trusted key and this conforms with the user's security policy.
|
||||
|
||||
Alternatively, if certificates are retrieved from a secure DNS zone
|
||||
with DNS security checking enabled and are verified by DNS security,
|
||||
the key within the retrieved certificate may be trusted without
|
||||
verifying the certificate chain if this conforms with the user's
|
||||
security policy.
|
||||
|
||||
If an organization chooses to issue certificates for its employees,
|
||||
placing CERT RRs in the DNS by owner name, and if DNSSEC (with NSEC)
|
||||
is in use, it is possible for someone to enumerate all employees of
|
||||
the organization. This is usually not considered desirable, for the
|
||||
same reason that enterprise phone listings are not often publicly
|
||||
published and are even marked confidential.
|
||||
|
||||
Using the URI type introduces another level of indirection that may
|
||||
open a new vulnerability. One method of securing that indirection is
|
||||
to include a hash of the certificate in the URI itself.
|
||||
|
||||
If DNSSEC 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.
|
||||
|
||||
8. IANA Considerations
|
||||
|
||||
The IANA has created a new registry for CERT RR: certificate types.
|
||||
The initial contents of this registry is:
|
||||
|
||||
Decimal Type Meaning Reference
|
||||
------- ---- ------- ---------
|
||||
0 Reserved RFC 4398
|
||||
1 PKIX X.509 as per PKIX RFC 4398
|
||||
2 SPKI SPKI certificate RFC 4398
|
||||
3 PGP OpenPGP packet RFC 4398
|
||||
4 IPKIX The URL of an X.509 data object RFC 4398
|
||||
5 ISPKI The URL of an SPKI certificate RFC 4398
|
||||
6 IPGP The fingerprint and URL RFC 4398
|
||||
of an OpenPGP packet
|
||||
7 ACPKIX Attribute Certificate RFC 4398
|
||||
8 IACPKIX The URL of an Attribute RFC 4398
|
||||
Certificate
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 12]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
9-252 Available for IANA assignment
|
||||
by IETF Standards action
|
||||
253 URI URI private RFC 4398
|
||||
254 OID OID private RFC 4398
|
||||
255 Reserved RFC 4398
|
||||
256-65279 Available for IANA assignment
|
||||
by IETF Consensus
|
||||
65280-65534 Experimental RFC 4398
|
||||
65535 Reserved RFC 4398
|
||||
|
||||
Certificate types 0x0000 through 0x00FF and 0xFF00 through 0xFFFF can
|
||||
only be assigned by an IETF standards action [6]. This document
|
||||
assigns 0x0001 through 0x0008 and 0x00FD and 0x00FE. Certificate
|
||||
types 0x0100 through 0xFEFF are assigned through IETF Consensus [6]
|
||||
based on RFC documentation of the certificate type. The availability
|
||||
of private types under 0x00FD and 0x00FE ought to satisfy most
|
||||
requirements for proprietary or private types.
|
||||
|
||||
The CERT RR reuses the DNS Security Algorithm Numbers registry. In
|
||||
particular, the CERT RR requires that algorithm number 0 remain
|
||||
reserved, as described in Section 2. The IANA will reference the
|
||||
CERT RR as a user of this registry and value 0, in particular.
|
||||
|
||||
9. Changes since RFC 2538
|
||||
|
||||
1. Editorial changes to conform with new document requirements,
|
||||
including splitting reference section into two parts and
|
||||
updating the references to point at latest versions, and to add
|
||||
some additional references.
|
||||
2. Improve terminology. For example replace "PGP" with "OpenPGP",
|
||||
to align with RFC 2440.
|
||||
3. In Section 2.1, clarify that OpenPGP public key data are binary,
|
||||
not the ASCII armored format, and reference 10.1 in RFC 2440 on
|
||||
how to deal with OpenPGP keys, and acknowledge that
|
||||
implementations may handle additional packet types.
|
||||
4. Clarify that integers in the representation format are decimal.
|
||||
5. Replace KEY/SIG with DNSKEY/RRSIG etc, to align with DNSSECbis
|
||||
terminology. Improve reference for Key Tag Algorithm
|
||||
calculations.
|
||||
6. Add examples that suggest use of CNAME to reduce bandwidth.
|
||||
7. In Section 3, appended the last paragraphs that discuss
|
||||
"content-based" vs "purpose-based" owner names. Add Section 3.2
|
||||
for purpose-based X.509 CERT owner names, and Section 3.4 for
|
||||
purpose-based OpenPGP CERT owner names.
|
||||
8. Added size considerations.
|
||||
9. The SPKI types has been reserved, until RFC 2692/2693 is moved
|
||||
from the experimental status.
|
||||
10. Added indirect types IPKIX, ISPKI, IPGP, and IACPKIX.
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 13]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
11. An IANA registry of CERT type values was created.
|
||||
|
||||
10. References
|
||||
|
||||
10.1. Normative References
|
||||
|
||||
[1] Mockapetris, P., "Domain names - concepts and facilities",
|
||||
STD 13, RFC 1034, November 1987.
|
||||
|
||||
[2] Mockapetris, P., "Domain names - implementation and
|
||||
specification", STD 13, RFC 1035, November 1987.
|
||||
|
||||
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||||
Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
[4] Kille, S., Wahl, M., Grimstad, A., Huber, R., and S. Sataluri,
|
||||
"Using Domains in LDAP/X.500 Distinguished Names", RFC 2247,
|
||||
January 1998.
|
||||
|
||||
[5] Callas, J., Donnerhacke, L., Finney, H., and R. Thayer,
|
||||
"OpenPGP Message Format", RFC 2440, November 1998.
|
||||
|
||||
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
|
||||
Considerations Section in RFCs", BCP 26, RFC 2434,
|
||||
October 1998.
|
||||
|
||||
[7] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
|
||||
|
||||
[8] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509
|
||||
Public Key Infrastructure Certificate and Certificate
|
||||
Revocation List (CRL) Profile", RFC 3280, April 2002.
|
||||
|
||||
[9] Farrell, S. and R. Housley, "An Internet Attribute Certificate
|
||||
Profile for Authorization", RFC 3281, April 2002.
|
||||
|
||||
[10] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
|
||||
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
|
||||
January 2005.
|
||||
|
||||
[11] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"DNS Security Introduction and Requirements", RFC 4033,
|
||||
March 2005.
|
||||
|
||||
[12] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 14]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
10.2. Informative References
|
||||
|
||||
[13] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
|
||||
RFC 2246, January 1999.
|
||||
|
||||
[14] Kent, S. and K. Seo, "Security Architecture for the Internet
|
||||
Protocol", RFC 4301, December 2005.
|
||||
|
||||
[15] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, B.,
|
||||
and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
|
||||
September 1999.
|
||||
|
||||
[16] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings",
|
||||
RFC 3548, July 2003.
|
||||
|
||||
[17] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
|
||||
(S/MIME) Version 3.1 Message Specification", RFC 3851,
|
||||
July 2004.
|
||||
|
||||
[18] Richardson, M., "A Method for Storing IPsec Keying Material in
|
||||
DNS", RFC 4025, March 2005.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 15]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
Appendix A. Copying Conditions
|
||||
|
||||
Regarding the portion of this document that was written by Simon
|
||||
Josefsson ("the author", for the remainder of this section), the
|
||||
author makes no guarantees and is not responsible for any damage
|
||||
resulting from its use. The author grants irrevocable permission to
|
||||
anyone to use, modify, and distribute it in any way that does not
|
||||
diminish the rights of anyone else to use, modify, and distribute it,
|
||||
provided that redistributed derivative works do not contain
|
||||
misleading author or version information. Derivative works need not
|
||||
be licensed under similar terms.
|
||||
|
||||
Author's Address
|
||||
|
||||
Simon Josefsson
|
||||
|
||||
EMail: simon@josefsson.org
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 16]
|
||||
|
||||
RFC 4398 Storing Certificates in the DNS February 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
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 provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Josefsson Standards Track [Page 17]
|
||||
|
||||
2691
doc/rfc/rfc4408.txt
2691
doc/rfc/rfc4408.txt
File diff suppressed because it is too large
Load Diff
@@ -1,451 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Network Working Group S. Weiler
|
||||
Request for Comments: 4470 SPARTA, Inc.
|
||||
Updates: 4035, 4034 J. Ihren
|
||||
Category: Standards Track Autonomica AB
|
||||
April 2006
|
||||
|
||||
|
||||
Minimally Covering NSEC Records and DNSSEC On-line Signing
|
||||
|
||||
|
||||
Status of This Memo
|
||||
|
||||
This document specifies an Internet standards track protocol for the
|
||||
Internet community, and requests discussion and suggestions for
|
||||
improvements. Please refer to the current edition of the "Internet
|
||||
Official Protocol Standards" (STD 1) for the standardization state
|
||||
and status of this protocol. Distribution of this memo is unlimited.
|
||||
|
||||
Copyright Notice
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
Abstract
|
||||
|
||||
This document describes how to construct DNSSEC NSEC resource records
|
||||
that cover a smaller range of names than called for by RFC 4034. By
|
||||
generating and signing these records on demand, authoritative name
|
||||
servers can effectively stop the disclosure of zone contents
|
||||
otherwise made possible by walking the chain of NSEC records in a
|
||||
signed zone.
|
||||
|
||||
Table of Contents
|
||||
|
||||
1. Introduction ....................................................1
|
||||
2. Applicability of This Technique .................................2
|
||||
3. Minimally Covering NSEC Records .................................2
|
||||
4. Better Epsilon Functions ........................................4
|
||||
5. Security Considerations .........................................5
|
||||
6. Acknowledgements ................................................6
|
||||
7. Normative References ............................................6
|
||||
|
||||
1. Introduction
|
||||
|
||||
With DNSSEC [1], an NSEC record lists the next instantiated name in
|
||||
its zone, proving that no names exist in the "span" between the
|
||||
NSEC's owner name and the name in the "next name" field. In this
|
||||
document, an NSEC record is said to "cover" the names between its
|
||||
owner name and next name.
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 1]
|
||||
|
||||
RFC 4470 NSEC Epsilon April 2006
|
||||
|
||||
|
||||
Through repeated queries that return NSEC records, it is possible to
|
||||
retrieve all of the names in the zone, a process commonly called
|
||||
"walking" the zone. Some zone owners have policies forbidding zone
|
||||
transfers by arbitrary clients; this side effect of the NSEC
|
||||
architecture subverts those policies.
|
||||
|
||||
This document presents a way to prevent zone walking by constructing
|
||||
NSEC records that cover fewer names. These records can make zone
|
||||
walking take approximately as many queries as simply asking for all
|
||||
possible names in a zone, making zone walking impractical. Some of
|
||||
these records must be created and signed on demand, which requires
|
||||
on-line private keys. Anyone contemplating use of this technique is
|
||||
strongly encouraged to review the discussion of the risks of on-line
|
||||
signing in Section 5.
|
||||
|
||||
1.2. Keywords
|
||||
|
||||
The keywords "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 [4].
|
||||
|
||||
2. Applicability of This Technique
|
||||
|
||||
The technique presented here may be useful to a zone owner that wants
|
||||
to use DNSSEC, is concerned about exposure of its zone contents via
|
||||
zone walking, and is willing to bear the costs of on-line signing.
|
||||
|
||||
As discussed in Section 5, on-line signing has several security
|
||||
risks, including an increased likelihood of private keys being
|
||||
disclosed and an increased risk of denial of service attack. Anyone
|
||||
contemplating use of this technique is strongly encouraged to review
|
||||
the discussion of the risks of on-line signing in Section 5.
|
||||
|
||||
Furthermore, at the time this document was published, the DNSEXT
|
||||
working group was actively working on a mechanism to prevent zone
|
||||
walking that does not require on-line signing (tentatively called
|
||||
NSEC3). The new mechanism is likely to expose slightly more
|
||||
information about the zone than this technique (e.g., the number of
|
||||
instantiated names), but it may be preferable to this technique.
|
||||
|
||||
3. Minimally Covering NSEC Records
|
||||
|
||||
This mechanism involves changes to NSEC records for instantiated
|
||||
names, which can still be generated and signed in advance, as well as
|
||||
the on-demand generation and signing of new NSEC records whenever a
|
||||
name must be proven not to exist.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 2]
|
||||
|
||||
RFC 4470 NSEC Epsilon April 2006
|
||||
|
||||
|
||||
In the "next name" field of instantiated names' NSEC records, rather
|
||||
than list the next instantiated name in the zone, list any name that
|
||||
falls lexically after the NSEC's owner name and before the next
|
||||
instantiated name in the zone, according to the ordering function in
|
||||
RFC 4034 [2] Section 6.1. This relaxes the requirement in Section
|
||||
4.1.1 of RFC 4034 that the "next name" field contains the next owner
|
||||
name in the zone. This change is expected to be fully compatible
|
||||
with all existing DNSSEC validators. These NSEC records are returned
|
||||
whenever proving something specifically about the owner name (e.g.,
|
||||
that no resource records of a given type appear at that name).
|
||||
|
||||
Whenever an NSEC record is needed to prove the non-existence of a
|
||||
name, a new NSEC record is dynamically produced and signed. The new
|
||||
NSEC record has an owner name lexically before the QNAME but
|
||||
lexically following any existing name and a "next name" lexically
|
||||
following the QNAME but before any existing name.
|
||||
|
||||
The generated NSEC record's type bitmap MUST have the RRSIG and NSEC
|
||||
bits set and SHOULD NOT have any other bits set. This relaxes the
|
||||
requirement in Section 2.3 of RFC4035 that NSEC RRs not appear at
|
||||
names that did not exist before the zone was signed.
|
||||
|
||||
The functions to generate the lexically following and proceeding
|
||||
names need not be perfect or consistent, but the generated NSEC
|
||||
records must not cover any existing names. Furthermore, this
|
||||
technique works best when the generated NSEC records cover as few
|
||||
names as possible. In this document, the functions that generate the
|
||||
nearby names are called "epsilon" functions, a reference to the
|
||||
mathematical convention of using the greek letter epsilon to
|
||||
represent small deviations.
|
||||
|
||||
An NSEC record denying the existence of a wildcard may be generated
|
||||
in the same way. Since the NSEC record covering a non-existent
|
||||
wildcard is likely to be used in response to many queries,
|
||||
authoritative name servers using the techniques described here may
|
||||
want to pregenerate or cache that record and its corresponding RRSIG.
|
||||
|
||||
For example, a query for an A record at the non-instantiated name
|
||||
example.com might produce the following two NSEC records, the first
|
||||
denying the existence of the name example.com and the second denying
|
||||
the existence of a wildcard:
|
||||
|
||||
exampld.com 3600 IN NSEC example-.com ( RRSIG NSEC )
|
||||
|
||||
\).com 3600 IN NSEC +.com ( RRSIG NSEC )
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 3]
|
||||
|
||||
RFC 4470 NSEC Epsilon April 2006
|
||||
|
||||
|
||||
Before answering a query with these records, an authoritative server
|
||||
must test for the existence of names between these endpoints. If the
|
||||
generated NSEC would cover existing names (e.g., exampldd.com or
|
||||
*bizarre.example.com), a better epsilon function may be used or the
|
||||
covered name closest to the QNAME could be used as the NSEC owner
|
||||
name or next name, as appropriate. If an existing name is used as
|
||||
the NSEC owner name, that name's real NSEC record MUST be returned.
|
||||
Using the same example, assuming an exampldd.com delegation exists,
|
||||
this record might be returned from the parent:
|
||||
|
||||
exampldd.com 3600 IN NSEC example-.com ( NS DS RRSIG NSEC )
|
||||
|
||||
Like every authoritative record in the zone, each generated NSEC
|
||||
record MUST have corresponding RRSIGs generated using each algorithm
|
||||
(but not necessarily each DNSKEY) in the zone's DNSKEY RRset, as
|
||||
described in RFC 4035 [3] Section 2.2. To minimize the number of
|
||||
signatures that must be generated, a zone may wish to limit the
|
||||
number of algorithms in its DNSKEY RRset.
|
||||
|
||||
4. Better Epsilon Functions
|
||||
|
||||
Section 6.1 of RFC 4034 defines a strict ordering of DNS names.
|
||||
Working backward from that definition, it should be possible to
|
||||
define epsilon functions that generate the immediately following and
|
||||
preceding names, respectively. This document does not define such
|
||||
functions. Instead, this section presents functions that come
|
||||
reasonably close to the perfect ones. As described above, an
|
||||
authoritative server should still ensure than no generated NSEC
|
||||
covers any existing name.
|
||||
|
||||
To increment a name, add a leading label with a single null (zero-
|
||||
value) octet.
|
||||
|
||||
To decrement a name, decrement the last character of the leftmost
|
||||
label, then fill that label to a length of 63 octets with octets of
|
||||
value 255. To decrement a null (zero-value) octet, remove the octet
|
||||
-- if an empty label is left, remove the label. Defining this
|
||||
function numerically: fill the leftmost label to its maximum length
|
||||
with zeros (numeric, not ASCII zeros) and subtract one.
|
||||
|
||||
In response to a query for the non-existent name foo.example.com,
|
||||
these functions produce NSEC records of the following:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 4]
|
||||
|
||||
RFC 4470 NSEC Epsilon April 2006
|
||||
|
||||
|
||||
fon\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255.example.com 3600 IN NSEC \000.foo.example.com ( NSEC RRSIG )
|
||||
|
||||
\)\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255\255\255\255\255\255\255\255\255\255\255\255\255\255
|
||||
\255\255.example.com 3600 IN NSEC \000.*.example.com ( NSEC RRSIG )
|
||||
|
||||
The first of these NSEC RRs proves that no exact match for
|
||||
foo.example.com exists, and the second proves that there is no
|
||||
wildcard in example.com.
|
||||
|
||||
Both of these functions are imperfect: they do not take into account
|
||||
constraints on number of labels in a name nor total length of a name.
|
||||
As noted in the previous section, though, this technique does not
|
||||
depend on the use of perfect epsilon functions: it is sufficient to
|
||||
test whether any instantiated names fall into the span covered by the
|
||||
generated NSEC and, if so, substitute those instantiated owner names
|
||||
for the NSEC owner name or next name, as appropriate.
|
||||
|
||||
5. Security Considerations
|
||||
|
||||
This approach requires on-demand generation of RRSIG records. This
|
||||
creates several new vulnerabilities.
|
||||
|
||||
First, on-demand signing requires that a zone's authoritative servers
|
||||
have access to its private keys. Storing private keys on well-known
|
||||
Internet-accessible servers may make them more vulnerable to
|
||||
unintended disclosure.
|
||||
|
||||
Second, since generation of digital signatures tends to be
|
||||
computationally demanding, the requirement for on-demand signing
|
||||
makes authoritative servers vulnerable to a denial of service attack.
|
||||
|
||||
Last, if the epsilon functions are predictable, on-demand signing may
|
||||
enable a chosen-plaintext attack on a zone's private keys. Zones
|
||||
using this approach should attempt to use cryptographic algorithms
|
||||
that are resistant to chosen-plaintext attacks. It is worth noting
|
||||
that although DNSSEC has a "mandatory to implement" algorithm, that
|
||||
is a requirement on resolvers and validators -- there is no
|
||||
requirement that a zone be signed with any given algorithm.
|
||||
|
||||
The success of using minimally covering NSEC records to prevent zone
|
||||
walking depends greatly on the quality of the epsilon functions
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 5]
|
||||
|
||||
RFC 4470 NSEC Epsilon April 2006
|
||||
|
||||
|
||||
chosen. An increment function that chooses a name obviously derived
|
||||
from the next instantiated name may be easily reverse engineered,
|
||||
destroying the value of this technique. An increment function that
|
||||
always returns a name close to the next instantiated name is likewise
|
||||
a poor choice. Good choices of epsilon functions are the ones that
|
||||
produce the immediately following and preceding names, respectively,
|
||||
though zone administrators may wish to use less perfect functions
|
||||
that return more human-friendly names than the functions described in
|
||||
Section 4 above.
|
||||
|
||||
Another obvious but misguided concern is the danger from synthesized
|
||||
NSEC records being replayed. It is possible for an attacker to
|
||||
replay an old but still validly signed NSEC record after a new name
|
||||
has been added in the span covered by that NSEC, incorrectly proving
|
||||
that there is no record at that name. This danger exists with DNSSEC
|
||||
as defined in [3]. The techniques described here actually decrease
|
||||
the danger, since the span covered by any NSEC record is smaller than
|
||||
before. Choosing better epsilon functions will further reduce this
|
||||
danger.
|
||||
|
||||
6. Acknowledgements
|
||||
|
||||
Many individuals contributed to this design. They include, in
|
||||
addition to the authors of this document, Olaf Kolkman, Ed Lewis,
|
||||
Peter Koch, Matt Larson, David Blacka, Suzanne Woolf, Jaap Akkerhuis,
|
||||
Jakob Schlyter, Bill Manning, and Joao Damas.
|
||||
|
||||
In addition, the editors would like to thank Ed Lewis, Scott Rose,
|
||||
and David Blacka for their careful review of the document.
|
||||
|
||||
7. Normative References
|
||||
|
||||
[1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"DNS Security Introduction and Requirements", RFC 4033, March
|
||||
2005.
|
||||
|
||||
[2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Resource Records for the DNS Security Extensions", RFC 4034,
|
||||
March 2005.
|
||||
|
||||
[3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
|
||||
"Protocol Modifications for the DNS Security Extensions", RFC
|
||||
4035, March 2005.
|
||||
|
||||
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
|
||||
Levels", BCP 14, RFC 2119, March 1997.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 6]
|
||||
|
||||
RFC 4470 NSEC Epsilon April 2006
|
||||
|
||||
|
||||
Authors' Addresses
|
||||
|
||||
Samuel Weiler
|
||||
SPARTA, Inc.
|
||||
7075 Samuel Morse Drive
|
||||
Columbia, Maryland 21046
|
||||
US
|
||||
|
||||
EMail: weiler@tislabs.com
|
||||
|
||||
|
||||
Johan Ihren
|
||||
Autonomica AB
|
||||
Bellmansgatan 30
|
||||
Stockholm SE-118 47
|
||||
Sweden
|
||||
|
||||
EMail: johani@autonomica.se
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 7]
|
||||
|
||||
RFC 4470 NSEC Epsilon April 2006
|
||||
|
||||
|
||||
Full Copyright Statement
|
||||
|
||||
Copyright (C) The Internet Society (2006).
|
||||
|
||||
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 provided by the IETF
|
||||
Administrative Support Activity (IASA).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Weiler & Ihren Standards Track [Page 8]
|
||||
|
||||
6051
doc/rfc/rfc4634.txt
6051
doc/rfc/rfc4634.txt
File diff suppressed because it is too large
Load Diff
1963
doc/rfc/rfc4641.txt
1963
doc/rfc/rfc4641.txt
File diff suppressed because it is too large
Load Diff
4
version
4
version
@@ -1,10 +1,10 @@
|
||||
# $Id: version,v 1.29.134.13 2007/02/15 01:42:38 each Exp $
|
||||
# $Id: version,v 1.29.134.13.8.1 2007/04/30 01:11:30 marka Exp $
|
||||
#
|
||||
# This file must follow /bin/sh rules. It is imported directly via
|
||||
# configure.
|
||||
#
|
||||
MAJORVER=9
|
||||
MINORVER=4
|
||||
PATCHVER=0
|
||||
PATCHVER=1
|
||||
RELEASETYPE=
|
||||
RELEASEVER=
|
||||
|
||||
Reference in New Issue
Block a user