contrib/bind9/doc/draft/draft-ietf-dnsext-ds-sha256-05.txt

   1
   2
   3
   4 Network Working Group                                        W. Hardaker
   5 Internet-Draft                                                    Sparta
   6 Expires: August 25, 2006                               February 21, 2006
   7
   8
   9  Use of SHA-256 in DNSSEC Delegation Signer (DS) Resource Records (RRs)
  10                    draft-ietf-dnsext-ds-sha256-05.txt
  11
  12 Status of this Memo
  13
  14    By submitting this Internet-Draft, each author represents that any
  15    applicable patent or other IPR claims of which he or she is aware
  16    have been or will be disclosed, and any of which he or she becomes
  17    aware will be disclosed, in accordance with Section 6 of BCP 79.
  18
  19    Internet-Drafts are working documents of the Internet Engineering
  20    Task Force (IETF), its areas, and its working groups.  Note that
  21    other groups may also distribute working documents as Internet-
  22    Drafts.
  23
  24    Internet-Drafts are draft documents valid for a maximum of six months
  25    and may be updated, replaced, or obsoleted by other documents at any
  26    time.  It is inappropriate to use Internet-Drafts as reference
  27    material or to cite them other than as "work in progress."
  28
  29    The list of current Internet-Drafts can be accessed at
  30    http://www.ietf.org/ietf/1id-abstracts.txt.
  31
  32    The list of Internet-Draft Shadow Directories can be accessed at
  33    http://www.ietf.org/shadow.html.
  34
  35    This Internet-Draft will expire on August 25, 2006.
  36
  37 Copyright Notice
  38
  39    Copyright (C) The Internet Society (2006).
  40
  41 Abstract
  42
  43    This document specifies how to use the SHA-256 digest type in DNS
  44    Delegation Signer (DS) Resource Records (RRs).  DS records, when
  45    stored in a parent zone, point to key signing DNSKEY key(s) in a
  46    child zone.
  47
  48
  49
  50
  51
  52
  53
  54
  55 Hardaker                 Expires August 25, 2006                [Page 1]
  56 \f
  57 Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
  58
  59
  60 Table of Contents
  61
  62    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  63    2.  Implementing the SHA-256 algorithm for DS record support  . . . 3
  64      2.1.  DS record field values  . . . . . . . . . . . . . . . . . . 3
  65      2.2.  DS Record with SHA-256 Wire Format  . . . . . . . . . . . . 3
  66      2.3.  Example DS Record Using SHA-256 . . . . . . . . . . . . . . 4
  67    3.  Implementation Requirements . . . . . . . . . . . . . . . . . . 4
  68    4.  Deployment Considerations . . . . . . . . . . . . . . . . . . . 4
  69    5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
  70    6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
  71      6.1.  Potential Digest Type Downgrade Attacks . . . . . . . . . . 5
  72      6.2.  SHA-1 vs SHA-256 Considerations for DS Records  . . . . . . 6
  73    7.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
  74    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  75      8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
  76      8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
  77    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
  78    Intellectual Property and Copyright Statements  . . . . . . . . . . 9
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Hardaker                 Expires August 25, 2006                [Page 2]
 112 \f
 113 Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
 114
 115
 116 1.  Introduction
 117
 118    The DNSSEC [RFC4033] [RFC4034] [RFC4035] DS RR is published in parent
 119    zones to distribute a cryptographic digest of a child's Key Signing
 120    Key (KSK) DNSKEY RR.  The DS RRset is signed by at least one of the
 121    parent zone's private zone data signing keys for each algorithm in
 122    use by the parent.  Each signature is published in an RRSIG resource
 123    record, owned by the same domain as the DS RRset and with a type
 124    covered of DS.
 125
 126    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 127    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 128    document are to be interpreted as described in [RFC2119].
 129
 130
 131 2.  Implementing the SHA-256 algorithm for DS record support
 132
 133    This document specifies that the digest type code [XXX: To be
 134    assigned by IANA; likely 2] is to be assigned to SHA-256 [SHA256]
 135    [SHA256CODE] for use within DS records.  The results of the digest
 136    algorithm MUST NOT be truncated and the entire 32 byte digest result
 137    is to be published in the DS record.
 138
 139 2.1.  DS record field values
 140
 141    Using the SHA-256 digest algorithm within a DS record will make use
 142    of the following DS-record fields:
 143
 144    Digest type: [XXX: To be assigned by IANA; likely 2]
 145
 146    Digest: A SHA-256 bit digest value calculated by using the following
 147       formula ("|" denotes concatenation).  The resulting value is not
 148       truncated and the entire 32 byte result is to used in the
 149       resulting DS record and related calculations.
 150
 151         digest = SHA_256(DNSKEY owner name | DNSKEY RDATA)
 152
 153       where DNSKEY RDATA is defined by [RFC4034] as:
 154
 155         DNSKEY RDATA = Flags | Protocol | Algorithm | Public Key
 156
 157    The Key Tag field and Algorithm fields remain unchanged by this
 158    document and are specified in the [RFC4034] specification.
 159
 160 2.2.  DS Record with SHA-256 Wire Format
 161
 162    The resulting on-the-wire format for the resulting DS record will be
 163    [XXX: IANA assignment should replace the 2 below]:
 164
 165
 166
 167 Hardaker                 Expires August 25, 2006                [Page 3]
 168 \f
 169 Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
 170
 171
 172                            1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 173        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 174       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 175       |           Key Tag             |  Algorithm    | DigestType=2  |
 176       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 177       /                                                               /
 178       /            Digest  (length for SHA-256 is 32 bytes)           /
 179       /                                                               /
 180       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
 181
 182 2.3.  Example DS Record Using SHA-256
 183
 184    The following is an example DNSKEY and matching DS record.  This
 185    DNSKEY record comes from the example DNSKEY/DS records found in
 186    section 5.4 of [RFC4034].
 187
 188    The DNSKEY record:
 189
 190    dskey.example.com. 86400 IN DNSKEY 256 3 5 ( AQOeiiR0GOMYkDshWoSKz9Xz
 191                                                 fwJr1AYtsmx3TGkJaNXVbfi/
 192                                                 2pHm822aJ5iI9BMzNXxeYCmZ
 193                                                 DRD99WYwYqUSdjMmmAphXdvx
 194                                                 egXd/M5+X7OrzKBaMbCVdFLU
 195                                                 Uh6DhweJBjEVv5f2wwjM9Xzc
 196                                                 nOf+EPbtG9DMBmADjFDc2w/r
 197                                                 ljwvFw==
 198                                                 ) ;  key id = 60485
 199
 200    The resulting DS record covering the above DNSKEY record using a SHA-
 201    256 digest: [RFC Editor: please replace XXX with the assigned digest
 202    type (likely 2):]
 203
 204    dskey.example.com. 86400 IN DS 60485 5 XXX ( D4B7D520E7BB5F0F67674A0C
 205                                                 CEB1E3E0614B93C4F9E99B83
 206                                                 83F6A1E4469DA50A )
 207
 208
 209 3.  Implementation Requirements
 210
 211    Implementations MUST support the use of the SHA-256 algorithm in DS
 212    RRs.  Validator implementations SHOULD ignore DS RRs containing SHA-1
 213    digests if DS RRs with SHA-256 digests are present in the DS RRset.
 214
 215
 216 4.  Deployment Considerations
 217
 218    If a validator does not support the SHA-256 digest type and no other
 219    DS RR exists in a zone's DS RRset with a supported digest type, then
 220
 221
 222
 223 Hardaker                 Expires August 25, 2006                [Page 4]
 224 \f
 225 Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
 226
 227
 228    the validator has no supported authentication path leading from the
 229    parent to the child.  The resolver should treat this case as it would
 230    the case of an authenticated NSEC RRset proving that no DS RRset
 231    exists, as described in [RFC4035], section 5.2.
 232
 233    Because zone administrators can not control the deployment speed of
 234    support for SHA-256 in validators that may be referencing any of
 235    their zones, zone operators should consider deploying both SHA-1 and
 236    SHA-256 based DS records.  This should be done for every DNSKEY for
 237    which DS records are being generated.  Whether to make use of both
 238    digest types and for how long is a policy decision that extends
 239    beyond the scope of this document.
 240
 241
 242 5.  IANA Considerations
 243
 244    Only one IANA action is required by this document:
 245
 246    The Digest Type to be used for supporting SHA-256 within DS records
 247    needs to be assigned by IANA.  This document requests that the Digest
 248    Type value of 2 be assigned to the SHA-256 digest algorithm.
 249
 250    At the time of this writing, the current digest types assigned for
 251    use in DS records are as follows:
 252
 253       VALUE     Digest Type          Status
 254         0       Reserved                -
 255         1       SHA-1                MANDATORY
 256         2       SHA-256              MANDATORY
 257       3-255    Unassigned               -
 258
 259
 260 6.  Security Considerations
 261
 262 6.1.  Potential Digest Type Downgrade Attacks
 263
 264    A downgrade attack from a stronger digest type to a weaker one is
 265    possible if all of the following are true:
 266
 267    o  A zone includes multiple DS records for a given child's DNSKEY,
 268       each of which use a different digest type.
 269
 270    o  A validator accepts a weaker digest even if a stronger one is
 271       present but invalid.
 272
 273    For example, if the following conditions are all true:
 274
 275
 276
 277
 278
 279 Hardaker                 Expires August 25, 2006                [Page 5]
 280 \f
 281 Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
 282
 283
 284    o  Both SHA-1 and SHA-256 based digests are published in DS records
 285       within a parent zone for a given child zone's DNSKEY.
 286
 287    o  The DS record with the SHA-1 digest matches the digest computed
 288       using the child zone's DNSKEY.
 289
 290    o  The DS record with the SHA-256 digest fails to match the digest
 291       computed using the child zone's DNSKEY.
 292
 293    Then if the validator accepts the above situation as secure then this
 294    can be used as a downgrade attack since the stronger SHA-256 digest
 295    is ignored.
 296
 297 6.2.  SHA-1 vs SHA-256 Considerations for DS Records
 298
 299    Users of DNSSEC are encouraged to deploy SHA-256 as soon as software
 300    implementations allow for it.  SHA-256 is widely believed to be more
 301    resilient to attack than SHA-1, and confidence in SHA-1's strength is
 302    being eroded by recently-announced attacks.  Regardless of whether or
 303    not the attacks on SHA-1 will affect DNSSEC, it is believed (at the
 304    time of this writing) that SHA-256 is the better choice for use in DS
 305    records.
 306
 307    At the time of this publication, the SHA-256 digest algorithm is
 308    considered sufficiently strong for the immediate future.  It is also
 309    considered sufficient for use in DNSSEC DS RRs for the immediate
 310    future.  However, future published attacks may weaken the usability
 311    of this algorithm within the DS RRs.  It is beyond the scope of this
 312    document to speculate extensively on the cryptographic strength of
 313    the SHA-256 digest algorithm.
 314
 315    Likewise, it is also beyond the scope of this document to specify
 316    whether or for how long SHA-1 based DS records should be
 317    simultaneously published alongside SHA-256 based DS records.
 318
 319
 320 7.  Acknowledgments
 321
 322    This document is a minor extension to the existing DNSSEC documents
 323    and those authors are gratefully appreciated for the hard work that
 324    went into the base documents.
 325
 326    The following people contributed to portions of this document in some
 327    fashion: Mark Andrews, Roy Arends, Olafur Gudmundsson, Paul Hoffman,
 328    Olaf M. Kolkman, Edward Lewis, Scott Rose, Stuart E. Schechter, Sam
 329    Weiler.
 330
 331
 332
 333
 334
 335 Hardaker                 Expires August 25, 2006                [Page 6]
 336 \f
 337 Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
 338
 339
 340 8.  References
 341
 342 8.1.  Normative References
 343
 344    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 345               Requirement Levels", BCP 14, RFC 2119, March 1997.
 346
 347    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
 348               Rose, "DNS Security Introduction and Requirements",
 349               RFC 4033, March 2005.
 350
 351    [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
 352               Rose, "Resource Records for the DNS Security Extensions",
 353               RFC 4034, March 2005.
 354
 355    [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
 356               Rose, "Protocol Modifications for the DNS Security
 357               Extensions", RFC 4035, March 2005.
 358
 359    [SHA256]   National Institute of Standards and Technology, "Secure
 360               Hash Algorithm. NIST FIPS 180-2", August 2002.
 361
 362 8.2.  Informative References
 363
 364    [SHA256CODE]
 365               Eastlake, D., "US Secure Hash Algorithms (SHA)",
 366               June 2005.
 367
 368
 369
 370
 371
 372
 373
 374
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391 Hardaker                 Expires August 25, 2006                [Page 7]
 392 \f
 393 Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
 394
 395
 396 Author's Address
 397
 398    Wes Hardaker
 399    Sparta
 400    P.O. Box 382
 401    Davis, CA  95617
 402    US
 403
 404    Email: hardaker@tislabs.com
 405
 406
 407
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447 Hardaker                 Expires August 25, 2006                [Page 8]
 448 \f
 449 Internet-Draft       Use of SHA-256 in DNSSEC DS RRs       February 2006
 450
 451
 452 Intellectual Property Statement
 453
 454    The IETF takes no position regarding the validity or scope of any
 455    Intellectual Property Rights or other rights that might be claimed to
 456    pertain to the implementation or use of the technology described in
 457    this document or the extent to which any license under such rights
 458    might or might not be available; nor does it represent that it has
 459    made any independent effort to identify any such rights.  Information
 460    on the procedures with respect to rights in RFC documents can be
 461    found in BCP 78 and BCP 79.
 462
 463    Copies of IPR disclosures made to the IETF Secretariat and any
 464    assurances of licenses to be made available, or the result of an
 465    attempt made to obtain a general license or permission for the use of
 466    such proprietary rights by implementers or users of this
 467    specification can be obtained from the IETF on-line IPR repository at
 468    http://www.ietf.org/ipr.
 469
 470    The IETF invites any interested party to bring to its attention any
 471    copyrights, patents or patent applications, or other proprietary
 472    rights that may cover technology that may be required to implement
 473    this standard.  Please address the information to the IETF at
 474    ietf-ipr@ietf.org.
 475
 476
 477 Disclaimer of Validity
 478
 479    This document and the information contained herein are provided on an
 480    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 481    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 482    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 483    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 484    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 485    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 486
 487
 488 Copyright Statement
 489
 490    Copyright (C) The Internet Society (2006).  This document is subject
 491    to the rights, licenses and restrictions contained in BCP 78, and
 492    except as set forth therein, the authors retain all their rights.
 493
 494
 495 Acknowledgment
 496
 497    Funding for the RFC Editor function is currently provided by the
 498    Internet Society.
 499
 500
 501
 502
 503 Hardaker                 Expires August 25, 2006                [Page 9]
 504 \f