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

David Schinazi <> Thu, 27 February 2020 18:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D317D3A0542 for <>; Thu, 27 Feb 2020 10:39:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 mjwGE3Kjv4Xd for <>; Thu, 27 Feb 2020 10:39:32 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 68E743A0414 for <>; Thu, 27 Feb 2020 10:39:32 -0800 (PST)
Received: by with SMTP id o15so358984ljg.6 for <>; Thu, 27 Feb 2020 10:39:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=I2nIhpaZaKjssh7HMfglYywB/XUmJWbYwpgUsDUVum0=; b=rKYywgLpy2OSr+vjqWQH6YLZ/nrYa9z/sdYlIJZC7NTdDTCcx2A3eJd84W/skyC9jO kGYmhWeGfuMoC9IRhEkx2VPixi00d1rAV3aCYVu6I3uB2Zhw8axq5eECaH1kHQlNrzj6 yfPstv90XqX4Bih28JQoCNWHzdYBcFtKjOKN4FAv67QEH5yhMcKgY/4hz5+QpzBZ1z4v FX6FA3M7Z3pKyFbGcGPbVafFFbiqYQFHAW0L48wJ/QW0r73BS+xPz4Lpa7NcHH/9+iBH 9Jl6mWP/5ac0jv5mbNEELE4fDu7GCDny+InH2+6sVZD6zfs7ksvj6A+pqJuerJOAuFuE TxVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=I2nIhpaZaKjssh7HMfglYywB/XUmJWbYwpgUsDUVum0=; b=aQ5t19Ce4JlnuxOFUy/keTqzzzsFL1iQkupfEDWyBPdMtBdXmLsk/IQhEWaHgexF5G MtA7Ssznezz5TNcr1Q/4Y57LTjL6ZU5sTHAkWH0IUp5AxMPqURCUvbJiQyGz4gjs5gwJ 4cEVrRJ40W5Z03FdTC9Se2ejBYBKxSCugA+Li8YBxTfJXPYOeaVT+qlFR12hi9ziZfIN 1ruFog4n6mdRR9OiGscXtuLJUk4WPW+rCOF5oY3BJPyRCJnc8Dn+W9/A3SP6hq94+fuk fbSMoVqg0dBRIJDEuVl0YwMj25afYysF3i2RP2UO115bMRYLKWyLlDANmDED3ujup5By gmkA==
X-Gm-Message-State: ANhLgQ3oe+EQBigiQ2b4HsDqjDyTsmQHnsPyPUfAyFT3OtxGQ0Qg0TwN J8X6RqutilXmgH0YhAtEMpn0OGjjKRVSfKQa/H17/u2d
X-Google-Smtp-Source: ADFU+vsOWWPs/MFS36Uxz25A3FkJLzxHJUSdk+hrW2rMOfeeDknTHjER6pbVOVGPM7C6UCrUlp+9vsFQdDEuD19N2/o=
X-Received: by 2002:a2e:a58c:: with SMTP id m12mr224183ljp.141.1582828770637; Thu, 27 Feb 2020 10:39:30 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: David Schinazi <>
Date: Thu, 27 Feb 2020 10:39:19 -0800
Message-ID: <>
To: Gorry Fairhurst <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="0000000000009d39d4059f930aa9"
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 18:39:35 -0000

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.


On Thu, Feb 27, 2020 at 1:09 AM Gorry Fairhurst <>

> 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.