contrib/bind9/doc/rfc/rfc3110.txt

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