Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)

["Wessels, Duane" <[e-mail]>]

Hi Ben, thank you for the detailed review.  It has taken me a while to work through
all of your comments and suggestions, but hopefully this addresses them sufficiently.



> On Oct 25, 2021, at 3:51 PM, Benjamin Kaduk via Datatracker <[e-mail]> wrote:
> 
> 
> ----------------------------------------------------------------------
> 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).

Is this better?

   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 with TLS 1.3 [RFC8446] takes one additional round-trip compared
   to TCP.  Connection setup times can be reduced with TCP Fast Open,
   and TLS False Start [RFC7918].  TLS session resumption does not
   reduce round-trip latency becase no application profile for use of
   TLS 0-RTT data with DNS has been published at the time of this
   writing.  However, TLS session resumption can reduce the number of
   cryptographic operations.


> (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)

Thanks, this has been corrected.


> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> This document targets BCP status, while proposing an Updates:
> relationship with an Internet Standard and an Informational document.
> As mentioned in
> https://secure-web.cisco.com/16mLP8dG_ibZ9_hePr-XOEAMh0ghoochCF5XPpWWxHVs2rqFvgauZy7CTG1l4e8I_O8UaNtqmDrRRxvsmORmD2R1aCRr-SZvwMWwE5IcT1ky6ggdBCttsM0zPB1RTtvux53rPHrjpxbLUVVLSGGOUyh6nVhhkw1KE2dqgrO18iMEmjsLol05Dkj15p5m2l-O0-ZirQbfx_OkxB8W8tw_WkmVpMMsLm7IQwjG-dVQgbr5pK_hBp8VLx7I4WgryUGMW/https%3A%2F%2Fmailarchive.ietf.org%2Farch%2Fmsg%2Flast-call%2FoMhqRigr4nbRSMll5NY4zXpZu20%2F
> 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):

This has been merged.

> 
> 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.

The 35% figure is derived from this statement in the reference:

   We saw 10,115 individual IPv6 addresses used by IPv6-capable recursive
   resolvers.  Of this set of resolvers, we saw 3,592 resolvers that
   consistently behaved in a manner that was consistent with being unable
   to receive a fragmented IPv6 packet.

3592/10115 is 35.51% and I took the liberty of rounding down rather than up.


> 
> 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).

This has been changed as noted in my reply to John Scudder.

> 
>   *  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.

Agreed, hopefully this is better:

   o  Authoritative servers MUST support and service TCP for receiving
      queries, so that resolvers can reliably receive responses that are
      larger than what fits in a single UDP packet.

   o  Recursive servers (and forwarders) MUST support and service TCP
      for receiving queries, so their TCP-capable clients can reliably
      receive responses that are larger than what fits in a single UDP
      packet.

   o  Recursive servers (and forwarders) MUST support TCP for sending
      queries, so that they can retry truncated UDP responses as
      necessary.


> 
> 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"

How about this?

   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, which
   includes factors such as the number of users or clients, typical
   traffic levels, and hardware resource constraints.

   DNS server software MAY provide a configurable limit on the number of
   established connections per source IP address or subnet.  This can be
   used to ensure that a single or small set of users cannot consume all
   TCP resources and deny service to other users.  Operators SHOULD
   ensure this limit is configured appropriately, based on their number
   and diversity of users, and whether users connect from unique IP
   addresses or through a shared Network Address Translator.


> 
> 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.

I feel like this point should’ve been brought up in the TFO RFC (7413),
rather than this document.  Section 6.3.4 talks about server farms but doesn’t
mention security concerns about sharing keys.

Perhaps it would be appropriate in this document to say that server clusters
should either use the same TFO server key (as recommended by 7413 sec 6.3.4),
or just disable TFO?


> 
> 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.

Is this sort of what you had in mind?

   As mentioned in Section 6, applications that implement TCP stream
   reassembly need to limit the amount of memory allocated to connection
   tracking.  A failure to do so could lead to a total failure of the
   logging or monitoring application.  Imposition of resource limits
   creates a tradeoff between allowing some stream reassembly to
   continue and allowing some evasion attacks to succeed. 


> 
> We might also consider reiterating that the core DNS over TCP security
> considerations (RFC 1035, ???) continue to apply.

1035 doesn’t have a lot to say, but maybe you are thinking about whats
in section 4.2.2?

Even so, this document is meant to be operational requirements and I suspect
you are maybe thinking of protocol/implementation requirements, which are
covered by RFC 7766?


> 
> 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.

The opening paragraph of section 4.1 has been updated due to other comments
on this same topic.  It now reads:

   Resolvers and other DNS clients should be aware that some servers
   might not be reachable over TCP.  For this reason, clients MAY track
   and limit the number of TCP connections and connection attempts to a
   single server.  Reachability problems can be caused by network
   elements close to the server, close to the client, or anywhere along
   the path between them.  Mobile clients that cache connection failures
   MAY do so on a per-network basis, or MAY clear such a cache upon
   change of network.

Does that address your concern?


> 
>   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).

Thanks, is this better?

   In fact,
   [DAI21] details a class of IP fragmentation attacks on DNS
   transactions if the IP Identifier field (16 bits in IPv4 and 32 bits
   in IPv6) can be predicted and a system is coerced to fragment rather
   than retransmit messages.


> 
> 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.)

Updated:

   A number of protocols have recently been developed
   to provide DNS privacy, including DNS over TLS [RFC7858], DNS over
   DTLS [RFC8094], DNS over HTTPS [RFC8484], with even more on the way.


> 
> 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://secure-web.cisco.com/1LAKZvPIvRrtY7gk6aYxiUqcEPVzMhQCQvufa-Aml_Nz9I7q1WXzR2996DBooUfTPwaaOtq4ifa_Eu7GYG78WGP0Nu3e6e-dNvPIbRiN18gWSfQ39FVHBgFHUpmFVc_k9EDG76jRRivXT60d1eXptpTxnxMR0C8g-ghgoTjrdffE3D42xSerFsEHxd9A5s7k1j_ZyNWxB7infwBRY-6emNntk28Su5YD9C_IwpQ3WkD9vEkA76s9CXU_14MazOgfy/https%3A%2F%2Fwww.ietf.org%2Fabout%2Fgroups%2Fiesg%2Fstatements%2Fnormative-informative-references%2F

Thanks, I’ve moved the references only mentioned in the appendix to the Informative section.

DW