idnits 2.17.00 (12 Aug 2021) /tmp/idnits31192/draft-hzpa-dprive-xfr-over-tls-01.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 11, 2019) is 1166 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) ** Downref: Normative reference to an Informational draft: draft-bortzmeyer-dprive-rfc7626-bis (ref. 'I-D.bortzmeyer-dprive-rfc7626-bis') ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) ** Obsolete normative reference: RFC 5077 (Obsoleted by RFC 8446) ** Downref: Normative reference to an Informational RFC: RFC 6973 Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 dprive H. Zhang 3 Internet-Draft P. Aras 4 Intended status: Standards Track Salesforce 5 Expires: September 12, 2019 W. Toorop 6 NLnet Labs 7 S. Dickinson 8 Sinodun IT 9 A. Mankin 10 Salesforce 11 March 11, 2019 13 DNS Zone Transfer over TLS 14 draft-hzpa-dprive-xfr-over-tls-01 16 Abstract 18 DNS zone transfers are transmitted in clear text, which gives 19 attackers the opportunity to collect the content of a zone by 20 eavesdropping on network connections. The DNS Transaction Signature 21 (TSIG) mechanism is specified to restrict direct zone transfer to 22 authorized clients only, but it does not add confidentiality. This 23 document specifies use of DNS-over-TLS to prevent zone contents 24 collection via passive monitoring of zone transfers. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 12, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 3. Zone Transfer Confidentiality Overview . . . . . . . . . . . 4 63 4. Zone Transfer with DoT - Authentication . . . . . . . . . . . 4 64 4.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4.2. Mutual TLS . . . . . . . . . . . . . . . . . . . . . . . 4 66 5. Session Establishment and Closing . . . . . . . . . . . . . . 4 67 5.1. AXFR Sessions . . . . . . . . . . . . . . . . . . . . . . 4 68 5.2. IXFR Sessions . . . . . . . . . . . . . . . . . . . . . . 4 69 5.3. Policies for Both AXFR and IXFR . . . . . . . . . . . . . 5 70 5.4. Next Steps . . . . . . . . . . . . . . . . . . . . . . . 5 71 6. Performance Considerations . . . . . . . . . . . . . . . . . 5 72 7. Implementation Considerations . . . . . . . . . . . . . . . . 5 73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 76 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 77 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 13. Normative References . . . . . . . . . . . . . . . . . . . . 6 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 81 1. Introduction 83 DNS has a number of privacy vulnerabilities, as discussed in detail 84 in [I-D.bortzmeyer-dprive-rfc7626-bis]. Stub client to recursive 85 resolver query privacy has received the most attention to date. 86 There are now standards track documents for three encryption 87 capabilities for stub to recursive queries and more work going on to 88 guide deployment of specifically DNS-over-TLS (DoT) [RFC7858] and 89 DNS-over-HTTPS (DoH) [RFC8484]. 91 [I-D.bortzmeyer-dprive-rfc7626-bis] established that stub client DNS 92 query transactions are not public and needed protection, but on zone 93 transfer [RFC1995] [RFC5936] it says only: 95 "Privacy risks for the holder of a zone (the risk that someone gets 96 the data) are discussed in [RFC5936] and [RFC5155]." 98 In what way is exposing the full contents of a zone a privacy risk? 99 The contents of the zone could include information such as names of 100 persons used in names of hosts. Best practice is not to use personal 101 information for domain names, but many such domain names exist. 102 There may also be regulatory, policy or other reasons why the zone 103 contents in full must be treated as private. 105 Neither of the RFCs mentioned in [I-D.bortzmeyer-dprive-rfc7626-bis] 106 contemplates the risk that someone gets the data through 107 eavesdropping on network connections, only via enumeration or 108 unauthorised transfer as described in the following paragraphs. 110 [RFC5155] specifies NSEC3 to prevent zone enumeration, which is when 111 queries for the authenticated denial of existences records of DNSSEC 112 allow a client to walk through the entire zone. Note that the need 113 for this protection also motivates NSEC5 [I-D.vcelak-nsec5]; zone 114 walking is now possible with NSEC3 due to crypto-breaking advances, 115 and NSEC5 is a response to this problem. 117 [RFC5155] does not address data obtained outside zone enumeration 118 (nor does [I-D.vcelak-nsec5]). Preventing eavesdropping of zone 119 transfers (this draft) is orthogonal to preventing zone enumeration, 120 though they aim to protect the same information. 122 [RFC5936] specifies using TSIG [RFC2845] for authorization of the 123 clients of a zone transfer and for data integrity, but does not 124 express any need for confidentiality, and TSIG does not offer 125 encryption. Some operators use SSH tunnelling or IPSec to encrypt 126 the transfer data. 128 Because the AXFR zone transfer is typically carried out over TCP from 129 authoritative DNS protocol implementations, encrypting AXFR using 130 DNS-over-TLS [RFC7858] seems like a simple step forward. This 131 document specifies how to use DoT to prevent zone collection from 132 zone transfers, including discussion of approaches for IXFR, which 133 uses UDP or TCP. 135 Next steps: Work on open questions at DNS table during IETF 104 136 Hackathon, expand this draft, then solicit discussion on the DPRIVE 137 mailing list. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] and [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 Privacy terminology is as described in Section 3 of [RFC6973]. 149 DNS terminology is as described in [RFC8499]. 151 DoT: DNS-over-TLS as specified in [RFC7858] 153 DoH: DNS-over-HTTPS as specified in [RFC8484] 155 3. Zone Transfer Confidentiality Overview 157 4. Zone Transfer with DoT - Authentication 159 4.1. TSIG 161 4.2. Mutual TLS 163 5. Session Establishment and Closing 165 5.1. AXFR Sessions 167 The connection flow in AXFR is a NOTIFY from the primary server to 168 the secondary server, and then an AXFR request from the secondary to 169 the primary after which the data flows. 171 The connection for AXFR via DoT SHOULD be established using port 853, 172 as specified in [RFC7858]. If there is no response on port 853, the 173 connection MAY be attempted using port 443 in case the server offers 174 DoT service on this port. 176 TODO: diagram of connection flow for AXFR, without and with DoT 178 5.2. IXFR Sessions 180 [RFC1995] specifies that Incremental Transfer may use UDP if the 181 entire IXFR response can be contained in a single DNS packet, 182 otherwise, TCP is used. 184 QUESTION: Given this, how should confidentiality of IXFR be provided? 186 To discuss: 188 o should IXFR have a mode in which TCP is mandatory? 190 o should IXFR have a mode in which TLS is mandatory? 192 o In workloads where there are frequent IXFRs, is the persistent 193 connection mode that TCP-Mode would enable (as well as the 194 retries) a benefit? 196 5.3. Policies for Both AXFR and IXFR 198 In order to assure the confidentiality of the zone information, 199 entire group of servers involved in XFR (the primary and all 200 secondaries) MUST have a consistent policy of requiring 201 confidentiality. If any do not, this is a weak link for attackers to 202 exploit. How to do this is TBD. 204 Additionally, the entire group of servers involved in XFR (the 205 primary and all secondaries) MUST have a consistent policy of 206 requiring Strict or Opportunistic DoT [RFC8310]. How to do this is 207 TBD. 209 5.4. Next Steps 211 Upcoming IETF Hackathon experiments will feed into this Session 212 Establishment and Closing section, as much about this needs 213 exploration as well as discussion on the mailing list. 215 6. Performance Considerations 217 The details in [RFC7858] and [RFC8310] about e.g. using persistent 218 connections and TLS Session Resumption [RFC5077] are fully applicable 219 to DNS Zone Transfer over DoT as well. 221 7. Implementation Considerations 223 TBA 225 8. IANA Considerations 227 TBD 229 9. Security Considerations 231 This document specifies a security measure against a DNS risk: the 232 risk that an attacker collects entire DNS zones through eavesdropping 233 on clear text DNS zone transfers. It presents a new Security 234 Consideration for DNS. Some questions to discuss are: should DoT in 235 this new case be required to use only TLS 1.3 and higher to avoid 236 residual exposure? How should padding be used (if it should)? 238 10. Acknowledgements 240 The authors thank Benno Overeinder, Shumon Huque and Tim Wicinski for 241 review and discussions. 243 11. Contributors 245 The following contributed significantly to the document: 247 12. Changelog 249 draft-hzpa-dprive-xfr-over-tls-01 251 o Editorial changes, updates to references. 253 draft-hzpa-dprive-xfr-over-tls-00 255 o Initial commit 257 13. Normative References 259 [I-D.bortzmeyer-dprive-rfc7626-bis] 260 Bortzmeyer, S. and S. Dickinson, "DNS Privacy 261 Considerations", draft-bortzmeyer-dprive-rfc7626-bis-02 262 (work in progress), January 2019. 264 [I-D.vcelak-nsec5] 265 Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and 266 D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of 267 Existence", draft-vcelak-nsec5-08 (work in progress), 268 December 2018. 270 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 271 DOI 10.17487/RFC1995, August 1996, . 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, 276 DOI 10.17487/RFC2119, March 1997, . 279 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 280 Wellington, "Secret Key Transaction Authentication for DNS 281 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 282 . 284 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 285 "Transport Layer Security (TLS) Session Resumption without 286 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 287 January 2008, . 289 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 290 Security (DNSSEC) Hashed Authenticated Denial of 291 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 292 . 294 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 295 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 296 . 298 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 299 Morris, J., Hansen, M., and R. Smith, "Privacy 300 Considerations for Internet Protocols", RFC 6973, 301 DOI 10.17487/RFC6973, July 2013, . 304 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 305 and P. Hoffman, "Specification for DNS over Transport 306 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 307 2016, . 309 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 310 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 311 May 2017, . 313 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 314 for DNS over TLS and DNS over DTLS", RFC 8310, 315 DOI 10.17487/RFC8310, March 2018, . 318 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 319 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 320 . 322 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 323 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 324 January 2019, . 326 Authors' Addresses 327 Han Zhang 328 Salesforce 329 San Francisco, CA 330 United States 332 Email: hzhang@salesforce.com 334 Pallavi Aras 335 Salesforce 336 Herndon, VA 337 United States 339 Email: paras@salesforce.com 341 Willem Toorop 342 NLnet Labs 343 Science Park 400 344 Amsterdam 1098 XH 345 The Netherlands 347 Email: willem@nlnetlabs.nl 349 Sara Dickinson 350 Sinodun IT 351 Magdalen Centre 352 Oxford Science Park 353 Oxford OX4 4GA 354 United Kingdom 356 Email: sara@sinodun.com 358 Allison Mankin 359 Salesforce 360 Herndon, VA 361 United States 363 Email: allison.mankin@gmail.com