> On Dec 24, 2021, at 11:27 AM, Benjamin Kaduk <ka...@mit.edu> 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
>>> <nore...@ietf.org> 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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
