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

"Roni Even (A)" <> Thu, 17 October 2019 09:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0D185120099 for <>; Thu, 17 Oct 2019 02:10:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.189
X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TCmzx8cudKNr for <>; Thu, 17 Oct 2019 02:10:36 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D00EB12008C for <>; Thu, 17 Oct 2019 02:10:35 -0700 (PDT)
Received: from (unknown []) by Forcepoint Email with ESMTP id BE0F338A93C845C23E9F for <>; Thu, 17 Oct 2019 10:10:32 +0100 (IST)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Thu, 17 Oct 2019 10:10:32 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Thu, 17 Oct 2019 10:10:32 +0100
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Thu, 17 Oct 2019 10:10:31 +0100
Received: from ([]) by ([]) with mapi id 14.03.0439.000; Thu, 17 Oct 2019 17:10:18 +0800
From: "Roni Even (A)" <>
To: "" <>
CC: Christian Huitema <>
Thread-Topic: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
Thread-Index: AdV+HJIZhebOrRcXTIK6bGArgFWweQATsG2AAZd2RMA=
Date: Thu, 17 Oct 2019 09:10:17 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD23D876E8dggemm526mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <>
Subject: Re: [tsvwg] [saag] 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: Thu, 17 Oct 2019 09:10:39 -0000


In my view the draft expands the text in RFC7258 "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." . There is no more text in RFC7258 that discuss what should an unacceptable outcome.

It is not biased  since it complements RFC7258 and RFC7624 as described in the introduction "Encryption of transport layer headers and  payload data has many benefits in terms of protecting user privacy.

   These benefits have been widely discussed [RFC7258<>]8>], [RFC7624<>]4>], and  this document strongly supports the increased use of encryption in  transport protocols. "

In my view it represent not only the view of the middlebox vendors but also among others, the operators that need to manage their networks .

Roni Even

From: tsvwg [] On Behalf Of Christian Huitema
Sent: Wednesday, October 09, 2019 5:33 PM
To: Black, David;
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

As the draft mentions:

   The use of transport layer authentication and encryption exposes a

   tussle between middlebox vendors, operators, applications developers

   and users

Much of the draft reads like a lamentation of the horrible consequences of encrypting transport headers, which looks very much like embracing the point of view of the middlebox vendors. Expressing that point of view is of course fine, and it might be enough to change the title, abstract and introduction to reflect that this is an opinion piece. But as a transport working group document I would like something a bit more balanced. It should spend more time acknowledging the ossification and privacy issues. It should ideally lay the ground work for alternative management solutions, such as controlled exposure like the spin bit in QUIC, IP header information, or standardized logs like the QLOG effort.

-- Christian Huitema

On 10/8/2019 2:08 PM, Black, David wrote:
FYI - some OPS area and SEC area eyes on this TSVWG draft now (during WGLC) would be a good thing ;-).

Thanks, --David (TSVWG co-chair)

From: Black, David <><>
Sent: Tuesday, October 8, 2019 5:06 PM
Cc: Black, David
Subject: WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

This email announces a TSVWG Working Group Last Call (WGLC) on:

The Impact of Transport Header Confidentiality on Network Operation and

                       Evolution of the Internet


This draft is intended to become an Informational RFC.

This WGLC will run through the end of the day on Wednesday, October 23.

That should allow time before the Singapore draft submission cutoff for

the authors to revise the draft with any changes that result from WGLC.

Comments should be sent to the<> list, although purely

editorial comments may be sent directly to the authors. Please cc: the

WG chairs at<>  if you would like the chairs to

track such editorial comments as part of the WGLC process.

No IPR disclosures have been submitted directly on this draft.


David, Gorry and Wes

(TSVWG Co-Chairs)


saag mailing list<>