idnits 2.17.1 draft-ietf-dnsext-rfc2536bis-dsa-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 313. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document obsoletes RFC2536, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 256 has weird spacing: '... expire ince...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2006) is 6402 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-2' -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 3755 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT DSA Information in the DNS 2 OBSOLETES: RFC 2536 Donald E. Eastlake 3rd 3 Motorola Laboratories 4 Expires: April 2007 October 2006 6 DSA Keying and Signature Information in the DNS 7 --- ------ --- --------- ----------- -- --- --- 8 9 Donald E. Eastlake 3rd 11 Status of This Document 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Distribution of this document is unlimited. Comments should be sent 19 to the DNS extensions working group mailing list 20 . 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/1id-abstracts.html 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html 38 Abstract 40 The standard method of encoding US Government Digital Signature 41 Algorithm keying and signature information for use in the Domain Name 42 System is specified. 44 Table of Contents 46 Status of This Document....................................1 47 Abstract...................................................1 49 Table of Contents..........................................2 51 1. Introduction............................................3 52 2. DSA Keying Information..................................3 53 3. DSA Signature Information...............................4 54 4. Performance Considerations..............................4 55 5. Security Considerations.................................5 56 6. IANA Considerations.....................................5 57 Appendix A: Example RRs....................................5 58 Appendix B: Changes from RFC 2536..........................7 59 Copyright, Disclaimer, and Additional IPR Provisions.......7 61 Normative References.......................................9 62 Informative References.....................................9 64 Author's Address..........................................11 65 Expiration and File Name..................................11 67 1. Introduction 69 The Domain Name System (DNS) is the global hierarchical replicated 70 distributed database system for Internet addressing, mail proxy, and 71 other information [RFC1034], [RFC1035]. The DNS has been extended to 72 include digital signatures and cryptographic keys as described in 73 [RFC4033], [RFC4034], [RFC4035] and there is additional work which 74 would use the storage of keying information in the DNS such as 75 IPSECKEY [RFC4025]. This document does not change the wire format of 76 KEY RR's but extends the use of DSA DNS keys to cover the DNSKEY RR. 78 This document describes how to encode US Government Digital Signature 79 Algorithm (DSA) keys and signatures in the DNS. Familiarity with the 80 US Digital Signature Algorithm is assumed [FIPS186-2], [Schneier]. 82 2. DSA Keying Information 84 When DSA public keys are stored in the DNS, the structure of the 85 relevant part of the RDATA part of the RR (currently KEY and DNSKEY) 86 being used is the fields listed below in the order given. 88 The period of key validity is not included in this data but is 89 indicated separately, for example by an RR such as RRSIG which signs 90 and authenticates the RR containing the keying information. 92 Field Size 93 ----- ---- 94 T 1 octet 95 Q 20 octets 96 P 64 + T*8 octets 97 G 64 + T*8 octets 98 Y 64 + T*8 octets 100 As described in [FIPS186-2] and [Schneier], T is a key size parameter 101 chosen such that 0 <= T <= 8. (The meaning if the T octet is greater 102 than 8 is reserved and the remainder of the data may have a different 103 format in that case.) Q is a prime number selected at key generation 104 time such that 2**159 < Q < 2**160. Thus Q is always 20 octets long 105 and, as with all other fields, is stored in "big-endian" network 106 order. P, G, and Y are calculated as directed by the [FIPS186-2] key 107 generation algorithm [Schneier]. P is in the range 2**(511+64*T) < P 108 < 2**(512+64*T) and thus is 64 + 8*T octets long. G and Y are 109 quantities modulo P and so can be up to the same length as P and are 110 allocated fixed size fields with the same number of octets as P. 112 During the key generation process, a random number X must be 113 generated such that 1 <= X <= Q-1. X is the private key and is used 114 in the final step of public key generation where Y is computed as 115 Y = G**X mod P 117 3. DSA Signature Information 119 The portion of the RDATA area used for US Digital Signature Algorithm 120 signature information is shown below with fields in the order they 121 are listed and the contents of each multi-octet field in "big-endian" 122 network order. 124 Field Size 125 ----- ---- 126 T 1 octet 127 R 20 octets 128 S 20 octets 130 First, the data signed must be determined. Then the following steps 131 are taken, as specified in [FIPS186-2], where Q, P, G, and Y are as 132 specified in the public key [Schneier]: 134 hash = SHA-1 ( data ) 136 Generate a random K such that 0 < K < Q. 138 R = ( G**K mod P ) mod Q 140 S = ( K**(-1) * (hash + X*R) ) mod Q 142 For information on the SHA-1 hash function see [FIPS180-2] and 143 [RFC3174]. 145 Since Q is 160 bits long, R and S can not be larger than 20 octets, 146 which is the space allocated. 148 T is copied from the public key. It is not logically necessary in an 149 RRSIG but is present so that values of T > 8 can more conveniently be 150 used as an escape for extended versions of DSA or other algorithms as 151 later standardized. 153 4. Performance Considerations 155 General signature generation speeds are roughly the same for RSA 156 [RFC3110] and DSA. With sufficient pre-computation, signature 157 generation with DSA is faster than RSA. Key generation is also 158 faster for DSA. However, DSA signature verification is an order of 159 magnitude slower than RSA when the RSA public exponent is chosen to 160 be small, as is recommended for some applications. 162 Current DNS implementations are optimized for small transfers, 163 typically less than 512 bytes including DNS overhead. Larger 164 transfers will perform correctly and extensions have been 165 standardized [RFC2671] to make larger transfers more efficient, it is 166 still advisable at this time to make reasonable efforts to minimize 167 the size of RR sets containing keying and/or signature information 168 consistent with adequate security. 170 5. Security Considerations 172 Keys retrieved from the DNS should not be trusted unless (1) they 173 have been securely obtained from a secure resolver or independently 174 verified by the user and (2) this secure resolver and secure 175 obtainment or independent verification conform to security policies 176 acceptable to the user. As with all cryptographic algorithms, 177 evaluating the necessary strength of the key is essential and 178 dependent on local security policy. 180 The key size limitation of a maximum of 1024 bits ( T = 8 ) in the 181 referenced DSA standard [FIPS186-2] may limit the security of DSA. 182 For particular applications, implementers are encouraged to consider 183 the range of available algorithms and key sizes. 185 DSA assumes the ability to frequently generate high quality random 186 numbers. See [RFC4086] for guidance. DSA is designed so that if 187 biased rather than random numbers are used, high bandwidth covert 188 channels are possible. See [Schneier] and more recent research. The 189 leakage of an entire DSA private key in only two DSA signatures has 190 been demonstrated. DSA provides security only if trusted 191 implementations, including trusted random number generation, are 192 used. 194 6. IANA Considerations 196 Allocation of meaning to values of the T parameter that are not 197 defined herein (i.e., > 8 ) requires an IETF standards actions. It 198 is intended that values unallocated herein be used to cover future 199 extensions of the DSS standard. 201 Appendix A: Example RRs 203 This section provides an example DNSKEY and corresponding RRSIG RR. 204 All numbers below in this Appendix are in hexadecimal. 206 The elements of the DSA key are as follows: 207 T = 00 208 Q = c773218c 737ec8ee 993b4f2d ed30f48e dace915f 209 P = 8df2a494 492276aa 3d25759b b06869cb eac0d83a fb8d0cf7 210 cbb8324f 0d7882e5 d0762fc5 b7210eaf c2e9adac 32ab7aac 211 49693dfb f83724c2 ec0736ee 31c80291 212 G = 626d0278 39ea0a13 413163a5 5b4cb500 299d5522 956cefcb 213 3bff10f3 99ce2c2e 71cb9de5 fa24babf 58e5b795 21925c9c 214 c42e9f6f 464b088c c572af53 e6d78802 215 Y = 19131871 d75b1612 a819f29d 78d1b0d7 346f7aa7 7bb62a85 216 9bfd6c56 75da9d21 2d3a36ef 1672ef66 0b8c7c25 5cc0ec74 217 858fba33 f44c0669 9630a76b 030ee333 219 Based on this, the RDATA portion of a zone signing DSNKEY RR would be 220 as show below where "F" is the flags field, "p" is the "protocol" 221 field, and "a" is the algorithm field. 222 01 00030300 c773218c 737ec8ee 993b4f2d ed30f48e 223 F> p>a>T> Q> 224 dace915f 8df2a494 492276aa 3d25759b b06869cb eac0d83a 225 P> 226 fb8d0cf7 cbb8324f 0d7882e5 d0762fc5 b7210eaf c2e9adac 227 32ab7aac 49693dfb f83724c2 ec0736ee 31c80291 626d0278 228 G> 229 39ea0a13 413163a5 5b4cb500 299d5522 956cefcb 3bff10f3 230 99ce2c2e 71cb9de5 fa24babf 58e5b795 21925c9c c42e9f6f 231 464b088c c572af53 e6d78802 19131871 d75b1612 a819f29d 232 Y> 233 78d1b0d7 346f7aa7 7bb62a85 9bfd6c56 75da9d21 2d3a36ef 234 1672ef66 0b8c7c25 5cc0ec74 858fba33 f44c0669 9630a76b 235 030ee333 237 The Key Tag for the above DNSKEY RDATA, whose RDLENGTH is 00d9, is 238 19a3. 240 Assume that the hash of the DNS data being signed is 241 a9993e36 4706816a ba3e2571 7850c26c 9cd0d89d 242 the resulting signature value would be 243 T = 00 244 R = 8bac1ab6 6410435c b7181f95 b16ab97c 92b341c0 245 S = 41e2345f 1f56df24 58f426d1 55b4ba2d b6dcd8c8 247 Based on this, the RDATA portion of an RRSIG with this hash is shown 248 below assuming the following other parameters: the RRSIG signs "A" 249 records; its validity time is from 00112233 seconds after the 1 250 January 1970 00:00:00 UTC through 00123456 seconds after that time; 251 the signer name of "xx."; the original TTL was one hour or 0e10 252 seconds; and the number of labels in the original owner name was 05. 253 "a" is the algorithm number for DSA and "l" is the "Labels" field. 255 0001 03 05 00000e10 00123456 00112233 19a3 02787800 256 Type a> l> OrigTTL expire incept ktag signer 257 00 8bac1ab6 6410435c b7181f95 b16ab97c 92b341c0 258 T> R> 259 41e2345f 1f56df24 58f426d1 55b4ba2d b6dcd8c8 260 S> 262 All numbers above in this Appendix are in hexadecimal. 264 Appendix B: Changes from RFC 2536 266 When [RFC2536] was published, keys and signatures in the DNS appeared 267 only in KEY and SIG resource records. As described in [RFC3755], due 268 to a revision in DNS data origin authentication security, the 269 recommended RRs were changed to DNSKEY and RRSIG which are described 270 in [RFC4034]; however, SIG continues to be used in transaction 271 authentication, SIG(0) [RFC2931], and KEY continue to be used in 272 connection with TKEY [RFC2930]. 274 Thus the primary change from RFC 2536 in this document is to 275 eliminate the tie to the KEY and SIG RRs. In addition, many 276 references have been updated and example DNSKEY and RRSIG RRs using 277 the DSA algorithm have been included. 279 Copyright, Disclaimer, and Additional IPR Provisions 281 Copyright (C) The Internet Society 2006. This document is subject to 282 the rights, licenses and restrictions contained in BCP 78, and except 283 as set forth therein, the authors retain all their rights. 285 This document and the information contained herein are provided on an 286 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 287 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 288 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 289 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 290 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 291 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 293 The IETF takes no position regarding the validity or scope of any 294 Intellectual Property Rights or other rights that might be claimed to 295 pertain to the implementation or use of the technology described in 296 this document or the extent to which any license under such rights 297 might or might not be available; nor does it represent that it has 298 made any independent effort to identify any such rights. Information 299 on the procedures with respect to rights in RFC documents can be 300 found in BCP 78 and BCP 79. 302 Copies of IPR disclosures made to the IETF Secretariat and any 303 assurances of licenses to be made available, or the result of an 304 attempt made to obtain a general license or permission for the use of 305 such proprietary rights by implementers or users of this 306 specification can be obtained from the IETF on-line IPR repository at 307 http://www.ietf.org/ipr. 309 The IETF invites any interested party to bring to its attention any 310 copyrights, patents or patent applications, or other proprietary 311 rights that may cover technology that may be required to implement 312 this standard. Please address the information to the IETF at ietf- 313 ipr@ietf.org. 315 Normative References 317 [FIPS186-2] - U.S. Federal Information Processing Standard: Digital 318 Signature Standard, 27 January 2000. 320 [RFC4034] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 321 Rose, "Resource Records for the DNS Security Extensions", RFC 4034, 322 March 2005. 324 Informative References 326 [FIPS180-2] - U.S. Federal Information Processing Standard: Secure 327 Hash Standard, 1 August 2002. 329 [RFC1034] - "Domain names - concepts and facilities", P. Mockapetris, 330 11/01/1987. 332 [RFC1035] - "Domain names - implementation and specification", P. 333 Mockapetris, 11/01/1987. 335 [RFC2536] - "DSA KEYs and SIGs in the Domain Name System (DNS)", D. 336 Eastlake, March 1999. 338 [RFC2671] - "Extension Mechanisms for DNS (EDNS0)", P. Vixie, August 339 1999. 341 [RFC2930] - Eastlake 3rd, D., "Secret Key Establishment for DNS (TKEY 342 RR)", RFC 2930, September 2000. 344 [RFC2931] - Eastlake 3rd, D., "DNS Request and Transaction Signatures 345 ( SIG(0)s )", RFC 2931, September 2000. 347 [RFC3110] - "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System 348 (DNS)", D. Eastlake 3rd. May 2001. 350 [RFC3174] - "US Secure Hash Algorithm 1 (SHA1)", D. Eastlake, P. 351 Jones, September 2001. 353 [RFC3755] - Weiler, S., "Legacy Resolver Compatibility for Delegation 354 Signer (DS)", May 2004. 356 [RFC4025] - "A Method for Storing IPsec Keying Material in DNS", M. 357 Richardson, March 2005. 359 [RFC4033] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 360 Rose, "DNS Security Introduction and Requirements", RFC 4033, March 361 2005. 363 [RFC4035] - Arends, R., Austein, R., Larson, M., Massey, D., and S. 364 Rose, "Protocol Modifications for the DNS Security Extensions", RFC 365 4035, March 2005. 367 [RFC4086] - Eastlake, D., 3rd, Schiller, J., and S. Crocker, 368 "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. 370 [Schneier] - "Applied Cryptography Second Edition: protocols, 371 algorithms, and source code in C" (second edition), Bruce Schneier, 372 1996, John Wiley and Sons, ISBN 0-471-11709-9. 374 Author's Address 376 Donald E. Eastlake 3rd 377 Motorola Labortories 378 155 Beaver Street 379 Milford, MA 01757 USA 381 Telephone: +1-508-786-7554(w) 382 EMail: Donald.Eastlake@motorola.com 384 Expiration and File Name 386 This draft expires in April 2007. 388 Its file name is draft-ietf-dnsext-rfc2536bis-dsa-08.txt.