--- 1/draft-ietf-dprive-xfr-over-tls-00.txt 2020-05-20 09:13:22.421277320 -0700 +++ 2/draft-ietf-dprive-xfr-over-tls-01.txt 2020-05-20 09:13:22.465278435 -0700 @@ -1,24 +1,24 @@ dprive H. Zhang Internet-Draft P. Aras Updates: 1995 (if approved) Salesforce Intended status: Standards Track W. Toorop -Expires: May 21, 2020 NLnet Labs +Expires: November 21, 2020 NLnet Labs S. Dickinson Sinodun IT A. Mankin Salesforce - November 18, 2019 + May 20, 2020 DNS Zone Transfer-over-TLS - draft-ietf-dprive-xfr-over-tls-00 + draft-ietf-dprive-xfr-over-tls-01 Abstract DNS zone transfers are transmitted in clear text, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies use of DNS-over-TLS to prevent zone contents collection via passive monitoring of zone transfers. @@ -31,25 +31,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 21, 2020. + This Internet-Draft will expire on November 21, 2020. Copyright Notice - Copyright (c) 2019 IETF Trust and the persons identified as the + Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -61,46 +61,46 @@ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Use Cases for XFR-over-TLS . . . . . . . . . . . . . . . . . 4 4. Connection and Data Flows in Existing XFR Mechanisms . . . . 5 4.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 5 4.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 6 4.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 7 4.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 7 4.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Connection and Data Flows in XoT . . . . . . . . . . . . . . 8 5.1. Performance Considerations . . . . . . . . . . . . . . . 8 - 5.2. AXoT mechanism . . . . . . . . . . . . . . . . . . . . . 8 - 5.3. IXoT mechanism . . . . . . . . . . . . . . . . . . . . . 9 - 5.3.1. Fallback to AXFR . . . . . . . . . . . . . . . . . . 10 + 5.2. TLS versions . . . . . . . . . . . . . . . . . . . . . . 8 + 5.3. AXoT mechanism . . . . . . . . . . . . . . . . . . . . . 8 + 5.4. IXoT mechanism . . . . . . . . . . . . . . . . . . . . . 9 + 5.4.1. Fallback to AXFR . . . . . . . . . . . . . . . . . . 10 6. Zone Transfer with DoT - Authentication . . . . . . . . . . . 10 6.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 6.3.1. Opportunistic . . . . . . . . . . . . . . . . . . . . 10 - 6.3.2. Strict . . . . . . . . . . . . . . . . . . . . . . . 10 - 6.3.3. Mutual . . . . . . . . . . . . . . . . . . . . . . . 10 + 6.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6.3.1. Opportunistic . . . . . . . . . . . . . . . . . . . . 11 + 6.3.2. Strict . . . . . . . . . . . . . . . . . . . . . . . 11 + 6.3.3. Mutual . . . . . . . . . . . . . . . . . . . . . . . 11 6.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 11 - 6.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 6.6. Comparison of Authentication Methods . . . . . . . . . . 11 - 7. Policies for Both AXFR and IXFR . . . . . . . . . . . . . . . 12 - 8. Multi-primary Configurations . . . . . . . . . . . . . . . . 13 + 6.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 6.6. Comparison of Authentication Methods . . . . . . . . . . 12 + 7. Policies for Both AXFR and IXFR . . . . . . . . . . . . . . . 13 + 8. Multi-primary Configurations . . . . . . . . . . . . . . . . 14 9. Implementation Considerations . . . . . . . . . . . . . . . . 14 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 12. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 15.1. Normative References . . . . . . . . . . . . . . . . . . 15 + 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 15.1. Normative References . . . . . . . . . . . . . . . . . . 16 15.2. Informative References . . . . . . . . . . . . . . . . . 17 - 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 - + 15.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction DNS has a number of privacy vulnerabilities, as discussed in detail in [I-D.ietf-dprive-rfc7626-bis]. Stub client to recursive resolver query privacy has received the most attention to date. There are now standards track documents for three encryption capabilities for stub to recursive queries and more work going on to guide deployment of specifically DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) @@ -160,22 +160,20 @@ Privacy terminology is as described in Section 3 of [RFC6973]. Note that in this document we choose to use the terms 'primary' and 'secondary' for two servers engaged in zone transfers. DNS terminology is as described in [RFC8499]. DoT: DNS-over-TLS as specified in [RFC7858] - DoH: DNS-over-HTTPS as specified in [RFC8484] - XoT: Generic XFR-over-TLS mechanisms as specified in this document AXoT: AXFR-over-TLS IXoT: IXFR over-TLS 3. Use Cases for XFR-over-TLS o Confidentiality. Clearly using an encrypted transport for zone transfers will defeat zone content leakage that can occur via @@ -183,24 +181,24 @@ o Authentication. Use of single or mutual TLS authentication (in combination with ACLs) can complement and potentially be an alternative to TSIG. o Performance. Existing AXFR and IXFR mechanisms have the burden of backwards compatibility with older implementations based on the original specifications in [RFC1034] and [RFC1035]. For example, some older AXFR servers don't support using a TCP connection for multiple AXFR sessions or XFRs of different zones because they - have not been updated to follow the guidance in [RFC5836]. Any + have not been updated to follow the guidance in [RFC5936]. Any implementation of XFR-over-TLS would obviously be required to implement optimized and interoperable transfers as described in - [RFC5936] e.g. transfer of multiple zones-over-one connection. + [RFC5936] e.g. transfer of multiple zones over one connection. o Performance. Current usage of TCP for IXFR is sub-optimal in some cases i.e. connections are frequently closed after a single IXFR. 4. Connection and Data Flows in Existing XFR Mechanisms The original specification for zone transfers in [RFC1034] and [RFC1035] was based on a polling mechanism: a secondary performed a periodic SOA query (based on the refresh timer) to determine if an AXFR was required. @@ -317,21 +314,21 @@ connections and SHOULD use [RFC7858] to manage persistent connections. 4.3. Data Leakage of NOTIFY and SOA Message Exchanges This section attempts to presents a rationale for also encrypting the other messages in the XFR mechanism. Since the SOA of the published zone can be trivially discovered by simply querying the publicly available authoritative servers leakage - RR of this is not discussed in the following sections. + of this RR is not discussed in the following sections. 4.3.1. NOTIFY Unencrypted NOTIFY messages identify configured secondaries on the primary. [RFC1996] also states: "If ANCOUNT>0, then the answer section represents an unsecure hint at the new RRset for this . @@ -348,55 +345,65 @@ 5.1. Performance Considerations The details in [RFC7766], [RFC7858] and [RFC8310] about e.g. using persistent connections and TLS Session Resumption [RFC5077] are fully applicable to XFR-over-TLS as well. It is RECOMMENDED that clients and servers that support XoT also implement EDNS0 Keepalive [RFC7828]. -5.2. AXoT mechanism + It is useful to note that in these mechanisms it is the secondary + that initiates the TLS connection to the primary for a XFR request, + so that in terms of connectivity the secondary is the TLS client and + the primary the TLS server. + +5.2. TLS versions + + For improved security all implementations of this specification MUST + use only TLS 1.3 [RFC8446] or later. + +5.3. AXoT mechanism The figure below provides an outline of the AXoT mechanism including NOTIFYs. Figure 3: AXoT mechanism [5] + The connection for AXFR-over-TLS SHOULD be established using port + 853, as specified in [RFC7858], unless there is mutual agreement + between the secondary and primary to use a port other than port 853 + for XFR-over-TLS. + All implementations that support XoT MUST fully implement [RFC5953] behavior on TLS connections. Sections 4.1, 4.1.1 and 4.1.2 of [RFC5936] describe guidance for AXFR clients and servers with regard to re-use of sessions for multiple AXFRs, AXFRs of different zones and using TCP session for other queries including SOA. For clarity we restate here that an AXoT client MAY use an already opened TLS connection to send a AXFR request. Using an existing open connection is RECOMMENDED over opening a new connection. (Non-AXoT session traffic can also use an open connection.) For clarity we additionally state here that an AXoT client MAY use an already opened TLS connection to send a SOA request. Using an existing open connection is RECOMMENDED over opening a new connection. - The connection for AXFR-over-TLS SHOULD be established using port - 853, as specified in [RFC7858], unless there is mutual agreement - between the secondary and primary to use a port other than port 853 - for XFR-over-TLS. - QUESTION: Should there be a requirement that the SOA is always done on a TLS connection if the XFR is? For the case when no transfer is required this could be unnecessary overhead. -5.3. IXoT mechanism +5.4. IXoT mechanism The figure below provides an outline of the IXoT mechanism including NOTIFYs. Figure 4: IXoT mechanism [6] The connection for IXFR-over-TLS SHOULD be established using port 853, as specified in [RFC7858], unless there is mutual agreement between the secondary and primary to use a port other than port 853 for XFR-over-TLS. @@ -427,21 +434,27 @@ request an appropriate timeout from the server (if the server supports EDNS0 Keepalive). If the server does not support EDNS0 Keepalive the client MAY keep the connection open for a few seconds ([RFC7766] recommends that servers use timeouts of at least a few seconds). An IXoT client MAY pipeline IXFR requests for different zones on a single TLS connection. AN IXoT server MAY respond to those requests out of order. -5.3.1. Fallback to AXFR + QUESTION: Since this is a new specification should there be a + requirement that IXoT servers are RECOMMENDED to condense responses + as described in Section 6 of [RFC1995]. [RFC1995] document says this + is optional and MAY be done but it can significantly reduce the size + of responses and may have implications for padding? + +5.4.1. Fallback to AXFR Fallback to AXFR can happen, for example, if the server is not able to provide an IXFR for the requested SOA. Implementations differ in how long they store zone deltas and how many may be stored at any one time. After a failed IXFR a IXoT client SHOULD request the AXFR on the already open TLS connection. 6. Zone Transfer with DoT - Authentication @@ -488,27 +501,28 @@ authentication and end-to-end channel confidentiality. 6.4. IP Based ACL on the Primary Most DNS server implementations offer an option to configure an IP based Access Control List (ACL), which is often used in combination with TSIG based ACLs to restrict access to zone transfers on primary servers. This is also possible with XoT but it must be noted that as with TCP - the implementation of such and ACL cannot be enforced on the primary + the implementation of such an ACL cannot be enforced on the primary until a XFR request is received on an established connection. - If control were to be any more fine-grained than this then a separate - port would be required for XoT such that implementations would be - able to refuse connections on that port to all clients except those - configured as secondaries. + If control were to be any more fine-grained than this then a + separate, dedicated port would need to be agreed between primary and + secondary for XoT such that implementations would be able to refuse + connections on that port to all clients except those configured as + secondaries. 6.5. ZONEMD Message Digest for DNS Zones (ZONEMD) [I-D.ietf-dnsop-dns-zone-digest] digest is a mechanism that can be used to verify the content of a standalone zone. It is designed to be independent of the transmission channel or mechanism, allowing a general consumer of a zone to do origin authentication of the entire zone contents. Note that the current version of [I-D.ietf-dnsop-dns-zone-digest] states: @@ -650,37 +664,40 @@ TBD 12. Security Considerations This document specifies a security measure against a DNS risk: the risk that an attacker collects entire DNS zones through eavesdropping on clear text DNS zone transfers. It presents a new Security Consideration for DNS. Some questions to discuss are: - o Should DoT in this new case be required to use only TLS 1.3 and - higher to avoid residual exposure? - o How should padding be used in IXFR? o Should there be an option to 'pad' an AXFR response (i.e. a set of AXFR responses on a given connection) to hide the zone size? 13. Acknowledgements The authors thank Benno Overeinder, Shumon Huque and Tim Wicinski for review and discussions. 14. Changelog draft-ietf-dprive-xfr-over-tls-00 + o Minor editorial updates + + o Add requirement for TLS 1.3. or later + + draft-ietf-dprive-xfr-over-tls-00 + o Rename after adoption and reference update. o Add placeholder for SIG(0) discussion o Update section on ZONEMD draft-hzpa-dprive-xfr-over-tls-02 o Substantial re-work of the document. @@ -691,22 +708,22 @@ draft-hzpa-dprive-xfr-over-tls-00 o Initial commit 15. References 15.1. Normative References [I-D.ietf-dprive-rfc7626-bis] Bortzmeyer, S. and S. Dickinson, "DNS Privacy - Considerations", draft-ietf-dprive-rfc7626-bis-02 (work in - progress), October 2019. + Considerations", draft-ietf-dprive-rfc7626-bis-05 (work in + progress), May 2020. [I-D.vcelak-nsec5] Vcelak, J., Goldberg, S., Papadopoulos, D., Huque, S., and D. Lawrence, "NSEC5, DNSSEC Authenticated Denial of Existence", draft-vcelak-nsec5-08 (work in progress), December 2018. [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, DOI 10.17487/RFC1995, August 1996, . @@ -761,21 +778,21 @@ [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . 15.2. Informative References [I-D.ietf-dnsop-dns-zone-digest] Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W. Hardaker, "Message Digest for DNS Zones", draft-ietf- - dnsop-dns-zone-digest-02 (work in progress), October 2019. + dnsop-dns-zone-digest-07 (work in progress), April 2020. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,