contrib/bind9/doc/rfc/rfc2536.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                        D. EastLake
   8 Request for Comments: 2536                                           IBM
   9 Category: Standards Track                                     March 1999
  10
  11
  12            DSA KEYs and SIGs in the Domain Name System (DNS)
  13
  14 Status of this Memo
  15
  16    This document specifies an Internet standards track protocol for the
  17    Internet community, and requests discussion and suggestions for
  18    improvements.  Please refer to the current edition of the "Internet
  19    Official Protocol Standards" (STD 1) for the standardization state
  20    and status of this protocol.  Distribution of this memo is unlimited.
  21
  22 Copyright Notice
  23
  24    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  25
  26 Abstract
  27
  28    A standard method for storing US Government Digital Signature
  29    Algorithm keys and signatures in the Domain Name System is described
  30    which utilizes DNS KEY and SIG resource records.
  31
  32 Table of Contents
  33
  34    Abstract...................................................1
  35    1. Introduction............................................1
  36    2. DSA KEY Resource Records................................2
  37    3. DSA SIG Resource Records................................3
  38    4. Performance Considerations..............................3
  39    5. Security Considerations.................................4
  40    6. IANA Considerations.....................................4
  41    References.................................................5
  42    Author's Address...........................................5
  43    Full Copyright Statement...................................6
  44
  45 1. Introduction
  46
  47    The Domain Name System (DNS) is the global hierarchical replicated
  48    distributed database system for Internet addressing, mail proxy, and
  49    other information. The DNS has been extended to include digital
  50    signatures and cryptographic keys as described in [RFC 2535].  Thus
  51    the DNS can now be secured and can be used for secure key
  52    distribution.
  53
  54
  55
  56
  57
  58 Eastlake                    Standards Track                     [Page 1]
  59 \f
  60 RFC 2536                     DSA in the DNS                   March 1999
  61
  62
  63    This document describes how to store US Government Digital Signature
  64    Algorithm (DSA) keys and signatures in the DNS.  Familiarity with the
  65    US Digital Signature Algorithm is assumed [Schneier].  Implementation
  66    of DSA is mandatory for DNS security.
  67
  68 2. DSA KEY Resource Records
  69
  70    DSA public keys are stored in the DNS as KEY RRs using algorithm
  71    number 3 [RFC 2535].  The structure of the algorithm specific portion
  72    of the RDATA part of this RR is as shown below.  These fields, from Q
  73    through Y are the "public key" part of the DSA KEY RR.
  74
  75    The period of key validity is not in the KEY RR but is indicated by
  76    the SIG RR(s) which signs and authenticates the KEY RR(s) at that
  77    domain name.
  78
  79            Field     Size
  80            -----     ----
  81             T         1  octet
  82             Q        20  octets
  83             P        64 + T*8  octets
  84             G        64 + T*8  octets
  85             Y        64 + T*8  octets
  86
  87    As described in [FIPS 186] and [Schneier]: T is a key size parameter
  88    chosen such that 0 <= T <= 8.  (The meaning for algorithm 3 if the T
  89    octet is greater than 8 is reserved and the remainder of the RDATA
  90    portion may have a different format in that case.)  Q is a prime
  91    number selected at key generation time such that 2**159 < Q < 2**160
  92    so Q is always 20 octets long and, as with all other fields, is
  93    stored in "big-endian" network order.  P, G, and Y are calculated as
  94    directed by the FIPS 186 key generation algorithm [Schneier].  P is
  95    in the range 2**(511+64T) < P < 2**(512+64T) and so is 64 + 8*T
  96    octets long.  G and Y are quantities modulus P and so can be up to
  97    the same length as P and are allocated fixed size fields with the
  98    same number of octets as P.
  99
 100    During the key generation process, a random number X must be
 101    generated such that 1 <= X <= Q-1.  X is the private key and is used
 102    in the final step of public key generation where Y is computed as
 103
 104              Y = G**X mod P
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Eastlake                    Standards Track                     [Page 2]
 115 \f
 116 RFC 2536                     DSA in the DNS                   March 1999
 117
 118
 119 3. DSA SIG Resource Records
 120
 121    The signature portion of the SIG RR RDATA area, when using the US
 122    Digital Signature Algorithm, is shown below with fields in the order
 123    they occur.  See [RFC 2535] for fields in the SIG RR RDATA which
 124    precede the signature itself.
 125
 126            Field     Size
 127            -----     ----
 128             T         1 octet
 129             R        20 octets
 130             S        20 octets
 131
 132    The data signed is determined as specified in [RFC 2535].  Then the
 133    following steps are taken, as specified in [FIPS 186], where Q, P, G,
 134    and Y are as specified in the public key [Schneier]:
 135
 136            hash = SHA-1 ( data )
 137
 138            Generate a random K such that 0 < K < Q.
 139
 140            R = ( G**K mod P ) mod Q
 141
 142            S = ( K**(-1) * (hash + X*R) ) mod Q
 143
 144    Since Q is 160 bits long, R and S can not be larger than 20 octets,
 145    which is the space allocated.
 146
 147    T is copied from the public key.  It is not logically necessary in
 148    the SIG but is present so that values of T > 8 can more conveniently
 149    be used as an escape for extended versions of DSA or other algorithms
 150    as later specified.
 151
 152 4. Performance Considerations
 153
 154    General signature generation speeds are roughly the same for RSA [RFC
 155    2537] and DSA.  With sufficient pre-computation, signature generation
 156    with DSA is faster than RSA.  Key generation is also faster for DSA.
 157    However, signature verification is an order of magnitude slower than
 158    RSA when the RSA public exponent is chosen to be small as is
 159    recommended for KEY RRs used in domain name system (DNS) data
 160    authentication.
 161
 162    Current DNS implementations are optimized for small transfers,
 163    typically less than 512 bytes including overhead.  While larger
 164    transfers will perform correctly and work is underway to make larger
 165    transfers more efficient, it is still advisable at this time to make
 166    reasonable efforts to minimize the size of KEY RR sets stored within
 167
 168
 169
 170 Eastlake                    Standards Track                     [Page 3]
 171 \f
 172 RFC 2536                     DSA in the DNS                   March 1999
 173
 174
 175    the DNS consistent with adequate security.  Keep in mind that in a
 176    secure zone, at least one authenticating SIG RR will also be
 177    returned.
 178
 179 5. Security Considerations
 180
 181    Many of the general security consideration in [RFC 2535] apply.  Keys
 182    retrieved from the DNS should not be trusted unless (1) they have
 183    been securely obtained from a secure resolver or independently
 184    verified by the user and (2) this secure resolver and secure
 185    obtainment or independent verification conform to security policies
 186    acceptable to the user.  As with all cryptographic algorithms,
 187    evaluating the necessary strength of the key is essential and
 188    dependent on local policy.
 189
 190    The key size limitation of a maximum of 1024 bits ( T = 8 ) in the
 191    current DSA standard may limit the security of DSA.  For particularly
 192    critical applications, implementors are encouraged to consider the
 193    range of available algorithms and key sizes.
 194
 195    DSA assumes the ability to frequently generate high quality random
 196    numbers.  See [RFC 1750] for guidance.  DSA is designed so that if
 197    manipulated rather than random numbers are used, very high bandwidth
 198    covert channels are possible.  See [Schneier] and more recent
 199    research.  The leakage of an entire DSA private key in only two DSA
 200    signatures has been demonstrated.  DSA provides security only if
 201    trusted implementations, including trusted random number generation,
 202    are used.
 203
 204 6. IANA Considerations
 205
 206    Allocation of meaning to values of the T parameter that are not
 207    defined herein requires an IETF standards actions.  It is intended
 208    that values unallocated herein be used to cover future extensions of
 209    the DSS standard.
 210
 211
 212
 213
 214
 215
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Eastlake                    Standards Track                     [Page 4]
 227 \f
 228 RFC 2536                     DSA in the DNS                   March 1999
 229
 230
 231 References
 232
 233    [FIPS 186]   U.S. Federal Information Processing Standard: Digital
 234                 Signature Standard.
 235
 236    [RFC 1034]   Mockapetris, P., "Domain Names - Concepts and
 237                 Facilities", STD 13, RFC 1034, November 1987.
 238
 239    [RFC 1035]   Mockapetris, P., "Domain Names - Implementation and
 240                 Specification", STD 13, RFC 1035, November 1987.
 241
 242    [RFC 1750]   Eastlake, D., Crocker, S. and J. Schiller, "Randomness
 243                 Recommendations for Security", RFC 1750, December 1994.
 244
 245    [RFC 2535]   Eastlake, D., "Domain Name System Security Extensions",
 246                 RFC 2535, March 1999.
 247
 248    [RFC 2537]   Eastlake, D., "RSA/MD5 KEYs and SIGs in the Domain Name
 249                 System (DNS)", RFC 2537, March 1999.
 250
 251    [Schneier]   Schneier, B., "Applied Cryptography Second Edition:
 252                 protocols, algorithms, and source code in C", 1996.
 253
 254 Author's Address
 255
 256    Donald E. Eastlake 3rd
 257    IBM
 258    65 Shindegan Hill Road, RR #1
 259    Carmel, NY 10512
 260
 261    Phone:   +1-914-276-2668(h)
 262             +1-914-784-7913(w)
 263    Fax:     +1-914-784-3833(w)
 264    EMail:   dee3@us.ibm.com
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Eastlake                    Standards Track                     [Page 5]
 283 \f
 284 RFC 2536                     DSA in the DNS                   March 1999
 285
 286
 287 Full Copyright Statement
 288
 289    Copyright (C) The Internet Society (1999).  All Rights Reserved.
 290
 291    This document and translations of it may be copied and furnished to
 292    others, and derivative works that comment on or otherwise explain it
 293    or assist in its implementation may be prepared, copied, published
 294    and distributed, in whole or in part, without restriction of any
 295    kind, provided that the above copyright notice and this paragraph are
 296    included on all such copies and derivative works.  However, this
 297    document itself may not be modified in any way, such as by removing
 298    the copyright notice or references to the Internet Society or other
 299    Internet organizations, except as needed for the purpose of
 300    developing Internet standards in which case the procedures for
 301    copyrights defined in the Internet Standards process must be
 302    followed, or as required to translate it into languages other than
 303    English.
 304
 305    The limited permissions granted above are perpetual and will not be
 306    revoked by the Internet Society or its successors or assigns.
 307
 308    This document and the information contained herein is provided on an
 309    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 310    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 311    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 312    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 313    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Eastlake                    Standards Track                     [Page 6]
 339 \f