Re: [tsvwg] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

Colin Perkins <> Wed, 06 November 2019 08:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCBD6120129 for <>; Wed, 6 Nov 2019 00:53:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XLB07PaASp3K for <>; Wed, 6 Nov 2019 00:52:58 -0800 (PST)
Received: from ( [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CFD3120113 for <>; Wed, 6 Nov 2019 00:52:58 -0800 (PST)
Received: from [] (port=31475 helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1iSH3g-0002Gd-P0; Wed, 06 Nov 2019 08:52:57 +0000
From: Colin Perkins <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_AA9CDCCB-8C54-435C-B885-F127ADC792C4"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Wed, 6 Nov 2019 08:52:31 +0000
In-Reply-To: <>
Cc: tsvwg <>, Joe Touch <>, Gorry Fairhurst <>
To: S Moonesamy <>
References: <> <4460_1571933453_5DB1CD0D_4460_57_4_5AE9CCAA1B4A2248AB61B4C7F0AD5FB931F030A0@OPEXCAUBM44.corporate.adroot.infra.ftgroup> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 14
Archived-At: <>
Subject: Re: [tsvwg] [OPSAWG] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 06 Nov 2019 08:53:01 -0000

> On 6 Nov 2019, at 08:14, S Moonesamy <> wrote:
> At 06:48 PM 04-11-2019, Joe Touch wrote:
>> That only happens if the WG and IESG say this is out of scope for the IETF. I.e., the ISE isn't an end-run.
>> IMO, given the fact that this is squarely within TSVWG and there's no consensus, the way forward is clear.
> The draft is within the scope of the IETF given that it is a Working Group draft.
> I went through the draft.  In Section 2:
>  "To achieve stable Internet operations, the IETF transport community
>   has to date relied heavily on the results of measurements and the
>   insights of the network operations community to understand the trade-
>   offs, and to inform selection of appropriate mechanisms to ensure a
>   safe, reliable, and robust Internet (e.g., [RFC1273])."
> That statement is backed by a citation to a RFC which pre-dates the IETF.
> Is the draft a statement from the transport community or is it intended to be a statement from the IETF (as a whole)?  If it is the latter, it could be read as building a case against RFC 7258.

The sentence immediately following that you quote is "Encryption is expected to form a core part of future transport protocol designs”, so I fail to see that. 

RFC 7258 says, in Section 2, that:

>    While PM is an attack, other forms of monitoring that might fit the
>    definition of PM can be beneficial and not part of any attack, e.g.,
>    network management functions monitor packets or flows and anti-spam
> Farrell & Tschofenig      Best Current Practice                 [Page 3]
> RFC 7258            Pervasive Monitoring Is an Attack           May 2014
>    mechanisms need to see mail message content.  Some monitoring can
>    even be part of the mitigation for PM, for example, certificate
>    transparency [RFC6962] involves monitoring Public Key Infrastructure
>    in ways that could detect some PM attack techniques.  However, there
>    is clear potential for monitoring mechanisms to be abused for PM, so
>    this tension needs careful consideration in protocol design.  Making
>    networks unmanageable to mitigate PM is not an acceptable outcome,
>    but ignoring PM would go against the consensus documented here.  An
>    appropriate balance will emerge over time as real instances of this
>    tension are considered.

This draft is discussing some of the issues that go into finding such an appropriate balance when considering transport protocol design. It does not say do not encrypt transport headers; it does say to consider certain issues and make an informed choice what parts of the transport headers should be encrypted and what should be exposed. There is a trade-off in protocol design. As the QUIC spin bit and ossification discussions show, there are reasons to expose certain header information and ways of doing so that preserve user privacy and protocol extensibility. This draft is encouraging that discussion, not pre-judging its outcome.

Colin Perkins