Re: [tcpm] Secdir last call review of draft-ietf-tcpm-rfc793bis-24

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Sun, 05 September 2021 16:51 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D623A0978 for <tcpm@ietfa.amsl.com>; Sun, 5 Sep 2021 09:51:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BhYyDVOIC_K for <tcpm@ietfa.amsl.com>; Sun, 5 Sep 2021 09:51:53 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 235943A0975 for <tcpm@ietf.org>; Sun, 5 Sep 2021 09:51:50 -0700 (PDT)
Received: from GF-MBP-2.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id ECB6D1B00193; Sun, 5 Sep 2021 17:51:07 +0100 (BST)
To: Kyle Rose <krose@krose.org>, Wesley Eddy <wes@mti-systems.com>
Cc: tcpm IETF list <tcpm@ietf.org>
References: <162767735763.27351.5673596060247016004@ietfa.amsl.com> <cd7d3085-7602-b6f9-471b-4c7fed99e158@mti-systems.com> <CAJU8_nXjH=i-cZDOLy3piA8a65=pe4YQEZSsNF27bGCtxjVmLg@mail.gmail.com> <290f7fc9-7a05-5474-ca8f-17d63d9f7b36@mti-systems.com> <CAJU8_nUTBm-6mF=FLvqvZyFAHJknsQMyAXuNYr+hK6fXBTC2eA@mail.gmail.com>
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Message-ID: <52ced251-299b-f47e-29d8-1c32e379c354@erg.abdn.ac.uk>
Date: Sun, 5 Sep 2021 17:51:07 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <CAJU8_nUTBm-6mF=FLvqvZyFAHJknsQMyAXuNYr+hK6fXBTC2eA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------3B865CC8290CF7395BD3495E"
Content-Language: en-GB
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/gz9MN_Jb_PMfoeZpmGtnQ2f9B6s>
Subject: Re: [tcpm] Secdir last call review of draft-ietf-tcpm-rfc793bis-24
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 05 Sep 2021 16:51:59 -0000

On 05/09/2021 17:13, Kyle Rose wrote:
> On Fri, Sep 3, 2021 at 3:54 PM Wesley Eddy <wes@mti-systems.com 
> <mailto:wes@mti-systems.com>> wrote:
>
>     > > The one item I see missing from this section is a mention of
>     lessons
>     > learned
>     > > and subsequently applied to the design of QUIC. I think it is
>     worth
>     > mentioning,
>     > > for instance, that TCP's large surface area of cleartext metadata
>     > exposes more
>     > > information to the path than required to successfully route
>     packets
>     > to their
>     > > destination, including to on-path adversaries that may be able to
>     > use this
>     > > metadata to bolster targeted or pervasive surveillance.
>
>     It looks like this is covered pretty well in RFC 8546, which you
>     mention
>     below, so I think it might suffice for 793bis to just add a sentence
>     noting pretty much exactly what you said above and referring
>     interested
>     readers to RFC 8546.
>
>
> Agreed, this sounds good.
>
>     > > There is one more omission, adjacent to (but not explicitly
>     about)
>     > security,
>     > > that I think warrants some text in this document: that is around
>     > ossification.....
>
>     I don't really want to add a whole section for this, since we aren't
>     going to actually change anything, however, I think it makes sense to
>     add the above-mentioned reference to 8546, plus a little bit more
>     expansion that references RFC 8558 as having additional
>     recommendations
>     that could be applied with regard to future TCP extensions.
>
>
> The IAB's use-it-or-lose-it draft 
> (https://datatracker.ietf.org/doc/html/z 
> <https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it> 
> might be the best reference for this particular problem. This is what 
> 8546 refers to when discussing this problem. But some brief text 
> describing how the problem applies to TCP extensibility might be 
> worthwhile, though I'm not sure where to put it into this document. 
> Something like:
>
>   q[ While TCP was designed from the start with extensibility in mind, 
> practically speaking standards-compliant extensions have faced 
> numerous obstacles to deployment as a result of constraints imposed by 
> on-path elements with assumptions about valid TCP traffic that they 
> then impose on flows. With respect to the option mechanism, for 
> instance, on-path elements collectively dubbed "middleboxes" [RFC 
> 3234] often filter or otherwise modify TCP packets to strip unknown 
> options or otherwise render them unusable; similarly, middleboxes 
> often re-segment TCP traffic, precluding the introduction of 
> extensions that presume end-to-end preservation of stream 
> segmentation, such as in early revisions of tcpcrypt [RFC 8548]. Such 
> protocol ossification beyond the constraints implied by the standard 
> described herein effectively limits TCP extensibility for use cases 
> requiring transit over the public Internet. (This effect has 
> subsequently motivated protocol design patterns that hide data from 
> path elements (for example, by encrypting as much header information 
> as possible) and that exercise cleartext or otherwise predictable 
> elements of the wire image ([USE-IT]) to preserve the intended degree 
> of future extensibility.) ]
> Kyle
>
>
> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

To me, this has a much more complicated history, and I think TCP has 
been extended many times - albeit not sucessfully in the ways mentioned 
above, but in other watys. It seems like a discussion of whether 
ossification has been good or bad. I'd also really quite concerned to 
see words like "often" used without clarifying further -  there are 
legitimate cases where filtering can be useful for managing the security 
of TCP connections: A firewall in one context might do many things, and 
that might actually be a good security model; in another context that 
might be different.

I'd also question the importance of 
https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it 
<https://datatracker.ietf.org/doc/html/draft-iab-use-it-or-lose-it>, in 
relation to the core TCP spec, even though the message is clear for MPTCP.

Maybe this is something for TCPm to consider in the future, but overall, 
I'm maybe a little unsure why a TCP spec would add this, and how this 
relates to TCP.

Gorry