--- 1/draft-ietf-dprive-xfr-over-tls-03.txt 2020-11-23 04:15:35.719662915 -0800 +++ 2/draft-ietf-dprive-xfr-over-tls-04.txt 2020-11-23 04:15:37.119698335 -0800 @@ -1,23 +1,23 @@ dprive W. Toorop Internet-Draft NLnet Labs Updates: 1995, 5936, 7766 (if approved) S. Dickinson Intended status: Standards Track Sinodun IT -Expires: May 6, 2021 S. Sahib +Expires: May 27, 2021 S. Sahib P. Aras A. Mankin Salesforce - November 2, 2020 + November 23, 2020 DNS Zone Transfer-over-TLS - draft-ietf-dprive-xfr-over-tls-03 + draft-ietf-dprive-xfr-over-tls-04 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 TLS, rather then clear text, to prevent zone content collection via passive monitoring of zone transfers: @@ -32,97 +32,99 @@ 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 6, 2021. + This Internet-Draft will expire on May 27, 2021. Copyright Notice 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3. Use Cases for XFR-over-TLS . . . . . . . . . . . . . . . . . 5 - 3.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 6 - 4. Connection and Data Flows in Existing XFR Mechanisms . . . . 7 - 4.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 7 - 4.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 9 - 4.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 11 - 4.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 11 - 4.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 11 - 5. Updates to existing specifications . . . . . . . . . . . . . 11 - 5.1. Update to RFC1995 for IXFR-over-TCP . . . . . . . . . . . 12 - 5.2. Update to RFC5936 for AXFR-over-TCP . . . . . . . . . . . 13 - 5.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP . . . . . 13 - 5.3.1. Connection reuse . . . . . . . . . . . . . . . . . . 13 - 5.3.2. AXFRs and IXFRs on the same connection . . . . . . . 13 - 5.3.3. XFR limits . . . . . . . . . . . . . . . . . . . . . 14 - 5.3.4. The edns-tcp-keepalive EDNS0 Option . . . . . . . . . 14 - 5.3.5. Backwards compatibility . . . . . . . . . . . . . . . 15 - 5.4. Update to RFC7766 . . . . . . . . . . . . . . . . . . . . 15 - 6. XoT specification . . . . . . . . . . . . . . . . . . . . . . 16 - 6.1. TLS versions . . . . . . . . . . . . . . . . . . . . . . 16 - 6.2. Port selection . . . . . . . . . . . . . . . . . . . . . 16 - 6.3. High level XoT descriptions . . . . . . . . . . . . . . . 16 - 6.4. XoT transfers . . . . . . . . . . . . . . . . . . . . . . 18 - 6.5. XoT connections . . . . . . . . . . . . . . . . . . . . . 19 - 6.6. XoT vs ADoT . . . . . . . . . . . . . . . . . . . . . . . 19 - 6.7. Response RCODES . . . . . . . . . . . . . . . . . . . . . 20 - 6.8. AXoT specifics . . . . . . . . . . . . . . . . . . . . . 20 - 6.8.1. Padding AXoT responses . . . . . . . . . . . . . . . 20 - 6.9. IXoT specifics . . . . . . . . . . . . . . . . . . . . . 21 - 6.9.1. Condensation of responses . . . . . . . . . . . . . . 21 - 6.9.2. Fallback to AXFR . . . . . . . . . . . . . . . . . . 21 - 6.9.3. Padding of IXoT responses . . . . . . . . . . . . . . 22 - 6.10. Name compression and maximum payload sizes . . . . . . . 22 - 7. Multi-primary Configurations . . . . . . . . . . . . . . . . 22 - 8. Authentication mechanisms . . . . . . . . . . . . . . . . . . 23 - 8.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 8.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 8.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 8.3.1. Opportunistic TLS . . . . . . . . . . . . . . . . . . 24 - 8.3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . 25 - 8.3.3. Mutual TLS . . . . . . . . . . . . . . . . . . . . . 25 - 8.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 25 - 8.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 26 - 9. XoT authentication . . . . . . . . . . . . . . . . . . . . . 26 - 10. Policies for Both AXoT and IXoT . . . . . . . . . . . . . . . 27 - 11. Implementation Considerations . . . . . . . . . . . . . . . . 28 - 12. Implementation Status . . . . . . . . . . . . . . . . . . . . 28 - 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 - 14. Security Considerations . . . . . . . . . . . . . . . . . . . 28 - 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 - 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 - 17. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 18.1. Normative References . . . . . . . . . . . . . . . . . . 30 - 18.2. Informative References . . . . . . . . . . . . . . . . . 32 - 18.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 2. Document work via GitHub . . . . . . . . . . . . . . . . . . 5 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Use Cases for XFR-over-TLS . . . . . . . . . . . . . . . . . 6 + 4.1. Threat model . . . . . . . . . . . . . . . . . . . . . . 6 + 5. Connection and Data Flows in Existing XFR Mechanisms . . . . 7 + 5.1. AXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 7 + 5.2. IXFR Mechanism . . . . . . . . . . . . . . . . . . . . . 9 + 5.3. Data Leakage of NOTIFY and SOA Message Exchanges . . . . 11 + 5.3.1. NOTIFY . . . . . . . . . . . . . . . . . . . . . . . 11 + 5.3.2. SOA . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 6. Updates to existing specifications . . . . . . . . . . . . . 11 + 6.1. Update to RFC1995 for IXFR-over-TCP . . . . . . . . . . . 12 + 6.2. Update to RFC5936 for AXFR-over-TCP . . . . . . . . . . . 13 + 6.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP . . . . . 13 + 6.3.1. Connection reuse . . . . . . . . . . . . . . . . . . 13 + 6.3.2. AXFRs and IXFRs on the same connection . . . . . . . 13 + 6.3.3. XFR limits . . . . . . . . . . . . . . . . . . . . . 14 + 6.3.4. The edns-tcp-keepalive EDNS0 Option . . . . . . . . . 14 + 6.3.5. Backwards compatibility . . . . . . . . . . . . . . . 15 + 6.4. Update to RFC7766 . . . . . . . . . . . . . . . . . . . . 15 + 7. XoT specification . . . . . . . . . . . . . . . . . . . . . . 16 + 7.1. TLS versions . . . . . . . . . . . . . . . . . . . . . . 16 + 7.2. Port selection . . . . . . . . . . . . . . . . . . . . . 16 + 7.3. High level XoT descriptions . . . . . . . . . . . . . . . 16 + 7.4. XoT transfers . . . . . . . . . . . . . . . . . . . . . . 18 + 7.5. XoT connections . . . . . . . . . . . . . . . . . . . . . 19 + 7.6. XoT vs ADoT . . . . . . . . . . . . . . . . . . . . . . . 19 + 7.7. Response RCODES . . . . . . . . . . . . . . . . . . . . . 20 + 7.8. AXoT specifics . . . . . . . . . . . . . . . . . . . . . 20 + 7.8.1. Padding AXoT responses . . . . . . . . . . . . . . . 20 + 7.9. IXoT specifics . . . . . . . . . . . . . . . . . . . . . 21 + 7.9.1. Condensation of responses . . . . . . . . . . . . . . 21 + 7.9.2. Fallback to AXFR . . . . . . . . . . . . . . . . . . 21 + 7.9.3. Padding of IXoT responses . . . . . . . . . . . . . . 22 + 7.10. Name compression and maximum payload sizes . . . . . . . 22 + + 8. Multi-primary Configurations . . . . . . . . . . . . . . . . 22 + 9. Authentication mechanisms . . . . . . . . . . . . . . . . . . 23 + 9.1. TSIG . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 9.2. SIG(0) . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 9.3. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 9.3.1. Opportunistic TLS . . . . . . . . . . . . . . . . . . 24 + 9.3.2. Strict TLS . . . . . . . . . . . . . . . . . . . . . 25 + 9.3.3. Mutual TLS . . . . . . . . . . . . . . . . . . . . . 25 + 9.4. IP Based ACL on the Primary . . . . . . . . . . . . . . . 25 + 9.5. ZONEMD . . . . . . . . . . . . . . . . . . . . . . . . . 26 + 10. XoT authentication . . . . . . . . . . . . . . . . . . . . . 26 + 11. Policies for Both AXoT and IXoT . . . . . . . . . . . . . . . 27 + 12. Implementation Considerations . . . . . . . . . . . . . . . . 28 + 13. Implementation Status . . . . . . . . . . . . . . . . . . . . 28 + 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 + 15. Security Considerations . . . . . . . . . . . . . . . . . . . 28 + 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 + 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 + 18. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 19.1. Normative References . . . . . . . . . . . . . . . . . . 31 + 19.2. Informative References . . . . . . . . . . . . . . . . . 32 + 19.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix A. XoT server connection handling . . . . . . . . . . . 34 A.1. Only listen on TLS on a specific IP address . . . . . . . 34 A.2. Client specific TLS acceptance . . . . . . . . . . . . . 34 A.3. SNI based TLS acceptance . . . . . . . . . . . . . . . . 35 A.4. TLS specific response policies . . . . . . . . . . . . . 35 A.4.1. SNI based response policies . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 1. Introduction @@ -199,21 +201,29 @@ per query basis. Since requests typically occur on TCP connections authoritatives must cater for accepting any TCP connection and then handling the authentication of each XFR request individually. Because both AXFR and IXFR zone transfers are typically carried out over TCP from authoritative DNS protocol implementations, encrypting zone transfers using TLS, based closely on DoT [RFC7858], seems like a simple step forward. This document specifies how to use TLS as a transport to prevent zone collection from zone transfers. -2. Terminology +2. Document work via GitHub + + [THIS SECTION TO BE REMOVED BEFORE PUBLICATION] The Github repository + for this document is at . Proposed text and editorial changes are very much + welcomed there, but any functional changes should always first be + discussed on the IETF DPRIVE WG (dns-privacy) mailing list. + +3. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here. Privacy terminology is as described in Section 3 of [RFC6973]. Note that in this document we choose to use the terms 'primary' and @@ -225,21 +235,21 @@ XFR-over-TCP: Used to mean both IXFR-over-TCP [RFC1995] and AXFR- over-TCP [RFC5936]. 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 +4. 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 passive surveillance. o Authentication. Use of single or mutual TLS (mTLS) 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 @@ -248,21 +258,21 @@ 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 [RFC5936]. Any implementation of XFR-over-TLS (XoT) would obviously be required to implement optimized and interoperable transfers as described in [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. -3.1. Threat model +4.1. Threat model The threat model considered here is one where the current contents and size of the zone are considered sensitive and should be protected during transfer. The threat model does not, however, consider the existence of a zone, the act of zone transfer between two entities, nor the identities of the nameservers hosting a zone (including both those acting as hidden primaries/secondaries or directly serving the zone) as sensitive information. The proposed mechanisms does not attempt to obscure @@ -275,21 +285,21 @@ infer relations between nameservers simply from traffic patterns, even when some or all of the traffic is encrypted It is noted that simply using XoT will indicate a desire by the zone owner that the contents of the zone remain confidential and so could be subject to blocking (e.g. via blocking of port 853) if an attacker had such capabilities. However this threat is likely true of any such mechanism that attempts to encrypt data passed between nameservers e.g. IPsec. -4. Connection and Data Flows in Existing XFR Mechanisms +5. 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. [RFC1995] and [RFC1996] introduced the concepts of IXFR and NOTIFY respectively, to provide for prompt propagation of zone updates. This has largely replaced AXFR where possible, particularly for dynamically updated zones. @@ -307,21 +317,21 @@ o SOA queries o Fallback from IXFR to AXFR o Fallback from IXFR-over-UDP to IXFR-over-TCP The term is used to encompasses the range of permutations that are possible and is useful to distinguish the 'XFR mechanism' from a single XFR request/response exchange. -4.1. AXFR Mechanism +5.1. AXFR Mechanism The figure below provides an outline of an AXFR mechanism including NOTIFYs. Secondary Primary | NOTIFY | | <-------------------------------- | UPD | --------------------------------> | | NOTIFY Response | @@ -375,21 +385,21 @@ Additionally, sections 4.1, 4.1.1 and 4.1.2 of [RFC5936] provide improved guidance for AXFR clients and servers with regard to re-use of TCP connections for multiple AXFRs and AXFRs of different zones. However [RFC5936] was constrained by having to be backwards compatible with some very early basic implementations of AXFR. For example, it outlines that the SOA query can also happen on this connection. However, this can cause interoperability problems with older implementations that support only the trivial case of one AXFR per connection. -4.2. IXFR Mechanism +5.2. IXFR Mechanism The figure below provides an outline of the IXFR mechanism including NOTIFYs. Secondary Primary | NOTIFY | | <-------------------------------- | UPD | --------------------------------> | | NOTIFY Response | @@ -441,65 +451,65 @@ IXFR-over-TCP. There may also be a fourth step where the secondary must fall back to AXFR because, e.g., the primary does not support IXFR. However it is noted that most widely used open source authoritative nameserver implementations (including both BIND [1] and NSD [2]) do IXFR using TCP by default in their latest releases. For BIND TCP connections are sometimes used for SOA queries but in general they are not used persistently and close after an IXFR is completed. -4.3. Data Leakage of NOTIFY and SOA Message Exchanges +5.3. Data Leakage of NOTIFY and SOA Message Exchanges This section attempts to presents a rationale for considering 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 of this RR is not discussed in the following sections. -4.3.1. NOTIFY +5.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 (QNAME,QCLASS,QTYPE). But since the only supported QTYPE for NOTIFY is SOA, this does not pose a potential leak. -4.3.2. SOA +5.3.2. SOA For hidden primaries or secondaries the SOA response leaks only the degree of lag of any downstream secondary. -5. Updates to existing specifications +6. Updates to existing specifications For convenience, the phrase 'XFR-over-TCP' is used in this document to mean both IXFR-over-TCP and AXFR-over-TCP and therefore statements that use it update both [RFC1995] and [RFC5936], and implicitly also apply to XoT. Differences in behavior specific to XoT are discussed - in Section 6. + in Section 7. Both [RFC1995] and [RFC5936] were published sometime before TCP was considered a first class transport for DNS. [RFC1995], in fact, says nothing with respect to optimizing IXFRs over TCP or re-using already open TCP connections to perform IXFRs or other queries. Therefore, there arguably is an implicit assumption (probably unintentional) that a TCP connection is used for one and only one IXFR request. Indeed, several open source implementations currently take this approach. And whilst [RFC5936] gives guidance on connection re-use for AXFR, it pre-dates more recent specifications describing - persistent TCP connections e.g. [RFC7626], [RFC7828] and AXFR + persistent TCP connections e.g. [RFC7766], [RFC7828] and AXFR implementations again often make less than optimal use of open connections. Given this, new implementations of XoT will clearly benefit from specific guidance on TCP/TLS connection usage for XFR because this will: o result in more consistent XoT implementations with better interoperability @@ -518,105 +528,105 @@ applies specifically to XFR exchanges. It also discusses how IXFR and AXFR can reuse the same TCP connection. For completeness, we also mention here the recent specification of extended DNS error (EDE) codes [RFC8914]. For zone transfers, when returning REFUSED to a zone transfer request to an 'unauthorized' client (e.g. where the client is not listed in an ACL for zone transfers or does not sign the request with the correct TSIG key), the extended DNS error code 18 (Prohibited) can also be sent. -5.1. Update to RFC1995 for IXFR-over-TCP +6.1. Update to RFC1995 for IXFR-over-TCP For clarity - an IXFR-over-TCP server compliant with this specification MUST be able to handle multiple concurrent IXoT requests on a single TCP connection (for the same and different zones) and SHOULD send the responses as soon as they are available, which might be out-of-order compared to the requests. -5.2. Update to RFC5936 for AXFR-over-TCP +6.2. Update to RFC5936 for AXFR-over-TCP For clarity - an AXFR-over-TCP server compliant with this specification MUST be able to handle multiple concurrent AXoT sessions on a single TCP connection (for the same and different zones). The response streams for concurrent AXFRs MAY be intermingled and AXFR-over-TCP clients compliant with this specification MUST be able to handle this. -5.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP +6.3. Updates to RFC1995 and RFC5936 for XFR-over-TCP -5.3.1. Connection reuse +6.3.1. Connection reuse As specified, XFR-over-TCP clients SHOULD re-use any existing open TCP connection when starting any new XFR request to the same primary, and for issuing SOA queries, instead of opening a new connection. The number of TCP connections between a secondary and primary SHOULD - be minimized (also see Section 5.4). + be minimized (also see Section 6.4). Valid reasons for not re-using existing connections might include: o reaching a configured limit for the number of outstanding queries or XFR requests allowed on a single TCP connection o the message ID pool has already been exhausted on an open connection o a large number of timeouts or slow responses have occurred on an open connection o an edns-tcp-keepalive EDNS0 option with a timeout of 0 has been received from the server and the client is in the process of - closing the connection (see Section 5.3.4) + closing the connection (see Section 6.3.4) If no TCP connections are currently open, XFR clients MAY send SOA queries over UDP or a new TCP connection. -5.3.2. AXFRs and IXFRs on the same connection +6.3.2. AXFRs and IXFRs on the same connection Neither [RFC1995] nor [RFC5936] explicitly discuss the use of a single TCP connection for both IXFR and AXFR requests. [RFC5936] does make the general state: "Non-AXFR session traffic can also use an open TCP connection." We clarify here that implementations capable of both AXFR and IXFR and compliant with this specification SHOULD o use the same TCP connection for both AXFR and IXFR requests to the same primary o pipeline such request and MAY intermingle them o send the response(s) for each request as soon as they are available i.e. responses MAY be sent intermingled -5.3.3. XFR limits +6.3.3. XFR limits The server MAY limit the number of concurrent IXFRs, AXFRs or total XFR transfers in progress, or from a given secondary, to protect server resources. [OPEN QUESTION] Testing has shown that BIND returns SERVFAIL if the limit on concurrent transfers is reached since this is regarded as a soft limit and a retry can/should succeed. Should there be a specific recommendation here about what is returned re: SERVFAIL vs REFUSED? [OPEN QUESTION] Is there a desire to define an additional XFR specific EDE code so that a client can determine why a specific XFR request was declined in this case e.g., Max concurrent XFR: too may concurrent transfers in progress. It could potentially contain a retry delay, or at least clients can apply a reasonable back-off for the retry. This could avoid retry storms which have been observed to actually increase the load on primaries in certain scenarios. -5.3.4. The edns-tcp-keepalive EDNS0 Option +6.3.4. The edns-tcp-keepalive EDNS0 Option XFR clients that send the edns-tcp-keepalive EDNS0 option on every XFR request provide the server with maximum opportunity to update the edns-tcp-keepalive timeout. The XFR server may use the frequency of recent XFRs to calculate an average update rate as input to the decision of what edns-tcp-keepalive timeout to use. If the server does not support edns-tcp-keepalive the client MAY keep the connection open for a few seconds ([RFC7766] recommends that servers use timeouts of at least a few seconds). @@ -630,33 +640,33 @@ We clarify here that if an OPT record is present in a received AXFR request, compliant responders MUST include an OPT record in each of the subsequent AXFR responses. Note that this requirement, combined with the use of edns-tcp-keepalive, enables AXFR servers to signal the desire to close a connection (when existing transactions have competed) due to low resources by sending an edns-tcp-keepalive EDNS0 option with a timeout of 0 on any AXFR response. This does not signal that the AXFR is aborted, just that the server wishes to close the connection as soon as possible. -5.3.5. Backwards compatibility +6.3.5. Backwards compatibility Certain legacy behaviors were noted in [RFC5936], with provisos that implementations may want to offer options to fallback to legacy behavior when interoperating with servers known not to support [RFC5936]. For purposes of interoperability, IXFR and AXFR implementations may want to continue offering such configuration options, as well as supporting some behaviors that were underspecified prior to this work (e.g. performing IXFR and AXFRs on separate connections). However, XoT implementations should have no need to do so. -5.4. Update to RFC7766 +6.4. Update to RFC7766 [RFC7766] made general implementation recommendations with regard to TCP/TLS connection handling: "To mitigate the risk of unintentional server overload, DNS clients MUST take care to minimize the number of concurrent TCP connections made to any individual server. It is RECOMMENDED that for any given client/server interaction there SHOULD be no more than one connection for regular queries, one for zone transfers, and one for each protocol that is being used on top @@ -691,36 +703,36 @@ o one TLS connection for zone transfers o one DoH connection for regular queries o one DoH connection for zone transfers We provide specific details in the later sections of reasons where more than one connection for a given transport might be required for zone transfers from a particular client. -6. XoT specification +7. XoT specification -6.1. TLS versions +7.1. TLS versions For improved security all implementations of this specification MUST use only TLS 1.3 [RFC8446] or later. -6.2. Port selection +7.2. Port selection The connection for XoT 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 XoT. There MAY be agreement to use different ports for AXoT and IXoT, or for different zones. -6.3. High level XoT descriptions +7.3. High level XoT descriptions It is useful to note that in XoT 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. The figure below provides an outline of the AXoT mechanism including NOTIFYs. Secondary Primary @@ -781,55 +793,55 @@ | | | TLS | | | session | IXFR Request | | | --------------------------------> | | | <-------------------------------- | | | IXFR Response | | | (Zone data) | --- Figure 1. IXoT Mechanism -6.4. XoT transfers +7.4. XoT transfers For a zone transfer between two end points to be considered protected with XoT all XFR requests and response for that zone MUST be sent over TLS connections where at a minimum: o the client MUST authenticate the server by use of an authentication domain name using a Strict Privacy Profile as described in [RFC8310] o the server MUST validate the client is authorized to request or proxy a zone transfer by using one or both of the following: * an IP based ACL (which can be either per-message or per- connection) * Mutual TLS (mTLS) The server MAY also require a valid TSIG/SIG(0) signature, but this alone is not sufficient to authenticate the client or server. - Authentication mechanisms are discussed in full in Section 8 and the - rationale for the above requirement in Section 9. Transfer group - policies are discussed in Section 10. + Authentication mechanisms are discussed in full in Section 9 and the + rationale for the above requirement in Section 10. Transfer group + policies are discussed in Section 11. -6.5. XoT connections +7.5. XoT connections - The details in Section 5 about e.g., persistent connections and XFR + The details in Section 6 about e.g., persistent connections and XFR message handling are fully applicable to XoT connections as well. However any behavior specified here takes precedence for XoT. If no TLS connections are currently open, XoT clients MAY send SOA queries over UDP or TCP, or TLS. -6.6. XoT vs ADoT +7.6. XoT vs ADoT As noted earlier, there is currently no specification for encryption of connections from recursive resolvers to authoritative servers. Some authoritatives are experimenting with ADoT and opportunistic encryption has also been raised as a possibility; it is therefore highly likely that use of encryption by authoritative servers will evolve in the coming years. This raises questions in the short term,S.S. with regard to TLS connection and message handling for authoritative servers. In @@ -846,52 +858,52 @@ evaluated when considering applying the same model to XoT. Proposing that a server should also start responding to all queries received over TLS just because it has enabled XoT would be equivalent to defining a form of authoritative DoT. This specification does not propose that, but it also does not prohibit servers from answering queries unrelated to XFR exchanges over TLS. Rather, this specification simply outlines in later sections: o how XoT implementations should utilize EDE codes in response to queries on TLS connections they are not willing to answer (see - Section 6.7) + Section 7.7) o the operational and policy options that a XoT server operator has with regard to managing TLS connections and messages (see Appendix A) -6.7. Response RCODES +7.7. Response RCODES XoT clients and servers MUST implement EDE codes. If a XoT server receives non-XoT traffic it is not willing to answer on a TLS connection it SHOULD respond with the extended DNS error code 21 - Not Supported [RFC8914]. XoT clients should not send any further queries of this type to the server for a reasonable period of time (for example, one hour) i.e., long enough that the server configuration or policy might be updated. [OPEN QUESTION] Should this instead be Prohibited (by policy), or should a new EDE be created for this case? Historically servers have used the REFUSED RCODE for many situations, and so clients often had no detailed information on which to base an error or fallback path when queries were refused. As a result the - client behavior could vary significantly. XoT severs that refuse + client behavior could vary significantly. XoT servers that refuse queries must cater for the fact that client behavior might vary from continually retrying queries regardless of receiving REFUSED to every query, or at the other extreme clients may decide to stop using the server over any transport. This might be because those clients are either non-XoT clients or do not implement EDE codes. -6.8. AXoT specifics +7.8. AXoT specifics -6.8.1. Padding AXoT responses +7.8.1. Padding AXoT responses The goal of padding AXoT responses would be two fold: o to obfuscate the actual size of the transferred zone to minimize information leakage about the entire contents of the zone. o to obfuscate the incremental changes to the zone between SOA updates to minimize information leakage about zone update activity and growth. @@ -927,81 +939,81 @@ future padding policies, we state here that secondary implementations MUST be resilient to receiving padded AXoT responses, including 'empty' AXoT responses that contain only an OPT RR containing the EDNS(0) option for padding. Recommendation of specific policies for padding AXoT responses are out of scope for this specification. Detailed considerations of such policies and the trade-offs involved are expected to be the subject of future work. -6.9. IXoT specifics +7.9. IXoT specifics -6.9.1. Condensation of responses +7.9.1. Condensation of responses [RFC1995] says condensation of responses is optional and MAY be done. Whilst it does add complexity to generating responses it can significantly reduce the size of responses. However any such reduction might be offset by increased message size due to padding. This specification does not update the optionality of condensation for XoT responses. -6.9.2. Fallback to AXFR +7.9.2. 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. Just as with IXFR-over-TCP, after a failed IXFR a IXoT client SHOULD request the AXFR on the already open XoT connection. -6.9.3. Padding of IXoT responses +7.9.3. Padding of IXoT responses The goal of padding IXoT responses would be to obfuscate the incremental changes to the zone between SOA updates to minimize information leakage about zone update activity and growth. Both the size and timing of the IXoT responses could reveal information. IXFR responses can vary in size greatly from the order of 100 bytes for one or two record updates, to tens of thousands of bytes for large dynamic DNSSEC signed zones. The frequency of IXFR responses can also depend greatly on if and how the zone is DNSSEC signed. In order to guarantee support for future padding policies, we state here that secondary implementations MUST be resilient to receiving padded IXoT responses. Recommendation of specific policies for padding IXoT responses are out of scope for this specification. Detailed considerations of such policies and the trade-offs involved are expected to be the subject of future work. -6.10. Name compression and maximum payload sizes +7.10. Name compression and maximum payload sizes It is noted here that name compression [RFC1035] can be used in XFR responses to reduce the size of the payload, however the maximum value of the offset that can be used in the name compression pointer structure is 16384. For some DNS implementations this limits the size of an individual XFR response used in practice to something around the order of 16kB. In principle, larger payload sizes can be supported for some responses with more sophisticated approaches (e.g. by pre-calculating the maximum offset required). Implementations may wish to offer options to disable name compression for XoT responses to enable larger payloads. This might be particularly helpful when padding is used since minimizing the payload size is not necessarily a useful optimization in this case and disabling name compression will reduce the resources required to construct the payload. -7. Multi-primary Configurations +8. Multi-primary Configurations Also known as multi-master configurations this model can provide flexibility and redundancy particularly for IXFR. A secondary will receive one or more NOTIFY messages and can send an SOA to all of the configured primaries. It can then choose to send an XFR request to the primary with the highest SOA (or other criteria, e.g., RTT). When using persistent connections the secondary may have a XoT connection already open to one or more primaries. Should a secondary preferentially request an XFR from a primary to which it already has @@ -1021,164 +1033,164 @@ open to all available primaries and only request XFRs from the primary with the highest serial number. Since normally the number of secondaries and primaries in direct contact in a transfer group is reasonably low this might be feasible if latency is the most significant concern. Recommendation of a particular scheme is out of scope of this document but implementations are encouraged to provide configuration options that allow operators to make choices about this behavior. -8. Authentication mechanisms +9. Authentication mechanisms - To provide context to the requirements in section Section 6.4, this + To provide context to the requirements in section Section 7.4, this section provides a brief summary of some of the existing authentication and validation mechanisms (both transport independent and TLS specific) that are available when performing zone transfers. - Section 9 then discusses in more details specifically how a + Section 10 then discusses in more details specifically how a combination of TLS authentication, TSIG and IP based ACLs interact for XoT. We classify the mechanisms based on the following properties: o 'Data Origin Authentication' (DO): Authentication that the DNS message originated from the party with whom credentials were shared, and of the data integrity of the message contents (the originating party may or may not be party operating the far end of a TCP/TLS connection in a 'proxy' scenario). o 'Channel Confidentiality' (CC): Confidentiality of the communication channel between the client and server (i.e. the two end points of a TCP/TLS connection) from passive surveillance. o 'Channel Authentication' (CA): Authentication of the identity of party to whom a TCP/TLS connection is made (this might not be a direct connection between the primary and secondary in a proxy scenario). -8.1. TSIG +9.1. TSIG TSIG [RFC2845] provides a mechanism for two or more parties to use shared secret keys which can then be used to create a message digest to protect individual DNS messages. This allows each party to authenticate that a request or response (and the data in it) came from the other party, even if it was transmitted over an unsecured channel or via a proxy. Properties: Data origin authentication -8.2. SIG(0) +9.2. SIG(0) - SIG(0) [RFC2535] similarly also provides a mechanism to digitally + SIG(0) [RFC2931] similarly also provides a mechanism to digitally sign a DNS message but uses public key authentication, where the public keys are stored in DNS as KEY RRs and a private key is stored at the signer. Properties: Data origin authentication -8.3. TLS +9.3. TLS -8.3.1. Opportunistic TLS +9.3.1. Opportunistic TLS Opportunistic TLS for DoT is defined in [RFC8310] and can provide a defense against passive surveillance, providing on-the-wire confidentiality. Essentially o clients that know authentication information for a server SHOULD try to authenticate the server o however they MAY fallback to using TLS without authentication and - o they MAY fallback to using cleartext is TLS is not available. + o they MAY fallback to using cleartext if TLS is not available. As such it does not offer a defense against active attacks (e.g. a MitM attack on the connection from client to server), and is not considered as useful for XoT. Properties: None guaranteed. -8.3.2. Strict TLS +9.3.2. Strict TLS Strict TLS for DoT [RFC8310] requires that a client is configured with an authentication domain name (and/or SPKI pinset) that MUST be used to authenticate the TLS handshake with the server. If authentication of the server fails, the client will not proceed with the connection. This provides a defense for the client against active surveillance, providing client-to-server authentication and end-to-end channel confidentiality. Properties: Channel confidentiality and authentication (of the server). -8.3.3. Mutual TLS +9.3.3. Mutual TLS This is an extension to Strict TLS [RFC8310] which requires that a client is configured with an authentication domain name (and/or SPKI pinset) and a client certificate. The client offers the certificate for authentication by the server and the client can authentic the server the same way as in Strict TLS. This provides a defense for both parties against active surveillance, providing bi-directional authentication and end-to-end channel confidentiality. Properties: Channel confidentiality and mutual authentication. -8.4. IP Based ACL on the Primary +9.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 on a per query basis. This is also possible with XoT but it must be noted that, as with TCP, the implementation of such an ACL cannot be enforced on the primary until an XFR request is received on an established connection. As discussed in Appendix A an IP based per connection ACL could also be implemented where only TLS connections from recognized secondaries are accepted. Properties: Channel authentication of the client. -8.5. ZONEMD +9.5. ZONEMD For completeness, we also describe Message Digest for DNS Zones (ZONEMD) [I-D.ietf-dnsop-dns-zone-digest] here. The message 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: "As specified herein, ZONEMD is impractical for large, dynamic zones due to the time and resources required for digest calculation. However, The ZONEMD record is extensible so that new digest schemes may be added in the future to support large, dynamic zones." It is complementary but orthogonal the above mechanisms; and can be used in conjunction with XoT but is not considered further here. -9. XoT authentication +10. XoT authentication It is noted that zone transfer scenarios can vary from a simple single primary/secondary relationship where both servers are under the control of a single operator to a complex hierarchical structure which includes proxies and multiple operators. Each deployment scenario will require specific analysis to determine which combination of authentication methods are best suited to the deployment model in question. - The XoT authentication requirement specified in Section 6.4 addresses + The XoT authentication requirement specified in Section 7.4 addresses the issue of ensuring that the transfers is encrypted between the two endpoints directly involved in the current transfers. The following table summarized the properties of a selection of the mechanisms - discussed in Section 8. The two letter acronyms for the properties + discussed in Section 9. The two letter acronyms for the properties are used below and (S) indicates the secondary and (P) indicates the primary. +----------------+-------+-------+-------+-------+-------+-------+ | Method | DO(S) | CC(S) | CA(S) | DO(P) | CC(P) | CA(P) | +----------------+-------+-------+-------+-------+-------+-------+ | Strict TLS | | Y | Y | | Y | | | Mutual TLS | | Y | Y | | Y | Y | | ACL on primary | | | | | | Y | | TSIG | Y | | | Y | | | @@ -1193,21 +1205,21 @@ o Using Strict TLS and an IP based ACL on the primary also provides authentication of both end points o Additional use of TSIG (or equally SIG(0)) can also provide data origin authentication which might be desirable for deployments that include a proxy between the secondary and primary, but is not part of the XoT requirement because it does nothing to guarantee channel confidentiality or authentication. -10. Policies for Both AXoT and IXoT +11. Policies for Both AXoT and IXoT Whilst the protection of the zone contents in a transfer between two end points can be provided by the XoT protocol, the protection of all the transfers of a given zone requires operational administration and policy management. We call the entire group of servers involved in XFR for a particular set of zones (all the primaries and all the secondaries) the 'transfer group'. @@ -1216,21 +1228,21 @@ In order to assure the confidentiality of the zone information, the entire transfer group MUST have a consistent policy of requiring confidentiality. If any do not, this is a weak link for attackers to exploit. An individual zone transfer is not considered protected by XoT unless both the client and server are configured to use only XoT and the overall zone transfer is not considered protected until all members of the transfer group are configured to use only XoT with all other - transfers servers (see Section 11). + transfers servers (see Section 12). A XoT policy should specify o What kind of TLS is required (Strict or Mutual TLS) o or if an IP based ACL is required. o (optionally) if TSIG/SIG(0) is required Since this may require configuration of a number of servers who may @@ -1241,83 +1253,89 @@ independently, e.g., by requesting zone transfers without TSIG, from unauthorized IP addresses or over cleartext DNS. Other aspects such as if a secondary will accept data without a TSIG digest or if secondaries are using Strict as opposed to Opportunistic TLS are more challenging. The mechanics of co-ordinating or enforcing such policies are out of the scope of this document but may be the subject of future operational guidance. -11. Implementation Considerations +12. Implementation Considerations Server implementations may want to also offer options that allow ACLs on a zone to specify that a specific client can use either XoT or TCP. This would allow for flexibility while clients are migrating to XoT. Client implementations may similarly want to offer options to cater for the multi-primary case where the primaries are migrating to XoT. Such configuration options MUST only be used in a 'migration mode' though and therefore should be used with care. -12. Implementation Status +13. Implementation Status The 1.9.2 version of Unbound [3] includes an option to perform AXoT (instead of AXFR-over-TCP). This requires the client (secondary) to authenticate the server (primary) using a configured authentication domain name. It is noted that use of a TLS proxy in front of the primary server is a simple deployment solution that can enable server side XoT. -13. IANA Considerations +14. IANA Considerations -14. Security Considerations +15. 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. This does not mitigate: o the risk that some level of zone activity might be inferred by observing zone transfer sizes and timing on encrypted connections (even with padding applied), in combination with obtaining SOA records by directly querying authoritative servers. o the risk that hidden primaries might be inferred or identified via observation of encrypted connections. o the risk of zone contents being obtained via zone enumeration techniques. Security concerns of DoT are outlined in [RFC7858] and [RFC8310]. -15. Acknowledgements +16. Acknowledgements The authors thank Tony Finch, Peter van Dijk, Benno Overeinder, Shumon Huque and Tim Wicinski for review and discussions. -16. Contributors +17. Contributors Significant contributions to the document were made by: Han Zhang Salesforce San Francisco, CA United States Email: hzhang@salesforce.com -17. Changelog +18. Changelog + + draft-ietf-dprive-xfr-over-tls-04 + + o Add Github repository + + o Fix typos and improve layout. draft-ietf-dprive-xfr-over-tls-03 o Remove propose to use ALPN o Clarify updates to both RFC1995 and RFC5936 by adding specific sections on this o Add a section on the threat model @@ -1366,23 +1384,23 @@ o Substantial re-work of the document. draft-hzpa-dprive-xfr-over-tls-01 o Editorial changes, updates to references. draft-hzpa-dprive-xfr-over-tls-00 o Initial commit -18. References +19. References -18.1. Normative References +19.1. Normative References [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. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . @@ -1453,37 +1471,37 @@ [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, . [RFC8914] Kumari, W., Hunt, E., Arends, R., Hardaker, W., and D. Lawrence, "Extended DNS Errors", RFC 8914, DOI 10.17487/RFC8914, October 2020, . -18.2. Informative References +19.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-14 (work in progress), October 2020. [I-D.ietf-dprive-dnsoquic] Huitema, C., Mankin, A., and S. Dickinson, "Specification of DNS over Dedicated QUIC Connections", draft-ietf- dprive-dnsoquic-01 (work in progress), October 2020. [I-D.ietf-dprive-phase2-requirements] Livingood, J., Mayrhofer, A., and B. Overeinder, "DNS Privacy Requirements for Exchanges between Recursive Resolvers and Authoritative Servers", draft-ietf-dprive- - phase2-requirements-01 (work in progress), June 2020. + phase2-requirements-02 (work in progress), November 2020. [I-D.ietf-tls-esni] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS Encrypted Client Hello", draft-ietf-tls-esni-08 (work in progress), October 2020. [I-D.vandijk-dprive-ds-dot-signal-and-pin] Dijk, P., Geuze, R., and E. Bretelle, "Signalling Authoritative DoT support in DS records, with key pinning", draft-vandijk-dprive-ds-dot-signal-and-pin-01 @@ -1492,39 +1510,39 @@ [nist-guide] Chandramouli, R. and S. Rose, "Secure Domain Name System (DNS) Deployment Guide", 2013, . [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, DOI 10.17487/RFC1982, August 1996, . - [RFC2535] Eastlake 3rd, D., "Domain Name System Security - Extensions", RFC 2535, DOI 10.17487/RFC2535, March 1999, - . + [RFC2931] Eastlake 3rd, D., "DNS Request and Transaction Signatures + ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, September + 2000, . [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . [RFC8484] Hoffman, P. and P. McManus, "DNS Queries over HTTPS (DoH)", RFC 8484, DOI 10.17487/RFC8484, October 2018, . -18.3. URIs +19.3. URIs [1] https://www.isc.org/bind/ [2] https://www.nlnetlabs.nl/projects/nsd/about/ [3] https://github.com/NLnetLabs/unbound/blob/release-1.9.2/doc/ Changelog Appendix A. XoT server connection handling