ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

added new RFCs

Browse Source
This commit is contained in:
Andreas Gustafsson
2001-06-14 18:23:41 +00:00
parent 843e4dfd2c
commit 998b2d7b67
2 changed files with 1014 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

619
doc/rfc/rfc3090.txt Normal file
View File

@@ -0,0 +1,619 @@
Network Working Group E. Lewis
Request for Comments: 3090 NAI Labs
Category: Standards Track March 2001
DNS Security Extension Clarification on Zone Status
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 (2001). All Rights Reserved.
Abstract
The definition of a secured zone is presented, clarifying and
updating sections of RFC 2535. RFC 2535 defines a zone to be secured
based on a per algorithm basis, e.g., a zone can be secured with RSA
keys, and not secured with DSA keys. This document changes this to
define a zone to be secured or not secured regardless of the key
algorithm used (or not used). To further simplify the determination
of a zone's status, "experimentally secure" status is deprecated.
1 Introduction
Whether a DNS zone is "secured" or not is a question asked in at
least four contexts. A zone administrator asks the question when
configuring a zone to use DNSSEC. A dynamic update server asks the
question when an update request arrives, which may require DNSSEC
processing. A delegating zone asks the question of a child zone when
the parent enters data indicating the status the child. A resolver
asks the question upon receipt of data belonging to the zone.
1.1 When a Zone's Status is Important
A zone administrator needs to be able to determine what steps are
needed to make the zone as secure as it can be. Realizing that due
to the distributed nature of DNS and its administration, any single
zone is at the mercy of other zones when it comes to the appearance
of security. This document will define what makes a zone qualify as
secure.
Lewis Standards Track [Page 1]
RFC 3090 DNS Security Extension on Zone Status March 2001
A name server performing dynamic updates needs to know whether a zone
being updated is to have signatures added to the updated data, NXT
records applied, and other required processing. In this case, it is
conceivable that the name server is configured with the knowledge,
but being able to determine the status of a zone by examining the
data is a desirable alternative to configuration parameters.
A delegating zone is required to indicate whether a child zone is
secured. The reason for this requirement lies in the way in which a
resolver makes its own determination about a zone (next paragraph).
To shorten a long story, a parent needs to know whether a child
should be considered secured. This is a two part question. Under
what circumstances does a parent consider a child zone to be secure,
and how does a parent know if the child conforms?
A resolver needs to know if a zone is secured when the resolver is
processing data from the zone. Ultimately, a resolver needs to know
whether or not to expect a usable signature covering the data. How
this determination is done is out of the scope of this document,
except that, in some cases, the resolver will need to contact the
parent of the zone to see if the parent states that the child is
secured.
1.2 Islands of Security
The goal of DNSSEC is to have each zone secured, from the root zone
and the top-level domains down the hierarchy to the leaf zones.
Transitioning from an unsecured DNS, as we have now, to a fully
secured - or "as much as will be secured" - tree will take some time.
During this time, DNSSEC will be applied in various locations in the
tree, not necessarily "top down."
For example, at a particular instant, the root zone and the "test."
TLD might be secured, but region1.test. might not be. (For
reference, let's assume that region2.test. is secured.) However,
subarea1.region1.test. may have gone through the process of becoming
secured, along with its delegations. The dilemma here is that
subarea1 cannot get its zone keys properly signed as its parent zone,
region1, is not secured.
The colloquial phrase describing the collection of contiguous secured
zones at or below subarea1.region1.test. is an "island of security."
The only way in which a DNSSEC resolver will come to trust any data
from this island is if the resolver is pre-configured with the zone
key(s) for subarea1.region1.test., i.e., the root of the island of
security. Other resolvers (not so configured) will recognize this
island as unsecured.
Lewis Standards Track [Page 2]
RFC 3090 DNS Security Extension on Zone Status March 2001
An island of security begins with one zone whose public key is pre-
configured in resolvers. Within this island are subzones which are
also secured. The "bottom" of the island is defined by delegations
to unsecured zones. One island may also be on top of another -
meaning that there is at least one unsecured zone between the bottom
of the upper island and the root of the lower secured island.
Although both subarea1.region1.test. and region2.test. have both been
properly brought to a secured state by the administering staff, only
the latter of the two is actually "globally" secured - in the sense
that all DNSSEC resolvers can and will verify its data. The former,
subarea1, will be seen as secured by a subset of those resolvers,
just those appropriately configured. This document refers to such
zones as being "locally" secured.
In RFC 2535, there is a provision for "certification authorities,"
entities that will sign public keys for zones such as subarea1.
There is another document, [RFC3008], that restricts this activity.
Regardless of the other document, resolvers would still need proper
configuration to be able to use the certification authority to verify
the data for the subarea1 island.
1.2.1 Determining the closest security root
Given a domain, in order to determine whether it is secure or not,
the first step is to determine the closest security root. The
closest security root is the top of an island of security whose name
has the most matching (in order from the root) right-most labels to
the given domain.
For example, given a name "sub.domain.testing.signed.exp.test.", and
given the secure roots "exp.test.", "testing.signed.exp.test." and
"not-the-same.xy.", the middle one is the closest. The first secure
root shares 2 labels, the middle 4, and the last 0.
The reason why the closest is desired is to eliminate false senses of
insecurity because of a NULL key. Continuing with the example, the
reason both "testing..." and "exp.test." are listed as secure root is
presumably because "signed.exp.test." is unsecured (has a NULL key).
If we started to descend from "exp.test." to our given domain
(sub...), we would encounter a NULL key and conclude that sub... was
unsigned. However, if we descend from "testing..." and find keys
"domain...." then we can conclude that "sub..." is secured.
Note that this example assumes one-label deep zones, and assumes that
we do not configure overlapping islands of security. To be clear,
the definition given should exclude "short.xy.test." from being a
closest security root for "short.xy." even though 2 labels match.
Lewis Standards Track [Page 3]
RFC 3090 DNS Security Extension on Zone Status March 2001
Overlapping islands of security introduce no conceptually interesting
ideas and do not impact the protocol in anyway. However, protocol
implementers are advised to make sure their code is not thrown for a
loop by overlaps. Overlaps are sure to be configuration problems as
islands of security grow to encompass larger regions of the name
space.
1.3 Parent Statement of Child Security
In 1.1 of this document, there is the comment "the parent states that
the child is secured." This has caused quite a bit of confusion.
The need to have the parent "state" the status of a child is derived
from the following observation. If you are looking to see if an
answer is secured, that it comes from an "island of security" and is
properly signed, you must begin at the (appropriate) root of the
island of security.
To find the answer you are inspecting, you may have to descend
through zones within the island of security. Beginning with the
trusted root of the island, you descend into the next zone down. As
you trust the upper zone, you need to get data from it about the next
zone down, otherwise there is a vulnerable point in which a zone can
be hijacked. When or if you reach a point of traversing from a
secured zone to an unsecured zone, you have left the island of
security and should conclude that the answer is unsecured.
However, in RFC 2535, section 2.3.4, these words seem to conflict
with the need to have the parent "state" something about a child:
There MUST be a zone KEY RR, signed by its superzone, for every
subzone if the superzone is secure. This will normally appear in
the subzone and may also be included in the superzone. But, in
the case of an unsecured subzone which can not or will not be
modified to add any security RRs, a KEY declaring the subzone to
be unsecured MUST appear with the superzone signature in the
superzone, if the superzone is secure.
The confusion here is that in RFC 2535, a secured parent states that
a child is secured by SAYING NOTHING ("may also be" as opposed to
"MUST also be"). This is counter intuitive, the fact that an absence
of data means something is "secured." This notion, while acceptable
in a theoretic setting has met with some discomfort in an operation
setting. However, the use of "silence" to state something does
indeed work in this case, so there hasn't been sufficient need
demonstrated to change the definition.
Lewis Standards Track [Page 4]
RFC 3090 DNS Security Extension on Zone Status March 2001
1.4 Impact on RFC 2535
This document updates sections of RFC 2535. The definition of a
secured zone is an update to section 3.4 of the RFC. Section 3.4 is
updated to eliminate the definition of experimental keys and
illustrate a way to still achieve the functionality they were
designed to provide. Section 3.1.3 is updated by the specifying the
value of the protocol octet in a zone key.
1.5 "MUST" and other key words
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY"
in this document are to be interpreted as described in [RFC 2119].
Currently, only "MUST" is used in this document.
2 Status of a Zone
In this section, rules governing a zone's DNSSEC status are
presented. There are three levels of security defined: global,
local, and unsecured. A zone is globally secure when it complies
with the strictest set of DNSSEC processing rules. A zone is locally
secured when it is configured in such a way that only resolvers that
are appropriately configured see the zone as secured. All other
zones are unsecured.
Note: there currently is no document completely defining DNSSEC
verification rules. For the purposes of this document, the strictest
rules are assumed to state that the verification chain of zone keys
parallels the delegation tree up to the root zone. (See 2.b below.)
This is not intended to disallow alternate verification paths, just
to establish a baseline definition.
To avoid repetition in the rules below, the following terms are
defined.
2.a Zone signing KEY RR - A KEY RR whose flag field has the value 01
for name type (indicating a zone key) and either value 00 or value 01
for key type (indicating a key permitted to authenticate data). (See
RFC 2535, section 3.1.2). The KEY RR also has a protocol octet value
of DNSSEC (3) or ALL (255).
The definition updates RFC 2535's definition of a zone key. The
requirement that the protocol field be either DNSSEC or ALL is a new
requirement (a change to section 3.1.3.)
2.b On-tree Validation - The authorization model in which only the
parent zone is recognized to supply a DNSSEC-meaningful signature
that is used by a resolver to build a chain of trust from the child's
Lewis Standards Track [Page 5]
RFC 3090 DNS Security Extension on Zone Status March 2001
keys to a recognized root of security. The term "on-tree" refers to
following the DNS domain hierarchy (upwards) to reach a trusted key,
presumably the root key if no other key is available. The term
"validation" refers to the digital signature by the parent to prove
the integrity, authentication and authorization of the child's key to
sign the child's zone data.
2.c Off-tree Validation - Any authorization model that permits domain
names other than the parent's to provide a signature over a child's
zone keys that will enable a resolver to trust the keys.
2.1 Globally Secured
A globally secured zone, in a nutshell, is a zone that uses only
mandatory to implement algorithms (RFC 2535, section 3.2) and relies
on a key certification chain that parallels the delegation tree (on-
tree validation). Globally secured zones are defined by the
following rules.
2.1.a. The zone's apex MUST have a KEY RR set. There MUST be at
least one zone signing KEY RR (2.a) of a mandatory to implement
algorithm in the set.
2.1.b. The zone's apex KEY RR set MUST be signed by a private key
belonging to the parent zone. The private key's public companion
MUST be a zone signing KEY RR (2.a) of a mandatory to implement
algorithm and owned by the parent's apex.
If a zone cannot get a conforming signature from the parent zone, the
child zone cannot be considered globally secured. The only exception
to this is the root zone, for which there is no parent zone.
2.1.c. NXT records MUST be deployed throughout the zone. (Clarifies
RFC 2535, section 2.3.2.) Note: there is some operational discomfort
with the current NXT record. This requirement is open to
modification when two things happen. First, an alternate mechanism
to the NXT is defined and second, a means by which a zone can
indicate that it is using an alternate method.
2.1.d. Each RR set that qualifies for zone membership MUST be signed
by a key that is in the apex's KEY RR set and is a zone signing KEY
RR (2.a) of a mandatory to implement algorithm. (Updates 2535,
section 2.3.1.)
Mentioned earlier, the root zone is a special case. The root zone
will be considered to be globally secured provided that if conforms
to the rules for locally secured, with the exception that rule 2.1.a.
be also met (mandatory to implement requirement).
Lewis Standards Track [Page 6]
RFC 3090 DNS Security Extension on Zone Status March 2001
2.2 Locally Secured
The term "locally" stems from the likely hood that the only resolvers
to be configured for a particular zone will be resolvers "local" to
an organization.
A locally secured zone is a zone that complies with rules like those
for a globally secured zone with the following exceptions. The
signing keys may be of an algorithm that is not mandatory to
implement and/or the verification of the zone keys in use may rely on
a verification chain that is not parallel to the delegation tree
(off-tree validation).
2.2.a. The zone's apex MUST have a KEY RR set. There MUST be at
least one zone signing KEY RR (2.a) in the set.
2.2.b. The zone's apex KEY RR set MUST be signed by a private key and
one of the following two subclauses MUST hold true.
2.2.b.1 The private key's public companion MUST be pre-configured in
all the resolvers of interest.
2.2.b.2 The private key's public companion MUST be a zone signing KEY
RR (2.a) authorized to provide validation of the zone's apex KEY RR
set, as recognized by resolvers of interest.
The previous sentence is trying to convey the notion of using a
trusted third party to provide validation of keys. If the domain
name owning the validating key is not the parent zone, the domain
name must represent someone the resolver trusts to provide
validation.
2.2.c. NXT records MUST be deployed throughout the zone. Note: see
the discussion following 2.1.c.
2.2.d. Each RR set that qualifies for zone membership MUST be signed
by a key that is in the apex's KEY RR set and is a zone signing KEY
RR (2.a). (Updates 2535, section 2.3.1.)
2.3 Unsecured
All other zones qualify as unsecured. This includes zones that are
designed to be experimentally secure, as defined in a later section
on that topic.
Lewis Standards Track [Page 7]
RFC 3090 DNS Security Extension on Zone Status March 2001
2.4 Wrap up
The designation of globally secured, locally secured, and unsecured
are merely labels to apply to zones, based on their contents.
Resolvers, when determining whether a signature is expected or not,
will only see a zone as secured or unsecured.
Resolvers that follow the most restrictive DNSSEC verification rules
will only see globally secured zones as secured, and all others as
unsecured, including zones which are locally secured. Resolvers that
are not as restrictive, such as those that implement algorithms in
addition to the mandatory to implement algorithms, will see some
locally secured zones as secured.
The intent of the labels "global" and "local" is to identify the
specific attributes of a zone. The words are chosen to assist in the
writing of a document recommending the actions a zone administrator
take in making use of the DNS security extensions. The words are
explicitly not intended to convey a state of compliance with DNS
security standards.
3 Experimental Status
The purpose of an experimentally secured zone is to facilitate the
migration from an unsecured zone to a secured zone. This distinction
is dropped.
The objective of facilitating the migration can be achieved without a
special designation of an experimentally secure status.
Experimentally secured is a special case of locally secured. A zone
administrator can achieve this by publishing a zone with signatures
and configuring a set of test resolvers with the corresponding public
keys. Even if the public key is published in a KEY RR, as long as
there is no parent signature, the resolvers will need some pre-
configuration to know to process the signatures. This allows a zone
to be secured with in the sphere of the experiment, yet still be
registered as unsecured in the general Internet.
4 IANA Considerations
This document does not request any action from an assigned number
authority nor recommends any actions.
Lewis Standards Track [Page 8]
RFC 3090 DNS Security Extension on Zone Status March 2001
5 Security Considerations
Without a means to enforce compliance with specified protocols or
recommended actions, declaring a DNS zone to be "completely" secured
is impossible. Even if, assuming an omnipotent view of DNS, one can
declare a zone to be properly configured for security, and all of the
zones up to the root too, a misbehaving resolver could be duped into
believing bad data. If a zone and resolver comply, a non-compliant
or subverted parent could interrupt operations. The best that can be
hoped for is that all parties are prepared to be judged secure and
that security incidents can be traced to the cause in short order.
6 Acknowledgements
The need to refine the definition of a secured zone has become
apparent through the efforts of the participants at two DNSSEC
workshops, sponsored by the NIC-SE (.se registrar), CAIRN (a DARPA-
funded research network), and other workshops. Further discussions
leading to the document include Olafur Gudmundsson, Russ Mundy,
Robert Watson, and Brian Wellington. Roy Arends, Ted Lindgreen and
others have contributed significant input via the namedroppers
mailing list.
7 References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2136] Vixie, P., (Ed.), Thomson, S., Rekhter, Y. and J. Bound,
"Dynamic Updates in the Domain Name System", RFC 2136,
April 1997.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC
2535, March 1999.
[RFC3007] Wellington, B., "Simple Secure Domain Name System (DNS)
Dynamic Update", RFC 3007, November 2000.
[RFC3008] Wellington, B., "Domain Name System Security (DNSSEC)
Signing Authority", RFC 3008, November 2000.
Lewis Standards Track [Page 9]
RFC 3090 DNS Security Extension on Zone Status March 2001
10 Author's Address
Edward Lewis
NAI Labs
3060 Washington Road Glenwood
MD 21738
Phone: +1 443 259 2352
EMail: lewis@tislabs.com
Lewis Standards Track [Page 10]
RFC 3090 DNS Security Extension on Zone Status March 2001
11 Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Lewis Standards Track [Page 11]

395
doc/rfc/rfc3110.txt Normal file
View File

@@ -0,0 +1,395 @@
Network Working Group D. Eastlake 3rd
Request for Comments: 3110 Motorola
Obsoletes: 2537 May 2001
Category: Standards Track
RSA/SHA-1 SIGs and RSA KEYs 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 (2001). All Rights Reserved.
Abstract
This document describes how to produce RSA/SHA1 SIG resource records
(RRs) in Section 3 and, so as to completely replace RFC 2537,
describes how to produce RSA KEY RRs in Section 2.
Since the adoption of a Proposed Standard for RSA signatures in the
DNS (Domain Name Space), advances in hashing have been made. A new
DNS signature algorithm is defined to make these advances available
in SIG RRs. The use of the previously specified weaker mechanism is
deprecated. The algorithm number of the RSA KEY RR is changed to
correspond to this new SIG algorithm. No other changes are made to
DNS security.
Acknowledgements
Material and comments from the following have been incorporated and
are gratefully acknowledged:
Olafur Gudmundsson
The IESG
Charlie Kaufman
Steve Wang
D. Eastlake 3rd Standards Track [Page 1]
RFC 3110 RSA SIGs and KEYs in the DNS May 2001
Table of Contents
1. Introduction................................................... 2
2. RSA Public KEY Resource Records................................ 3
3. RSA/SHA1 SIG Resource Records.................................. 3
4. Performance Considerations..................................... 4
5. IANA Considerations............................................ 5
6. Security Considerations........................................ 5
References........................................................ 5
Author's Address.................................................. 6
Full Copyright Statement.......................................... 7
1. Introduction
The Domain Name System (DNS) is the global hierarchical replicated
distributed database system for Internet addressing, mail proxy, and
other information [RFC1034, 1035, etc.]. The DNS has been extended
to include digital signatures and cryptographic keys as described in
[RFC2535]. Thus the DNS can now be secured and used for secure key
distribution.
Familiarity with the RSA and SHA-1 algorithms is assumed [Schneier,
FIP180] in this document.
RFC 2537 described how to store RSA keys and RSA/MD5 based signatures
in the DNS. However, since the adoption of RFC 2537, continued
cryptographic research has revealed hints of weakness in the MD5
[RFC1321] algorithm used in RFC 2537. The SHA1 Secure Hash Algorithm
[FIP180], which produces a larger hash, has been developed. By now
there has been sufficient experience with SHA1 that it is generally
acknowledged to be stronger than MD5. While this stronger hash is
probably not needed today in most secure DNS zones, critical zones
such a root, most top level domains, and some second and third level
domains, are sufficiently valuable targets that it would be negligent
not to provide what are generally agreed to be stronger mechanisms.
Furthermore, future advances in cryptanalysis and/or computer speeds
may require a stronger hash everywhere. In addition, the additional
computation required by SHA1 above that required by MD5 is
insignificant compared with the computational effort required by the
RSA modular exponentiation.
This document describes how to produce RSA/SHA1 SIG RRs in Section 3
and, so as to completely replace RFC 2537, describes how to produce
RSA KEY RRs in Section 2.
Implementation of the RSA algorithm in DNS with SHA1 is MANDATORY for
DNSSEC. The generation of RSA/MD5 SIG RRs as described in RFC 2537
is NOT RECOMMENDED.
D. Eastlake 3rd Standards Track [Page 2]
RFC 3110 RSA SIGs and KEYs in the DNS May 2001
The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", "NOT
RECOMMENDED", and "MAY" in this document are to be interpreted as
described in RFC 2119.
2. RSA Public KEY Resource Records
RSA public keys are stored in the DNS as KEY RRs using algorithm
number 5 [RFC2535]. The structure of the algorithm specific portion
of the RDATA part of such RRs is as shown below.
Field Size
----- ----
exponent length 1 or 3 octets (see text)
exponent as specified by length field
modulus remaining space
For interoperability, the exponent and modulus are each limited to
4096 bits in length. The public key exponent is a variable length
unsigned integer. Its length in octets is represented as one octet
if it is in the range of 1 to 255 and by a zero octet followed by a
two octet unsigned length if it is longer than 255 bytes. The public
key modulus field is a multiprecision unsigned integer. The length
of the modulus can be determined from the RDLENGTH and the preceding
RDATA fields including the exponent. Leading zero octets are
prohibited in the exponent and modulus.
Note: KEY RRs for use with RSA/SHA1 DNS signatures MUST use this
algorithm number (rather than the algorithm number specified in the
obsoleted RFC 2537).
Note: This changes the algorithm number for RSA KEY RRs to be the
same as the new algorithm number for RSA/SHA1 SIGs.
3. RSA/SHA1 SIG Resource Records
RSA/SHA1 signatures are stored in the DNS using SIG resource records
(RRs) with algorithm number 5.
The signature portion of the SIG RR RDATA area, when using the
RSA/SHA1 algorithm, is calculated as shown below. The data signed is
determined as specified in RFC 2535. See RFC 2535 for fields in the
SIG RR RDATA which precede the signature itself.
hash = SHA1 ( data )
signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n)
D. Eastlake 3rd Standards Track [Page 3]
RFC 3110 RSA SIGs and KEYs in the DNS May 2001
where SHA1 is the message digest algorithm documented in [FIP180],
"|" is concatenation, "e" is the private key exponent of the signer,
and "n" is the modulus of the signer's public key. 01, FF, and 00
are fixed octets of the corresponding hexadecimal value. "prefix" is
the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1
[RFC2437], that is,
hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
This prefix is included to make it easier to use standard
cryptographic libraries. The FF octet MUST be repeated the maximum
number of times such that the value of the quantity being
exponentiated is one octet shorter than the value of n.
(The above specifications are identical to the corresponding parts of
Public Key Cryptographic Standard #1 [RFC2437].)
The size of "n", including most and least significant bits (which
will be 1) MUST be not less than 512 bits and not more than 4096
bits. "n" and "e" SHOULD be chosen such that the public exponent is
small. These are protocol limits. For a discussion of key size see
RFC 2541.
Leading zero bytes are permitted in the RSA/SHA1 algorithm signature.
4. Performance Considerations
General signature generation speeds are roughly the same for RSA and
DSA [RFC2536]. 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 with
DSA when the RSA public exponent is chosen to be small as is
recommended for KEY RRs used in domain name system (DNS) data
authentication.
A public exponent of 3 minimizes the effort needed to verify a
signature. Use of 3 as the public exponent is weak for
confidentiality uses since, if the same data can be collected
encrypted under three different keys with an exponent of 3 then,
using the Chinese Remainder Theorem [NETSEC], the original plain text
can be easily recovered. If a key is known to be used only for
authentication, as is the case with DNSSEC, then an exponent of 3 is
acceptable. However other applications in the future may wish to
leverage DNS distributed keys for applications that do require
confidentiality. For keys which might have such other uses, a more
conservative choice would be 65537 (F4, the fourth fermat number).
D. Eastlake 3rd Standards Track [Page 4]
RFC 3110 RSA SIGs and KEYs in the DNS May 2001
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 [RFC2671] to make larger transfers more efficient, it is
still advisable at this time to make reasonable efforts to minimize
the size of KEY RR sets stored within the DNS consistent with
adequate security. Keep in mind that in a secure zone, at least one
authenticating SIG RR will also be returned.
5. IANA Considerations
The DNSSEC algorithm number 5 is allocated for RSA/SHA1 SIG RRs and
RSA KEY RRs.
6. Security Considerations
Many of the general security considerations in RFC 2535 apply. 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. For particularly critical applications,
implementers are encouraged to consider the range of available
algorithms and key sizes. See also RFC 2541, "DNS Security
Operational Considerations".
References
[FIP180] U.S. Department of Commerce, "Secure Hash Standard", FIPS
PUB 180-1, 17 Apr 1995.
[NETSEC] Network Security: PRIVATE Communications in a PUBLIC
World, Charlie Kaufman, Radia Perlman, & Mike Speciner,
Prentice Hall Series in Computer Networking and
Distributed Communications, 1995.
[RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992.
D. Eastlake 3rd Standards Track [Page 5]
RFC 3110 RSA SIGs and KEYs in the DNS May 2001
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
Specifications Version 2.0", RFC 2437, October 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions",
RFC 2535, March 1999.
[RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
(DNS)", RFC 2536, March 1999.
[RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
System (DNS)", RFC 2537, March 1999.
[RFC2541] Eastlake, D., "DNS Security Operational Considerations",
RFC 2541, March 1999.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
2671, August 1999.
[Schneier] Bruce Schneier, "Applied Cryptography Second Edition:
protocols, algorithms, and source code in C", 1996, John
Wiley and Sons, ISBN 0-471-11709-9.
Author's Address
Donald E. Eastlake 3rd
Motorola
155 Beaver Street
Milford, MA 01757 USA
Phone: +1-508-261-5434 (w)
+1-508-634-2066 (h)
Fax +1-508-261-4777 (w)
EMail: Donald.Eastlake@motorola.com
D. Eastlake 3rd Standards Track [Page 6]
RFC 3110 RSA SIGs and KEYs in the DNS May 2001
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
D. Eastlake 3rd Standards Track [Page 7]