396 lines
15 KiB
Plaintext
396 lines
15 KiB
Plaintext
|
||
|
||
|
||
|
||
|
||
|
||
Network Working Group D. Blacka
|
||
Request for Comments: 4955 VeriSign, Inc.
|
||
Category: Standards Track July 2007
|
||
|
||
|
||
DNS Security (DNSSEC) Experiments
|
||
|
||
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 IETF Trust (2007).
|
||
|
||
Abstract
|
||
|
||
This document describes a methodology for deploying alternate, non-
|
||
backwards-compatible, DNS Security (DNSSEC) methodologies in an
|
||
experimental fashion without disrupting the deployment of standard
|
||
DNSSEC.
|
||
|
||
Table of Contents
|
||
|
||
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
2. Definitions and Terminology . . . . . . . . . . . . . . . . . . 2
|
||
3. Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 2
|
||
4. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
|
||
5. Defining an Experiment . . . . . . . . . . . . . . . . . . . . 4
|
||
6. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 5
|
||
7. Use in Non-Experiments . . . . . . . . . . . . . . . . . . . . 5
|
||
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
|
||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
|
||
9.1. Normative References . . . . . . . . . . . . . . . . . . . 6
|
||
9.2. Informative References . . . . . . . . . . . . . . . . . . 6
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Blacka Standards Track [Page 1]
|
||
|
||
RFC 4955 DNS Security (DNSSEC) Experiments July 2007
|
||
|
||
|
||
1. 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 coexistence
|
||
with standard DNSSEC and DNS by using unknown algorithm identifiers
|
||
to hide the experimental DNSSEC protocol modifications from standard
|
||
security-aware resolvers.
|
||
|
||
2. Definitions and Terminology
|
||
|
||
Throughout this document, familiarity with the DNS system (RFC 1035
|
||
[5]) and the DNS security extensions (RFC 4033 [2], RFC 4034 [3], and
|
||
RFC 4035 [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].
|
||
|
||
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 Standards Track [Page 2]
|
||
|
||
RFC 4955 DNS Security (DNSSEC) Experiments July 2007
|
||
|
||
|
||
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 RFC 4035 [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.
|
||
|
||
Although this behavior isn't strictly mandatory (as marked by MUST),
|
||
it is unlikely for a validator to implement a substantially different
|
||
behavior. Essentially, if the validator does not have a usable chain
|
||
of trust to a child zone, then it can only do one of two things:
|
||
treat responses from the zone as insecure (the recommended behavior),
|
||
or treat the responses as bogus. If the validator chooses the
|
||
latter, this will both violate the expectation of the zone owner and
|
||
defeat the purpose of the above rule. However, with local policy, it
|
||
is within the right of a validator to refuse to trust certain zones
|
||
based on any criteria, including the use of unknown signing
|
||
algorithms.
|
||
|
||
Because we are talking about experiments, it is RECOMMENDED that
|
||
private algorithm numbers be used (see RFC 4034 [3], Appendix A.1.1.
|
||
Note that secure handling of private algorithms requires special
|
||
handing by the validator logic. See "Clarifications and
|
||
Implementation Notes for DNSSECbis" [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.
|
||
|
||
|
||
|
||
Blacka Standards Track [Page 3]
|
||
|
||
RFC 4955 DNS Security (DNSSEC) Experiments July 2007
|
||
|
||
|
||
It is RECOMMENDED that for a particular DNSSEC experiment, a
|
||
particular domain name base is chosen for all new algorithms, then
|
||
the algorithm number (or name) is prepended to it. For example, for
|
||
experiment A, the base name of "dnssec-experiment-a.example.com" is
|
||
chosen. Then, aliases for algorithms 3 (DSA) and 5 (RSASHA1) are
|
||
defined to be "3.dnssec-experiment-a.example.com" and
|
||
"5.dnssec-experiment-a.example.com". However, any unique identifier
|
||
will suffice.
|
||
|
||
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 possible to validate experimentally,
|
||
or it is not.
|
||
|
||
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
|
||
Object Identifier (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).
|
||
|
||
|
||
|
||
Blacka Standards Track [Page 4]
|
||
|
||
RFC 4955 DNS Security (DNSSEC) Experiments July 2007
|
||
|
||
|
||
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.
|
||
|
||
6. Considerations
|
||
|
||
There are a number of considerations with using this methodology.
|
||
|
||
1. If an unaware validator does not correctly follow the rules laid
|
||
out in RFC 4035 (e.g., the validator interprets a DNSSEC record
|
||
prior to validating it), or if the experiment is broader in scope
|
||
that just modifying the DNSSEC semantics, the experiment may not
|
||
be sufficiently masked by this technique. This may cause
|
||
unintended resolution failures.
|
||
|
||
2. It will not be possible for security-aware resolvers unaware of
|
||
the experiment to build a chain of trust through an experimental
|
||
zone.
|
||
|
||
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.
|
||
|
||
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.
|
||
|
||
Implementers should take into account any security issues that may
|
||
result from environments being configured to trust both experimental
|
||
and non-experimental zones. If the experimental zone is more
|
||
|
||
|
||
|
||
Blacka Standards Track [Page 5]
|
||
|
||
RFC 4955 DNS Security (DNSSEC) Experiments July 2007
|
||
|
||
|
||
vulnerable to attacks, it could, for example, be used to promote
|
||
trust in zones not part of the experiment, possibly under the control
|
||
of an attacker.
|
||
|
||
9. References
|
||
|
||
9.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.
|
||
|
||
9.2. Informative References
|
||
|
||
[5] Mockapetris, P., "Domain names - implementation and
|
||
specification", STD 13, RFC 1035, November 1987.
|
||
|
||
[6] Weiler, S. and R. Austein, "Clarifications and Implementation
|
||
Notes for DNSSECbis", Work in Progress, March 2007.
|
||
|
||
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 Standards Track [Page 6]
|
||
|
||
RFC 4955 DNS Security (DNSSEC) Experiments July 2007
|
||
|
||
|
||
Full Copyright Statement
|
||
|
||
Copyright (C) The IETF Trust (2007).
|
||
|
||
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, THE IETF TRUST AND
|
||
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
|
||
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
|
||
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
||
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
||
|
||
Intellectual Property
|
||
|
||
The IETF takes no position regarding the validity or scope of any
|
||
Intellectual Property Rights or other rights that might be claimed to
|
||
pertain to the implementation or use of the technology described in
|
||
this document or the extent to which any license under such rights
|
||
might or might not be available; nor does it represent that it has
|
||
made any independent effort to identify any such rights. Information
|
||
on the procedures with respect to rights in RFC documents can be
|
||
found in BCP 78 and BCP 79.
|
||
|
||
Copies of IPR disclosures made to the IETF Secretariat and any
|
||
assurances of licenses to be made available, or the result of an
|
||
attempt made to obtain a general license or permission for the use of
|
||
such proprietary rights by implementers or users of this
|
||
specification can be obtained from the IETF on-line IPR repository at
|
||
http://www.ietf.org/ipr.
|
||
|
||
The IETF invites any interested party to bring to its attention any
|
||
copyrights, patents or patent applications, or other proprietary
|
||
rights that may cover technology that may be required to implement
|
||
this standard. Please address the information to the IETF at
|
||
ietf-ipr@ietf.org.
|
||
|
||
Acknowledgement
|
||
|
||
Funding for the RFC Editor function is currently provided by the
|
||
Internet Society.
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Blacka Standards Track [Page 7]
|
||
|