diff --git a/doc/rfc/rfc3090.txt b/doc/rfc/rfc3090.txt new file mode 100644 index 0000000000..08008f7a3d --- /dev/null +++ b/doc/rfc/rfc3090.txt @@ -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] + diff --git a/doc/rfc/rfc3110.txt b/doc/rfc/rfc3110.txt new file mode 100644 index 0000000000..764694860c --- /dev/null +++ b/doc/rfc/rfc3110.txt @@ -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] +