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

Martin Duke <martin.h.duke@gmail.com> Wed, 08 September 2021 18:45 UTC

Return-Path: <martin.h.duke@gmail.com>
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 12F093A3254 for <tcpm@ietfa.amsl.com>; Wed, 8 Sep 2021 11:45:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 RX3VTuBLOJOg for <tcpm@ietfa.amsl.com>; Wed, 8 Sep 2021 11:44:54 -0700 (PDT)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 931BC3A3252 for <tcpm@ietf.org>; Wed, 8 Sep 2021 11:44:54 -0700 (PDT)
Received: by mail-il1-x132.google.com with SMTP id q14so259434ils.5 for <tcpm@ietf.org>; Wed, 08 Sep 2021 11:44:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7h3Wpigtl21AEeVt1crG4kxdreUxP79JseycfVLAy/U=; b=LmamMO8mTx7/6OWC7A1+ESvWIY88Xvw9pumFC86hm5UgXrAW8Jw8Ys+SU+fAl0XHo2 drrxaE0hQxS0YxredxxzGHbKcMe2W7h6stclU5I2XVPRnEuKv4vYsaM59/FpfJgKU7sN 4aMxeiKv0GVCijxMm1Kjck1JV7f0jIDfZEjjhx584cwZ+L3odpimEyn5000IxdQ83DPZ ZE7vY8YWFeRP82NYx99G9slE3o6UR6/gEzXbRod18a3HxTcAdIHtdaztWdRQ0A9cguE9 BVo3xkhYo7kugnaQ/zIpCoXJG4RffipFtHndDhPaTcRQS1jfEXi0wE8fm/pWyAITO72H kC3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7h3Wpigtl21AEeVt1crG4kxdreUxP79JseycfVLAy/U=; b=Cvb7QFapCjXMnmJPFuDoYwnSYyYUN4ryAsYfD0rO8SEBSkEVR9d6gq4u8pqFQW5hK2 ZGcFBdtut9XT0W0iUnYR9cyVG16mz/hm6KXG9TmJBsXo2uKjJiqsm8T+tOqXNef1Zb5J esdT0K3no/4AGWoF2PGuWF9/I3AXuKqqRMirGiAQUvDXLt+jzI9VN58rxCG8FGmxtgUE 4AsLvlBpGLLAGLTiJ4yO8O9g9tPVJFpNGvU5Q19momnINc56Efxb4NbFbpQ+rZURSk4j m+mbleyHgXRD3Q4tabkA3qzejaOuHcSFVC7PTTNnIcAG+iTki30f0IojXIjEUWh0OzA1 KdrQ==
X-Gm-Message-State: AOAM533mrN0b0h7rYIr6DUMqPTKzmDchDkkkpSTdnj8+TV2h0BZHalz3 Fm3c50sd0PGPJzrmwa1HJ99JlyR9ckUOlJFKcN2CufSF
X-Google-Smtp-Source: ABdhPJzvftD8oQnb3pN7NswTLL32QaC0z3Xdw93/1OHJueZnQfaT/kFNH67gfVh/APwYVsv2O9Z1/l4ht4RXo2sH0KU=
X-Received: by 2002:a05:6e02:17cf:: with SMTP id z15mr931024ilu.103.1631126692544; Wed, 08 Sep 2021 11:44:52 -0700 (PDT)
MIME-Version: 1.0
References: <CAJU8_nXi5=6MD9cvGkd3E3xvF3o=JeR4xw4+x5NphTQxstYGbw@mail.gmail.com> <D00D6D29-226C-4C2D-85D2-D133FAF5E27A@erg.abdn.ac.uk> <64c81d66-a566-cc92-cfb0-61302ec2fabb@mti-systems.com> <CAJU8_nXn41btL6FY_e_BfC1rrN-WfNo6wJ8p+YRSExjikiBZsg@mail.gmail.com> <99a37672-8b4d-a51e-31ae-6620f9f20a0d@erg.abdn.ac.uk> <CAJU8_nXCUvf-hE39jRajTxuXua5xqsM5Lv+Y-r24yuRJpd3vzA@mail.gmail.com>
In-Reply-To: <CAJU8_nXCUvf-hE39jRajTxuXua5xqsM5Lv+Y-r24yuRJpd3vzA@mail.gmail.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Wed, 8 Sep 2021 11:44:40 -0700
Message-ID: <CAM4esxQg9So-9-vya3gTGUzqP1qVLrZTjMyr_p64FVs6FTe3Dw@mail.gmail.com>
To: Kyle Rose <krose@krose.org>
Cc: Gorry Fairhurst <gorry@erg.abdn.ac.uk>, tcpm IETF list <tcpm@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000017c76b05cb8047b7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/UbwjK_VxzxEGqjlGKmm54rICqkU>
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: Wed, 08 Sep 2021 18:45:00 -0000

I'm going to move forward with taking this to the ballot, though if there's
a convenient way to address this I invite Wes to do so.

I don't think we want to go down the road of requiring an "ossification
considerations" section at this point.

On Wed, Sep 8, 2021 at 9:23 AM Kyle Rose <krose@krose.org> wrote:

> Right, I agree the right sentiment is expressed there: my issue is mainly
> with the reference to it in the text Wes proposed being in the
> security/privacy considerations section, and with no express reference to
> ossification, which is an important part of the issue (as noted in 9065).
> It's placement and context that I think needs augmenting. No word beginning
> with "ossif" appears anywhere in draft -25. It's possible there's an
> appropriate place earlier in the doc, or maybe there should be a short
> "extensibility considerations" section. Or maybe I'm simply in the rough on
> this, and there's no need to link this document to the wire image
> ossification issue.
>
> Kyle
>
> On Wed, Sep 8, 2021 at 11:56 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> wrote:
>
>> On 08/09/2021 15:52, Kyle Rose wrote:
>>
>> 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
>> mechanisms.
>>
>> Kyle
>>
>> Kyle,
>>
>> RFC9065 might bring some context, when it concluded:
>>
>>      "Unencrypted transport header fields are likely to ossify rapidly,
>>       as network devices come to rely on their presence, making it
>>       difficult to change the transport in future.  This argues that the
>>       choice to expose information to the network is made deliberately
>>       and with care, since it is essentially defining a stable interface
>>       between the transport and the network. Some protocols will want
>>       to make that interface as limited as possible; other protocols
>>       might find value in exposing certain information to signal to the
>>       network or in allowing the network to change certain header fields
>>       as signals to the transport.  The visible wire image of a protocol
>>       should be explicitly designed."
>>
>> My point was that to some extent, ossification - in as much as the wire
>> image is visible and usable by middleboxes, was a design decision made
>> when TCP was defined. Many of the methods defined in the PILC WG for
>> various types of subnetworks also utilised these features.
>> Connection-tracking firewalls have been around for decades, and rely on
>> this, etc. This isn't/wasn't a bug, although not making it clear what
>> middleboxes should do might have been an oversight.
>> Different design decisions were made for RTP/UDP and QUIC and others,
>> with different implications.
>>
>> Gorry
>>
>> On Tue, Sep 7, 2021 at 11:37 PM Wesley Eddy <wes@mti-systems.com> 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.
>>>
>>
>> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm
>