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

Kyle Rose <> Sun, 05 September 2021 16:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5CC13A03FE for <>; Sun, 5 Sep 2021 09:13:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rathHJTMszO0 for <>; Sun, 5 Sep 2021 09:13:16 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EAF8B3A03F3 for <>; Sun, 5 Sep 2021 09:13:15 -0700 (PDT)
Received: by with SMTP id k5-20020a05600c1c8500b002f76c42214bso3195515wms.3 for <>; Sun, 05 Sep 2021 09:13:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3FbNDl93jc7EzrLSz/9pI6S6Wd+W9LMo/7xOVDNL98w=; b=lb9LpBe1R/8PWTbldeTuUbHMBy2LFxEqrthHm9RzY/ELbWieR1sFpzDgcG425nxE9c LxDZG0Z+Jp7kgPb4OlaXxGSndsnLyZxL3kMD2oDyxU8zQXsPyWBgHR2PptLbqEfLI5l4 WPSUsJoIOdrS884xwBiFagDsZk70OouAkZMjE=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3FbNDl93jc7EzrLSz/9pI6S6Wd+W9LMo/7xOVDNL98w=; b=t7mjOhaPqfSRytGc8yvOLHYw9lrLCLdSHPfiBVg6jtXkjlogKrUgtphCeDrLJ+Y6MX GYcEjmoeaSd816x3T/YN/983dfDYjRvLSvpqfAdXWMG+umeBXf4w+Nlybb9Qx1s+twnP Kl0R9HtlNUcB8qJdA7L0I7vqIDN0UDmulEhjjMKn8R8QmHbPnHDuyFOPt97yC5nEP/UP HnBsVtGrHu6qh+g/Om2rtf8+pL/B5Otcij8/oSmMNnkmgUb8pVvbWINQjoHPtmBoIfms AvSbGKMsP69pIAJ2Ct2P9kx2+nANwzVBiRRUFC6wMiQU1uHd11NZdVsHJEg/r5cO6Xxo RIqw==
X-Gm-Message-State: AOAM5330BpqP/ajWKLEru5oG1dS6irZooaCBakPbI+6JPPwjU0X+UEoo 165xIpeZ0+7+ekTGYeFkfxwVmMxgW0VpBPMy2F3jn3+XD2SKVxuv
X-Google-Smtp-Source: ABdhPJy3p+9pRkFkB0KPRnmO+3iWxuBk1wPr303ghOG9U/PEz4SC5pgPYNTMCuKH5JkNmtjtGBEx6DGyAdC321gcqLs=
X-Received: by 2002:a05:600c:3554:: with SMTP id i20mr7412225wmq.164.1630858393408; Sun, 05 Sep 2021 09:13:13 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Kyle Rose <>
Date: Sun, 05 Sep 2021 12:13:02 -0400
Message-ID: <>
To: Wesley Eddy <>
Cc: tcpm IETF list <>
Content-Type: multipart/alternative; boundary="00000000000037f2b805cb41cfdd"
Archived-At: <>
Subject: Re: [tcpm] Secdir last call review of draft-ietf-tcpm-rfc793bis-24
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 05 Sep 2021 16:13:22 -0000

On Fri, Sep 3, 2021 at 3:54 PM Wesley Eddy <> 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 ( 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.) ]