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

"Wessels, Duane" <> Wed, 05 January 2022 21:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D44093A08A0; Wed, 5 Jan 2022 13:22:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8yI66ovuxLjT; Wed, 5 Jan 2022 13:22:49 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5907F3A089B; Wed, 5 Jan 2022 13:22:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; l=12636; q=dns/txt; s=VRSN; t=1641417769; h=from:to:cc:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=5ygZFpyka4I1LrcEKc/q7mvxGG0d+ECr0HG6x8jWq4I=; b=OIwfXMDSEOGCgIrpxa0EJNhkPPqz9HpVHoUs+DoN5jbWbjJ+ezVOpHF7 P1RL/FAoc1Rk0/VOrbdoCx3yyX07razh+DcOMWDJVRC+Vc+IVcN/FJwWm 6h3zF0nPBtnX9GkUZGKvIq9dAmBVSAaQ/JHf6e87qkAH/wQ/UUJm3rJmi ijwI0U10AH/3KHfAMNvsFaNTCXKinQVm1djUgk7WTOkbpu+ZO2PdUcchx Es/GfS8tbdhicM1uHsS+PHtzs+EQH8TENaUnjfR7/uu9CkUgchNmdtIYu knKs5C68b5pdkAH1miUECpZA6ubPwSRlsUoP5Lh2K8vslW3WnuDeI02R3 A==;
IronPort-Data: A9a23:N7z+d6BrRHicsRVW/zfiw5YqxClBgxIJ4kV8jS/XYbTApD4g02cBy zBLXm3UM/iCZDf3KtFya4vi/RhUv5PXndNiTANkpHpgcSlH+JHPbTi7wuccHM8zwunrFh8PA xA2M4GYRCwMo/u1Si6FatANl1ElvU2zbue6WL6s1hxZH1c+En940U87wYbVv6Yz6TSHK1LV0 T/Ni5CHULOV82Yc3rU8sv/rRLtH5ZweiRtA1rAMTakjUGz2zhH5OKkiyZSZdBMUdGX08tmSH I4vxJnhlo/Q10l1VoP9yt4XeGVSKlLZFVDmZna7x8FOK/WNz8A/+v9TCRYSVatYo2jYz/ts6 950jICfeygDHJ3hgeVCEBYNRkmSPYUekFPGCVKFl5Ws6WD2KyKq3f5pFllwNIFe5PxsBydF8 vlwxDIlN0jF3r3thuvmEa8w1qzPL+GyVG8bkn1/wCrCAPI9aY7OWaTR5NBemjw3g6iiGN6HP JNFOGQ0MXwsZTVuJ2spFptixt3y2CbyKyVUrw+y+Isetj27IAtZleKF3MDuUt+DSdhWtkOZu iTL83mRKhAXL9O3yDeZ/DSrnOCntS/hUYwOUby16vAvjFuIwXRWBBsNEEewubyjh1ejWshSL kES5jEGrKUu+gqsVNaVdxG+u3mc+xUcUttKCMU75R2DjK3O7G6xCm4fSSZpadE6uokxXzNC/ kSUjczuHzhjr7yZRFqS876VqXW5Pi19EIMZTSUeS1Ia5dTz+Nh2lQzVCNNiC+u/iZv/Azeph S6Qty54jLIW5SIW65iGEZn8q2rEjvD0osQdv207gkrNAttFWbOY
IronPort-HdrOrdr: A9a23:iW1XP6NzZaGu+MBcThyjsMiBIKoaSvp037BN7TEVdfU1SL37qy nAppQmPHPP5gr5O0tOpTnoAsDpfZq2z+8X3WB+B9afdTijlmeuIJpr8IfuhxbxcheTysdtkY NtabJ3BtG1L1Rr5PyR3CCIV/It2sOO/qztv/rZ1HsFd2xXQrtt9Bh0ETyWFUBKRA1LbKBTKK ah
X-IronPort-AV: E=Sophos;i="5.88,264,1635206400"; d="scan'208";a="13149635"
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.12; Wed, 5 Jan 2022 16:22:46 -0500
Received: from ([fe80::a89b:32d6:b967:337d]) by ([fe80::a89b:32d6:b967:337d%4]) with mapi id 15.01.2375.012; Wed, 5 Jan 2022 16:22:46 -0500
From: "Wessels, Duane" <>
To: Benjamin Kaduk <>
CC: The IESG <>, "" <>, "" <>, "" <>, Suzanne Woolf <>
Thread-Topic: [EXTERNAL] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
Thread-Index: AQHYAnpir8thuXVeiUiTKewcmMHNyQ==
Date: Wed, 05 Jan 2022 21:22:46 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-mailer: Apple Mail (2.3654.
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [DNSOP] Benjamin Kaduk's Discuss on draft-ietf-dnsop-dns-tcp-requirements-13: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 05 Jan 2022 21:22:54 -0000

> On Dec 24, 2021, at 11:27 AM, Benjamin Kaduk <> 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
> 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 <> wrote:
>>> ----------------------------------------------------------------------
>>> ----------------------------------------------------------------------
>>> (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,
> 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,