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

Wesley Eddy <> Wed, 08 September 2021 03:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B324C3A13B1 for <>; Tue, 7 Sep 2021 20:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 QBQKTcCsR0-I for <>; Tue, 7 Sep 2021 20:37:03 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3DAA23A13AD for <>; Tue, 7 Sep 2021 20:37:03 -0700 (PDT)
Received: by with SMTP id a10so885405qka.12 for <>; Tue, 07 Sep 2021 20:37:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=dx4WK3SMuiJ507BgxOg2JWwTQteLXPTC5b5UlmtkMqU=; b=ONiUatN+drqjhSkdQ/PbcGTj0erwsJ3SLBLMPkvDs4rFlOWqEPEKqIfGz7GzCyPIlG HnNIzNq+AyUdE1wqIpRgHMgjjgt3x2TRRj72UO5mCk1Cniy0G/sRXiQPwXkczuw+Z1Eg gyJ4dnBUmvIwtohXOx8OoKMp6R2anGlXBwCHTOFxw5TV0x20AocrL7md4gDjwmxrMWe/ x508r34hlMpNf3X8yqS078NLRliwt5Q2byrYZc5P3sdc82Z9Bka2+oNq6zwDtbWNjI22 n86EwT0Lere8pg4E87G/OaNguUINkMoXuNgsDtFAhjGykCAbHzwlZJFwSEwSUCj8B6yJ 6DFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=dx4WK3SMuiJ507BgxOg2JWwTQteLXPTC5b5UlmtkMqU=; b=LB58Ga8qV1r2EldxDgUQgLpy6gR2olCfKJnEydobykQDW0x/JNRQPATaQ1Iuaez38x XGwZrNFXY5q7b0tqHITBZFj3zqv7h65+NXsnAqPIh9cF9mUSIb1T6JRcmgo2l8yjJZgz DQVJ1vNB4byR1mhBjwHJ67enO7jrjPbMzsbl6qtlxvoqDixyliOe0DZVb5Bn8lb2PsYr OK/ihsFQUgHo9U4RBgvCwlLjPMaOmRzJzM9muHdsuoruVPklU4wQKcBLtvHJ432ss1n4 50x4/mctrEwZp1GUnaCc5zPAmHuXrm3xYJ0joZ6hNfNesnfYsmX2PQR5qwJB/BSWq9H2 9sAg==
X-Gm-Message-State: AOAM533qHWLGCenl5YlFjtDDBzQrsKVM4BV87esGoPut8JX2vnXeGJIH HsKjrDHBcXCZ++RVcsci/jUVRmAf6TN5ag==
X-Google-Smtp-Source: ABdhPJwMPTrsL6k8cqg2YtV0+k1bYkpEHHGS5j5YLkhJoHax9aHVNZ5i3cmp2x07HEfOcIbheFiZWA==
X-Received: by 2002:ae9:e858:: with SMTP id a85mr1547343qkg.97.1631072220869; Tue, 07 Sep 2021 20:37:00 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id v24sm793393qkv.11.2021. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Sep 2021 20:37:00 -0700 (PDT)
To: Gorry Fairhurst <>, Kyle Rose <>
Cc: tcpm IETF list <>
References: <> <>
From: Wesley Eddy <>
Message-ID: <>
Date: Tue, 07 Sep 2021 23:36:55 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------A3B6C608B76984F58611B31C"
Content-Language: en-US
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 03:37:08 -0000

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.