--- 1/draft-ietf-dprive-xfr-over-tls-04.txt 2021-01-20 08:16:36.679502010 -0800 +++ 2/draft-ietf-dprive-xfr-over-tls-05.txt 2021-01-20 08:16:36.759504043 -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 27, 2021 S. Sahib +Expires: July 24, 2021 S. Sahib P. Aras A. Mankin Salesforce - November 23, 2020 + January 20, 2021 DNS Zone Transfer-over-TLS - draft-ietf-dprive-xfr-over-tls-04 + draft-ietf-dprive-xfr-over-tls-05 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,25 +32,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 27, 2021. + This Internet-Draft will expire on July 24, 2021. Copyright Notice - Copyright (c) 2020 IETF Trust and the persons identified as the + Copyright (c) 2021 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 @@ -102,36 +102,36 @@ 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 + 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 + 15. Security Considerations . . . . . . . . . . . . . . . . . . . 29 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 17. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 29 18. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 29 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 19.1. Normative References . . . . . . . . . . . . . . . . . . 31 - 19.2. Informative References . . . . . . . . . . . . . . . . . 32 + 19.2. Informative References . . . . . . . . . . . . . . . . . 33 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.1. Only listen on TLS on a specific IP address . . . . . . . 35 + A.2. Client specific TLS acceptance . . . . . . . . . . . . . 35 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 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 37 1. Introduction DNS has a number of privacy vulnerabilities, as discussed in detail in [RFC7626]. Stub client to recursive resolver query privacy has received the most attention to date, with standards track documents for both DNS-over-TLS (DoT) [RFC7858] and DNS-over-HTTPS (DoH) [RFC8484], and a proposal for DNS-over-QUIC [I-D.ietf-dprive-dnsoquic]. There is ongoing work on DNS privacy requirements for exchanges between recursive resolvers and @@ -325,21 +325,21 @@ single XFR request/response exchange. 5.1. AXFR Mechanism The figure below provides an outline of an AXFR mechanism including NOTIFYs. Secondary Primary | NOTIFY | - | <-------------------------------- | UPD + | <-------------------------------- | UDP | --------------------------------> | | NOTIFY Response | | | | | | SOA Request | | --------------------------------> | UDP (or part of | <-------------------------------- | a TCP session) | SOA Response | | | | | @@ -393,21 +393,21 @@ per connection. 5.2. IXFR Mechanism The figure below provides an outline of the IXFR mechanism including NOTIFYs. Secondary Primary | NOTIFY | - | <-------------------------------- | UPD + | <-------------------------------- | UDP | --------------------------------> | | NOTIFY Response | | | | | | SOA Request | | --------------------------------> | UDP or TCP | <-------------------------------- | | SOA Response | | | | | @@ -596,35 +596,23 @@ 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 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. + server resources. Servers SHOULD return SERVFAIL if this limit is + hit, since it is a transient error and a retry at a later time might + succeed. 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 @@ -642,22 +630,22 @@ 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. 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 + Certain legacy behaviors were noted in [RFC5936], with provisions + 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. 6.4. Update to RFC7766 @@ -731,21 +718,21 @@ 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 | NOTIFY | - | <-------------------------------- | UPD + | <-------------------------------- | UDP | --------------------------------> | | NOTIFY Response | | | | | | SOA Request | | --------------------------------> | UDP (or part of | <-------------------------------- | a TCP/TLS session) | SOA Response | | | | | @@ -766,21 +753,21 @@ | | Figure 3. AXoT Mechanism The figure below provides an outline of the IXoT mechanism including NOTIFYs. Secondary Primary | NOTIFY | - | <-------------------------------- | UPD + | <-------------------------------- | UDP | --------------------------------> | | NOTIFY Response | | | | | | SOA Request | | --------------------------------> | UDP (or part of | <-------------------------------- | a TCP/TLS session) | SOA Response | | | | | @@ -874,23 +861,20 @@ 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 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. @@ -1264,34 +1248,47 @@ 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. + though, and therefore should be used with care. 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 + 1. The 1.9.2 version of Unbound [3] includes an option to perform + AXoT (instead of AXFR-over-TCP). + + 2. There are currently open pull requests against NSD to implement + + 1. Connection re-use by default during XFR-over-TCP [4] + + 2. Client side XFR-over-TLS [5] + + 3. Version 9.17.7 of BIND contained an initial implementation of + DoT, implementation of XoT is planned for early 2021 [6] + + Both items 1. and 2.2. listed above require the client (secondary) to authenticate the server (primary) using a configured authentication - domain name. + domain name if XoT is used. 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. 14. IANA Considerations + None. + 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 @@ -1317,25 +1314,28 @@ Han Zhang Salesforce San Francisco, CA United States Email: hzhang@salesforce.com 18. Changelog - draft-ietf-dprive-xfr-over-tls-04 + draft-ietf-dprive-xfr-over-tls-05 + + o Remove the open questions that received no comments. + o Add more detail to the implementation section o Add Github repository - o Fix typos and improve layout. + o Fix typos and references 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 @@ -1363,23 +1364,20 @@ o Update security considerations o Move multi-primary considerations to earlier as they are related to connection handling draft-ietf-dprive-xfr-over-tls-01 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. @@ -1491,22 +1489,22 @@ 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-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. + Encrypted Client Hello", draft-ietf-tls-esni-09 (work in + progress), December 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 (work in progress), July 2020. [nist-guide] Chandramouli, R. and S. Rose, "Secure Domain Name System (DNS) Deployment Guide", 2013, @@ -1537,20 +1535,26 @@ 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 + [4] https://github.com/NLnetLabs/nsd/pull/145 + + [5] https://github.com/NLnetLabs/nsd/pull/149 + + [6] https://gitlab.isc.org/isc-projects/bind9/-/issues/1784 + Appendix A. XoT server connection handling For completeness, it is noted that an earlier version of the specification suggested using a XoT specific ALPN to negotiate TLS connections that supported only a limited set of queries (SOA, XRFs) however this did not gain support. Reasons given included additional code complexity and proxies having no natural way to forward the ALPN signal to DNS nameservers over TCP connections. A.1. Only listen on TLS on a specific IP address