Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> logging

"Lubashev, Igor" <> Tue, 15 October 2019 21:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B986120052 for <>; Tue, 15 Oct 2019 14:10:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 8wLFplGVSu88 for <>; Tue, 15 Oct 2019 14:10:44 -0700 (PDT)
Received: from ( [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 04989120086 for <>; Tue, 15 Oct 2019 14:10:43 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x9FL7m6e013813; Tue, 15 Oct 2019 22:10:35 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=w+lzFS3jLee8IQbpalm6c3EIe5QJCfk27+ACBUxXpZw=; b=bXgninzRwQ6g0rmEOCBZdwiOQ0zQVoXPz6gztZPzfZlzVb0R75Y27vNckYj88VB4Y5ca RAUl2u0dupF2V80UyTdA8oLAFr3h3KZeQnWArSopfX3ODRouKXfdi2/IJ7EbaYVsjkCc 20nSGn8N7MVacWuKfz8LCL03WjSTq5MpYLlGKHRdYdnZswnPMwFMqT8uXzg+CSXHgDMV QHYY7oouhrhopYABjSj5AAWw2whJCNZfE1SXtOOlitPG66at3dLRsq+/ux1ufG0pKDhR gE8BSlu8UQCkj4e+1hNlSNmcvfbFhLzOx55mAVd5J8hSefk+WyUzEmk5dgHFpGfqnc0P Hg==
Received: from prod-mail-ppoint2 ( [] (may be forged)) by with ESMTP id 2vk6vhggmm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 15 Oct 2019 22:10:35 +0100
Received: from pps.filterd ( []) by ( with SMTP id x9FL2ga7013394; Tue, 15 Oct 2019 17:10:34 -0400
Received: from ([]) by with ESMTP id 2vka5wdm4e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 15 Oct 2019 17:10:33 -0400
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 15 Oct 2019 16:10:32 -0500
Received: from ([]) by ([]) with mapi id 15.00.1473.005; Tue, 15 Oct 2019 14:10:32 -0700
From: "Lubashev, Igor" <>
To: Joe Touch <>, "" <>
CC: Christian Huitema <>, "" <>
Thread-Topic: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> logging
Thread-Index: AQHVgNGd1G79uAZ3RkSVWxP1abPriadYaQ2AgAOut+A=
Date: Tue, 15 Oct 2019 21:10:31 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_f81b200a24e64fb0abc04b922d458f08ustx2exdag1mb6msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-15_08:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910150181
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-15_08:2019-10-15,2019-10-15 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=999 clxscore=1011 priorityscore=1501 suspectscore=0 malwarescore=0 phishscore=0 lowpriorityscore=0 mlxscore=0 impostorscore=0 bulkscore=0 spamscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910150182
Archived-At: <>
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> logging
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: Tue, 15 Oct 2019 21:10:48 -0000

> From: Joe Touch <> on Sunday, October 13, 2019 12:00 AM
> Hi, Gorry,
>> On Oct 12, 2019, at 12:48 AM, Gorry Fairhurst <<>> wrote:
>> I'm intrigued by how far we can understand opportunities for open client logs to replace pcap dumps, and would like to delve a little deeper into what we understand - there seem many possible actors and that may be interesting to look at a few viewpoints:
>> * a user of a transport protocol (e.g., understanding cost/benefit of feature choices);
> There’s only one viewpoint that drives this conversation. It’s the user’s.
> If the user wants to encrypt, that’s their prerogative. We should not be recommending or assuming otherwise,

Most users would likely say that they want Internet that is as fast as possible (low latency/high throughput), very reliable, secure (passwords and emails are safe from peeping toms) and reasonably private. Different people will make different trade-offs between the above, especially about the degree of privacy vs performance and reliability.

I see this draft to be about the trade-off between benefits of an attempts at extreme privacy at a single layer and the effects of these design choices on performance and reliability of the Internet.

>> * a service provider (e.g., trying to understand performance impairments in the network);
> They should never need to look at others’ transport headers to do this.

What else should they look at?  They have to look at packets flowing via their networks and make sense of what’s going – both proactively in terms of monitoring QoS that their customers are getting and reactively in terms of troubleshooting specific issues.  AOM only works within a single network (when it works) and does not help at all with identifying problems and narrowing down responsibility for a problem upstream or downstream from own network.


>> * researchers/equipment developers seeking to correlate/tune transport timing with network policies (e.g., interactions between congestion control and link scheduling);
> And if we’re part of their experiment, it needs to be by opt-in and with full understanding of what data they use and how they use it.

We should add “network operators” to the list of entities trying to tune network policies.  Users expect their ISPs (and their upstreams) to do traffic engineering (including running experiments) to improve their network performance/reliability. Browser vendors and server operators do the same all the time.  No opt-in expected/required.  As Christian points out elsewhere, it is no easy task in the face of diverse and sometimes selfish players, but that’s the Internet we have. Everyone has to be able to keep optimizing their part of the Internet ecosystem or users’ experience will suffer.


> The doc currently states, in that area (sec 6) largely as somewhat of a conclusion:
>   The choice of whether future transport protocols encrypt their
>   protocol headers needs to be taken based not solely on security and
>   privacy considerations, but also taking into account the impact on
>   operations, standards and research.
> That, in a nutshell, is the problem.
> NO. Security does NOT need to “take into account” the impact on the supposed “rights” of others to make our traffic part of an experiment.

It is, indeed, very hard to compromise on security “a little bit” and still have much of any security left.  There are many aspects to privacy (which sites you visit, when you go online, where you are located – geo-location/ISP/city/country, which devices you use, who else uses your devices, what bandwidth cap you have, are you on a lan or wifi, how many devices you have at home, etc).  It is reasonable to discuss a balance of performance/reliability and degrees of privacy afforded by a general-purpose transport. Users who need extreme privacy already know to use specialized transports like TOR/VPNs/etc (and use specialized measures to protect their privacy on other layers).

I think it is unfortunate that security is even mentioned in this draft. Header encryption is not about security; it is about privacy and protocol ossification resistance.

  *   Igor

> Joe

On 09/10/2019, 15:32, Christian Huitema wrote:

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)