idnits 2.17.00 (12 Aug 2021) /tmp/idnits40212/draft-schwartz-ds-glue-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (19 August 2021) is 268 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RDATAs' is mentioned on line 275, but not defined == Outdated reference: A later version (-02) exists of draft-ietf-dnsop-ns-revalidation-01 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive B. Schwartz 3 Internet-Draft Google LLC 4 Intended status: Standards Track 19 August 2021 5 Expires: 20 February 2022 7 Authenticated delegation information using DS records 8 draft-schwartz-ds-glue-02 10 Abstract 12 This draft describes a mechanism for conveying arbitrary 13 authenticated DNS data from a parent nameserver to a recursive 14 resolver as part of a delegation response. 16 Discussion Venues 18 This note is to be removed before publishing as an RFC. 20 Discussion of this document takes place on the mailing list 21 (ds@ietf.org), which is archived at 22 https://mailarchive.ietf.org/arch/browse/ds/. 24 Source for this draft and an issue tracker can be found at 25 https://github.com/bemasc/ds-glue. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on 20 February 2022. 44 Copyright Notice 46 Copyright (c) 2021 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 51 license-info) in effect on the date of publication of this document. 52 Please review these documents carefully, as they describe your rights 53 and restrictions with respect to this document. Code Components 54 extracted from this document must include Simplified BSD License text 55 as described in Section 4.e of the Trust Legal Provisions and are 56 provided without warranty as described in the Simplified BSD License. 58 Table of Contents 60 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 61 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Obstacle 1: Authentication . . . . . . . . . . . . . . . 3 63 2.2. Obstacle 2: Flexibility . . . . . . . . . . . . . . . . . 3 64 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.2. Interpretation . . . . . . . . . . . . . . . . . . . . . 5 67 3.3. Allowed RR types . . . . . . . . . . . . . . . . . . . . 6 68 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4.1. Out-of-bailiwick referral . . . . . . . . . . . . . . . . 6 70 4.2. In-bailiwick referral . . . . . . . . . . . . . . . . . . 7 71 4.3. In-bailiwick referral without IPv4 . . . . . . . . . . . 7 72 4.4. Delegation with authenticated encryption . . . . . . . . 8 73 4.4.1. Disabling DANE . . . . . . . . . . . . . . . . . . . 8 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 75 6. Operational Considerations . . . . . . . . . . . . . . . . . 8 76 6.1. Compatibility with existing resolvers . . . . . . . . . . 8 77 6.2. Publishing DSGLUE records . . . . . . . . . . . . . . . . 9 78 6.3. Referral response size . . . . . . . . . . . . . . . . . 9 79 6.4. PKI and DANE for Authenticated Encryption . . . . . . . . 9 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 83 8.2. Informative References . . . . . . . . . . . . . . . . . 11 84 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 87 1. Conventions and Definitions 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 91 "OPTIONAL" in this document are to be interpreted as described in 92 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 93 capitals, as shown here. 95 2. Background 97 The DPRIVE working group has been pursuing designs for authenticated 98 encryption of recursive-to-authoritative communication. Recursive 99 resolvers could enable authenticated encryption most easily and 100 efficiently if they received authenticated information about the 101 target nameserver's configuration during the in-bailiwick delegation 102 that precedes the direct connection. However, there are several 103 obstacles to this. 105 2.1. Obstacle 1: Authentication 107 Glue records in DNS referral responses are unauthenticated. Parents 108 do not generally provide RRSIGs for these records in their responses, 109 and resolvers do not expect such signatures to be present. An in- 110 path attacker can modify or remove records in the delegation response 111 without detection. 113 If the parent zone also implements authenticated encryption, this 114 provides sufficient protection for the glue records, but many 115 important parent zones seem unlikely to implement authenticated 116 encryption in the near future. 118 2.2. Obstacle 2: Flexibility 120 Existing nameserver deployments assume that the delegation response 121 includes only a fixed set of existing RR types (NS, A, AAAA, DS, 122 RRSIG, etc.). These systems are slow to upgrade, and the working 123 group would like to be able to begin deploying authenticated 124 encryption without first requiring a significant change in these 125 parents. 127 3. Proposal 129 This draft proposes a way to convey a glue RRSet inside a DS record, 130 enabling authenticated delivery of arbitrary RR types as part of the 131 delegation response. 133 There are three main records or RRSets involved in this process: 135 * A Source RRSet to be conveyed, which may be of any RR type and 136 anywhere below the zone cut. 138 * A Virtual DNSKEY Record encapsulating the Source RRSet. 140 * The DSGLUE Record, a DS record derived from the Virtual DNSKEY 141 Record and published in the parent. 143 3.1. Encoding 145 To encode a Source RRSet, a zone operator first transforms it into a 146 Virtual DNSKEY Record as follows: 148 * Owner Name = The Owner Name of the Source RRSet relative to the 149 child zone apex. 151 * Flags = 0x0001, i.e. only SEP (bit 15) is set. 153 * Protocol = 3 155 * Algorithm = DS Glue (see IANA registration in Section 7) 157 * Public Key = The following fields, concatenated 159 - The RR type (uint16) 161 - The RRSet TTL (uint32) 163 - For each Source Record in canonical order ([RFC4034], 164 Section 6.3), 166 o A length prefix (uint16) 168 o The canonicalized RDATA ([RFC4034], Section 6.2). 170 For example, this Source RRSet: 172 $ORIGIN example.com. 173 @ 3600 IN NS ns1 174 IN NS ns2 175 IN NS NS.OTHER.EXAMPLE. 177 would be represented as the following Virtual DNSKEY Record: 179 ; Public Key = 180 ; \000\002 ; Type = NS 181 ; \000\000\014\016 ; TTL=3600 182 ; \000\018 \002ns\005other\007example\000 ; Len=18, ns.other.example. 183 ; \000\017 \003ns1\007example\003com\000 ; Len=17, ns1.example.com. 184 ; \000\017 \003ns2\007example\003com\000 ; Len=17, ns2.example.com. 186 . 300 IN DNSKEY 1 3 $DSGLUE_NUM ( AAIAAA4QABICbnMFb3RoZXIHZXhhbXBsZ 187 QAAEQNuczEHZXhhbXBsZQNjb20AABEDbnMyB2V4YW1wbGUDY29tAA== ) 189 Note that: 191 * The NS Source Records are "real" records that appear in 192 authoritative Answers and/or delegation glue, but the DNSKEY 193 record is a "virtual record" because it does not appear in any 194 zone or response (in this form). 196 * The Virtual DNSKEY Record's owner name is "." because the Source 197 RRSet appears at the zone apex. 199 * The NS RDATA has been reordered and converted to lowercase as 200 specified by the canonicalization algorithm. 202 Having constructed a Virtual DNSKEY Record, the DSGLUE Record is 203 constructed as usual, but always using the VERBATIM digest type 204 [I-D.draft-vandijk-dnsop-ds-digest-verbatim]. Thus, the DSGLUE 205 Record's wire format RDATA forms the following concatenation: 207 Key Tag | Algorithm = DSGLUE | Digest Type = VERBATIM | Digest = ( 208 DNSKEY owner name = name prefix | DNSKEY RDATA = ( 209 Flags = 1 | Protocol = 3 | Algorithm = DSGLUE | Public Key = ( 210 RR Type | TTL | Len(1) | RDATA(1) | Len(2) | RDATA(2) | ... 211 ) 212 ) 213 ) 215 The DSGLUE record is a real DS record that appears in the usual DS 216 RRSet, whose owner name is the child apex. 218 QUESTION: Should we skip the virtual DNSKEY record, and construct 219 the fake DS directly? This would save 4-6 bytes per RRSet, but 220 would lose the ability to reuse DNSKEY->DS construction codepaths 221 (unchanged except for a new digest type). 223 3.2. Interpretation 225 Upon receiving a delegation response, resolvers implementing this 226 specification SHALL compute the Adjusted Delegation Response as 227 follows: 229 1. Copy the delegation response. 231 2. Reverse the encoding process of any DSGLUE records to reconstruct 232 the source RRSets. 234 3. Add each of these reconstructed RRSets to the Adjusted Delegation 235 Response, replacing any RRSet with the same owner name and type. 237 Note that a Source RRSet MAY be empty, indicating that there are no 238 records of the corresponding type at this name. After reconstructing 239 an empty Source RRSet, recipients MUST remove any matching RRSets 240 from the Adjusted Delegation Response and any glue cache, and MAY 241 cache the negative result for the indicated TTL. 243 Resolution then proceeds as usual, using the Adjusted Delegation 244 Response. When processing the DS RRSet, the recipient will verify 245 the DS RRSIGs as usual, and abort the resolution as Bogus if DNSSEC 246 validation fails. 248 Resolvers that do not implement this specification will ignore the 249 DSGLUE records due to the unrecognized algorithm. Thus, these 250 records are safe to use for both signed and unsigned child zones. 252 Source Records reconstructed from DSGLUE SHOULD be processed exactly 253 like ordinary unauthenticated glue records. For example, they MAY be 254 cached for use in future delegations but MUST NOT be returned in any 255 responses (c.f. Section 5.4.1 of [RFC2181]). 257 3.3. Allowed RR types 259 DSGLUE records are capable of containing any record type. However, 260 the meaning of certain record types (e.g. NSEC) is not yet clear in 261 the DSGLUE context. To avoid ambiguity, child zones MUST only 262 publish DSGLUE records containing RR types that have been registered 263 for use with DSGLUE (Section 7), and recipients MUST ignore DSGLUE 264 records indicating unexpected record types. 266 Recipients implementing this specification MUST accept the NS, A, and 267 AAAA RR types in DSGLUE. Support for the other allowed RR types is 268 OPTIONAL. 270 Recipients MUST ignore any unauthenticated TLSA records. 272 4. Examples 274 For these examples, the macro "$DSGLUE(prefix, RR type, TTL, 275 [RDATAs])" constructs a DSGLUE DS record as described in Section 3.1. 277 4.1. Out-of-bailiwick referral 279 An out-of-bailiwick referral contains only NS records, e.g. 281 $ORIGIN com. 282 example 3600 IN NS ns1.example.net. 283 IN NS ns2.example.net. 285 These Source Records would be encoded in DSGLUE as: 287 $ORIGIN com. 288 example 3600 IN DS $DSGLUE(., NS, 3600, 289 [ns1.example.net., ns2.example.net.]) 291 4.2. In-bailiwick referral 293 An in-bailiwick referral contains NS records and at least one kind of 294 address record. 296 $ORIGIN com. 297 example 3600 IN NS ns1.example 298 IN NS ns2.example 299 ns1.example 600 IN A 192.0.2.1 300 IN AAAA 2001:db8::1 301 ns2.example 600 IN A 192.0.2.2 302 IN AAAA 2001:db8::2 304 These records would be encoded in DSGLUE as: 306 $ORIGIN com. 307 example 600 IN DS $DSGLUE(., NS, 3600, [ns1.example.com., 308 ns2.example.com.]) 309 IN DS $DSGLUE(ns1., A, 600, [192.0.2.1]) 310 IN DS $DSGLUE(ns1., AAAA, 600, [2001:db8::1]) 311 IN DS $DSGLUE(ns2., A, 600, [192.0.2.1]) 312 IN DS $DSGLUE(ns2., AAAA, 600, [2001:db8::2]) 314 4.3. In-bailiwick referral without IPv4 316 Consider a delegation to a nameserver that is only reachable with 317 IPv6: 319 $ORIGIN com. 320 example 3600 IN NS ns1.example 321 ns1.example 600 IN AAAA 2001:db8::1 323 A zone in this configuration can optionally use an empty DSGLUE 324 record to indicate that there is no IPv4 address: 326 $ORIGIN com. 327 example 600 IN DS $DSGLUE(., NS, 3600, [ns1.example.com.]) 328 IN DS $DSGLUE(ns1., AAAA, 600, [2001:db8::1]) 329 IN DS $DSGLUE(ns1., A, 7200, []) 331 This arrangement prevents an adversary from inserting forged A 332 records for ns1.example.com into the delegation response. 334 Note that this negative answer is treated as glue that only applies 335 during delegation, so A records for ns1.example.com can still be 336 resolved if they exist. 338 4.4. Delegation with authenticated encryption 340 Assuming a SVCB-based signaling mechanism similar to 341 [I-D.draft-schwartz-svcb-dns], an in-bailiwick referral with support 342 for authenticated encryption is indicated as follows: 344 $ORIGIN com. 345 example 600 IN DS $DSGLUE(., NS, 3600, [ns1.example.com.]) 346 IN DS $DSGLUE(ns1., A, 600, [192.0.2.1]) 347 IN DS $DSGLUE(ns1., AAAA, 600, [2001:db8::1]) 348 IN DS $DSGLUE(_dns.ns1., SVCB, 3600, 349 [1 ns1.example.com. alpn=dot]) 351 4.4.1. Disabling DANE 353 Resolvers check whether a nameserver supports DANE by resolving a 354 TLSA record during the delegation process (Section 6.4). However, 355 this adds unnecessary latency to the delegation if the nameserver 356 does not implement DANE. As an optimization, such nameservers can 357 add an empty DSGLUE RRSet to indicate that there is no such TLSA 358 record, e.g.: 360 IN DS $DSGLUE(_853._tcp.ns1., TLSA, 7200, []) 362 5. Security Considerations 364 Resolvers that process DSGLUE MUST perform DNSSEC validation. 366 Source Records published as DSGLUE have owner names within the child 367 zone, but are signed only by the parent. This makes them fully 368 authenticated, but provides different cryptographic guarantees than a 369 direct signature by the child. For example, these records might not 370 appear in any key use logs maintained by the child. 372 6. Operational Considerations 374 6.1. Compatibility with existing resolvers 376 Resolver support for DSGLUE is OPTIONAL, so child zones MUST continue 377 to place ordinary NS, A, and AAAA records in the parent zone as 378 needed for non-DSGLUE resolution. 380 6.2. Publishing DSGLUE records 382 In order for the child to publish DSGLUE records, the parent must 383 allow the child to publish arbitrary DS records or have specific 384 support for this specification. 386 If the parent supports CDS [RFC8078], child zones MAY use CDS to push 387 DSGLUE records into the parent. Note that CDNSKEY records cannot be 388 used, because (1) the child cannot publish CDNSKEY records with the 389 required owner name and (2) the child cannot guarantee that the 390 parent will use the VERBATIM digest to produce the DS record. 392 Child zones SHOULD publish all Source Records as ordinary records of 393 the specified type at the indicated owner name, in order to enable 394 revalidation [I-D.draft-ietf-dnsop-ns-revalidation] and simplify 395 debugging. 397 6.3. Referral response size 399 When records are present in both ordinary glue and DSGLUE, the 400 response size is approximately doubled. This could cause performance 401 issues due to response truncation when the initial query is over UDP. 403 6.4. PKI and DANE for Authenticated Encryption 405 TODO: Move some of this text into a different draft. 407 Nameservers supporting authenticated encryption MAY indicate any DANE 408 mode, or none at all. 410 As an optimization, nameservers using DANE MAY place a TLSA record in 411 the DSGLUE to avoid the latency of a TLSA lookup during delegation. 412 However, child zones should be aware that this adds complexity and 413 delay to the process of TLSA key rotation. 415 QUESTION: Should we recommend for or against including nonempty 416 TLSA in DSGLUE? If CDS-like update mechanisms work well, and 417 ADoT-DANE is widely deployed, this could warrant a positive 418 recommendation. Conversely, if rotation is error-prone, and ADoT- 419 DANE is rare, a negative recommendation might be better. 421 Nameservers that support PKI-based authentication but not DANE SHOULD 422 deny the TLSA RRSet in the DSGLUE, as shown in Section 4.4.1, to 423 avoid an unnecessary delay. 425 Resolvers that support authenticated encryption MAY implement support 426 for PKI-based authentication, DANE, or both. PKI-only resolvers MUST 427 nonetheless resolve TLSA records, and MUST NOT require authentication 428 if the DANE mode is DANE-TA(2) or DANE-EE(3) [RFC7671]. DANE-only 429 resolvers MUST NOT require authentication if the TLSA record does not 430 exist. 432 7. IANA Considerations 434 IANA is requested to add a new entry to the DNS Security Algorithm 435 Numbers registry: 437 +=============+===============+==========+=======+======+===========+ 438 | Number | Description | Mnemonic |Zone |Trans.| Reference | 439 | | | |Signing|Sec. | | 440 +=============+===============+==========+=======+======+===========+ 441 | $DSGLUE_NUM | Authenticated | DSGLUE |N |? | (This | 442 | | Glue | | | | document) | 443 +-------------+---------------+----------+-------+------+-----------+ 445 Table 1 447 IANA is requested to open a new registry named "Authenticated Glue 448 Allowed Record Types", with a policy of "Standards Action" and the 449 following fields: 451 * Record Type: The name of a registered DNS record type 453 * Interpretation Reference: The standards document defining how to 454 interpret this RR type in the Authenticated Glue context. 456 The initial contents are as follows: 458 +=============+==========================+ 459 | Record Type | Interpretation Reference | 460 +=============+==========================+ 461 | NS | (This document) | 462 +-------------+--------------------------+ 463 | A | (This document) | 464 +-------------+--------------------------+ 465 | AAAA | (This document) | 466 +-------------+--------------------------+ 467 | SVCB | (This document) | 468 +-------------+--------------------------+ 469 | TLSA | (This document) | 470 +-------------+--------------------------+ 472 Table 2 474 8. References 475 8.1. Normative References 477 [I-D.draft-vandijk-dnsop-ds-digest-verbatim] 478 Dijk, P. V., "The VERBATIM Digest Algorithm for DS 479 records", Work in Progress, Internet-Draft, draft-vandijk- 480 dnsop-ds-digest-verbatim-01, 10 August 2021, 481 . 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, 486 DOI 10.17487/RFC2119, March 1997, 487 . 489 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 490 Rose, "Resource Records for the DNS Security Extensions", 491 RFC 4034, DOI 10.17487/RFC4034, March 2005, 492 . 494 [RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based 495 Authentication of Named Entities (DANE) Protocol: Updates 496 and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, 497 October 2015, . 499 [RFC8078] Gudmundsson, O. and P. Wouters, "Managing DS Records from 500 the Parent via CDS/CDNSKEY", RFC 8078, 501 DOI 10.17487/RFC8078, March 2017, 502 . 504 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 505 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 506 May 2017, . 508 8.2. Informative References 510 [I-D.draft-ietf-dnsop-ns-revalidation] 511 Huque, S., Vixie, P., and R. Dolmans, "Delegation 512 Revalidation by DNS Resolvers", Work in Progress, 513 Internet-Draft, draft-ietf-dnsop-ns-revalidation-01, 12 514 July 2021, . 517 [I-D.draft-schwartz-svcb-dns] 518 Schwartz, B., "Service Binding Mapping for DNS Servers", 519 Work in Progress, Internet-Draft, draft-schwartz-svcb-dns- 520 04, 26 July 2021, . 523 [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS 524 Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, 525 . 527 Acknowledgments 529 Thanks to Paul Hoffman, Ilari Liusvaara, Puneet Sood, and Alexandar 530 Mayrhofer for detailed comments. 532 Author's Address 534 Benjamin Schwartz 535 Google LLC 537 Email: bemasc@google.com