idnits 2.17.1 draft-hzpa-dprive-xfr-over-tls-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 (March 11, 2019) is 1865 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) == Unused Reference: 'I-D.bortzmeyer-dprive-rfc7626-bis' is defined on line 228, but no explicit reference was found in the text == Unused Reference: 'I-D.dickinson-dprive-bcp-op' is defined on line 233, but no explicit reference was found in the text == Unused Reference: 'RFC5077' is defined on line 253, but no explicit reference was found in the text == Unused Reference: 'RFC7525' is defined on line 273, but no explicit reference was found in the text == Unused Reference: 'RFC7766' is defined on line 283, but no explicit reference was found in the text == Unused Reference: 'RFC7830' is defined on line 288, but no explicit reference was found in the text == Unused Reference: 'RFC8310' is defined on line 301, but no explicit reference was found in the text == Unused Reference: 'RFC8446' is defined on line 306, but no explicit reference was found in the text == Unused Reference: 'RFC8467' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'NSEC5Research' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC7129' is defined on line 331, but no explicit reference was found in the text == Unused Reference: 'RFC7816' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC7871' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'RFC7873' is defined on line 344, but no explicit reference was found in the text == Unused Reference: 'RFC8094' is defined on line 348, but no explicit reference was found in the text ** 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 ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) ** Obsolete normative reference: RFC 7626 (Obsoleted by RFC 9076) ** Downref: Normative reference to an Experimental RFC: RFC 8467 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) -- Obsolete informational reference (is this intentional?): RFC 7816 (Obsoleted by RFC 9156) Summary: 8 errors (**), 0 flaws (~~), 16 warnings (==), 2 comments (--). 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-00 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 links. The DNS Transaction Signature (TSIG) is 21 specified to restrict direct zone transfer to authorized clients, but 22 it does not add confidentiality. This document specifies use of TLS 23 to prevent zone collection 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 12, 2019. 42 Copyright Notice 44 Copyright (c) 2019 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Zone Transfer Confidentiality Overview . . . . . . . . . . . 3 62 4. Zone Transfer with DOT - Authentication . . . . . . . . . . . 3 63 5. Session Establishment and Closing . . . . . . . . . . . . . . 4 64 6. Performance Considerations . . . . . . . . . . . . . . . . . 5 65 7. Implementation Considerations . . . . . . . . . . . . . . . . 5 66 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 67 9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 68 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 69 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 5 70 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 13.1. Normative References . . . . . . . . . . . . . . . . . . 5 73 13.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 DNS has a number of privacy vulnerabilities, as discussed in detail 79 in [RFC7626]. Query privacy has received the most attention. There 80 are now standards for three encryption capabilities for queries and 81 more work going on to guide deployment [RFC7858] [RFC8484]. 83 [RFC7626] established that the query transactions are not public and 84 needed protection, but on zone transfer it says only: Privacy risks 85 for the holder of a zone (the risk that someone gets the data) are 86 discussed in [RFC5936] and [RFC5155]. 88 In what way is exposing the full content of a zone a privacy risk? 89 The contents of the zone could include information such as names of 90 persons used in names of hosts. Best practice is not to use personal 91 information for domain names, but many such domain names exist. 92 There may also be regulatory or other reasons why the zone content in 93 full must be treated as private. 95 Neither of the RFCs mentioned by RFC7626 contemplates the risk that 96 someone gets the data through link eavesdropping. 98 [RFC5155] specifies NSEC3 to prevent zone enumeration, which is when 99 queries for the authenticated denial of existences records of DNSSEC 100 allow a client to walk through the entire zone. Note that the need 101 for this protection also motivates NSEC5; zone walking is now 102 possible with NSEC3 due to crypto-breaking advances, and NSEC5 is a 103 response to this problem. 105 [RFC5155] does not address data obtained outside zone enumeration 106 (nor does NSEC5). Preventing eavesdropping of zone transfers (this 107 draft) is orthogonal to preventing zone enumeration, though they aim 108 to protect the same information. 110 [RFC5936] specifies using TSIG [RFC2845] for authorization of the 111 clients of a zone transfer and for data integrity, but does not 112 express any need for confidentiality, and TSIG does not offer 113 encryption. Some operators use SSH tunneling or IPSEC to encrypt the 114 transfer data. Because the AXFR zone transfer is carried out over 115 TCP from DNS protocol implementations, encrypting AXFR using DNS over 116 TLS [RFC7858], aka DOT, seems like a simple step forward. This 117 document specifies how to use DOT to prevent zone collection from 118 zone transfers, including discussion of approaches for IXFR, which 119 uses UDP or TCP. 121 Next steps: work on questions at DNS table during Hackathon, expand 122 this draft, then solicit discussion on the DPRIVE mailing list. 124 2. Terminology 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in BCP 129 14 [RFC2119] [RFC8174] when, and only when, they appear in all 130 capitals, as shown here. 132 Privacy terminology is as described in Section 3 of [RFC6973]. 134 DNS terminology is as described in [RFC8499]: 136 3. Zone Transfer Confidentiality Overview 138 4. Zone Transfer with DOT - Authentication 140 Subsection - TSIG 142 Subsection - Mutual TLS 144 5. Session Establishment and Closing 146 Subsection - AXFR Sessions 148 The connection flow in AXFR is a NOTIFY from the primary server to 149 the secondary server, and then an AXFR request from the secondary to 150 the primay after which the data flows. 152 The connection for AXFR SHOULD be established using port 853, as 153 specified in [RFC7858]. If there is no response on port 853, the 154 connection MAY be attempted using port 443. 156 TODO: diagram of connection flow for AXFR, without and with DOT 158 Subsection - IXFR Sessions (?) 160 [RFC1995] specifies that Incremental Transfer may use UDP if the 161 entire IXFR response can be contained in a single DNS packet, 162 otherwise, TCP is used. 164 Given this, how should confidentiality of IXFR be provided? To 165 discuss: should IXFR have a mode in which TCP is mandatory? or 166 should there be an approach of starting with DNS over DTLS, and 167 switching to DNS over TLS with a TCP switch? In workloads where 168 there are frequent IXFRs, is the persistent mode that TCP-Mode would 169 enable (as well as the retries, a benefit? 171 Subsection - Policies for Both AXFR and IXFR 173 In order to assure the confidentiality of the zone information, all 174 the servers (primary and secondary) MUST have a consistent 175 confidentiality use. If any do not, this is a weak link for 176 attackers to exploit. How to do this is TBD. 178 The entire group (the primary and all secondaries) MUST have a 179 consistent policy on Strict or Non-Strict mode of operation. How to 180 do this is TBD. 182 Subsection - Next Steps 184 Upcoming open hackathon experiments will feed into this Session 185 Establishment and Closing section, as much about this needs 186 exploration as well as dicussion on the mailing list. 188 6. Performance Considerations 190 The details in [RFC7858] about using persistent connections and TLS 191 Session Resume are fully applicable to DNS Transfer over DOT as well. 193 7. Implementation Considerations 195 TBA 197 8. IANA Considerations 199 TBD 201 9. Security Considerations 203 This document specifies a security measure against a DNS risk, the 204 risk that an attacker collects entire DNS zones through eavesdropping 205 on plaintext DNS zone transfers. It presents a new Security 206 Consideration for DNS. Some questions to discuss are: should DOT in 207 this new case be required to use only TLS1.3 and higher to avoid 208 residual exposure? How should padding be used (if it should)? 210 10. Acknowledgements 212 Benno, Shumon, Tim 214 11. Contributors 216 The following contributed significantly to the document: 218 12. Changelog 220 draft-hzpa-dprive-xfr-over-tls-00 222 o Initial commit 224 13. References 226 13.1. Normative References 228 [I-D.bortzmeyer-dprive-rfc7626-bis] 229 Bortzmeyer, S. and S. Dickinson, "DNS Privacy 230 Considerations", draft-bortzmeyer-dprive-rfc7626-bis-02 231 (work in progress), January 2019. 233 [I-D.dickinson-dprive-bcp-op] 234 Dickinson, S., Overeinder, B., Rijswijk-Deij, R., and A. 235 Mankin, "Recommendations for DNS Privacy Service 236 Operators", draft-dickinson-dprive-bcp-op-01 (work in 237 progress), July 2018. 239 [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, 240 DOI 10.17487/RFC1995, August 1996, 241 . 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, 245 DOI 10.17487/RFC2119, March 1997, 246 . 248 [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. 249 Wellington, "Secret Key Transaction Authentication for DNS 250 (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000, 251 . 253 [RFC5077] Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, 254 "Transport Layer Security (TLS) Session Resumption without 255 Server-Side State", RFC 5077, DOI 10.17487/RFC5077, 256 January 2008, . 258 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 259 Security (DNSSEC) Hashed Authenticated Denial of 260 Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, 261 . 263 [RFC5936] Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol 264 (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010, 265 . 267 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 268 Morris, J., Hansen, M., and R. Smith, "Privacy 269 Considerations for Internet Protocols", RFC 6973, 270 DOI 10.17487/RFC6973, July 2013, 271 . 273 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 274 "Recommendations for Secure Use of Transport Layer 275 Security (TLS) and Datagram Transport Layer Security 276 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 277 2015, . 279 [RFC7626] Bortzmeyer, S., "DNS Privacy Considerations", RFC 7626, 280 DOI 10.17487/RFC7626, August 2015, 281 . 283 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 284 D. Wessels, "DNS Transport over TCP - Implementation 285 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 286 . 288 [RFC7830] Mayrhofer, A., "The EDNS(0) Padding Option", RFC 7830, 289 DOI 10.17487/RFC7830, May 2016, 290 . 292 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 293 and P. Hoffman, "Specification for DNS over Transport 294 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 295 2016, . 297 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 298 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 299 May 2017, . 301 [RFC8310] Dickinson, S., Gillmor, D., and T. Reddy, "Usage Profiles 302 for DNS over TLS and DNS over DTLS", RFC 8310, 303 DOI 10.17487/RFC8310, March 2018, 304 . 306 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 307 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 308 . 310 [RFC8467] Mayrhofer, A., "Padding Policies for Extension Mechanisms 311 for DNS (EDNS(0))", RFC 8467, DOI 10.17487/RFC8467, 312 October 2018, . 314 [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS 315 (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, 316 . 318 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 319 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 320 January 2019, . 322 13.2. Informative References 324 [NSEC5Research] 325 Goldberg, S., Naor, M., Papadopoulos, D., and L. Reyzin, 326 "NSEC5: Provably Preventing DNSSEC Zone Enumeration", 327 2015, . 331 [RFC7129] Gieben, R. and W. Mekking, "Authenticated Denial of 332 Existence in the DNS", RFC 7129, DOI 10.17487/RFC7129, 333 February 2014, . 335 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 336 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 337 . 339 [RFC7871] Contavalli, C., van der Gaast, W., Lawrence, D., and W. 340 Kumari, "Client Subnet in DNS Queries", RFC 7871, 341 DOI 10.17487/RFC7871, May 2016, 342 . 344 [RFC7873] Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS) 345 Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016, 346 . 348 [RFC8094] Reddy, T., Wing, D., and P. Patil, "DNS over Datagram 349 Transport Layer Security (DTLS)", RFC 8094, 350 DOI 10.17487/RFC8094, February 2017, 351 . 353 Authors' Addresses 355 Han Zhang 356 Salesforce 357 San Francisco, CA 358 United States 360 Email: hzhang@salesforce.com 362 Pallavi Aras 363 Salesforce 364 Herndon, VA 365 United States 367 Email: paras@salesforce.com 368 Willem Toorop 369 NLnet Labs 370 Science Park 400 371 Amsterdam Amsterdam 1098 XH 372 The Netherlands 374 Email: willem@nlnetlabs.nl 376 Sara Dickinson 377 Sinodun IT 378 Magdalen Centre 379 Oxford Science Park 380 Oxford OX4 4GA 381 United Kingdom 383 Email: sara@sinodun.com 385 Allison Mankin 386 Salesforce 387 Herndon, VA 389 Email: allison.mankin@gmail.com