Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt

Gorry Fairhurst <> Tue, 19 February 2019 17:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7D6E6130F44 for <>; Tue, 19 Feb 2019 09:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id U0efrV5YUroZ for <>; Tue, 19 Feb 2019 09:40:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id D0403130F2A for <>; Tue, 19 Feb 2019 09:40:47 -0800 (PST)
Received: from Gs-MacBook-Pro.local ( []) by (Postfix) with ESMTPSA id 62B5C1B00244; Tue, 19 Feb 2019 17:40:44 +0000 (GMT)
Message-ID: <>
Date: Tue, 19 Feb 2019 17:40:44 +0000
From: Gorry Fairhurst <>
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Tom Herbert <>
CC: tsvwg <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [tsvwg] I-D Action: draft-ietf-tsvwg-transport-encrypt-04.txt
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, 19 Feb 2019 17:40:50 -0000

On 19/02/2019, 17:13, Tom Herbert wrote:
> Hello,
> I am still having a hard time believing that need for operators to
> inspect and process transport layer information in ad hoc ways
> remotely outweighs the need for users' security and privacy and to
> impede protocol ossification.
Whatever you c
> Regardless of the arguments in the
> draft, I believe that the trend will be more use of encryption even in
> the transport layer.
That certainly is the way it looks, to summarise the draft says:

    As seen, different transports use encryption to protect their header
    information to varying degrees.  There is, however, a trend towards
    increased protection with newer transport protocols.

> Consequently, it would be nice if the draft had
> more discussion about alternative means for network devices to get the
> information about the transport layer that they need.
Our guidance on scoping means that we can include deployed methods, are 
there examples that you can tell us about?
> In particular, I
> still think possibility of using extension headers is far too easily
> dismissed by the draft (please see my previous comments about that).
I also think there may be potential here in future, and would love to 
see this area explored - it is a topic in which I have research, and I 
believe you also. I can't however point yet to deployment examples in 
this area. Do you know more?

> Tom
> On Mon, Feb 18, 2019 at 12:38 PM<>  wrote:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Transport Area Working Group WG of the IETF.
>>          Title           : The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet
>>          Authors         : Godred Fairhurst
>>                            Colin Perkins
>>          Filename        : draft-ietf-tsvwg-transport-encrypt-04.txt
>>          Pages           : 43
>>          Date            : 2019-02-18
>> Abstract:
>>     This document describes implications of applying end-to-end
>>     encryption at the transport layer.  It identifies in-network uses of
>>     transport layer header information.  It then reviews the implications
>>     of developing end-to-end transport protocols that use authentication
>>     to protect the integrity of transport information or encryption to
>>     provide confidentiality of the transport protocol header and expected
>>     implications of transport protocol design and network operation.
>>     Since transport measurement and analysis of the impact of network
>>     characteristics have been important to the design of current
>>     transport protocols, it also considers the impact on transport and
>>     application evolution.
>> The IETF datatracker status page for this draft is:
>> There are also htmlized versions available at:
>> A diff from the previous version is available at:
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> Internet-Drafts are also available by anonymous FTP at: