Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.
In further discussions it became clear that the authors do not intend for XoT traffic to use an ALPN code at all. I'm afraid this may be a misunderstanding of previous guidance from TLS that XoT did not need its own ALPN code, but could simply use the DoT ALPN since the messages are distinguishable on the wire. To not use an ALPN at all violates best TLS practice. The reasoning given in Appendix A, that this creates difficulty for proxies, doesn't make sense to me. We can talk about it in the telechat.
- There ought to be a warning somewhere that mTLS verifies that the CA has verified identity, while IP ACLs merely prove that the bearer can observe the path to the address. The former is much stronger than the latter, unless there are more mechanisms built into the ACL than are obvious from the text here.
My understanding is that this point is essentially overtaken by events, as a similar concern was raised already by Martin D, John, and Roman, and there is a commitment to update the text already made. I'm putting it in at the Discuss level to make sure that I follow-up on the revised text when it appears. But, for concreteness: the text in Sections 8.4, 10.4, and 11 treat cryptographic mTLS, TSIG, and SIG(0) authentication as providing an equivalent level of protection to the (non-cryptographic) IP ACL. My understanding is that IETF consensus is to prefer cryptographic mechanisms for authentication and authorization, when available. Relatedly, the text in Section 8.4 says that TSIG/SIG(0) are "not sufficient to authenticate the client or server", which is technically true, but also seems misleading. In XFR scenarios it's not clear that specific identification (authentication) of the counterparty is necessary for secure operation, if authorization to receive/send the zone can be established without specific identification. My undersatnding is that, when combined with a strict TLS profile for server authentication and appropriate trust policy on TLS clients, TSIG and SIG(0) both serve to provide proof of authorization for the exchange even though they only provide authentication in the form of group membership (the relevant key material is typically available to multiple machines). As such, don't they provide strong enough cryptographic protection (and end-to-end, no less!) to be a superior authorization mechanism than an IP ACL? (Any resulting text changes may bleed into Sections 11 and 12 in addition to 8.4, per my COMMENT.)
I support Martin D's discuss about using the DoT ALPN value. The Introduction might mention the three documents being updated (in addition to the Abstract and the dedicated document sections for effectuating the updates). We typically treat Abstract and Introduction as things that are consumed entirely independently, even if that is not always true in practice. Both Abstract and Introduction could probably stand to say a bit more about how this document is also providing general updates and optimizations for DNS-over-TCP behavior (mostly, but not entirely, for XFR-over-TCP), in addition to the details of XoT itself. (This is understandable since providing support for XoT is a convenient milestone that other updates can be attached to.) Thank you for updating in account of the genart reviewer; that saved me a few comments. I made some editorial suggestions via a github pull request at: https://github.com/hanzhang0116/hzpa-dprive-xfr-over-tls/pull/25 Section 1 In what way is exposing the full contents of a zone a privacy risk? Brainstorming, in split-DNS scenarios the contents of the "internal" zone might only be intended for authenticated+authorized users, and leaking it would provide reconaissance into the internal network. hard to enumerate an DNSSEC signed zone as an unsigned zone). Whilst this is widely used, zone walking is now possible with NSEC3 due to crypto-breaking advances. This has prompted further work on an alternative mechanism for DNSSEC authenticated denial of existence - NSEC5 [I-D.vcelak-nsec5] - however questions remain over the practicality of this mechanism. Do we want to consider direct reference(s) for "crypto-breaking advances" instead of leaving a layer of indirection through the nsec5 draft? I would also strongly suggest demystifying the NSEC3 zone-walking mechanism and not suggesting that there has been a magic break against cryptographic hashes. If I understand correctly, a mechanism roughly analogous to the classical NSEC-walking mechanism is used to enumerate the hash intervals in the zone, and then a standard brute-forcing mechanism is applied to the hash values, facilitated by knowledge of the structure of domain names (and optionally the statistical distribution of domain names as well). So this might instead become: > Whilst this is widely used, zone walking is also possible with NSEC3. > The initial procedure finds the hashed forms of the names in the zone, > and using the known properties and distributions of domain names, > brute-force attacks to recover the un-hashed names are feasible. This > has prompted further work [...] transfers using ACLs and TSIG in more detail. It also discusses the possibility that specific deployments might choose to use a lower level network layer to protect zone transfers, e.g., IPSec. I think the wording might be off, here, perhaps s/lower level network layer/lower level security layer/? 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 (1.3 or later) as a transport to prevent zone collection from zone transfers. This seems to be the first standalone mention of TLS, so an RFC 8446 reference is probably appropriate. Section 3 Please use the boilerplate from RFC 8174 verbatim (it does not have an "and" between [RFC2119] and [RFC8174], at least). Section 4 o an attacker who can monitor network traffic can relatively easily infer relations between nameservers simply from traffic patterns, even when some or all of the traffic is encrypted This is generally true, though I could construct some scenarios (e.g., using draft-ietf-ipsecme-iptfs) where it would not hold. This would generally only be achievable for the defender at significant cost in unneeded ("chaff") traffic, though. Should we qualify this statement somehow, e.g., in terms of current deployments or the common case? Section 5 I suggest including a preface to the list, other than the section title. Perhaps "The following principles [are/were] considered in the design for XoT"? * Current usage of TCP for IXFR is sub-optimal in some cases i.e. connections are frequently closed after a single IXFR. Perhaps say something about how XoT is an opportunity to improve performance by providing different guidance, as was done for the "backwards compatibility" sub-bullet? Section 6.3 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. It seems it *is* discussed, though, in the context of hidden primaries or secondaries (which is qualitatively different from "the published zone" and thus not quite in conflict with the first part of the claim). Section 7 o remove any need for XoT implementations to support legacy behavior that XFR-over-TCP implementations have historically often supported I'm not sure I follow the reasoning for "remove any need". If an authoritative resolver implementation that supports XoT also needs to talk to any non-XoT-supporting primary or secondary, it seems like it may still need that legacy behavior. I see how an XoT-only implementation can divest the legacy baggage, but don't think we can get to assuming XoT-only in a single step. Section 7.x Is it possible to give clarity about which sections or which behaviors are being updated in these respective subsections? Section 7.2 zones). The response streams for concurrent AXFRs MAY be intermingled and AXFR-over-TCP clients compliant with this specification which pipeline AXFR requests MUST be able to handle this. Should we say anything about the demultiplexing strategy here (DNS header message ID?)? Section 7.3.2 o pipeline such requests (if they pipeline XFR requests in general) and MAY intermingle them I don't think I understand what it means to intermingle *requests* (vs responses). Is this defined somewhere that could be referenced? Section 7.3.5 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. Similarly to my remark on Section 7, does this only hold for "XoT-only implementations"? Section 7.4 Just to check my understanding, these updates to RFC 7766 apply for all cases, not just XFR (in contrast to the Section 7.3 updates, which only apply for XFR scenarios)? I wonder if this could be emphasized somehow (as well as that these updates apply for regular DNS over TCP, not just DoT), though I don't have any ideas at the moment. Section 8.1 For improved security all implementations of this specification MUST use only TLS 1.3 [RFC8446] or later. (nit) improved over what baseline? Perhaps "In order to provide the highest level of security protections"? Section 8.3 (nit) is there some reason why the SOA request/response exchange could not be done on an unencrypted TCP connection (not that there would be much reason to do so if TCP/TLS is to be used for the actual XFR)? Section 8.7 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 (non-normative) requirement seems vague and unactionable. Can we give any more precise guidance on when the SHOULD from the previous can be ignored? (We might also clarify that the EDE code 21 is (likely?) to accompany a REFUSED RCODE, since we only mention REFUSED in this paragraph.) Section 8.8.1 Note that the re-use of XoT connections for transfers of multiple different zones complicates any attempt to analyze the traffic size and timing to extract information. I might try to hedge this statement a bit. While it is technically true that analyzing the combined transfer is more complicated than analyzing individual transfers in isolation, past experience in traffic analysis (combined with the ability to query the live serial numbers of the domains being served) suggests that the additional burden on the attacker is not very large. Section 8.9.3 I'd suggest mentioning the possibility that a client will have to send dummy IXFR requests in order to achieve the strongest level of obfuscation (thus triggering dummy responses that do not correspond to actual zone updates). I don't have a great sense for how many ways such dummy requests can be formed (is just asking for a repeat of the previously requested delta going to work?) or whether it is worth emphasizing that servers will need to be prepared to handle such requests, though. We don't need to specify the actual mechanism here, just raise awareness that some mechanism might be used/defined in the future. Section 9 The way we describe two potential options for policy on secondaries for selecting which primary to request XFR from risks running afoul of the RFC 7127 characterization that proposed standards have "resolved known design choices". I am choosing to not ballot Discuss on this topic because the scenario is predicated on there existing a multi-primary configuration, which suggests that any server that is primary is authorized to be a source of the data, and thus that there is not supposed to be a difference in end result regardless of which primary is selected. Section 11 In the vein of my discuss point, it's not entirely clear whether it's more important to focus on client authentication or client authorization. TSIG and SIG(0) seem to be better modeled as authorization mechanisms than authentication ones (in addition to providing DO as already indicated), and considering the questino of authorization to initiate XFR may be more relevant to operational needs than specifically authentication of the client (which is just going to be used as input to an ACL that performs an authorization check). Section 12 Within any transfer group both AXFRs and IXFRs for a zone MUST all use the same policy, e.g., if AXFRs use AXoT then all IXFRs MUST use IXoT. 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. These two requirements seem to be at least partially redundant. It's also not entirely clear to me how useful it is to preclude the possibility of a mixed environment where all the protocols used provide equivalent levesl of confidentiality protection. (The latter requirement on protecting confidentiality does not preclude this possibility, to be clear, just the example policy of "MUST use XoT".) 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 I'm not sure this is a clear way to spell the required behavior. In particular, my understanding is that strict TLS is always required, plus at least one of TLS client authentication (for mutual TLS) or IP ACL. The rest of the document suggests that TSIG/SIG(0) is an orthogonal axis, but my understanding is that TSIG/SIG(0), as cryptographic mechanisms, would be preferred over the IP ACL, and in fact that they would fill the roll well enough to be able to serve as a third option alongside TLS client authentication and IP ACL. I understand that some changes to the exposition in this area are in preparation based on the feedback already received from Martin D, John, and Roman, and may have further comments when the updated text is available. Certain aspects of the Policies can be relatively easily tested 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. (Pedantically, I don't think it would be very hard to acquire a certificate+private key that could be used to produce a TLS connection that would succeed if the secondary is using opportunistic TLS and fail under strict TLS -- a self-signed certificate not expected to be trusted would likely suffice. That said, I don't dispute the "more challenging" characterization, since the operational consequences of actually using that mechanism to test the behavior of the secondary could be significant.) Section 14 Is there anything useful to say about a hidden primary setup where the primary serves only XFR and not regular queries? Off the top of my head it might allow for enforcing the IP ACL sooner, before an actual XFR request is seen, but I expect that my insight is not the most useful contribution in this space. Similarly, such a hidden primary might reject all non-TLS connections, etc. Section 16 Both items 1. and 2.2. listed above require the client (secondary) to authenticate the server (primary) using a configured authentication domain name if XoT is used. I recognize that this section is to be removed for publication, but knowing what is used as the X.509 trust store along with the configured authentication domain name would be interesting. Section 21.2 Though RFC 2931 is not referenced in many places, the prose does have some MAY-level guidance to use TSIG and SIG(0) as providing equivalent protection, so I think that RFC 2931 should be classified as normative just as RFC 8945 is. (It's a proposed standard so there is no downref issue.) I guess that RFC 6891 is going to be transatively normative by way of Extended DNS Errors and RFC 7828, but I'm not going to insist that it be classified directly as normative here. Section A.3 I'm extremely reluctant to suggest using SNI in this manner (as an impromptu authorization bearer token, akin to port knocking). At a protocol level it would be just as easy to configure the use of TLS with pre-shared key, that would provide real security. Note that as of RFC 8773 it is permitted to use a PSK and certificate authentication in combination, so use of PSK in this manner would not (again, at the protocol level) impede security. Implementation support is probably lacking on this front, but that's no different than the currently described mechanism... Because this topic relates to TLS usage, I have started an email thread with the TLS WG for it: https://mailarchive.ietf.org/arch/msg/tls/ZIPo1mF_wnOXkgS7Uv_wzIBFmR8/ The tentative recommendation so far is in rough agreement with my instincts, and suggest removing the entire appendix. Section A.4 Some primaries might rely on TSIG/SIG(0) combined with per-query IP based ACLs to authenticate secondaries. In this case the primary must accept all incoming TLS connections and then apply a TLS specific response policy on a per query basis. (nit) Is this actually necessarily a "TLS-specific" response policy? IIUC essentially the same procedures apply today for DNS-over-TCP XFR. Cons: The server must handle the burden of accepting all TLS connections just to perform XFRs with a small number of secondaries. Client behavior to REFUSED response is not clearly defined (see below). [...] (nit) Is this still "below"? I recall discussion of this up in §8.7 and there's not much left in the document... Section A.4.1 (Similar concerns as for A.3, above, apply to this (ab)use of SNI. I expect there are other superior mechanisms here, as well, though did not think about it much. Even defining a new TLS extension (the policy is only "specification required") would be an improvement (though still not provide very solid security properties).
[[ questions ]] [ general ] * The appendix discussion of ALPN made me think that some ALPN recommendation might be worth mentioning. The ALPN registry mentions "dot" and claims RFC 7858 as the reference. However, I wasn't able to find a reference to "dot" in 7858 (certainly not in the IANA section), nor in 8310 (which has only an empty IANA section). Now I'm wondering where the "dot" ALPN really came from. Nevertheless, given this state of things, it best to continue to not say anything specific about ALPN use on these XoT connections? (I'm fully prepared to accept "yes" as an answer, but support others' ALPN concerns.) [[ comments ]] [ sections 8.4 and 12 ] * Section 8.4 has MUST for two of three client authorization strategies, whereas section 12 has a lowercase "should" where these are listed for inclusion in an XoT policy. "Should" there be more agreement in use of requirements language? [[ nits ]] [ section 4 ] * "The proposed mechanisms does not" -> "do not", or just "mechanism"? [ section 6 ] * "The term is used to encompasses" -> s/es//
Section 1. s/can make reconnaissance trivial/can make reconnaissance and attack targeting easier/ Section 1. Per “… zone walking is now possible with NSEC3 due to crypto-breaking advances”, a reference here would be helpful. Section 1. As far as I can tell the work on draft-vcelak-nsec5 has not been adopted and the draft is expired. Perhaps this should be signaled via s/This has prompted further work on an alternative mechanism/This promoted work on an alternative mechanism/ Section 1. Per “It is noted that in all of the common open source implementations …”, as this is a point in time assessment, it would be helpful to at least mention parenthetically the implementations/version numbers assessed informally for this conclusion. Section 1. Editorial. “… must cater for accepting …” doesn’t parse for me. Section 4. 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 To further document the assumptions, consider adding that this threat model doesn’t consider/protect the mechanisms to decide on triggering the zone transfer (e.g., protecting NOTIFY messages from an active attacker) Section 6.2. Per “However it is noted that most widely used open source authoritative nameserver implementations (including both [BIND] and [NSD]) do IXFR using TCP by default in their latest releases”, as this document ages, “latest release” may not be meaningful. Consider providing a version number for [BIND] and [NSD]. Section 8.4 and 10.4. As already mentioned by Martin and John -- It seems like a strong statement to say that IP ACLs are in the same class of “channel authentication” as mTLS. Section 8.8.1. It’s difficult to assess how effective this notional padding approach would be for providing traffic analysis protection. A few thoughts on the existing text realizing the details are out of scope: -- Does padding for AXoT need to be coordinated with the padding on IXoT? -- Is keeping state required to ensure that padding provides the appropriate obfuscation over time?
Section 7, paragraph 7, comment: > Therefore this document updates both the previous specifications for > XFR-over-TCP to clarify that It would be useful to explicitly cite those here; I assume you mean [RFC1995] and [RFC5936]. ------------------------------------------------------------------------------- All comments below are about very minor potential issues that you may choose to address in some way - or ignore - as you see fit. Some were flagged by automated tools, so there will likely be some false positives. There is no need to let me know what you did with these suggestions. Section 1, paragraph 10, nit: - contemplates the risk that someone gets the data through - - + contemplate the risk that someone gets the data through Section 1, paragraph 11, nit: - Zone enumeration is trivially possible for DNSSEC zones which use - ^ ^^^ - NSEC; i.e. queries for the authenticated denial of existences - ^ + Zone enumeration is trivially possible for DNSSEC zones that use + ^ ^^ + NSEC; i.e., queries for the authenticated denial of existences + ^ Section 4, paragraph 4, nit: - o much of this information can be obtained by various methods + o much of this information can be obtained by various methods, + + Section 5, paragraph 5, nit: - multiple AXFR sessions or XFRs of different zones because they + multiple AXFR sessions or XFRs of different zones, because they + + Section 5, paragraph 6, nit: - * Current usage of TCP for IXFR is sub-optimal in some cases i.e. + * Current usage of TCP for IXFR is sub-optimal in some cases, i.e., + + + Section 6.1, paragraph 8, nit: - [RFC5936] defines this specific step as an 'AXFR session' i.e. as + [RFC5936] defines this specific step as an 'AXFR session', i.e., as + + + Section 6.2, paragraph 12, nit: - using TCP by default in their latest releases. For BIND TCP - connections are sometimes used for SOA queries but in general they + using TCP by default in their latest releases. For BIND, TCP + + + connections are sometimes used for SOA queries, but in general they + + Section 6.3, paragraph 3, nit: - simply querying the publicly available authoritative servers leakage + simply querying the publicly available authoritative servers, leakage + + Section 6.3.2, paragraph 2, nit: - For hidden primaries or secondaries the SOA response leaks only the + For hidden primaries or secondaries, the SOA response leaks only the + + Section 7, paragraph 4, nit: - specific guidance on TCP/TLS connection usage for XFR because this + specific guidance on TCP/TLS connection usage for XFR, because this + + Section 7, paragraph 9, nit: - significantly more complex for clients to handle both because of + significantly more complex for clients to handle, both because of + + Section 7, paragraph 9, nit: - be multiple messages in the responses. For these reasons it is + be multiple messages in the responses. For these reasons, it is + + Section 7, paragraph 9, nit: - when they are all XFR queries i.e. clients sending multiple XFRs + when they are all XFR queries, i.e., clients sending multiple XFRs + + + Section 7, paragraph 9, nit: - later) since they will never receive them. + later), since they will never receive them. + + Section 7, paragraph 11, nit: - applies specifically to XFR exchanges. It also discusses how IXFR - ^^ -- + applies specifically to XFR exchanges. They also discuss how IXFR + ^^^^ Section 7, paragraph 12, nit: - the extended DNS error code 18 (Prohibited) can also be sent. - ^^^ + the extended DNS error code 18 (Prohibited) MAY also be sent. + ^^^ Section 7.1, paragraph 2, nit: - For clarity - an IXFR-over-TCP server compliant with this - ^^^^^^^^^^^^^^^ + An IXFR-over-TCP server compliant with this + ^ Section 7.2, paragraph 2, nit: - For clarity - an AXFR-over-TCP server compliant with this - ^^^^^^^^^^^^^^^ + An AXFR-over-TCP server compliant with this + ^ Section 7.3.1, paragraph 4, nit: - zones might be preferred for operational reasons. In this case + zones might be preferred for operational reasons. In this case, + + Section 7.3.2, paragraph 7, nit: - available i.e. responses MAY be sent intermingled + available, i.e., responses MAY be sent intermingled + + + Section 7.3.4, paragraph 2, nit: - does not support edns-tcp-keepalive the client MAY keep the + does not support edns-tcp-keepalive, the client MAY keep the + + Section 7.3.5, paragraph 2, nit: - that implementations may want to offer options to fallback to legacy - behavior when interoperating with servers known not to support - --- + that implementations may want to offer options to fall back to legacy + + + behavior when interoperating with servers known to not support + +++ Section 7.4, paragraph 6, nit: - TCP in any given client/server interaction there SHOULD be no more + TCP in any given client/server interaction, there SHOULD be no more + + Section 7.4, paragraph 7, nit: - As an illustration, it could be imagined that in future such an + As an illustration, it could be imagined that in the future such an + ++++ Section 8.1, paragraph 2, nit: - For improved security all implementations of this specification MUST + For improved security, all implementations of this specification MUST + + Section 8.3, paragraph 2, nit: - It is useful to note that in XoT it is the secondary that initiates + It is useful to note that in XoT, it is the secondary that initiates + + Section 8.3, paragraph 2, nit: - of connectivity the secondary is the TLS client and the primary the + of connectivity, the secondary is the TLS client and the primary the + + Section 8.4, paragraph 2, nit: - with XoT all XFR requests and response for that zone MUST be sent + with XoT, all XFR requests and responses for that zone MUST be sent + + + Section 8.4, paragraph 3, nit: - authentication domain name using a Strict Privacy Profile as + authentication domain name using a Strict Privacy Profile, as + + Section 8.5, paragraph 2, nit: - However any behavior specified here takes precedence for XoT. + However, any behavior specified here takes precedence for XoT. + + Section 8.6, paragraph 3, nit: - near future with a small number of configured secondaries but that do - wish to support DoT for regular queries from recursive in that same + near future with a small number of configured secondaries, but that do + + + wish to support DoT for regular queries from recursives in that same + + Section 8.7, paragraph 2, nit: - connection it SHOULD respond with the extended DNS error code 21 - - Not Supported [RFC8914]. XoT clients should not send any further - ^^^^^^ ^^^ + connection, it SHOULD respond with the extended DNS error code 21 - + + + Not Supported [RFC8914]. XoT clients SHOULD NOT send any further + ^^^^^^ ^^^ Section 8.7, paragraph 2, nit: - (for example, one hour) i.e., long enough that the server + (for example, one hour), i.e., long enough that the server + + Section 8.7, paragraph 3, nit: - Historically servers have used the REFUSED RCODE for many situations, + Historically, servers have used the REFUSED RCODE for many situations, + + Section 8.7, paragraph 3, nit: - error or fallback path when queries were refused. As a result the + error or fallback path when queries were refused. As a result, the + + Section 8.8.1, paragraph 3, nit: - o to obfuscate the actual size of the transferred zone to minimize + o to obfuscate the actual size of the transferred zone, to minimize + + Section 8.8.1, paragraph 4, nit: - updates to minimize information leakage about zone update activity + updates, to minimize information leakage about zone update activity + + Section 8.8.1, paragraph 6, nit: - It is noted here that, depending on the padding policies eventually - - + It is noted here that depending on the padding policies eventually Section 8.8.1, paragraph 6, nit: - the EDNS(0) option for padding. For example, without this capability + the EDNS(0) option for padding. For example, without this capability, + + Section 8.8.1, paragraph 6, nit: - theoretically be limited if there had to be a minimum of 1 RR per + theoretically be limited, if there had to be a minimum of 1 RR per + + Section 8.8.1, paragraph 7, nit: - response series in order to signal the conclusion of the zone + response series, in order to signal the conclusion of the zone + + Section 8.9.1, paragraph 2, nit: - Whilst it does add complexity to generating responses it can - significantly reduce the size of responses. However any such + Whilst it does add complexity to generating responses, it can + + + significantly reduce the size of responses. However, any such + + Section 8.9.3, paragraph 2, nit: - incremental changes to the zone between SOA updates to minimize + incremental changes to the zone between SOA updates, to minimize + + Section 8.9.3, paragraph 3, nit: - IXFR responses can vary in size greatly from the order of 100 bytes - ^^^^^^^^ + IXFR responses can greatly vary in size, from the order of 100 bytes + ++++++++ ^ Section 8.10, paragraph 2, nit: - structure is 16384. For some DNS implementations this limits the + structure is 16384. For some DNS implementations, this limits the + + Section 8.10, paragraph 3, nit: - particularly helpful when padding is used since minimizing the + particularly helpful when padding is used, since minimizing the + + Section 9, paragraph 3, nit: - When using persistent connections the secondary may have a XoT + When using persistent connections, the secondary may have a XoT + + Section 9, paragraph 4, nit: - a 'preferred primary connection' model. In this case the secondary + a 'preferred primary connection' model. In this case, the secondary + + Section 9, paragraph 5, nit: - model. Here a secondary could keep multiple persistent connections + model. Here, a secondary could keep multiple persistent connections + + Section 9, paragraph 5, nit: - reasonably low this might be feasible if latency is the most + reasonably low, this might be feasible if latency is the most + + Section 9, paragraph 6, nit: - document but implementations are encouraged to provide configuration + document, but implementations are encouraged to provide configuration + + Section 10, paragraph 2, nit: - To provide context to the requirements in section Section 8.4, this - -------- + To provide context to the requirements in Section 8.4, this Section 10, paragraph 5, nit: - communication channel between the client and server (i.e. the two + communication channel between the client and server (i.e., the two + + Section 10.2, paragraph 2, nit: - sign a DNS message but uses public key authentication, where the + sign a DNS message, but uses public key authentication, where the + + Section 10.3.1, paragraph 4, nit: - o however they MAY fallback to using TLS without authentication and + o however, they MAY fallback to using TLS without authentication and + + Section 10.3.1, paragraph 6, nit: - As such it does not offer a defense against active attacks (e.g., an + As such, it does not offer a defense against active attacks (e.g., an + + Section 10.4, paragraph 3, nit: - This is also possible with XoT but it must be noted that, as with + This is also possible with XoT, but it must be noted that, as with + + Section 10.4, paragraph 4, nit: - As discussed in Appendix A an IP based per connection ACL could also - ^ ^ - be implemented where only TLS connections from recognized secondaries + As discussed in Appendix A, an IP-based per-connection ACL could also + + ^ ^ + be implemented, where only TLS connections from recognized secondaries + + Section 10.5, paragraph 4, nit: - It is complementary but orthogonal the above mechanisms; and can be - used in conjunction with XoT but is not considered further here. + It is complementary but orthogonal to the above mechanisms; and can be + +++ + used in conjunction with XoT, but is not considered further here. + + Section 11, paragraph 2, nit: - single primary/secondary relationship where both servers are under - the control of a single operator to a complex hierarchical structure + single primary/secondary relationship, where both servers are under + + + the control of a single operator, to a complex hierarchical structure, + + + Section 11, paragraph 9, nit: - origin authentication which might be desirable for deployments + origin authentication, which might be desirable for deployments + + Section 12, paragraph 6, nit: - both the client and server are configured to use only XoT and the + both the client and server are configured to use only XoT, and the + + Section 12, paragraph 10, nit: - Since this may require configuration of a number of servers who may - ^ ^ - be under the control of different operators the desired consistency + Since this may require configuration of a number of servers that may + ^ ^^ + be under the control of different operators, the desired consistency + + Section 12, paragraph 11, nit: - Certain aspects of the Policies can be relatively easily tested - ^ + Certain aspects of the policies can be relatively easily tested + ^ Section 12, paragraph 11, nit: - 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 + 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 + + Section 12, paragraph 12, nit: - the scope of this document but may be the subject of future + the scope of this document, but may be the subject of future + + "Appendix A.", paragraph 2, nit: - connections that supported only a limited set of queries (SOA, XRFs) + connections that supported only a limited set of queries (SOA, XRFs), + + "A.1.", paragraph 2, nit: - Obviously a nameserver which hosts a zone and services queries for + Obviously, a nameserver which hosts a zone and services queries for + + "A.2.", paragraph 3, nit: - assessed. Once the connection is accepted the server might well be - willing to answer any query on that connection since it is coming + assessed. Once the connection is accepted, the server might well be + + + willing to answer any query on that connection, since it is coming + + "A.4.", paragraph 2, nit: - based ACLs to authenticate secondaries. In this case the primary + based ACLs to authenticate secondaries. In this case, the primary + + "A.4.", paragraph 3, nit: - transfers) this is not strict and nothing in the DNS protocol - prevents using the same connection for both types of traffic. Hence + transfers), this is not strict and nothing in the DNS protocol + + + prevents using the same connection for both types of traffic. Hence, + + "A.4.", paragraph 5, nit: - o strict: REFUSE all queries on TLS connections except SOA and + o strict: REFUSE all queries on TLS connections, except SOA and + + "A.4.", paragraph 8, nit: - o relaxed: answer all non-XoT queries on all TLS connections with + o relaxed: answer all non-XoT queries on all TLS connections, with + + Section 1, paragraph 2, nit: > rt by authoritatives might work. However there is currently no RFC that speci > ^^^^^^^ Did you forget a comma after a conjunctive/linking adverb? Section 1, paragraph 15, nit: > ations such ACLs are applied on a per query basis. Since requests typically > ^^^^^^^^^ In this context, "per-query" forms an adjective and is spelled with a hyphen. Section 1, paragraph 16, nit: > ow to use TLS (1.3 or later) as a transport to prevent zone collection from > ^^^^^^^^^^^ Uncountable nouns are usually not used with an indefinite article. Use simply "transport". Section 2, paragraph 1, nit: > O BE REMOVED BEFORE PUBLICATION] The Github repository for this document is a > ^^^^^^ The official name of this software platform is spelled with a capital "H". Section 4, paragraph 3, nit: > information. The proposed mechanisms does not attempt to obscure such informa > ^^^^ You should probably use "do". Section 4, paragraph 6, nit: > n attacker had such capabilities. However this threat is likely true of any > ^^^^^^^ Did you forget a comma after a conjunctive/linking adverb? Section 6, paragraph 9, nit: > FR-over-TCP The term is used to encompasses the range of permutations that a > ^^^^^^^^^^^ The verb after "to" should be in the base form: "encompass". Section 6.1, paragraph 10, nit: > Rs and AXFRs of different zones. However [RFC5936] was constrained by having > ^^^^^^^ Did you forget a comma after a conjunctive/linking adverb? Section 6.2, paragraph 9, nit: > packet, otherwise, TCP is used. In fact it says: "Thus, a client should f > ^^^^^^^ The comma is probably missing here: "fact, it". Section 6.2, paragraph 11, nit: > primary does not support IXFR. However it is noted that most widely used ope > ^^^^^^^ Did you forget a comma after a conjunctive/linking adverb? Section 6.3, paragraph 1, nit: > xchanges This section attempts to presents a rationale for considering encryp > ^^^^^^^^ The verb after "to" should be in the base form: "present". Section 7, paragraph 3, nit: > before TCP was considered a first class transport for DNS. [RFC1995], in fa > ^^^^^^^^^^^^^^^^^^^^^^^ Uncountable nouns are usually not used with an indefinite article. Use simply "first class transport". Section 7.3.1, paragraph 6, nit: > on an open connection o a large number of timeouts or slow responses have oc > ^^^^^^^^^^^^^^^^^ Specify a number, remove phrase, or simply use "many" or "numerous" Section 7.3.1, paragraph 8, nit: > received from the server and the client is in the process of closing the con > ^^ Did you mean "are"? Section 8.6, paragraph 3, nit: > e XoT in the near future with a small number of configured secondaries, but t > ^^^^^^^^^^^^^^^^^ Specify a number, remove phrase, use "a few", or use "some" Section 8.8.1, paragraph 1, nit: > l of padding AXoT responses would be two fold: o to obfuscate the actual size > ^^^^^^^^ The adjective or adverb 'twofold' needs to be written as one word. Section 8.8.1, paragraph 6, nit: > is, AXoT responses that contain no RR's apart from an OPT RR containing the > ^^^^ The possessive apostrophe seems to be incorrect. Please remove the apostrophe if you want to use the plural form of 'RR'. Section 8.10, paragraph 2, nit: > e to something around the order of 16kB. In principle, larger payload sizes > ^^^^ Insert a space between the numerical value and the unit symbol: "16 kB" Section 9, paragraph 2, nit: > messages and can send an SOA to all of the configured primaries. It can then > ^^^^^^^^^^ Consider using "all the". Section 10, paragraph 2, nit: > tion provides a brief summary of some of the existing authentication and vali > ^^^^^^^^^^^ If the text is a generality, 'of the' is not necessary. Section 10.4, paragraph 2, nit: > transfers on primary servers on a per query basis. This is also possible wit > ^^^^^^^^^ In this context, "per-query" forms an adjective and is spelled with a hyphen. Section 20, paragraph 13, nit: > references o Correct typos in acknowledgments draft-ietf-dprive-xfr-over-tls > ^^^^^^^^^^^^^^^ Do not mix variants of the same word ('acknowledgment' and 'acknowledgement') within a single text. Section 20, paragraph 20, nit: > -ietf-dprive-xfr-over-tls-04 o Add Github repository o Fix typos and referen > ^^^^^^ The official name of this software platform is spelled with a capital "H". Section 21.2, paragraph 10, nit: > nsaction Signatures ( SIG(0)s )", RFC 2931, DOI 10.17487/RFC2931, Sep > ^^^ The word '0)s' is not standard English. Did you mean "0's" (curly apostrophe) or "0's" (straight apostrophe)? "A.1.", paragraph 3, nit: > zone transfer on all transports on a per query basis. Cons: Attackers passiv > ^^^^^^^^^ In this context, "per-query" forms an adjective and is spelled with a hyphen. "A.4.", paragraph 2, nit: > TLS specific response policy on a per query basis. As an aside, whilst [RFC7 > ^^^^^^^^^ In this context, "per-query" forms an adjective and is spelled with a hyphen. "A.4.", paragraph 3, nit: > d make per query decisions about whether or not to answer those queries. Exa > ^^^^^^^^^^^^^^ Consider shortening this phrase to just "whether". It is correct though if you mean 'regardless of whether'. "A.4.", paragraph 10, nit: > ions just to perform XFRs with a small number of secondaries. Client behavior > ^^^^^^^^^^^^^^^^^ Specify a number, remove phrase, use "a few", or use "some" "A.4.1.", paragraph 1, nit: > I based response policies In a similar fashion, XoT servers might use the pre > ^^^^^^^^^^^^^^^^^^^^ Consider replacing this phrase with the adverb "similarly" to avoid wordiness. "A.4.1.", paragraph 2, nit: > S connections. Pros: This has to potential to allow a clean distinction betw > ^^^^^^^^^^^^^^^ Did you mean "too potential to"? Document references draft-ietf-dprive-rfc7626-bis-08, but draft-ietf-dprive-rfc7626-bis-09 is the latest available revision. Document references draft-ietf-dprive-dnsoquic-01, but draft-ietf-dprive-dnsoquic-02 is the latest available revision. Document references draft-ietf-tls-esni-09, but draft-ietf-tls-esni-10 is the latest available revision.
With my BCP 14 language complainer hat on: Section 7: * "Implementations SHOULD use [RFC7828] [...] to manage persistent connections." -- since this is a SHOULD, can you suggest why an implementer might opt not to do this? Section 7.3.1 does a great job of handling the SHOULD it presents, for example. Sections 7.3.2 and 7.3.3: * Same issue as above with the SHOULDs here. Section 7.4: * "Therefore, it is RECOMMENDED that [...] there SHOULD be no more than [...]." -- I don't know how to reconcile this RECOMMENDED-SHOULD combination in the same sentence. I suggest that the first clause can be dropped with no loss of meaning. Everything else is nits, some of which were probably also mentioned by others: Section 1: * "authoritatives" should probably be "authoritative nameservers" * "authenticated denial of existences records" -- s/existences/existence/ Section 4: * "The proposed mechanisms does not attempt" -- s/does/do/, or s/mechanisms/mechanism/ Section 6: * "term is used to encompasses" -- s/encompasses/encompass/, or remove "is used to" Sections 6.1 and 6.2 * "higher than the secondaries serial" -- s/secondaries/secondary's/ Section 6.2: * "So there may be a fourth step above where [...]. There may also be a fourth step where [...]." -- so there can be two "fourth" steps? Section 6.3: * "This section attempts to presents" -- remove "attempts to", or s/presents/present/ * In the second paragraph, I think you need a comma after "servers".
Thank you for the work on this document. My only (very minor) comment is on abbreviations, and will likely come up with the RFC Editor: there is a number of acronyms used throughout the text, please expand them on first use: XFR, AXFR, IXFR, SOA, ACL, RR, ALPN. Francesca
Thanks for the well-written and easy to follow spec. Below are some comments you may want to take into consideration. 1. Abstract XFR-over-TLS (XoT). Additionally, this specification updates RFC1995, RFC5936 and RFC7766. Please say a few words about how the spec updates those RFCs, don’t make the reader go digging for it. 2. Section 1 transfers (this draft) is orthogonal to preventing zone enumeration, though they aim to protect the same information. s/this draft/this document/ 3. Sections 6.1, 6.2 3. If the primary serial is higher than the secondaries serial s/secondaries/secondary’s/ 4. Section 6.3 This section attempts to presents a rationale for considering “Attempts to present”. But really, why not just “presents”? 5. Section 6.3 Since the SOA of the published zone can be trivially discovered by simply querying the publicly available authoritative servers leakage Comma between “servers” and “leakage”. 6. Section 6.3.2 For hidden primaries or secondaries the SOA response leaks only the degree of SOA serial number lag of any downstream secondary. I don’t understand. This either means the sentence would make sense if only I had the right domain knowledge (which is OK then), or it means the sentence doesn’t make sense (which isn’t). 7. Section 7 The following sections include detailed clarifications on the updates to XFR behavior implied in [RFC7766] and how the use of [RFC7828] applies specifically to XFR exchanges. It also discusses how IXFR and AXFR can reuse the same TCP connection. “They also discuss” — agreement in number with “the following sections”. 8. Section 7.4 This specification for XoT updates the guidance in [RFC7766] to provide the same separation of connection purpose (regular queries and zone transfers) for all transports being used on top of TCP. The “for XoT” confuses this sentence, making it sound a bit like the advice is restricted to XoT. I think those two words should be struck, it would be just fine as “this specification updates…” 9. Section 8.1 For improved security all implementations of this specification MUST use only TLS 1.3 [RFC8446] or later. Improved compared to what? I think the first three words could go, then the question wouldn’t come up. 9. Section 8.4 (also 10.4) 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 former is weaker, surely? I see Martin also raised this in his comments, I agree with what he wrote. It’s odd to see these two authorization methods, with very different security properties, presented as equivalent with no discussion anywhere of their relative (de)merits. 10. Section 8.8.1 (also 8.9.3) The goal of padding AXoT responses would be two fold: “Is”, not “would be” (also 893) 11. Section 10.2 SIG(0) [RFC2931] similarly also provides a mechanism to digitally Similarly, or also — pick one. 12. Section 11 The XoT authentication requirement specified in Section 8.4 addresses the issue of ensuring that the transfers is encrypted between the two “Transfers are” or “transfer is”. 13. Section 11 endpoints directly involved in the current transfers. The following table summarized the properties of a selection of the mechanisms “Summarizes” 14. Appendix A For completeness, it is noted that an earlier version of the specification suggested using a XoT specific ALPN to negotiate TLS Please define APLN on first use 15. A.4 As an aside, whilst [RFC7766] makes a general purpose distinction to clients in the usage of connections (between regular queries and zone Do you mean “general purpose distinction between clients“? The use of “to” doesn’t make sense to me. 16. A.4 Client behavior to REFUSED response is not clearly defined (see below). I do not see anything relevant below.
Hi, Thank you for this document. I was surprised by the length of this document - i.e., 40 pages to say to use TLS rather than TCP, and noting that DoH is only 20 pages long! But in reality, this document seems to be more than just zone transfers over TLS and seems to clarify/optimize various behavior related to using TCP connection handling. I have a few concrete suggestions that you are at liberty to handle as you see fit: (1) Please ensure that the abstract accurately summarizes the focus on the document, with a sentence of two summarizing the updates to RFC1995, RFC5936 and RFC7766. (2) I presume that section 21.3 is intended to be deleted (since the references appear to only be from section 16 which is planned to be removed), if so adding a RFC editor note would be helpful. (3) It wasn't clear to me whether the text in the appendix is meant to be normative or illustrative. It might be helpful to be clear which it is meant to be. Regards, Rob