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

Colin Perkins <> Fri, 28 February 2020 00:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EB1F33A0921 for <>; Thu, 27 Feb 2020 16:05:09 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id g_6dt4BN8Coa for <>; Thu, 27 Feb 2020 16:05:06 -0800 (PST)
Received: from ( [IPv6:2a00:1098:0:82: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 8FDA63A091C for <>; Thu, 27 Feb 2020 16:05:06 -0800 (PST)
Received: from [] (port=48267 helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1j7T9I-0002mJ-Ch; Fri, 28 Feb 2020 00:05:04 +0000
From: Colin Perkins <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3A68DD0D-B6A7-4760-859F-20F84120F852"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Fri, 28 Feb 2020 00:04:54 +0000
In-Reply-To: <>
Cc: Spencer Dawkins at IETF <>, Gorry Fairhurst <>, "" <>
To: Martin Duke <>
References: <> <> <> <> <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 14
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: Fri, 28 Feb 2020 00:05:10 -0000

Right – my goal with this draft is not to say ‘encrypt' or 'don’t encrypt' the transport headers, but rather to highlight various issues to consider when deciding whether, and what, to encrypt. It’s information to help transport designers make an informed choice. 


> On 27 Feb 2020, at 21:26, Martin Duke <> wrote:
> One thing that came out of the spin bit discussion is that some transport protocol experts honestly do not understand how this information is used constructively in the network. That may be why the initial tone may have been a little unbalanced.
> To answer your question, David, I think your takeaway as a transport designer is to understand what you are sacrificing when you encrypt transport headers, and consider exposing specific items if the benefits would suit the use case. Other transport designers (though none that I actually know) might benefit from an explanation on why transport encryption is worth doing.
> Martin
> On Thu, Feb 27, 2020 at 12:25 PM Spencer Dawkins at IETF < <>> wrote:
> Speaking as a non-area director (so, I don't have a hat to remove) ... 
> On Thu, Feb 27, 2020 at 1:18 PM Gorry Fairhurst < <>> wrote:
> 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 focussed.
> I believe I was the AD who gave this advice, and Gorry is recounting that story the way I remember it. 
> From my perspective, we had just been through a great deal of kerfluffling with MARNEW(1), SPUD(2), ACCORD(3), PLUS(4), and "Effects of Pervasive Encryption on Operators"(5), all of which had various levels of food-flinging, and all of which had various levels of assertions about whether operators needed to manage transport protocols, with little agreement on ground truths about what was, and was not, possible to manage when looking at existing transport protocols. 
> I wasn't seeing anything that led me to expect that to change before the earth fell into the sun, and the volume level was increasing (watching Meetecho for the PLUS BOF would drive anyone to drink, even today). So I encouraged Gorry to focus on ground truths, so that we would be able to actually have discussions about what might go into a BCP for protocol designers (as David reasonably points out, that would be great), and/or a BCP for network operators.
> One can debate whether I did the right thing (but that wasn't appealed, and I wasn't recalled). I'd defer to the current ADs (both now and after IETF 107) on what to do next, but I thought it would be useful to provide background on how TSVWG got here.
> Best of luck to Magnus, Mirja, and Martin, of course. And you don't HAVE to have a name that starts with the letter "M" to stand as a nominee for TSV AD this coming Nomcom cycle :-)
> Best,
> Spencer
> (1) <>
> (2) <>
> (3) <>
> (4) <>
> (5) <>

Colin Perkins