Benjamin Kaduk has entered the following ballot position for draft-ietf-dnsop-dns-tcp-requirements-13: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-tcp-requirements/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- (1) This should be pretty easy to resolve, but this text from §4.4 does not seem to match up with the referenced document: The use of TLS places even stronger operational burdens on DNS clients and servers. Cryptographic functions for authentication and encryption requires additional processing. Unoptimized connection setup takes two additional round-trips compared to TCP, but can be reduced with TCP Fast Open, TLS session resumption [RFC8446] and TLS False Start [RFC7918]. Two additional round trips was true of TLS 1.2 and prior versions, but as of TLS 1.3 the application data from the client can be sent after only 1 round trip, accompanying the client Finished (and authentication messages, if in use). Given the nature of the rest of the sentence, we might want to specifically mention TLS 1.3 as an improvement over TLS 1.2, but there are probably a number of ways that we could fix it. Note additionally that for TLS 1.3, session resumption is not a reduction in the number of round trips unless 0-RTT data is used (but AFAIK there is not a published application profile specifying acceptable DNS content for TLS 0-RTT data, so use of TLS 0-RTT data for DNS is forbidden), but is still an efficiency gain due to the reduced number of cryptographic operations (including certificate validation). (2) Trivial to address, but the section heading for Appendix A.8 references RFC 3326 (The Reason Header Field for the Session Initiation Protocol (SIP)), not RFC 3226 (DNSSEC and IPv6 A6 aware server/resolver message size requirements) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This document targets BCP status, while proposing an Updates: relationship with an Internet Standard and an Informational document. As mentioned in https://mailarchive.ietf.org/arch/msg/last-call/oMhqRigr4nbRSMll5NY4zXpZu20/ there is some motivation for having updates to standards-track documents occur via other standards-track documents, but given that this document is mostly about giving operational guidance for DNS-over-TCP usage, there seems to be some argument that BCP is a more appropriate status for it. However, I do wonder if there is some existing BCP that this document would become part of, or if it would need to be given a new BCP number. It's not entirely clear how much scope there is for future additions that would become part of that same BCP, and whether a BCP number is truly needed in that scenario. It would be good to hear others' thoughts on this topic, especially in the form of references to previous WG discussion. I made a pull request on github with some editorial suggestions, most of which by volume are classifying the "Standards Track" documents in Appendix A properly as Internet Standard or Proposed Standard (there don't seen to be any lingering Draft Standards in the list): https://github.com/jtkristoff/draft-ietf-dnsop-dns-tcp-requirements/pull/10 Section 2.4 headers. Unfortunately, it is quite common for both ICMPv6 and IPv6 extension headers to be blocked by middleboxes. According to [HUSTON] some 35% of IPv6-capable recursive resolvers were unable to receive a fragmented IPv6 packet. [...] I looked through [HUSTON] and wasn't able to find this "35%" figure. There is a remark that "37% of endpoints used IPv6-capable DNS resolvers that were incapable of receiving a fragmented IPv6 response", but that seems to be a somewhat different statement in addition to a somewhat different percentage value. In particular, the sampling domain for the [HUSTON] statement as written appears to be "all endpoints", but the statement in this draft uses the sampling domain of "IPv6-capable recursive resolvers". However, the corresponding calculation in [HUSTON] looks to be using "IPv6-capable resolvers" as the sampling domain, just as this document states, which suggests that the error in phrasing is in [HUSTON] and not in this document. Section 3 As the directorate review noted, it's a little surprising to see the OLD/NEW formulation for one of the updates to §6.1.3.2 of RFC 1123 but not the others. In particular, using OLD/NEW would allow us to implicitly reiterate that the "MUST send a UDP query first" requirement for non-zone-transfers is no longer present (by virtue of the update made by RFC 7766). * Recursive servers (or forwarders) MUST support and service all TCP queries so that they do not prevent large responses from a TCP- capable server from reaching its TCP-capable clients. This might benefit from a bit of unpacking. I think that "MUST support and service ... queries" refers to the stub/recursive side of things, with "responses from a TCP-capable server" would refer to the recursive/authoritative side. But the rest of the sentence seems to be assuming that if TCP is used on one side then it is used on the other side, so that limitations of TCP use on one side do not carry over to the other. However, I didn't think that there was a requirement on recursives to go forward with TCP for queries received over TCP, so I'm not entirely sure what the actual guidance here is intended to be. Section 4.2 DNS server software SHOULD provide a configurable limit on the total number of established TCP connections. If the limit is reached, the application is expected to either close existing (idle) connections or refuse new connections. Operators SHOULD ensure the limit is configured appropriately for their particular situation. I think that one of the directorate reviews touched on this topic, but I wonder if we can give more guidance on what factors of a particular situation might be relevant for determining what is appropriate. In this case, that might include the number of requests the hardware is capable of serving and the number of requests expected from legitimate clients; we do seem to provide a bit more detail in the following paragraph (not quoted here) regarding "number and diversity of users" Section 8 There's a lot of good advice interspersed in the main body text already; thank you for that! The discussion in §4.1 suggests ("SHOULD") to share a TFO server key amongst servers in a server farm, but this introduces the usual security considerations for a group-shared symmetric key. The highlights are that any member of the group can impersonate any other member, and compromise of one machine compromises all members' use of the key. While there's not a great fully generic treatment of these issues in the RFC series that I know of (yet, at least), I've seen RFC 4046 cited for it sometimes, and draft-ietf-core-oscore-groupcomm has a section on "security of the group mode" that also has some overlap with the relevant considerations for sharing TFO keys. In a similar vein, in §6 we again SHOULD-level recommend that applications capturing network packets do TCP segment reassembly in order to defeat obfuscation techniques involving TCP segmentation. I am happy to see that we go on to caution against resource exhaustion attacks while doing so, but have two related comments: first, that caution might merit mention again here, and second, that we should note (either here or there) that when applying resource limits, there's a tradeoff between allowing service and allowing some attacks to succeed. Giving up on segmentation reassembly due to resource usage means that a potential attack could succeed, but dropping streams where segmentation recovery uses excess resources might deny legitimate service. We might also consider reiterating that the core DNS over TCP security considerations (RFC 1035, ???) continue to apply. Clients that keep state about whether a given server supports TCP (per discussion in §4.1) might be susceptible to an attacker that is on-path in one location disrupting TCP in that location and causing the client to store state that a given server does not support TCP, when TCP connections from a different location, where the attacker is not on path, would succeed. short-lived DNS transactions over TCP may pose challenges. In fact, [DAI21] details a class of IP fragmentation attacks on DNS transactions if the IP ID field can be predicted and a system is coerced to fragment rather than retransmit messages. [...] I suggest more detail on the "IP ID field" (including IPv4/v6 differences). Section 9 being queried). DNS over TLS or DTLS is the recommended way to achieve DNS privacy. Is it really the (sole) recommended way? It certainly suffices, but what is the status of DoH/DoQ? Perhaps "DNS over TLS or DTLS serves to provide DNS privacy" optionally followed by a note about DoH or "other mechanisms" in general. (May be superseded by Roman's Discuss.) Section 11.1 I recommend re-review of the classification of the references. Just because a reference is on the standards-track does not mean that we must reference it normatively -- e.g., RFC 1995/1996 are mentioned only in the listing of "other standards related to DNS transport over TCP", but they are not required reading in order to understand and implement this document. See https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/ . Section 11.2 I'm having a really hard time seeing how RFC 1123 is classified as informative given that we have an Updates: relationship to it -- that would seem to require some familiarity with its contents in order to know how to use this document properly. The same question might be asked of RFC 1536 as well. The link for [FRAG_POISON] did not lead me to the desired document, just a generic homepage. I couldn't locate anything about [DAI21]; is there additional information that can be provided to assist in locating it? It is slightly surprising that RFC 1034 does not need to be normative, but it seems that the only places we directly reference use 1035 rather than 1034, so informative would be correct. The "SHOULD enable TFO" might make RFC 7413 into a normative reference (see the IESG statement linked above) Since [TDNS] is available at https://www.isi.edu/~johnh/PAPERS/Zhu15b.html should we include that link? Likewise, [TOYAMA] seems to refer to https://archive.nanog.org/meetings/nanog32/presentations/toyama.pdf, and [VERISIGN] to https://indico.dns-oarc.net/event/20/contributions/270/attachments/249/465/rtt_Oarc_ThomasWessels_v1.pdf Appendix A.2 This Informational document [RFC1536] states UDP is the "chosen protocol for communication though TCP is used for zone transfers." That statement should now be considered in its historical context and is no longer a proper reflection of modern expectations. That statement is explicitly updated by this document, which might be worth noting. NITS Section 3 of the Internet DNS as ever, if not more so. Furthermore, there has been serious research that argues connection-oriented DNS transactions may provide security and privacy advantages over UDP transport [TDNS]. In fact, the standard for DNS over TLS [RFC7858] is just this sort of specification. [...] This might be some editing remnants -- "just this sort of specification" seems to be trying to refer to some previous discussion of a type of specification, but there isn't any in the preceding text anymore. ([TDNS] does propose a specification for a DNS-over-TLS type scheme, from a very quick glance, or maybe there is an intent to connect "specification" with "[of a] connection-oriented DNS transaction [protocol]".) _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
