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

Gorry Fairhurst <> Mon, 16 March 2020 14:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04D323A09A3 for <>; Mon, 16 Mar 2020 07:51:53 -0700 (PDT)
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 M0NwG2zVI1fV for <>; Mon, 16 Mar 2020 07:51:51 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0C94E3A09A1 for <>; Mon, 16 Mar 2020 07:51:50 -0700 (PDT)
Received: from GF-MacBook-Pro.local ( []) by (Postfix) with ESMTPSA id 8565F1B001FC; Mon, 16 Mar 2020 14:51:42 +0000 (GMT)
To: Eric Rescorla <>
Cc: Martin Duke <>, David Schinazi <>, "" <>
References: <> <> <> <> <> <> <> <> <> <>
From: Gorry Fairhurst <>
Message-ID: <>
Date: Mon, 16 Mar 2020 14:51:41 +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="------------E17232819CC789ECC748F2C4"
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: Mon, 16 Mar 2020 14:51:53 -0000

On 16/03/2020 13:06, Eric Rescorla wrote:
> On Mon, Mar 16, 2020 at 2:36 AM Gorry Fairhurst < 
> <>> wrote:
>     Ekr,
>     On 15/03/2020 13:19, Eric Rescorla wrote:
>>     Let me try to expand my point a bit.
>>     Longstanding practice is for entities in the middle of the network to
>>     use signals that were intended for the endpoint for their own
>>     purposes.  With QUIC (and a lesser extent SCTP/DTLS), those signals
>>     are being encrypted and thus unavailable to those non-endpoint
>>     entities; this draft is mostly devoted to documenting the negative
>>     impact of that change on the operations of those entities.
>     I disagree that this is "documenting the negative impact of that
>     change".
>     The draft is about how this protocol information has and is being
>     used. As long as I can remember, there has been devices that
>     utilise some of this information, at the edge of an enterprise
>     there is often at least one device with this role; within a
>     managed network there are devices; etc. If the trend to use
>     encrypted methods continues, some of these practices need to be
>     re-assessed, and the functions more widely understood than in an
>     era when nearly everything was thought to be TCP or "multimedia".
> I'm not sure what you're arguing here. What I said above is that
> this draft was "mostly devoted to documenting the negative
> impact of that change on the operations of those entities."
> In other words, it lists a bunch of things that people do now
> that will stop working. Do you not think that much of the
> material in this draft is of that form?
> -Ekr
So the conclusion, para 2 states:

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

I agree many existing tools would stop working if IPsec formed the 
majority of traffic, same for QUIC. I think when considering what to do 
next, it can be useful to work from the current position and understand 
the implications of changes that are being proposed/used/whatever.

At least from my personal position, this document was providing some 
input to that thinking. So, I do not understand your issue.