Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)

Gorry Fairhurst <> Thu, 27 February 2020 19:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3523A3A097C for <>; Thu, 27 Feb 2020 11:17:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BzIqd4a0I8ld for <>; Thu, 27 Feb 2020 11:17:47 -0800 (PST)
Received: from ( [IPv6:2001:630:42:150::2]) by (Postfix) with ESMTP id A1FC63A096E for <>; Thu, 27 Feb 2020 11:17:47 -0800 (PST)
Received: from GF-MacBook-Pro.local ( []) by (Postfix) with ESMTPSA id D4C511B001C0; Thu, 27 Feb 2020 19:17:43 +0000 (GMT)
To: David Schinazi <>
Cc: "" <>
References: <> <> <>
From: Gorry Fairhurst <>
Message-ID: <>
Date: Thu, 27 Feb 2020 19:17:43 +0000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------CA2A0902F7A41427985D8D12"
Content-Language: en-GB
Archived-At: <>
Subject: Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)
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, 27 Feb 2020 19:17:50 -0000

We discussed the scope a lot at the start, and the advice I received was 
that this is not the document to tell people about what they have to do.

I think the decisions about whether to encrypt all transport fields or 
some or none isn't something I saw huge consensus upon. I did see many 
strong arguments, but what I heard often depended on which working group 
was speaking and the background of people involved. Had I asked a 
different question, e.g. do you think Privacy is important I would have 
got a different answer (we do have a BCP that notes that).

The AD advice I recall at the time we asked to work on this, correct me 
Spencer if I am wrong, was to not attempt a BCP until the WG could first 
publish an informational document. This is that document. The purpose 
then, as I see, is to examine where we have arrived. Had we had a 
document like this, other discussions such as how to manage QUIC, 
whether PLUS could be useful, etc could have been more informed and 


On 27/02/2020 18:39, David Schinazi wrote:
> Hi Gorry,
> Thanks for updating the document, and for slightly tweaking the
> tone to focus less strongly on the downsides of transport header
> encryption. It's much appreciated.
> However, I'm now pretty confused by the latest version (-12).
> Could you help me answer these two questions please:
> 1) Who is the target audience for this document?
> 2) What should that audience walk away with?
> I initially assumed that the answer to (1) was "designers
> of new transport protocols". But considering myself in that
> category, I don't know what I'm supposed to take away
> from the draft. I was expecting the answer to (2) to be
> "you SHOULD or SHOULD NOT encrypt transport protocol
> headers (pick one)" but that's not the case.
> Here are excerpts from the draft's Conclusion section:
>    This document has described some current practises, and the
>    implications for some stakeholders, when transport layer header
>    encryption is used.  It does not judge whether these practises are
>    necessary, or endorse the use of any specific practise.
>    This document does not make recommendations about what
>    information ought to be exposed, to whom it ought to be observable,
>    or how this will be achieved.
>    An appropriate balance will emerge over time as real instances
>    of this tension are analysed [RFC7258].
> The messages I'm walking away with are:
> A) there is a tension between folks who want to encrypt and
>     folks who don't
> B) we don't have enough information, it's too early to tell what the
>     impact of transport header encryption really is
> As such, I'm now more confused than I was before reading the
> draft, as it doesn't help me answer the question of "when designing
> a new transport protocol, should I be encrypting my transport
> headers or not?".
> I personally oppose publication of the document as it stands,
> because I find it confusing and non-actionable. I would like to see
> this useful content in a BCP document once we have enough
> information to actually recommend something.
> Thanks,
> David
> On Thu, Feb 27, 2020 at 1:09 AM Gorry Fairhurst < 
> <>> wrote:
>     The editors have just uploaded a new revision of
>     draft-ietf-tsvwg-transport-encrypt following review comments. We
>     are not
>     aware of further review comments and now think that this new
>     version is
>     now ready to proceed.
>     Best wishes,
>     Gorry and Colin
>     ---
>     A new version of I-D, draft-ietf-tsvwg-transport-encrypt-12.txt
>     has been successfully submitted by Godred Fairhurst and posted to the
>     IETF repository.
>     Name: draft-ietf-tsvwg-transport-encrypt
>     Revision: 12
>     Title: Considerations around Transport Header Confidentiality,
>     Network
>     Operations, and the Evolution of Internet Transport Protocols
>     Document date: 2020-02-26
>     Group: tsvwg
>     Pages: 48
>     URL:
>     Status:
>     <>
>     Htmlized:
>     Htmlized:
>     Diff:
>     Abstract:
>     To protect user data and privacy, Internet transport protocols have
>     supported payload encryption and authentication for some time. Such
>     encryption and authentication is now also starting to be applied to
>     the transport protocol headers. This helps avoid transport protocol
>     ossification by middleboxes, while also protecting metadata about the
>     communication. Current operational practice in some networks inspect
>     transport header information within the network, but this is no
>     longer possible when those transport headers are encrypted. This
>     document discusses the possible impact when network traffic uses a
>     protocol with an encrypted transport header. It suggests issues to
>     consider when designing new transport protocols, to account for
>     network operations, prevent network ossification, enable transport
>     evolution, and respect user privacy.