contrib/bind9/doc/draft/draft-ietf-dnsext-dnssec-opt-in-07.txt

   1
   2
   3
   4 DNSEXT                                                         R. Arends
   5 Internet-Draft                                      Telematica Instituut
   6 Expires: January 19, 2006                                     M. Kosters
   7                                                                D. Blacka
   8                                                           Verisign, Inc.
   9                                                            July 18, 2005
  10
  11
  12                              DNSSEC Opt-In
  13                    draft-ietf-dnsext-dnssec-opt-in-07
  14
  15 Status of this Memo
  16
  17    By submitting this Internet-Draft, each author represents that any
  18    applicable patent or other IPR claims of which he or she is aware
  19    have been or will be disclosed, and any of which he or she becomes
  20    aware will be disclosed, in accordance with Section 6 of BCP 79.
  21
  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.
  26
  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."
  31
  32    The list of current Internet-Drafts can be accessed at
  33    http://www.ietf.org/ietf/1id-abstracts.txt.
  34
  35    The list of Internet-Draft Shadow Directories can be accessed at
  36    http://www.ietf.org/shadow.html.
  37
  38    This Internet-Draft will expire on January 19, 2006.
  39
  40 Copyright Notice
  41
  42    Copyright (C) The Internet Society (2005).
  43
  44 Abstract
  45
  46    In the DNS security extensions (DNSSEC, defined in RFC 4033 [3], RFC
  47    4034 [4], and RFC 4035 [5]), delegations to unsigned subzones are
  48    cryptographically secured.  Maintaining this cryptography is not
  49    practical or necessary.  This document describes an experimental
  50    "Opt-In" model that allows administrators to omit this cryptography
  51    and manage the cost of adopting DNSSEC with large zones.
  52
  53
  54
  55 Arends, et al.          Expires January 19, 2006                [Page 1]
  56 \f
  57 Internet-Draft                DNSSEC Opt-In                    July 2005
  58
  59
  60 Table of Contents
  61
  62    1.  Definitions and Terminology  . . . . . . . . . . . . . . . . .  3
  63    2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
  64    3.  Experimental Status  . . . . . . . . . . . . . . . . . . . . .  4
  65    4.  Protocol Additions . . . . . . . . . . . . . . . . . . . . . .  4
  66      4.1   Server Considerations  . . . . . . . . . . . . . . . . . .  5
  67        4.1.1   Delegations Only . . . . . . . . . . . . . . . . . . .  5
  68        4.1.2   Insecure Delegation Responses  . . . . . . . . . . . .  6
  69        4.1.3   Wildcards and Opt-In . . . . . . . . . . . . . . . . .  6
  70        4.1.4   Dynamic Update . . . . . . . . . . . . . . . . . . . .  7
  71      4.2   Client Considerations  . . . . . . . . . . . . . . . . . .  7
  72        4.2.1   Delegations Only . . . . . . . . . . . . . . . . . . .  7
  73        4.2.2   Validation Process Changes . . . . . . . . . . . . . .  7
  74        4.2.3   NSEC Record Caching  . . . . . . . . . . . . . . . . .  8
  75        4.2.4   Use of the AD bit  . . . . . . . . . . . . . . . . . .  8
  76    5.  Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
  77    6.  Example  . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
  78    7.  Transition Issues  . . . . . . . . . . . . . . . . . . . . . . 10
  79    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
  80    9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
  81    10.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 12
  82    11.   References . . . . . . . . . . . . . . . . . . . . . . . . . 13
  83      11.1  Normative References . . . . . . . . . . . . . . . . . . . 13
  84      11.2  Informative References . . . . . . . . . . . . . . . . . . 13
  85        Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
  86    A.  Implementing Opt-In using "Views"  . . . . . . . . . . . . . . 14
  87        Intellectual Property and Copyright Statements . . . . . . . . 16
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110
 111 Arends, et al.          Expires January 19, 2006                [Page 2]
 112 \f
 113 Internet-Draft                DNSSEC Opt-In                    July 2005
 114
 115
 116 1.  Definitions and Terminology
 117
 118    Throughout this document, familiarity with the DNS system (RFC 1035
 119    [1]), DNS security extensions ([3], [4], and [5], referred to in this
 120    document as "standard DNSSEC"), and DNSSEC terminology (RFC 3090
 121    [10]) is assumed.
 122
 123    The following abbreviations and terms are used in this document:
 124
 125    RR: is used to refer to a DNS resource record.
 126    RRset: refers to a Resource Record Set, as defined by [8].  In this
 127       document, the RRset is also defined to include the covering RRSIG
 128       records, if any exist.
 129    signed name: refers to a DNS name that has, at minimum, a (signed)
 130       NSEC record.
 131    unsigned name: refers to a DNS name that does not (at least) have a
 132       NSEC record.
 133    covering NSEC record/RRset: is the NSEC record used to prove
 134       (non)existence of a particular name or RRset.  This means that for
 135       a RRset or name 'N', the covering NSEC record has the name 'N', or
 136       has an owner name less than 'N' and "next" name greater than 'N'.
 137    delegation: refers to a NS RRset with a name different from the
 138       current zone apex (non-zone-apex), signifying a delegation to a
 139       subzone.
 140    secure delegation: refers to a signed name containing a delegation
 141       (NS RRset), and a signed DS RRset, signifying a delegation to a
 142       signed subzone.
 143    insecure delegation: refers to a signed name containing a delegation
 144       (NS RRset), but lacking a DS RRset, signifying a delegation to an
 145       unsigned subzone.
 146    Opt-In insecure delegation: refers to an unsigned name containing
 147       only a delegation NS RRset.  The covering NSEC record uses the
 148       Opt-In methodology described in this document.
 149
 150    The key words "MUST, "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 151    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY, and "OPTIONAL" in this
 152    document are to be interpreted as described in RFC 2119 [7].
 153
 154 2.  Overview
 155
 156    The cost to cryptographically secure delegations to unsigned zones is
 157    high for large delegation-centric zones and zones where insecure
 158    delegations will be updated rapidly.  For these zones, the costs of
 159    maintaining the NSEC record chain may be extremely high relative to
 160    the gain of cryptographically authenticating existence of unsecured
 161    zones.
 162
 163    This document describes an experimental method of eliminating the
 164
 165
 166
 167 Arends, et al.          Expires January 19, 2006                [Page 3]
 168 \f
 169 Internet-Draft                DNSSEC Opt-In                    July 2005
 170
 171
 172    superfluous cryptography present in secure delegations to unsigned
 173    zones.  Using "Opt-In", a zone administrator can choose to remove
 174    insecure delegations from the NSEC chain.  This is accomplished by
 175    extending the semantics of the NSEC record by using a redundant bit
 176    in the type map.
 177
 178 3.  Experimental Status
 179
 180    This document describes an EXPERIMENTAL extension to DNSSEC.  It
 181    interoperates with non-experimental DNSSEC using the technique
 182    described in [6].  This experiment is identified with the following
 183    private algorithms (using algorithm 253):
 184
 185    "3.optin.verisignlabs.com": is an alias for DNSSEC algorithm 3, DSA,
 186       and
 187    "5.optin.verisignlabs.com": is an alias for DNSSEC algorithm 5,
 188       RSASHA1.
 189
 190    Servers wishing to sign and serve zones that utilize Opt-In MUST sign
 191    the zone with only one or more of these private algorithms.  This
 192    requires the signing tools and servers to support private algorithms,
 193    as well as Opt-In.
 194
 195    Resolvers wishing to validate Opt-In zones MUST only do so when the
 196    zone is only signed using one or more of these private algorithms.
 197
 198    The remainder of this document assumes that the servers and resolvers
 199    involved are aware of and are involved in this experiment.
 200
 201 4.  Protocol Additions
 202
 203    In DNSSEC, delegation NS RRsets are not signed, but are instead
 204    accompanied by a NSEC RRset of the same name and (possibly) a DS
 205    record.  The security status of the subzone is determined by the
 206    presence or absence of the DS RRset, cryptographically proven by the
 207    NSEC record.  Opt-In expands this definition by allowing insecure
 208    delegations to exist within an otherwise signed zone without the
 209    corresponding NSEC record at the delegation's owner name.  These
 210    insecure delegations are proven insecure by using a covering NSEC
 211    record.
 212
 213    Since this represents a change of the interpretation of NSEC records,
 214    resolvers must be able to distinguish between RFC standard DNSSEC
 215    NSEC records and Opt-In NSEC records.  This is accomplished by
 216    "tagging" the NSEC records that cover (or potentially cover) insecure
 217    delegation nodes.  This tag is indicated by the absence of the NSEC
 218    bit in the type map.  Since the NSEC bit in the type map merely
 219    indicates the existence of the record itself, this bit is redundant
 220
 221
 222
 223 Arends, et al.          Expires January 19, 2006                [Page 4]
 224 \f
 225 Internet-Draft                DNSSEC Opt-In                    July 2005
 226
 227
 228    and safe for use as a tag.
 229
 230    An Opt-In tagged NSEC record does not assert the (non)existence of
 231    the delegations that it covers (except for a delegation with the same
 232    name).  This allows for the addition or removal of these delegations
 233    without recalculating or resigning records in the NSEC chain.
 234    However, Opt-In tagged NSEC records do assert the (non)existence of
 235    other RRsets.
 236
 237    An Opt-In NSEC record MAY have the same name as an insecure
 238    delegation.  In this case, the delegation is proven insecure by the
 239    lack of a DS bit in type map and the signed NSEC record does assert
 240    the existence of the delegation.
 241
 242    Zones using Opt-In MAY contain a mixture of Opt-In tagged NSEC
 243    records and standard DNSSEC NSEC records.  If a NSEC record is not
 244    Opt-In, there MUST NOT be any insecure delegations (or any other
 245    records) between it and the RRsets indicated by the 'next domain
 246    name' in the NSEC RDATA.  If it is Opt-In, there MUST only be
 247    insecure delegations between it and the next node indicated by the
 248    'next domain name' in the NSEC RDATA.
 249
 250    In summary,
 251
 252    o  An Opt-In NSEC type is identified by a zero-valued (or not-
 253       specified) NSEC bit in the type bit map of the NSEC record.
 254    o  A RFC2535bis NSEC type is identified by a one-valued NSEC bit in
 255       the type bit map of the NSEC record.
 256
 257    and,
 258
 259    o  An Opt-In NSEC record does not assert the non-existence of a name
 260       between its owner name and "next" name, although it does assert
 261       that any name in this span MUST be an insecure delegation.
 262    o  An Opt-In NSEC record does assert the (non)existence of RRsets
 263       with the same owner name.
 264
 265 4.1  Server Considerations
 266
 267    Opt-In imposes some new requirements on authoritative DNS servers.
 268
 269 4.1.1  Delegations Only
 270
 271    This specification dictates that only insecure delegations may exist
 272    between the owner and "next" names of an Opt-In tagged NSEC record.
 273    Signing tools SHOULD NOT generate signed zones that violate this
 274    restriction.  Servers SHOULD refuse to load and/or serve zones that
 275    violate this restriction.  Servers also SHOULD reject AXFR or IXFR
 276
 277
 278
 279 Arends, et al.          Expires January 19, 2006                [Page 5]
 280 \f
 281 Internet-Draft                DNSSEC Opt-In                    July 2005
 282
 283
 284    responses that violate this restriction.
 285
 286 4.1.2  Insecure Delegation Responses
 287
 288    When returning an Opt-In insecure delegation, the server MUST return
 289    the covering NSEC RRset in the Authority section.
 290
 291    In standard DNSSEC, NSEC records already must be returned along with
 292    the insecure delegation.  The primary difference that this proposal
 293    introduces is that the Opt-In tagged NSEC record will have a
 294    different owner name from the delegation RRset.  This may require
 295    implementations to search for the covering NSEC RRset.
 296
 297 4.1.3  Wildcards and Opt-In
 298
 299    Standard DNSSEC describes the practice of returning NSEC records to
 300    prove the non-existence of an applicable wildcard in non-existent
 301    name responses.  This NSEC record can be described as a "negative
 302    wildcard proof".  The use of Opt-In NSEC records changes the
 303    necessity for this practice.  For non-existent name responses when
 304    the query name (qname) is covered by an Opt-In tagged NSEC record,
 305    servers MAY choose to omit the wildcard proof record, and clients
 306    MUST NOT treat the absence of this NSEC record as a validation error.
 307
 308    The intent of the standard DNSSEC negative wildcard proof requirement
 309    is to prevent malicious users from undetectably removing valid
 310    wildcard responses.  In order for this cryptographic proof to work,
 311    the resolver must be able to prove:
 312
 313    1.  The exact qname does not exist.  This is done by the "normal"
 314        NSEC record.
 315    2.  No applicable wildcard exists.  This is done by returning a NSEC
 316        record proving that the wildcard does not exist (this is the
 317        negative wildcard proof).
 318
 319    However, if the NSEC record covering the exact qname is an Opt-In
 320    NSEC record, the resolver will not be able to prove the first part of
 321    this equation, as the qname might exist as an insecure delegation.
 322    Thus, since the total proof cannot be completed, the negative
 323    wildcard proof NSEC record is not useful.
 324
 325    The negative wildcard proof is also not useful when returned as part
 326    of an Opt-In insecure delegation response for a similar reason: the
 327    resolver cannot prove that the qname does or does not exist, and
 328    therefore cannot prove that a wildcard expansion is valid.
 329
 330    The presence of an Opt-In tagged NSEC record does not change the
 331    practice of returning a NSEC along with a wildcard expansion.  Even
 332
 333
 334
 335 Arends, et al.          Expires January 19, 2006                [Page 6]
 336 \f
 337 Internet-Draft                DNSSEC Opt-In                    July 2005
 338
 339
 340    though the Opt-In NSEC will not be able to prove that the wildcard
 341    expansion is valid, it will prove that the wildcard expansion is not
 342    masking any signed records.
 343
 344 4.1.4  Dynamic Update
 345
 346    Opt-In changes the semantics of Secure DNS Dynamic Update [9].  In
 347    particular, it introduces the need for rules that describe when to
 348    add or remove a delegation name from the NSEC chain.  This document
 349    does not attempt to define these rules.  Until these rules are
 350    defined, servers MUST NOT process DNS Dynamic Update requests against
 351    zones that use Opt-In NSEC records.  Servers SHOULD return responses
 352    to update requests with RCODE=REFUSED.
 353
 354 4.2  Client Considerations
 355
 356    Opt-In imposes some new requirements on security-aware resolvers
 357    (caching or otherwise).
 358
 359 4.2.1  Delegations Only
 360
 361    As stated in the "Server Considerations" section above, this
 362    specification restricts the namespace covered by Opt-In tagged NSEC
 363    records to insecure delegations only.  Thus, resolvers MUST reject as
 364    invalid any records that fall within an Opt-In NSEC record's span
 365    that are not NS records or corresponding glue records.
 366
 367 4.2.2  Validation Process Changes
 368
 369    This specification does not change the resolver's resolution
 370    algorithm.  However, it does change the DNSSEC validation process.
 371    Resolvers MUST be able to use Opt-In tagged NSEC records to
 372    cryptographically prove the validity and security status (as
 373    insecure) of a referral.  Resolvers determine the security status of
 374    the referred-to zone as follows:
 375
 376    o  In standard DNSSEC, the security status is proven by the existence
 377       or absence of a DS RRset at the same name as the delegation.  The
 378       existence of the DS RRset indicates that the referred-to zone is
 379       signed.  The absence of the DS RRset is proven using a verified
 380       NSEC record of the same name that does not have the DS bit set in
 381       the type map.  This NSEC record MAY also be tagged as Opt-In.
 382    o  Using Opt-In, the security status is proven by the existence of a
 383       DS record (for signed) or the presence of a verified Opt-In tagged
 384       NSEC record that covers the delegation name.  That is, the NSEC
 385       record does not have the NSEC bit set in the type map, and the
 386       delegation name falls between the NSEC's owner and "next" name.
 387
 388
 389
 390
 391 Arends, et al.          Expires January 19, 2006                [Page 7]
 392 \f
 393 Internet-Draft                DNSSEC Opt-In                    July 2005
 394
 395
 396    Using Opt-In does not substantially change the nature of following
 397    referrals within DNSSEC.  At every delegation point, the resolver
 398    will have cryptographic proof that the referred-to subzone is signed
 399    or unsigned.
 400
 401    When receiving either an Opt-In insecure delegation response or a
 402    non-existent name response where that name is covered by an Opt-In
 403    tagged NSEC record, the resolver MUST NOT require proof (in the form
 404    of a NSEC record) that a wildcard did not exist.
 405
 406 4.2.3  NSEC Record Caching
 407
 408    Caching resolvers MUST be able to retrieve the appropriate covering
 409    Opt-In NSEC record when returning referrals that need them.  This
 410    requirement differs from standard DNSSEC in that the covering NSEC
 411    will not have the same owner name as the delegation.  Some
 412    implementations may have to use new methods for finding these NSEC
 413    records.
 414
 415 4.2.4  Use of the AD bit
 416
 417    The AD bit, as defined by [2] and [5], MUST NOT be set when:
 418
 419    o  sending a Name Error (RCODE=3) response where the covering NSEC is
 420       tagged as Opt-In.
 421    o  sending an Opt-In insecure delegation response, unless the
 422       covering (Opt-In) NSEC record's owner name equals the delegation
 423       name.
 424
 425    This rule is based on what the Opt-In NSEC record actually proves:
 426    for names that exist between the Opt-In NSEC record's owner and
 427    "next" names, the Opt-In NSEC record cannot prove the non-existence
 428    or existence of the name.  As such, not all data in the response has
 429    been cryptographically verified, so the AD bit cannot be set.
 430
 431 5.  Benefits
 432
 433    Using Opt-In allows administrators of large and/or changing
 434    delegation-centric zones to minimize the overhead involved in
 435    maintaining the security of the zone.
 436
 437    Opt-In accomplishes this by eliminating the need for NSEC records for
 438    insecure delegations.  This, in a zone with a large number of
 439    delegations to unsigned subzones, can lead to substantial space
 440    savings (both in memory and on disk).  Additionally, Opt-In allows
 441    for the addition or removal of insecure delegations without modifying
 442    the NSEC record chain.  Zones that are frequently updating insecure
 443    delegations (e.g., TLDs) can avoid the substantial overhead of
 444
 445
 446
 447 Arends, et al.          Expires January 19, 2006                [Page 8]
 448 \f
 449 Internet-Draft                DNSSEC Opt-In                    July 2005
 450
 451
 452    modifying and resigning the affected NSEC records.
 453
 454 6.  Example
 455
 456    Consider the zone EXAMPLE, shown below.  This is a zone where all of
 457    the NSEC records are tagged as Opt-In.
 458
 459    Example A: Fully Opt-In Zone.
 460
 461          EXAMPLE.               SOA    ...
 462          EXAMPLE.               RRSIG  SOA ...
 463          EXAMPLE.               NS     FIRST-SECURE.EXAMPLE.
 464          EXAMPLE.               RRSIG  NS ...
 465          EXAMPLE.               DNSKEY ...
 466          EXAMPLE.               RRSIG  DNSKEY ...
 467          EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (
 468                                        SOA NS RRSIG DNSKEY )
 469          EXAMPLE.               RRSIG  NSEC ...
 470
 471          FIRST-SECURE.EXAMPLE.  A      ...
 472          FIRST-SECURE.EXAMPLE.  RRSIG  A ...
 473          FIRST-SECURE.EXAMPLE.  NSEC   NOT-SECURE-2.EXAMPLE. A RRSIG
 474          FIRST-SECURE.EXAMPLE.  RRSIG  NSEC ...
 475
 476          NOT-SECURE.EXAMPLE.    NS     NS.NOT-SECURE.EXAMPLE.
 477          NS.NOT-SECURE.EXAMPLE. A      ...
 478
 479          NOT-SECURE-2.EXAMPLE.  NS     NS.NOT-SECURE.EXAMPLE.
 480          NOT-SECURE-2.EXAMPLE   NSEC   SECOND-SECURE.EXAMPLE NS RRSIG
 481          NOT-SECURE-2.EXAMPLE   RRSIG  NSEC ...
 482
 483          SECOND-SECURE.EXAMPLE. NS     NS.ELSEWHERE.
 484          SECOND-SECURE.EXAMPLE. DS     ...
 485          SECOND-SECURE.EXAMPLE. RRSIG  DS ...
 486          SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DNSKEY
 487          SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
 488
 489          UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE.
 490          NS.UNSIGNED.EXAMPLE.   A      ...
 491
 492
 493    In this example, a query for a signed RRset (e.g., "FIRST-
 494    SECURE.EXAMPLE A"), or a secure delegation ("WWW.SECOND-
 495    SECURE.EXAMPLE A") will result in a standard DNSSEC response.
 496
 497    A query for a nonexistent RRset will result in a response that
 498    differs from standard DNSSEC by: the NSEC record will be tagged as
 499    Opt-In, there may be no NSEC record proving the non-existence of a
 500
 501
 502
 503 Arends, et al.          Expires January 19, 2006                [Page 9]
 504 \f
 505 Internet-Draft                DNSSEC Opt-In                    July 2005
 506
 507
 508    matching wildcard record, and the AD bit will not be set.
 509
 510    A query for an insecure delegation RRset (or a referral) will return
 511    both the answer (in the Authority section) and the corresponding
 512    Opt-In NSEC record to prove that it is not secure.
 513
 514    Example A.1: Response to query for WWW.UNSIGNED.EXAMPLE.  A
 515
 516
 517          RCODE=NOERROR, AD=0
 518
 519          Answer Section:
 520
 521          Authority Section:
 522          UNSIGNED.EXAMPLE.      NS     NS.UNSIGNED.EXAMPLE
 523          SECOND-SECURE.EXAMPLE. NSEC   EXAMPLE. NS RRSIG DS
 524          SECOND-SECURE.EXAMPLE. RRSIG  NSEC ...
 525
 526          Additional Section:
 527          NS.UNSIGNED.EXAMPLE.   A      ...
 528
 529    In the Example A.1 zone, the EXAMPLE. node MAY use either style of
 530    NSEC record, because there are no insecure delegations that occur
 531    between it and the next node, FIRST-SECURE.EXAMPLE.  In other words,
 532    Example A would still be a valid zone if the NSEC record for EXAMPLE.
 533    was changed to the following RR:
 534
 535          EXAMPLE.               NSEC   FIRST-SECURE.EXAMPLE. (SOA NS
 536                                        RRSIG DNSKEY NSEC )
 537
 538    However, the other NSEC records (FIRST-SECURE.EXAMPLE. and SECOND-
 539    SECURE.EXAMPLE.)  MUST be tagged as Opt-In because there are insecure
 540    delegations in the range they define.  (NOT-SECURE.EXAMPLE. and
 541    UNSIGNED.EXAMPLE., respectively).
 542
 543    NOT-SECURE-2.EXAMPLE. is an example of an insecure delegation that is
 544    part of the NSEC chain and also covered by an Opt-In tagged NSEC
 545    record.  Because NOT-SECURE-2.EXAMPLE. is a signed name, it cannot be
 546    removed from the zone without modifying and resigning the prior NSEC
 547    record.  Delegations with names that fall between NOT-SECURE-
 548    2.EXAMPLE. and SECOND-SECURE.EXAMPLE. may be added or removed without
 549    resigning any NSEC records.
 550
 551 7.  Transition Issues
 552
 553    Opt-In is not backwards compatible with standard DNSSEC and is
 554    considered experimental.  Standard DNSSEC compliant implementations
 555    would not recognize Opt-In tagged NSEC records as different from
 556
 557
 558
 559 Arends, et al.          Expires January 19, 2006               [Page 10]
 560 \f
 561 Internet-Draft                DNSSEC Opt-In                    July 2005
 562
 563
 564    standard NSEC records.  Because of this, standard DNSSEC
 565    implementations, if they were to validate Opt-In style responses,
 566    would reject all Opt-In insecure delegations within a zone as
 567    invalid.  However, by only signing with private algorithms, standard
 568    DNSSEC implementations will treat Opt-In responses as unsigned.
 569
 570    It should be noted that all elements in the resolution path between
 571    (and including) the validator and the authoritative name server must
 572    be aware of the Opt-In experiment and implement the Opt-In semantics
 573    for successful validation to be possible.  In particular, this
 574    includes any caching middleboxes between the validator and
 575    authoritative name server.
 576
 577 8.  Security Considerations
 578
 579    Opt-In allows for unsigned names, in the form of delegations to
 580    unsigned subzones, to exist within an otherwise signed zone.  All
 581    unsigned names are, by definition, insecure, and their validity or
 582    existence cannot by cryptographically proven.
 583
 584    In general:
 585
 586    o  Records with unsigned names (whether existing or not) suffer from
 587       the same vulnerabilities as records in an unsigned zone.  These
 588       vulnerabilities are described in more detail in [12] (note in
 589       particular sections 2.3, "Name Games" and 2.6, "Authenticated
 590       Denial").
 591    o  Records with signed names have the same security whether or not
 592       Opt-In is used.
 593
 594    Note that with or without Opt-In, an insecure delegation may have its
 595    contents undetectably altered by an attacker.  Because of this, the
 596    primary difference in security that Opt-In introduces is the loss of
 597    the ability to prove the existence or nonexistence of an insecure
 598    delegation within the span of an Opt-In NSEC record.
 599
 600    In particular, this means that a malicious entity may be able to
 601    insert or delete records with unsigned names.  These records are
 602    normally NS records, but this also includes signed wildcard
 603    expansions (while the wildcard record itself is signed, its expanded
 604    name is an unsigned name).
 605
 606    For example, if a resolver received the following response from the
 607    example zone above:
 608
 609
 610
 611
 612
 613
 614
 615 Arends, et al.          Expires January 19, 2006               [Page 11]
 616 \f
 617 Internet-Draft                DNSSEC Opt-In                    July 2005
 618
 619
 620    Example S.1: Response to query for WWW.DOES-NOT-EXIST.EXAMPLE.  A
 621
 622          RCODE=NOERROR
 623
 624          Answer Section:
 625
 626          Authority Section:
 627          DOES-NOT-EXIST.EXAMPLE. NS     NS.FORGED.
 628          EXAMPLE.                NSEC   FIRST-SECURE.EXAMPLE. SOA NS \
 629                                         RRSIG DNSKEY
 630          EXAMPLE.                RRSIG  NSEC ...
 631
 632          Additional Section:
 633
 634
 635    The resolver would have no choice but to believe that the referral to
 636    NS.FORGED. is valid.  If a wildcard existed that would have been
 637    expanded to cover "WWW.DOES-NOT-EXIST.EXAMPLE.", an attacker could
 638    have undetectably removed it and replaced it with the forged
 639    delegation.
 640
 641    Note that being able to add a delegation is functionally equivalent
 642    to being able to add any record type: an attacker merely has to forge
 643    a delegation to nameserver under his/her control and place whatever
 644    records needed at the subzone apex.
 645
 646    While in particular cases, this issue may not present a significant
 647    security problem, in general it should not be lightly dismissed.
 648    Therefore, it is strongly RECOMMENDED that Opt-In be used sparingly.
 649    In particular, zone signing tools SHOULD NOT default to Opt-In, and
 650    MAY choose to not support Opt-In at all.
 651
 652 9.  IANA Considerations
 653
 654    None.
 655
 656 10.  Acknowledgments
 657
 658    The contributions, suggestions and remarks of the following persons
 659    (in alphabetic order) to this draft are acknowledged:
 660
 661       Mats Dufberg, Miek Gieben, Olafur Gudmundsson, Bob Halley, Olaf
 662       Kolkman, Edward Lewis, Ted Lindgreen, Rip Loomis, Bill Manning,
 663       Dan Massey, Scott Rose, Mike Schiraldi, Jakob Schlyter, Brian
 664       Wellington.
 665
 666 11.  References
 667
 668
 669
 670
 671 Arends, et al.          Expires January 19, 2006               [Page 12]
 672 \f
 673 Internet-Draft                DNSSEC Opt-In                    July 2005
 674
 675
 676 11.1  Normative References
 677
 678    [1]  Mockapetris, P., "Domain names - implementation and
 679         specification", STD 13, RFC 1035, November 1987.
 680
 681    [2]  Wellington, B. and O. Gudmundsson, "Redefinition of DNS
 682         Authenticated Data (AD) bit", RFC 3655, November 2003.
 683
 684    [3]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
 685         "DNS Security Introduction and Requirements", RFC 4033,
 686         March 2005.
 687
 688    [4]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
 689         "Resource Records for the DNS Security Extensions", RFC 4034,
 690         March 2005.
 691
 692    [5]  Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose,
 693         "Protocol Modifications for the DNS Security Extensions",
 694         RFC 4035, March 2005.
 695
 696    [6]  Blacka, D., "DNSSEC Experiments",
 697         draft-ietf-dnsext-dnssec-experiments-01 (work in progress),
 698         July 2005.
 699
 700 11.2  Informative References
 701
 702    [7]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
 703          Levels", BCP 14, RFC 2119, March 1997.
 704
 705    [8]   Elz, R. and R. Bush, "Clarifications to the DNS Specification",
 706          RFC 2181, July 1997.
 707
 708    [9]   Eastlake, D., "Secure Domain Name System Dynamic Update",
 709          RFC 2137, April 1997.
 710
 711    [10]  Lewis, E., "DNS Security Extension Clarification on Zone
 712          Status", RFC 3090, March 2001.
 713
 714    [11]  Conrad, D., "Indicating Resolver Support of DNSSEC", RFC 3225,
 715          December 2001.
 716
 717    [12]  Atkins, D. and R. Austein, "Threat Analysis of the Domain Name
 718          System (DNS)", RFC 3833, August 2004.
 719
 720
 721
 722
 723
 724
 725
 726
 727 Arends, et al.          Expires January 19, 2006               [Page 13]
 728 \f
 729 Internet-Draft                DNSSEC Opt-In                    July 2005
 730
 731
 732 Authors' Addresses
 733
 734    Roy Arends
 735    Telematica Instituut
 736    Drienerlolaan 5
 737    7522 NB  Enschede
 738    NL
 739
 740    Email: roy.arends@telin.nl
 741
 742
 743    Mark Kosters
 744    Verisign, Inc.
 745    21355 Ridgetop Circle
 746    Dulles, VA  20166
 747    US
 748
 749    Phone: +1 703 948 3200
 750    Email: markk@verisign.com
 751    URI:   http://www.verisignlabs.com
 752
 753
 754    David Blacka
 755    Verisign, Inc.
 756    21355 Ridgetop Circle
 757    Dulles, VA  20166
 758    US
 759
 760    Phone: +1 703 948 3200
 761    Email: davidb@verisign.com
 762    URI:   http://www.verisignlabs.com
 763
 764 Appendix A.  Implementing Opt-In using "Views"
 765
 766    In many cases, it may be convenient to implement an Opt-In zone by
 767    combining two separately maintained "views" of a zone at request
 768    time.  In this context, "view" refers to a particular version of a
 769    zone, not to any specific DNS implementation feature.
 770
 771    In this scenario, one view is the secure view, the other is the
 772    insecure (or legacy) view.  The secure view consists of an entirely
 773    signed zone using Opt-In tagged NSEC records.  The insecure view
 774    contains no DNSSEC information.  It is helpful, although not
 775    necessary, for the secure view to be a subset (minus DNSSEC records)
 776    of the insecure view.
 777
 778    In addition, the only RRsets that may solely exist in the insecure
 779    view are non-zone-apex NS RRsets.  That is, all non-NS RRsets (and
 780
 781
 782
 783 Arends, et al.          Expires January 19, 2006               [Page 14]
 784 \f
 785 Internet-Draft                DNSSEC Opt-In                    July 2005
 786
 787
 788    the zone apex NS RRset) MUST be signed and in the secure view.
 789
 790    These two views may be combined at request time to provide a virtual,
 791    single Opt-In zone.  The following algorithm is used when responding
 792    to each query:
 793       V_A is the secure view as described above.
 794       V_B is the insecure view as described above.
 795       R_A is a response generated from V_A, following RFC 2535bis.
 796       R_B is a response generated from V_B, following DNS resolution as
 797       per RFC 1035 [1].
 798       R_C is the response generated by combining R_A with R_B, as
 799       described below.
 800       A query is DNSSEC-aware if it either has the DO bit [11] turned
 801       on, or is for a DNSSEC-specific record type.
 802
 803
 804
 805    1.  If V_A is a subset of V_B and the query is not DNSSEC-aware,
 806        generate and return R_B, otherwise
 807    2.  Generate R_A.
 808    3.  If R_A's RCODE != NXDOMAIN, return R_A, otherwise
 809    4.  Generate R_B and combine it with R_A to form R_C:
 810           For each section (ANSWER, AUTHORITY, ADDITIONAL), copy the
 811           records from R_A into R_B, EXCEPT the AUTHORITY section SOA
 812           record, if R_B's RCODE = NOERROR.
 813    5.  Return R_C.
 814
 815
 816
 817
 818
 819
 820
 821
 822
 823
 824
 825
 826
 827
 828
 829
 830
 831
 832
 833
 834
 835
 836
 837
 838
 839 Arends, et al.          Expires January 19, 2006               [Page 15]
 840 \f
 841 Internet-Draft                DNSSEC Opt-In                    July 2005
 842
 843
 844 Intellectual Property Statement
 845
 846    The IETF takes no position regarding the validity or scope of any
 847    Intellectual Property Rights or other rights that might be claimed to
 848    pertain to the implementation or use of the technology described in
 849    this document or the extent to which any license under such rights
 850    might or might not be available; nor does it represent that it has
 851    made any independent effort to identify any such rights.  Information
 852    on the procedures with respect to rights in RFC documents can be
 853    found in BCP 78 and BCP 79.
 854
 855    Copies of IPR disclosures made to the IETF Secretariat and any
 856    assurances of licenses to be made available, or the result of an
 857    attempt made to obtain a general license or permission for the use of
 858    such proprietary rights by implementers or users of this
 859    specification can be obtained from the IETF on-line IPR repository at
 860    http://www.ietf.org/ipr.
 861
 862    The IETF invites any interested party to bring to its attention any
 863    copyrights, patents or patent applications, or other proprietary
 864    rights that may cover technology that may be required to implement
 865    this standard.  Please address the information to the IETF at
 866    ietf-ipr@ietf.org.
 867
 868
 869 Disclaimer of Validity
 870
 871    This document and the information contained herein are provided on an
 872    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 873    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 874    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 875    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 876    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 877    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 878
 879
 880 Copyright Statement
 881
 882    Copyright (C) The Internet Society (2005).  This document is subject
 883    to the rights, licenses and restrictions contained in BCP 78, and
 884    except as set forth therein, the authors retain all their rights.
 885
 886
 887 Acknowledgment
 888
 889    Funding for the RFC Editor function is currently provided by the
 890    Internet Society.
 891
 892
 893
 894
 895 Arends, et al.          Expires January 19, 2006               [Page 16]
 896 \f