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

Kyle Rose <> Wed, 08 September 2021 14:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5CADA3A2ADF for <>; Wed, 8 Sep 2021 07:52:24 -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 2hj7nfs3NHjA for <>; Wed, 8 Sep 2021 07:52:20 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 873BE3A2ADE for <>; Wed, 8 Sep 2021 07:52:19 -0700 (PDT)
Received: by with SMTP id m25-20020a7bcb99000000b002e751bcb5dbso1770274wmi.5 for <>; Wed, 08 Sep 2021 07:52:19 -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=biU572j3yMZ1TxeSvzCltf98gw0kYQAqAiiGoGU7omQ=; b=Uv7fMmMvKmQw276yKawKaKBq7i7Oy9M8kZl5QpJBFJ89kmlggejD8d06esfGdrow6a DGVh/kFUsSzOyqiG8eaw/Jrx/lM6C/X2y6ItjUHbwqQCxvzlSJLXO9bx+mF2ohQfKMJs YlbGP7XCqrbYuSYOAqzAPwkPgBiYOliPrp++4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=biU572j3yMZ1TxeSvzCltf98gw0kYQAqAiiGoGU7omQ=; b=emr81EnQ1825lQlKVg2o3D5luMQyCGX8J2WxEnVS2sjimK//h+1t9ELOgfYrdzQUg7 SS13JgaDZF+74ymrew1Xjzf4Yw3FTqM6KPFifHNEQCzLLr7y0uhJnKOntBYynsNX7NRi 4elRdipKRsLpnJJ25U1Cmu9lVgJC/Q+OUCSD3UP2cvVxyDH0yQZtbYj3kJAn7PLO+k6j rI4drEiYHSXfrtu7+i3EyVkVdCaBmzHAJAjk7bx/1xGOdZGYV3m32QLQL3eAlrybiiTI 8qhQ9CmV64qs8OnuBD6BLwh9JpV9Fst6QInytPyyyj4L/6H2wrH1NIr15WynwYXFTB6j IaWQ==
X-Gm-Message-State: AOAM530D4gQOFGYg5R3wFSEcjWAx5uyTFM+NMYwgMyZUBluczbJXfR5N INIeYj1VQC3XIHWbIvSEViSKW+5R+kK+d5sX1P9Ybg==
X-Google-Smtp-Source: ABdhPJzvfNmXwxfc6sNitCNWKxujXg+4eBwirDcc+kbYvO73wTL8izhPS5XIiIKVcbNZ6wM5l1FxeS+c1NvnQ6wb7To=
X-Received: by 2002:a05:600c:14c6:: with SMTP id i6mr4035122wmh.99.1631112736199; Wed, 08 Sep 2021 07:52:16 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Kyle Rose <>
Date: Wed, 08 Sep 2021 10:52:05 -0400
Message-ID: <>
To: Wesley Eddy <>
Cc: Gorry Fairhurst <>, tcpm IETF list <>
Content-Type: multipart/alternative; boundary="0000000000003ae92905cb7d0757"
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: Wed, 08 Sep 2021 14:52:25 -0000

The concern here is broader than security/privacy considerations: while
exposing data unnecessarily to the network does create such concerns, your
proposed text doesn't touch on the problem of protocol ossification, which
is orthogonal to privacy even if it can be mitigated by many of the same


On Tue, Sep 7, 2021 at 11:37 PM Wesley Eddy <> wrote:

> Hopefully wrapping this thread up ... I've just posted a -25 revision that
> contains a new paragraph which I think now has references to all of the
> mentioned documents.
>    The concept of a protocol's "wire image" is described in RFC 8546
>    [54], which describes how TCP's cleartext headers expose more
>    metadata to nodes on the path than is strictly required to route the
>    packets to their destination.  On-path adversaries may be able to
>    leverage this metadata.  Lessons learned in this respect from TCP
>    have been applied in the design of newer transports like QUIC [58].
>    Additionally, based partly on experiences with TCP and its
>    extensions, there are considerations that might be applicable for
>    future TCP extensions and other transports that the IETF has
>    documented in RFC 9065 [59], along with IAB recommendations in RFC
>    8558 [56] and [66].
> (where [66] is the IAB use-it-or-lose-it I-D)
> I think this should be good for Martin to move ahead with it if captures
> the right sense of what everyone has been suggesting to add.