1 Network Working Group D. Eastlake 3rd
2 Request for Comments: 3110 Motorola
3 Obsoletes: 2537 May 2001
4 Category: Standards Track
5
6
7 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)
8
9 Status of this Memo
10
11 This document specifies an Internet standards track protocol for the
12 Internet community, and requests discussion and suggestions for
13 improvements. Please refer to the current edition of the "Internet
14 Official Protocol Standards" (STD 1) for the standardization state
15 and status of this protocol. Distribution of this memo is unlimited.
16
17 Copyright Notice
18
19 Copyright (C) The Internet Society (2001). All Rights Reserved.
20
21 Abstract
22
23 This document describes how to produce RSA/SHA1 SIG resource records
24 (RRs) in Section 3 and, so as to completely replace RFC 2537,
25 describes how to produce RSA KEY RRs in Section 2.
26
27 Since the adoption of a Proposed Standard for RSA signatures in the
28 DNS (Domain Name Space), advances in hashing have been made. A new
29 DNS signature algorithm is defined to make these advances available
30 in SIG RRs. The use of the previously specified weaker mechanism is
31 deprecated. The algorithm number of the RSA KEY RR is changed to
32 correspond to this new SIG algorithm. No other changes are made to
33 DNS security.
34
35 Acknowledgements
36
37 Material and comments from the following have been incorporated and
38 are gratefully acknowledged:
39
40 Olafur Gudmundsson
41
42 The IESG
43
44 Charlie Kaufman
45
46 Steve Wang
47
48
49
50
51
52 D. Eastlake 3rd Standards Track [Page 1]
53 RFC 3110 RSA SIGs and KEYs in the DNS May 2001
54
55
56 Table of Contents
57
58 1. Introduction................................................... 2
59 2. RSA Public KEY Resource Records................................ 3
60 3. RSA/SHA1 SIG Resource Records.................................. 3
61 4. Performance Considerations..................................... 4
62 5. IANA Considerations............................................ 5
63 6. Security Considerations........................................ 5
64 References........................................................ 5
65 Author's Address.................................................. 6
66 Full Copyright Statement.......................................... 7
67
68 1. Introduction
69
70 The Domain Name System (DNS) is the global hierarchical replicated
71 distributed database system for Internet addressing, mail proxy, and
72 other information [RFC1034, 1035, etc.]. The DNS has been extended
73 to include digital signatures and cryptographic keys as described in
74 [RFC2535]. Thus the DNS can now be secured and used for secure key
75 distribution.
76
77 Familiarity with the RSA and SHA-1 algorithms is assumed [Schneier,
78 FIP180] in this document.
79
80 RFC 2537 described how to store RSA keys and RSA/MD5 based signatures
81 in the DNS. However, since the adoption of RFC 2537, continued
82 cryptographic research has revealed hints of weakness in the MD5
83 [RFC1321] algorithm used in RFC 2537. The SHA1 Secure Hash Algorithm
84 [FIP180], which produces a larger hash, has been developed. By now
85 there has been sufficient experience with SHA1 that it is generally
86 acknowledged to be stronger than MD5. While this stronger hash is
87 probably not needed today in most secure DNS zones, critical zones
88 such a root, most top level domains, and some second and third level
89 domains, are sufficiently valuable targets that it would be negligent
90 not to provide what are generally agreed to be stronger mechanisms.
91 Furthermore, future advances in cryptanalysis and/or computer speeds
92 may require a stronger hash everywhere. In addition, the additional
93 computation required by SHA1 above that required by MD5 is
94 insignificant compared with the computational effort required by the
95 RSA modular exponentiation.
96
97 This document describes how to produce RSA/SHA1 SIG RRs in Section 3
98 and, so as to completely replace RFC 2537, describes how to produce
99 RSA KEY RRs in Section 2.
100
101 Implementation of the RSA algorithm in DNS with SHA1 is MANDATORY for
102 DNSSEC. The generation of RSA/MD5 SIG RRs as described in RFC 2537
103 is NOT RECOMMENDED.
104
105
106
107 D. Eastlake 3rd Standards Track [Page 2]
108 RFC 3110 RSA SIGs and KEYs in the DNS May 2001
109
110
111 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", "NOT
112 RECOMMENDED", and "MAY" in this document are to be interpreted as
113 described in RFC 2119.
114
115 2. RSA Public KEY Resource Records
116
117 RSA public keys are stored in the DNS as KEY RRs using algorithm
118 number 5 [RFC2535]. The structure of the algorithm specific portion
119 of the RDATA part of such RRs is as shown below.
120
121 Field Size
122 ----- ----
123 exponent length 1 or 3 octets (see text)
124 exponent as specified by length field
125 modulus remaining space
126
127 For interoperability, the exponent and modulus are each limited to
128 4096 bits in length. The public key exponent is a variable length
129 unsigned integer. Its length in octets is represented as one octet
130 if it is in the range of 1 to 255 and by a zero octet followed by a
131 two octet unsigned length if it is longer than 255 bytes. The public
132 key modulus field is a multiprecision unsigned integer. The length
133 of the modulus can be determined from the RDLENGTH and the preceding
134 RDATA fields including the exponent. Leading zero octets are
135 prohibited in the exponent and modulus.
136
137 Note: KEY RRs for use with RSA/SHA1 DNS signatures MUST use this
138 algorithm number (rather than the algorithm number specified in the
139 obsoleted RFC 2537).
140
141 Note: This changes the algorithm number for RSA KEY RRs to be the
142 same as the new algorithm number for RSA/SHA1 SIGs.
143
144 3. RSA/SHA1 SIG Resource Records
145
146 RSA/SHA1 signatures are stored in the DNS using SIG resource records
147 (RRs) with algorithm number 5.
148
149 The signature portion of the SIG RR RDATA area, when using the
150 RSA/SHA1 algorithm, is calculated as shown below. The data signed is
151 determined as specified in RFC 2535. See RFC 2535 for fields in the
152 SIG RR RDATA which precede the signature itself.
153
154 hash = SHA1 ( data )
155
156 signature = ( 01 | FF* | 00 | prefix | hash ) ** e (mod n)
157
158
159
160
161
162 D. Eastlake 3rd Standards Track [Page 3]
163 RFC 3110 RSA SIGs and KEYs in the DNS May 2001
164
165
166 where SHA1 is the message digest algorithm documented in [FIP180],
167 "|" is concatenation, "e" is the private key exponent of the signer,
168 and "n" is the modulus of the signer's public key. 01, FF, and 00
169 are fixed octets of the corresponding hexadecimal value. "prefix" is
170 the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1
171 [RFC2437], that is,
172
173 hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14
174
175 This prefix is included to make it easier to use standard
176 cryptographic libraries. The FF octet MUST be repeated the maximum
177 number of times such that the value of the quantity being
178 exponentiated is one octet shorter than the value of n.
179
180 (The above specifications are identical to the corresponding parts of
181 Public Key Cryptographic Standard #1 [RFC2437].)
182
183 The size of "n", including most and least significant bits (which
184 will be 1) MUST be not less than 512 bits and not more than 4096
185 bits. "n" and "e" SHOULD be chosen such that the public exponent is
186 small. These are protocol limits. For a discussion of key size see
187 RFC 2541.
188
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.
This RFC is implemented in BIND 9.18 (all versions).
Section 2.3 of RFC 6944 says that the status of RSASHA1 is Must Implement. Note that RFC 6944 is obsoleted by RFC8624, which keeps the same recommendation to implement.
189 Leading zero bytes are permitted in the RSA/SHA1 algorithm signature.
190
191 4. Performance Considerations
192
193 General signature generation speeds are roughly the same for RSA and
194 DSA [RFC2536]. With sufficient pre-computation, signature generation
195 with DSA is faster than RSA. Key generation is also faster for DSA.
196 However, signature verification is an order of magnitude slower with
197 DSA when the RSA public exponent is chosen to be small as is
198 recommended for KEY RRs used in domain name system (DNS) data
199 authentication.
200
201 A public exponent of 3 minimizes the effort needed to verify a
202 signature. Use of 3 as the public exponent is weak for
203 confidentiality uses since, if the same data can be collected
204 encrypted under three different keys with an exponent of 3 then,
205 using the Chinese Remainder Theorem [NETSEC], the original plain text
206 can be easily recovered. If a key is known to be used only for
207 authentication, as is the case with DNSSEC, then an exponent of 3 is
208 acceptable. However other applications in the future may wish to
209 leverage DNS distributed keys for applications that do require
210 confidentiality. For keys which might have such other uses, a more
211 conservative choice would be 65537 (F4, the fourth fermat number).
212
213
214
215
216
217 D. Eastlake 3rd Standards Track [Page 4]
218 RFC 3110 RSA SIGs and KEYs in the DNS May 2001
219
220
221 Current DNS implementations are optimized for small transfers,
222 typically less than 512 bytes including DNS overhead. Larger
223 transfers will perform correctly and extensions have been
224 standardized [RFC2671] to make larger transfers more efficient, it is
225 still advisable at this time to make reasonable efforts to minimize
226 the size of KEY RR sets stored within the DNS consistent with
227 adequate security. Keep in mind that in a secure zone, at least one
228 authenticating SIG RR will also be returned.
229
230 5. IANA Considerations
231
232 The DNSSEC algorithm number 5 is allocated for RSA/SHA1 SIG RRs and
233 RSA KEY RRs.
234
235 6. Security Considerations
236
237 Many of the general security considerations in RFC 2535 apply. Keys
238 retrieved from the DNS should not be trusted unless (1) they have
239 been securely obtained from a secure resolver or independently
240 verified by the user and (2) this secure resolver and secure
241 obtainment or independent verification conform to security policies
242 acceptable to the user. As with all cryptographic algorithms,
243 evaluating the necessary strength of the key is essential and
244 dependent on local policy. For particularly critical applications,
245 implementers are encouraged to consider the range of available
246 algorithms and key sizes. See also RFC 2541, "DNS Security
247 Operational Considerations".
248
249 References
250
251 [FIP180] U.S. Department of Commerce, "Secure Hash Standard", FIPS
252 PUB 180-1, 17 Apr 1995.
253
254 [NETSEC] Network Security: PRIVATE Communications in a PUBLIC
255 World, Charlie Kaufman, Radia Perlman, & Mike Speciner,
256 Prentice Hall Series in Computer Networking and
257 Distributed Communications, 1995.
258
259 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
260 STD 13, RFC 1034, November 1987.
261
262 [RFC1035] Mockapetris, P., "Domain Names - Implementation and
263 Specification", STD 13, RFC 1035, November 1987.
264
265 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
266 April 1992.
267
268
269
270
271
272 D. Eastlake 3rd Standards Track [Page 5]
273 RFC 3110 RSA SIGs and KEYs in the DNS May 2001
274
275
276 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
277 Requirement Levels", BCP 14, RFC 2119, March 1997.
278
279 [RFC2437] Kaliski, B. and J. Staddon, "PKCS #1: RSA Cryptography
280 Specifications Version 2.0", RFC 2437, October 1998.
281
282 [RFC2535] Eastlake, D., "Domain Name System Security Extensions",
283 RFC 2535, March 1999.
284
285 [RFC2536] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System
286 (DNS)", RFC 2536, March 1999.
287
288 [RFC2537] Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
289 System (DNS)", RFC 2537, March 1999.
290
291 [RFC2541] Eastlake, D., "DNS Security Operational Considerations",
292 RFC 2541, March 1999.
293
294 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC
295 2671, August 1999.
296
297 [Schneier] Bruce Schneier, "Applied Cryptography Second Edition:
298 protocols, algorithms, and source code in C", 1996, John
299 Wiley and Sons, ISBN 0-471-11709-9.
300
301 Author's Address
302
303 Donald E. Eastlake 3rd
304 Motorola
305 155 Beaver Street
306 Milford, MA 01757 USA
307
308 Phone: +1-508-261-5434 (w)
309 +1-508-634-2066 (h)
310 Fax +1-508-261-4777 (w)
311 EMail: Donald.Eastlake@motorola.com
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327 D. Eastlake 3rd Standards Track [Page 6]
328 RFC 3110 RSA SIGs and KEYs in the DNS May 2001
329
330
331 Full Copyright Statement
332
333 Copyright (C) The Internet Society (2001). All Rights Reserved.
334
335 This document and translations of it may be copied and furnished to
336 others, and derivative works that comment on or otherwise explain it
337 or assist in its implementation may be prepared, copied, published
338 and distributed, in whole or in part, without restriction of any
339 kind, provided that the above copyright notice and this paragraph are
340 included on all such copies and derivative works. However, this
341 document itself may not be modified in any way, such as by removing
342 the copyright notice or references to the Internet Society or other
343 Internet organizations, except as needed for the purpose of
344 developing Internet standards in which case the procedures for
345 copyrights defined in the Internet Standards process must be
346 followed, or as required to translate it into languages other than
347 English.
348
349 The limited permissions granted above are perpetual and will not be
350 revoked by the Internet Society or its successors or assigns.
351
352 This document and the information contained herein is provided on an
353 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
354 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
355 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
356 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
357 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
358
359 Acknowledgement
360
361 Funding for the RFC Editor function is currently provided by the
362 Internet Society.
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382 D. Eastlake 3rd Standards Track [Page 7]
383
conservative choice would be 65537 (F4, the fourth fermat number).
conservative choice would be 65537 (F4, thefourthfifth Fermat number).