idnits 2.17.1 draft-schwartz-dprive-name-signal-00.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 (8 June 2021) is 1052 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-schwartz-svcb-dns-03 == Outdated reference: A later version (-04) exists of draft-ietf-dprive-unauth-to-authoritative-01 == Outdated reference: A later version (-01) exists of draft-vandijk-dnsop-ds-digest-verbatim-00 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive B. Schwartz 3 Internet-Draft W. Kumari 4 Intended status: Experimental Google LLC 5 Expires: 10 December 2021 8 June 2021 7 Nameserver Access Modes with Encryption Held in Alphanumeric 8 Configuration Keys 9 draft-schwartz-dprive-name-signal-00 11 Abstract 13 Some recent proposals to the DPRIVE working group rely on the use of 14 SVCB records to provide instructions about how to reach an 15 authoritative nameserver over an encrypted transport. These 16 proposals will be difficult to deploy until the parent domain's 17 delegation software has been modified to support these records. As 18 an interim solution for these domains, this draft proposes encoding 19 relevant signals in the child's NS-name. 21 Discussion Venues 23 This note is to be removed before publishing as an RFC. 25 Discussion of this document takes place on the mailing list (dns- 26 privacy@ietf.org), which is archived at 27 https://mailarchive.ietf.org/arch/browse/dns-privacy/. 29 Source for this draft and an issue tracker can be found at 30 https://github.com/wkumari/draft-schwartz-dprive-name-signal. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on 10 December 2021. 49 Copyright Notice 51 Copyright (c) 2021 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 56 license-info) in effect on the date of publication of this document. 57 Please review these documents carefully, as they describe your rights 58 and restrictions with respect to this document. Code Components 59 extracted from this document must include Simplified BSD License text 60 as described in Section 4.e of the Trust Legal Provisions and are 61 provided without warranty as described in the Simplified BSD License. 63 Table of Contents 65 1. Conventions and Definitions . . . . . . . . . . . . . . . . . 2 66 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Proposal . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Flag form . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Menu form . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.3. Implementation requirements . . . . . . . . . . . . . . . 5 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 5 72 5. Operational Considerations . . . . . . . . . . . . . . . . . 5 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 74 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 76 7.2. Informative References . . . . . . . . . . . . . . . . . 7 77 Appendix A. Comparison with related designs . . . . . . . . . . 8 78 A.1. Indicating DoT support with a name prefix . . . . . . . . 8 79 A.2. Encoding the SPKI pin in the leaf label . . . . . . . . . 8 80 A.3. Encoding the signal in an additional NS record . . . . . 8 81 A.4. Extending the DS record . . . . . . . . . . . . . . . . . 9 82 A.5. Enabling authentication of delegation data . . . . . . . 9 83 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 9 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 86 1. Conventions and Definitions 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 90 "OPTIONAL" in this document are to be interpreted as described in 91 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 92 capitals, as shown here. 94 2. Background 96 [I-D.draft-schwartz-svcb-dns] defines how to use SVCB records to 97 describe the secure transport protocols supported by a DNS server. 98 [I-D.draft-ietf-dprive-unauth-to-authoritative] describes the use of 99 such records on the names of nameservers (the "NS name") to enable 100 opportunistic encryption of recursive-to-authoritative DNS queries. 101 Resolvers are permitted to fetch SVCB records asynchronously and 102 cache them, resulting in "partial opportunistic encryption": even 103 without an active adversary forcing a downgrade, queries will 104 sometimes be sent in cleartext. Participating authoritative 105 nameservers and recursive resolvers would have to be modified to make 106 use of these records. 108 When the child zone is DNSSEC-signed, publishing a SVCB record of 109 this kind is technically sufficient to enable authenticated 110 encryption. However, in order to support reliable authentication, 111 recursive resolvers would have to query for a SVCB record on every 112 signed delegation, and wait for a response before issuing their 113 intended query. We call this behavior a "synchronous binding check". 115 Many validating resolvers might not be willing to enable a 116 "synchronous binding check" behavior, as this would slow down 117 resolution of many existing domains in order to enable a new feature 118 (authenticated encryption) that is not yet used at all. To enable 119 authenticated encryption without this general performance loss, 120 [I-D.draft-rescorla-dprive-adox-latest] proposes to deliver the SVCB 121 records from the parent, in the delegation response. This avoids the 122 need for a binding check, at the cost of additionally requiring 123 modifications to the parent nameserver, which must provide these 124 extra records in delegation responses. 126 Providing these additional records is sufficient to enable "full 127 opportunistic encryption": the transport is always encrypted in the 128 absence of an active adversary. However, these records are not 129 protected by DNSSEC, so the child can only achieve fully 130 authenticated encryption if the parent also implements fully 131 authenticated encryption or otherwise protects the delivery of these 132 records. 134 Even if this approach is standardized, many parent zones may not 135 support delivery of SVCB records in delegation responses in the near 136 future. To enable the broadest use of encrypted transport, we may 137 need an interim solution that can be deployed more easily. 139 3. Proposal 141 We propose to indicate a nameserver's support for encrypted 142 transports using a signal encoded in its name. This signal takes two 143 forms: a "flag" and a "menu". 145 QUESTION: Do we need both of these forms, or should we drop one? 147 We note that encoding semantics in DNS labels is a hack, but believe 148 that the privacy benefits outweigh the ick factor. 150 In either form, the signal helps resolvers to acquire a SVCB RRSet 151 for the nameserver. Resolvers use this RRSet as specified in 152 [I-D.draft-rescorla-dprive-adox-latest]. 154 3.1. Flag form 156 If the NS name's first label is "svcb", this is regarded as a "flag". 157 When contacting a flagged nameserver, participating resolvers SHOULD 158 perform a synchronous binding check, and upgrade to a secure 159 transport if appropriate, before issuing the query. 161 The presence of this flag does not guarantee that the corresponding 162 SVCB records are actually present. 164 3.2. Menu form 166 If the NS name's first label starts with "svcb--", the label's 167 subsequent characters represent a "menu" of connection options, which 168 can be decoded into a SVCB RRSet. To decode the RRSet, each 169 character is transformed into a SVCB RR with the following 170 components: 172 * The owner name is the NS name plus the prefix label "_dns". 174 * The SvcPriority is the character's order in the list (starting at 175 1) 177 * The TargetName is the NS name 179 * The SvcParams are indicated in the registry entry for this menu 180 character (Section 6). 182 For example, the name "svcb-qt.ns3.example." would be decoded to this 183 RRSet: 185 _dns.svcb--qt.ns3.example. IN SVCB 1 svcb--qt.ns3.example. alpn=doq 186 _dns.svcb--qt.ns3.example. IN SVCB 2 svcb--qt.ns3.example. alpn=dot 187 The menu characters are a-z and 0-9; all other characters are 188 reserved for future use. Upon encountering any character outside 189 these ranges, parsers MUST stop and return successfully. Parsers 190 MUST ignore characters that are allowed but not recognized. 192 QUESTION: Do we need more than 36 codepoints? Is there a nice 193 simple format that would give us a lot more codepoints? 195 QUESTION: Should we consider a format that actually encodes the 196 SvcParams in the label instead? 198 3.3. Implementation requirements 200 Resolvers that implement support for "menu" mode MUST also support 201 the "flag" mode. Resolvers that support either mode MUST also 202 support [I-D.draft-rescorla-dprive-adox-latest], and ignore the in- 203 name signal if any SVCB records are included in a delegation 204 response. 206 When possible, zones SHOULD use SVCB records in the delegation 207 response and omit any in-name signal. 209 4. Security Considerations 211 NS names received during delegation are not protected by DNSSEC. 212 Therefore, just like in [I-D.draft-rescorla-dprive-adox-latest], this 213 scheme only enables authenticated encryption if the parent domain can 214 provide authentication without DNSSEC validation, e.g. using a secure 215 transport or Zone Digest [RFC8976]. 217 QUESTION: Do we expect to have parent zones that can provide 218 authenticated NS names but cannot provide authenticated SVCB 219 records in delegation responses? (Maybe the root, with ZONEMD?) 220 If not, does this proposal provide enough value? 222 5. Operational Considerations 224 It is possible that an existing NS name already matches the "flag" 225 pattern. Such a "false positive flag" will result in a small 226 performance loss due to the unnecessary synchronous binding check, 227 but will not otherwise impair functionality. 229 If a pre-existing NS name contains the menu pattern, that nameserver 230 will become unreachable by resolvers implementing this specification. 231 The authors believe that no such nameservers are currently deployed, 232 and such servers are unlikely to be deployed by accident. 234 6. IANA Considerations 236 IANA is requested to create a new registry entitled "Authoritative 237 Server Transport In-Name Signal Characters", with the following 238 fields: 240 * Character: a digit or lower-case letter 242 * SvcParams: a valid SVCB SvcParams set in presentation format 244 The registry policy is *TBD*. 246 The initial contents (*DO NOT USE*, subject to change) are as 247 follows: 249 +===========+==================================+ 250 | Character | SvcParams | 251 +===========+==================================+ 252 | t | alpn=dot | 253 +-----------+----------------------------------+ 254 | h | alpn=h2 dohpath=/dns-query{?dns} | 255 +-----------+----------------------------------+ 256 | 3 | alpn=h3 dohpath=/dns-query{?dns} | 257 +-----------+----------------------------------+ 258 | q | alpn=doq | 259 +-----------+----------------------------------+ 261 Table 1 263 7. References 265 7.1. Normative References 267 [I-D.draft-schwartz-svcb-dns] 268 Schwartz, B., "Service Binding Mapping for DNS Servers", 269 Work in Progress, Internet-Draft, draft-schwartz-svcb-dns- 270 03, 19 April 2021, . 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, 275 DOI 10.17487/RFC2119, March 1997, 276 . 278 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 279 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 280 May 2017, . 282 7.2. Informative References 284 [I-D.draft-bretelle-dprive-dot-spki-in-ns-name] 285 Bretelle, E., "Encoding DNS-over-TLS (DoT) Subject Public 286 Key Info (SPKI) in Name Server name", Work in Progress, 287 Internet-Draft, draft-bretelle-dprive-dot-spki-in-ns-name- 288 00, 11 March 2019, . 291 [I-D.draft-fujiwara-dnsop-delegation-information-signer] 292 Fujiwara, K., "Delegation Information (Referrals) Signer 293 for DNSSEC", Work in Progress, Internet-Draft, draft- 294 fujiwara-dnsop-delegation-information-signer-00, 2 295 November 2020, . 298 [I-D.draft-ietf-dprive-unauth-to-authoritative] 299 Hoffman, P. and P. V. Dijk, "Recursive to Authoritative 300 DNS with Unauthenticated Encryption", Work in Progress, 301 Internet-Draft, draft-ietf-dprive-unauth-to-authoritative- 302 01, 19 May 2021, . 305 [I-D.draft-levine-dprive-signal-02] 306 Levine, J., "Signaling That an Authoritative DNS server 307 offers DoT", Work in Progress, Internet-Draft, draft- 308 levine-dprive-signal-02, 17 November 2019, 309 . 312 [I-D.draft-rescorla-dprive-adox-latest] 313 Pauly, T., Rescorla, E., Schinazi, D., and C. A. Wood, 314 "Signaling Authoritative DNS Encryption", Work in 315 Progress, Internet-Draft, draft-rescorla-dprive-adox- 316 latest-00, 26 February 2021, 317 . 320 [I-D.draft-vandijk-dnsop-ds-digest-verbatim] 321 Dijk, P. V., "The VERBATIM Digest Algorithm for DS 322 records", Work in Progress, Internet-Draft, draft-vandijk- 323 dnsop-ds-digest-verbatim-00, 25 September 2020, 324 . 327 [I-D.draft-vandijk-dprive-ds-dot-signal-and-pin] 328 Dijk, P. V., Geuze, R., and E. Bretelle, "Signalling 329 Authoritative DoT support in DS records, with key 330 pinning", Work in Progress, Internet-Draft, draft-vandijk- 331 dprive-ds-dot-signal-and-pin-01, 13 July 2020, 332 . 335 [RFC8976] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. 336 Hardaker, "Message Digest for DNS Zones", RFC 8976, 337 DOI 10.17487/RFC8976, February 2021, 338 . 340 Appendix A. Comparison with related designs 342 Several other designs have been proposed to encode a transport 343 upgrade signal in an existing record type. 345 A.1. Indicating DoT support with a name prefix 347 Section 3.6 of [I-D.draft-levine-dprive-signal-02] discusses using 348 the "xs-" name prefix to indicate support for DNS over TLS. This is 349 equivalent to a "svcb-t" label in this formulation. This draft may 350 be seen as an expansion of that proposal, harmonized with the SVCB- 351 based discovery drafts. 353 A.2. Encoding the SPKI pin in the leaf label 355 [I-D.draft-bretelle-dprive-dot-spki-in-ns-name] also proposes to 356 encode a signal in the leaf label. The signal includes an SPKI pin, 357 for authentication of the TLS connection. 359 Including an SPKI pin allows authentication of the nameserver without 360 relying on DANE or PKI validation. However, like this draft, it does 361 not achieve authenticated encryption unless the NS name can be 362 delivered securely during delegation. It may also create operational 363 challenges when rotating TLS keys, due to the need to update the 364 parent zone. 366 A.3. Encoding the signal in an additional NS record 368 It would be possible to encode the signal by adding a special NS 369 record to the RRSet. This would avoid the need to rename any 370 existing nameservers. However, this arrangement has different 371 semantics: it is scoped to the entire child zone, rather than a 372 specific nameserver. It also relies heavily on existing resolvers 373 having robust and performant fallback behavior, which may not be a 374 safe assumption. 376 (Credit: Paul Hoffman) 378 A.4. Extending the DS record 380 [I-D.draft-vandijk-dprive-ds-dot-signal-and-pin] encodes a signal and 381 pin in a DS record by allocating a new fake "signature algorithm" and 382 encoding the TLS SPKI in a DNSKEY record. This enables fully 383 authenticated encryption (only requiring that the parent zone is 384 signed). However, it has very limited flexibility for representing 385 different transport configurations, and creates challenges during TLS 386 key rotation. 388 A.5. Enabling authentication of delegation data 390 [I-D.draft-fujiwara-dnsop-delegation-information-signer] adds a DS 391 record over the delegation information. When combined with this 392 draft, this would enable fully authenticated encrypted transport. 393 However, this approach requires very tight coherence between the 394 child and parent (e.g. when removing a nameserver) that may not be 395 achievable in practice. 397 [I-D.draft-vandijk-dnsop-ds-digest-verbatim] allows children to push 398 arbitrary authenticated delegation data into the parent. This could 399 be used to convey SVCB RRSets for the delegation securely. However, 400 it requires parents to accept a new digest type, and bends the usual 401 DS semantics even further. 403 Acknowledgments 405 *TODO* 407 Authors' Addresses 409 Benjamin M. Schwartz 410 Google LLC 412 Email: bemasc@google.com 414 Warren Kumari 415 Google LLC 417 Email: warren@kumari.net