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

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

> On Dec 24, 2021, at 11:27 AM, Benjamin Kaduk <[e-mail]> wrote:
> 
> Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 
> 
> Hi Duane,
> 
> Sorry for the very delayed response.
> I will go update my ballot position shortly, but please see
> https://secure-web.cisco.com/1NC-Sp-k6c9fQvvh8KF_51aDQMeCoXJOhd8ivZXqXshCS_zHlPK9gm5KW3WpwesqBhQZy2tr0vvxGjusWah0AD2lYdmmloT1EBJRUpjjPXs1V0NjYwNf3CzNPxn66JGiamjcl3YxFfhCFF99bFT9_oUKN8EogHEJZysGMZyiVkG-AK2oOzI9kNaghHqRWls10qqte96vadcqFsjLZtvYgr9IPUB4UMR8QrUvCZNrS4oGYTUmwWdPB1_hRkrOg5Hu6/https%3A%2F%2Fgithub.com%2Fjtkristoff%2Fdraft-ietf-dnsop-dns-tcp-requirements%2Fpull%2F11
> for some further edits to the text for discuss point (1).
> 
> On Mon, Nov 08, 2021 at 10:35:21PM +0000, Wessels, Duane wrote:
>> 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.
> 
> As mentioned above,
> https://secure-web.cisco.com/1NC-Sp-k6c9fQvvh8KF_51aDQMeCoXJOhd8ivZXqXshCS_zHlPK9gm5KW3WpwesqBhQZy2tr0vvxGjusWah0AD2lYdmmloT1EBJRUpjjPXs1V0NjYwNf3CzNPxn66JGiamjcl3YxFfhCFF99bFT9_oUKN8EogHEJZysGMZyiVkG-AK2oOzI9kNaghHqRWls10qqte96vadcqFsjLZtvYgr9IPUB4UMR8QrUvCZNrS4oGYTUmwWdPB1_hRkrOg5Hu6/https%3A%2F%2Fgithub.com%2Fjtkristoff%2Fdraft-ietf-dnsop-dns-tcp-requirements%2Fpull%2F11
> has a few tweaks to this to account for the differences between TLS 1.2 and
> TLS 1.3, and the skew in feature availability between the TLS versions.
> (Highlights: RFC 7918 is 1.2-only, and TLS 1.2 session resumption does save
> a round-trip (the current text implicitly assumes 1.3).)

This pull request was accepted and merged.

>> 
>> 
>>> 
>>> 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?
> 
> It would have been nice if 7413 covered this topic, yes, but it didn't.
> The reasons that 7413 recommends for clusters to share the same key remain
> valid, but it comes with a caveat that a compromise of one such server
> facilitates attacks on the others.  Your proposal here doesn't mention that
> caveat, so it seems like the guidance is incomplete (even if the overall
> dichotomy of choice is essentially complete).
> 
> To make a concrete (though perhaps straw-man) proposal:
> 
>  This document recommends that DNS Servers enable TFO when possible.  RFC
>  7413 recommends that a pool of servers behind a load balancer with shared
>  server IP address also share the key used to generate Fast Open cookies,
>  to prevent inordinate fallback to the 3WHS.  This guidance remains
>  accurate, but comes with a caveat: compromise of one server would reveal
>  this group-shared key, and allow for attacks involving the other servers
>  in the pool by forging invalid Fast Open cookies.
> 
> I recognize this is a lot of text for a fairly minor issue, but didn't come
> up with anything shorter in the time allotted.

That works for me.  I’ve added it to the document.

> 
>> 
>>> 
>>> 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?
> 
> Ah, yes, 7766 looks like a good thing to replace the "???" above.  (I
> didn't check what was in 1035 when writing the above comment.)

I’ve added this short paragraph to Security Considerations:

   This document, providing operational requirements, is the companion
   to the implementation requirements of DNS over TCP, provided in
   [RFC7766].  The security considerations from [RFC7766] still apply.

I am reluctant to include anything here about 1035 because “security” does
not appear anywhere in that document.  Section 4.2.2 of 1035 talks about TCP
usage, but nothing about security.

> 
> The rest of the stuff (both above and below) looks good, and thank you
> again for the detailed responses.
> 
> -Ben

Thank you,

DW