contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-bis-updates-01.txt

   1
   2
   3
   4 Network Working Group                                          S. Weiler
   5 Internet-Draft                                               SPARTA, Inc
   6 Updates: 4034, 4035 (if approved)                           May 23, 2005
   7 Expires: November 24, 2005
   8
   9
  10          Clarifications and Implementation Notes for DNSSECbis
  11                 draft-ietf-dnsext-dnssec-bis-updates-01
  12
  13 Status of this Memo
  14
  15    By submitting this Internet-Draft, each author represents that any
  16    applicable patent or other IPR claims of which he or she is aware
  17    have been or will be disclosed, and any of which he or she becomes
  18    aware will be disclosed, in accordance with Section 6 of BCP 79.
  19
  20    Internet-Drafts are working documents of the Internet Engineering
  21    Task Force (IETF), its areas, and its working groups.  Note that
  22    other groups may also distribute working documents as Internet-
  23    Drafts.
  24
  25    Internet-Drafts are draft documents valid for a maximum of six months
  26    and may be updated, replaced, or obsoleted by other documents at any
  27    time.  It is inappropriate to use Internet-Drafts as reference
  28    material or to cite them other than as "work in progress."
  29
  30    The list of current Internet-Drafts can be accessed at
  31    http://www.ietf.org/ietf/1id-abstracts.txt.
  32
  33    The list of Internet-Draft Shadow Directories can be accessed at
  34    http://www.ietf.org/shadow.html.
  35
  36    This Internet-Draft will expire on November 24, 2005.
  37
  38 Copyright Notice
  39
  40    Copyright (C) The Internet Society (2005).
  41
  42 Abstract
  43
  44    This document is a collection of minor technical clarifications to
  45    the DNSSECbis document set.  It is meant to serve as a resource to
  46    implementors as well as an interim repository of possible DNSSECbis
  47    errata.
  48
  49
  50
  51
  52
  53
  54
  55 Weiler                  Expires November 24, 2005               [Page 1]
  56 \f
  57 Internet-Draft       DNSSECbis Implementation Notes             May 2005
  58
  59
  60 Proposed additions in future versions
  61
  62    An index sorted by the section of DNSSECbis being clarified.
  63
  64    A list of proposed protocol changes being made in other documents,
  65    such as NSEC3 and Epsilon.  This document would not make those
  66    changes, merely provide an index into the documents that are making
  67    changes.
  68
  69 Changes between -00 and -01
  70
  71    Document significantly restructured.
  72
  73    Added section on QTYPE=ANY.
  74
  75 Changes between personal submission and first WG draft
  76
  77    Added Section 2.1 based on namedroppers discussions from March 9-10,
  78    2005.
  79
  80    Added Section 3.4, Section 3.3, Section 4.3, and Section 2.2.
  81
  82    Added the DNSSECbis RFC numbers.
  83
  84    Figured out the confusion in Section 4.1.
  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 Weiler                  Expires November 24, 2005               [Page 2]
 112 \f
 113 Internet-Draft       DNSSECbis Implementation Notes             May 2005
 114
 115
 116 Table of Contents
 117
 118    1.  Introduction and Terminology . . . . . . . . . . . . . . . . .  4
 119      1.1   Structure of this Document . . . . . . . . . . . . . . . .  4
 120      1.2   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
 121    2.  Significant Concerns . . . . . . . . . . . . . . . . . . . . .  4
 122      2.1   Clarifications on Non-Existence Proofs . . . . . . . . . .  4
 123      2.2   Empty Non-Terminal Proofs  . . . . . . . . . . . . . . . .  5
 124      2.3   Validating Responses to an ANY Query . . . . . . . . . . .  5
 125    3.  Interoperability Concerns  . . . . . . . . . . . . . . . . . .  5
 126      3.1   Unknown DS Message Digest Algorithms . . . . . . . . . . .  5
 127      3.2   Private Algorithms . . . . . . . . . . . . . . . . . . . .  6
 128      3.3   Caution About Local Policy and Multiple RRSIGs . . . . . .  6
 129      3.4   Key Tag Calculation  . . . . . . . . . . . . . . . . . . .  7
 130    4.  Minor Corrections and Clarifications . . . . . . . . . . . . .  7
 131      4.1   Finding Zone Cuts  . . . . . . . . . . . . . . . . . . . .  7
 132      4.2   Clarifications on DNSKEY Usage . . . . . . . . . . . . . .  7
 133      4.3   Errors in Examples . . . . . . . . . . . . . . . . . . . .  8
 134    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
 135    6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
 136    7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
 137      7.1   Normative References . . . . . . . . . . . . . . . . . . .  8
 138      7.2   Informative References . . . . . . . . . . . . . . . . . .  9
 139        Author's Address . . . . . . . . . . . . . . . . . . . . . . .  9
 140    A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . .  9
 141        Intellectual Property and Copyright Statements . . . . . . . . 11
 142
 143
 144
 145
 146
 147
 148
 149
 150
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167 Weiler                  Expires November 24, 2005               [Page 3]
 168 \f
 169 Internet-Draft       DNSSECbis Implementation Notes             May 2005
 170
 171
 172 1.  Introduction and Terminology
 173
 174    This document lists some minor clarifications and corrections to
 175    DNSSECbis, as described in [1], [2], and [3].
 176
 177    It is intended to serve as a resource for implementors and as a
 178    repository of items that need to be addressed when advancing the
 179    DNSSECbis documents from Proposed Standard to Draft Standard.
 180
 181    In this version (-01 of the WG document), feedback is particularly
 182    solicited on the structure of the document and whether the text in
 183    the recently added sections is correct and sufficient.
 184
 185    Proposed substantive additions to this document should be sent to the
 186    namedroppers mailing list as well as to the editor of this document.
 187    The editor would greatly prefer text suitable for direct inclusion in
 188    this document.
 189
 190 1.1  Structure of this Document
 191
 192    The clarifications to DNSSECbis are sorted according to the editor's
 193    impression of their importance, starting with ones which could, if
 194    ignored, lead to security and stability problems and progressing down
 195    to clarifications that are likely to have little operational impact.
 196    Mere typos and awkward phrasings are not addressed unless they could
 197    lead to misinterpretation of the DNSSECbis documents.
 198
 199 1.2  Terminology
 200
 201    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 202    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 203    document are to be interpreted as described in RFC 2119 [4].
 204
 205 2.  Significant Concerns
 206
 207    This section provides clarifications that, if overlooked, could lead
 208    to security issues or major interoperability problems.
 209
 210 2.1  Clarifications on Non-Existence Proofs
 211
 212    RFC4035 Section 5.4 slightly underspecifies the algorithm for
 213    checking non-existence proofs.  In particular, the algorithm there
 214    might incorrectly allow the NSEC from the parent side of a zone cut
 215    to prove the non-existence of either other RRs at that name in the
 216    child zone or other names in the child zone.  It might also allow a
 217    NSEC at the same name as a DNAME to prove the non-existence of names
 218    beneath that DNAME.
 219
 220
 221
 222
 223 Weiler                  Expires November 24, 2005               [Page 4]
 224 \f
 225 Internet-Draft       DNSSECbis Implementation Notes             May 2005
 226
 227
 228    A parent-side delegation NSEC (one with the NS bit set, but no SOA
 229    bit set, and with a singer field that's shorter than the owner name)
 230    must not be used to assume non-existence of any RRs below that zone
 231    cut (both RRs at that ownername and at ownernames with more leading
 232    labels, no matter their content).  Similarly, an NSEC with the DNAME
 233    bit set must not be used to assume the non-existence of any
 234    descendant of that NSEC's owner name.
 235
 236 2.2  Empty Non-Terminal Proofs
 237
 238    To be written, based on Roy Arends' May 11th message to namedroppers.
 239
 240 2.3  Validating Responses to an ANY Query
 241
 242    RFC4035 does not address now to validate responses when QTYPE=*.  As
 243    described in Section 6.2.2 of RFC1034, a proper response to QTYPE=*
 244    may include a subset of the RRsets at a given name -- it is not
 245    necessary to include all RRsets at the QNAME in the response.
 246
 247    When validating a response to QTYPE=*, validate all received RRsets
 248    that match QNAME and QCLASS.  If any of those RRsets fail validation,
 249    treat the answer as Bogus.  If there are no RRsets matching QNAME and
 250    QCLASS, validate that fact using the rules in RFC4035 Section 5.4 (as
 251    clarified in this document).  To be clear, a validator must not
 252    insist on receiving all records at the QNAME in response to QTYPE=*.
 253
 254 3.  Interoperability Concerns
 255
 256 3.1  Unknown DS Message Digest Algorithms
 257
 258    Section 5.2 of RFC4035 includes rules for how to handle delegations
 259    to zones that are signed with entirely unsupported algorithms, as
 260    indicated by the algorithms shown in those zone's DS RRsets.  It does
 261    not explicitly address how to handle DS records that use unsupported
 262    message digest algorithms.  In brief, DS records using unknown or
 263    unsupported message digest algorithms MUST be treated the same way as
 264    DS records referring to DNSKEY RRs of unknown or unsupported
 265    algorithms.
 266
 267    The existing text says:
 268
 269       If the validator does not support any of the algorithms listed
 270       in an authenticated DS RRset, then the resolver has no supported
 271       authentication path leading from the parent to the child.  The
 272       resolver should treat this case as it would the case of an
 273       authenticated NSEC RRset proving that no DS RRset exists, as
 274       described above.
 275
 276
 277
 278
 279 Weiler                  Expires November 24, 2005               [Page 5]
 280 \f
 281 Internet-Draft       DNSSECbis Implementation Notes             May 2005
 282
 283
 284    To paraphrase the above, when determining the security status of a
 285    zone, a validator discards (for this purpose only) any DS records
 286    listing unknown or unsupported algorithms.  If none are left, the
 287    zone is treated as if it were unsigned.
 288
 289    Modified to consider DS message digest algorithms, a validator also
 290    discards any DS records using unknown or unsupported message digest
 291    algorithms.
 292
 293 3.2  Private Algorithms
 294
 295    As discussed above, section 5.2 of RFC4035 requires that validators
 296    make decisions about the security status of zones based on the public
 297    key algorithms shown in the DS records for those zones.  In the case
 298    of private algorithms, as described in RFC4034 Appendix A.1.1, the
 299    eight-bit algorithm field in the DS RR is not conclusive about what
 300    algorithm(s) is actually in use.
 301
 302    If no private algorithms appear in the DS set or if any supported
 303    algorithm appears in the DS set, no special processing will be
 304    needed.  In the remaining cases, the security status of the zone
 305    depends on whether or not the resolver supports any of the private
 306    algorithms in use (provided that these DS records use supported hash
 307    functions, as discussed in Section 3.1).  In these cases, the
 308    resolver MUST retrieve the corresponding DNSKEY for each private
 309    algorithm DS record and examine the public key field to determine the
 310    algorithm in use.  The security-aware resolver MUST ensure that the
 311    hash of the DNSKEY RR's owner name and RDATA matches the digest in
 312    the DS RR.  If they do not match, and no other DS establishes that
 313    the zone is secure, the referral should be considered BAD data, as
 314    discussed in RFC4035.
 315
 316    This clarification facilitates the broader use of private algorithms,
 317    as suggested by [5].
 318
 319 3.3  Caution About Local Policy and Multiple RRSIGs
 320
 321    When multiple RRSIGs cover a given RRset, RFC4035 Section 5.3.3
 322    suggests that "the local resolver security policy determines whether
 323    the resolver also has to test these RRSIG RRs and how to resolve
 324    conflicts if these RRSIG RRs lead to differing results."  In most
 325    cases, a resolver would be well advised to accept any valid RRSIG as
 326    sufficient.  If the first RRSIG tested fails validation, a resolver
 327    would be well advised to try others, giving a successful validation
 328    result if any can be validated and giving a failure only if all
 329    RRSIGs fail validation.
 330
 331    If a resolver adopts a more restrictive policy, there's a danger that
 332
 333
 334
 335 Weiler                  Expires November 24, 2005               [Page 6]
 336 \f
 337 Internet-Draft       DNSSECbis Implementation Notes             May 2005
 338
 339
 340    properly-signed data might unnecessarily fail validation, perhaps
 341    because of cache timing issues.  Furthermore, certain zone management
 342    techniques, like the Double Signature Zone-signing Key Rollover
 343    method described in section 4.2.1.2 of [6] might not work reliably.
 344
 345 3.4  Key Tag Calculation
 346
 347    RFC4034 Appendix B.1 incorrectly defines the Key Tag field
 348    calculation for algorithm 1.  It correctly says that the Key Tag is
 349    the most significant 16 of the least significant 24 bits of the
 350    public key modulus.  However, RFC4034 then goes on to incorrectly say
 351    that this is 4th to last and 3rd to last octets of the public key
 352    modulus.  It is, in fact, the 3rd to last and 2nd to last octets.
 353
 354 4.  Minor Corrections and Clarifications
 355
 356 4.1  Finding Zone Cuts
 357
 358    Appendix C.8 of RFC4035 discusses sending DS queries to the servers
 359    for a parent zone.  To do that, a resolver may first need to apply
 360    special rules to discover what those servers are.
 361
 362    As explained in Section 3.1.4.1 of RFC4035, security-aware name
 363    servers need to apply special processing rules to handle the DS RR,
 364    and in some situations the resolver may also need to apply special
 365    rules to locate the name servers for the parent zone if the resolver
 366    does not already have the parent's NS RRset.  Section 4.2 of RFC4035
 367    specifies a mechanism for doing that.
 368
 369 4.2  Clarifications on DNSKEY Usage
 370
 371    Questions of the form "can I use a different DNSKEY for signing the
 372    X" have occasionally arisen.
 373
 374    The short answer is "yes, absolutely".  You can even use a different
 375    DNSKEY for each RRset in a zone, subject only to practical limits on
 376    the size of the DNSKEY RRset.  However, be aware that there is no way
 377    to tell resolvers what a particularly DNSKEY is supposed to be used
 378    for -- any DNSKEY in the zone's signed DNSKEY RRset may be used to
 379    authenticate any RRset in the zone.  For example, if a weaker or less
 380    trusted DNSKEY is being used to authenticate NSEC RRsets or all
 381    dynamically updated records, that same DNSKEY can also be used to
 382    sign any other RRsets from the zone.
 383
 384    Furthermore, note that the SEP bit setting has no effect on how a
 385    DNSKEY may be used -- the validation process is specifically
 386    prohibited from using that bit by RFC4034 section 2.1.2.  It possible
 387    to use a DNSKEY without the SEP bit set as the sole secure entry
 388
 389
 390
 391 Weiler                  Expires November 24, 2005               [Page 7]
 392 \f
 393 Internet-Draft       DNSSECbis Implementation Notes             May 2005
 394
 395
 396    point to the zone, yet use a DNSKEY with the SEP bit set to sign all
 397    RRsets in the zone (other than the DNSKEY RRset).  It's also possible
 398    to use a single DNSKEY, with or without the SEP bit set, to sign the
 399    entire zone, including the DNSKEY RRset itself.
 400
 401 4.3  Errors in Examples
 402
 403    The text in RFC4035 Section C.1 refers to the examples in B.1 as
 404    "x.w.example.com" while B.1 uses "x.w.example".  This is painfully
 405    obvious in the second paragraph where it states that the RRSIG labels
 406    field value of 3 indicates that the answer was not the result of
 407    wildcard expansion.  This is true for "x.w.example" but not for
 408    "x.w.example.com", which of course has a label count of 4
 409    (antithetically, a label count of 3 would imply the answer was the
 410    result of a wildcard expansion).
 411
 412    The first paragraph of RFC4035 Section C.6 also has a minor error:
 413    the reference to "a.z.w.w.example" should instead be "a.z.w.example",
 414    as in the previous line.
 415
 416 5.  IANA Considerations
 417
 418    This document specifies no IANA Actions.
 419
 420 6.  Security Considerations
 421
 422    This document does not make fundamental changes to the DNSSEC
 423    protocol, as it was generally understood when DNSSECbis was
 424    published.  It does, however, address some ambiguities and omissions
 425    in those documents that, if not recognized and addressed in
 426    implementations, could lead to security failures.  In particular, the
 427    validation algorithm clarifications in Section 2 are critical for
 428    preserving the security properties DNSSEC offers.  Furthermore,
 429    failure to address some of the interoperability concerns in Section 3
 430    could limit the ability to later change or expand DNSSEC, including
 431    by adding new algorithms.
 432
 433 7.  References
 434
 435 7.1  Normative References
 436
 437    [1]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
 438         "DNS Security Introduction and Requirements", RFC 4033,
 439         March 2005.
 440
 441    [2]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
 442         "Resource Records for the DNS Security Extensions", RFC 4034,
 443         March 2005.
 444
 445
 446
 447 Weiler                  Expires November 24, 2005               [Page 8]
 448 \f
 449 Internet-Draft       DNSSECbis Implementation Notes             May 2005
 450
 451
 452    [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
 453         "Protocol Modifications for the DNS Security Extensions",
 454         RFC 4035, March 2005.
 455
 456    [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
 457         Levels", BCP 14, RFC 2119, March 1997.
 458
 459 7.2  Informative References
 460
 461    [5]  Blacka, D., "DNSSEC Experiments",
 462         draft-blacka-dnssec-experiments-00 (work in progress),
 463         December 2004.
 464
 465    [6]  Gieben, R. and O. Kolkman, "DNSSEC Operational Practices",
 466         draft-ietf-dnsop-dnssec-operational-practices-04 (work in
 467         progress), May 2005.
 468
 469
 470 Author's Address
 471
 472    Samuel Weiler
 473    SPARTA, Inc
 474    7075 Samuel Morse Drive
 475    Columbia, Maryland  21046
 476    US
 477
 478    Email: weiler@tislabs.com
 479
 480 Appendix A.  Acknowledgments
 481
 482    The editor is extremely grateful to those who, in addition to finding
 483    errors and omissions in the DNSSECbis document set, have provided
 484    text suitable for inclusion in this document.
 485
 486    The lack of specificity about handling private algorithms, as
 487    described in Section 3.2, and the lack of specificity in handling ANY
 488    queries, as described in Section 2.3, were discovered by David
 489    Blacka.
 490
 491    The error in algorithm 1 key tag calculation, as described in
 492    Section 3.4, was found by Abhijit Hayatnagarkar.  Donald Eastlake
 493    contributed text for Section 3.4.
 494
 495    The bug relating to delegation NSEC RR's in Section 2.1 was found by
 496    Roy Badami.  Roy Arends found the related problem with DNAME.
 497
 498    The errors in the RFC4035 examples were found by Roy Arends, who also
 499    contributed text for Section 4.3 of this document.
 500
 501
 502
 503 Weiler                  Expires November 24, 2005               [Page 9]
 504 \f
 505 Internet-Draft       DNSSECbis Implementation Notes             May 2005
 506
 507
 508    The editor would like to thank Olafur Gudmundsson and Scott Rose for
 509    their substantive comments on the text of this document.
 510
 511
 512
 513
 514
 515
 516
 517
 518
 519
 520
 521
 522
 523
 524
 525
 526
 527
 528
 529
 530
 531
 532
 533
 534
 535
 536
 537
 538
 539
 540
 541
 542
 543
 544
 545
 546
 547
 548
 549
 550
 551
 552
 553
 554
 555
 556
 557
 558
 559 Weiler                  Expires November 24, 2005              [Page 10]
 560 \f
 561 Internet-Draft       DNSSECbis Implementation Notes             May 2005
 562
 563
 564 Intellectual Property Statement
 565
 566    The IETF takes no position regarding the validity or scope of any
 567    Intellectual Property Rights or other rights that might be claimed to
 568    pertain to the implementation or use of the technology described in
 569    this document or the extent to which any license under such rights
 570    might or might not be available; nor does it represent that it has
 571    made any independent effort to identify any such rights.  Information
 572    on the procedures with respect to rights in RFC documents can be
 573    found in BCP 78 and BCP 79.
 574
 575    Copies of IPR disclosures made to the IETF Secretariat and any
 576    assurances of licenses to be made available, or the result of an
 577    attempt made to obtain a general license or permission for the use of
 578    such proprietary rights by implementers or users of this
 579    specification can be obtained from the IETF on-line IPR repository at
 580    http://www.ietf.org/ipr.
 581
 582    The IETF invites any interested party to bring to its attention any
 583    copyrights, patents or patent applications, or other proprietary
 584    rights that may cover technology that may be required to implement
 585    this standard.  Please address the information to the IETF at
 586    ietf-ipr@ietf.org.
 587
 588
 589 Disclaimer of Validity
 590
 591    This document and the information contained herein are provided on an
 592    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 593    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 594    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 595    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 596    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 597    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 598
 599
 600 Copyright Statement
 601
 602    Copyright (C) The Internet Society (2005).  This document is subject
 603    to the rights, licenses and restrictions contained in BCP 78, and
 604    except as set forth therein, the authors retain all their rights.
 605
 606
 607 Acknowledgment
 608
 609    Funding for the RFC Editor function is currently provided by the
 610    Internet Society.
 611
 612
 613
 614
 615 Weiler                  Expires November 24, 2005              [Page 11]
 616 \f