Re: [tsvwg] Review of draft-fairhurst-tsvwg-transport-encrypt

Gorry Fairhurst <> Thu, 17 May 2018 05:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE41312E8EF for <>; Wed, 16 May 2018 22:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sCaM05_lMgYp for <>; Wed, 16 May 2018 22:52:52 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 42FDE12EA8D for <>; Wed, 16 May 2018 22:52:52 -0700 (PDT)
Received: from Gs-MacBook-Pro.local ( []) by (Postfix) with ESMTPA id 1A5111B0015C; Thu, 17 May 2018 06:52:15 +0100 (BST)
Message-ID: <>
Date: Thu, 17 May 2018 06:52:15 +0100
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: Kathleen Moriarty <>
CC:, Colin Perkins <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [tsvwg] Review of draft-fairhurst-tsvwg-transport-encrypt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 May 2018 05:53:10 -0000

Thanks Kathleen,

it really helps to receive reviews, I'll try to respond to each in turn.

On 08/05/2018, 18:22, Kathleen Moriarty wrote:
> Hello Gorry&  Colin,
> Thanks for your work on this draft.  In my opinion, it is very
> important to dig through the implications of encrypting transport
> headers.  The document is well written and easy to read, thanks for
> that as well.  Al and I had a hard time with that since ours was
> contribution driven and controversial.
> Here's some feedback from my review that I hope you find helpful:
> General:
> If you added section references to mm-wg-encrypt where it is
> referenced, that may be helpful to the reader.
I have now tried to do this where I could.
> Specific feedback:
> The apps side will object to this phrasing as they don't see the need
> for any 'help'.  I agree with your point, just warning of the obstacle
> in case you can reword it to prevent objections.
>     Choosing to encrypt all information may reduce
>     the ability for networks to "help" (e.g., in response to tracing
>     issues, making appropriate QoS decisions).
We aded more clarity on the ability for networks to "help" users and 
> Section 3 intro text
> Encrypted traffic can also be profiled to identify threat actors.
> This will continue to be important as threat actors may have advanced
> capabilities and may modify the encrypted streams in identifiable ways
> that can differentiate their traffic from others.
> I was expecting to see some text toward the end of 3 on adoption of
> these protocols.  We can put out protocols, but it's up to industry to
> decide when and where to adopt protocols.
I'd be happy to improve this section, but at the moment I'm unsure what 
you have in mind.
>  From a few recent talks,
> what I saw from the audiences is that those aware of QUIC are outright
> blocking it.  The business imperative is not there for the
> applications using QUIC to justify it's use within the business
> network, at least not yet.
Indeed. I have seen similar talks and discussions that take this view. 
We are trying to the base the draft on what has been deployed and 
approaches that have been used - do you think we could/should say more?
> Section 3.3
> Do you want to make this specific to IPsec tunnel mode since that
> hides the true end points as well?  Transport mode isn't well deployed
> because of interoperability issues and not current use case driving
> it's usage, but that does leave the true IP source and destination
> addresses exposed, more than what you see with tunnel mode.
Yes. I have done this.
> Section 5.3
> This is starting to touch on NetNeutrality and if you are going to go
> there, you should state it explicitly.  At the enterprise level (it
> doesn't seem like you are covering that in this draft), I am hearing
> QUIC is outright blocked by those that are aware of it on the network,
> so it's not just NetNeutrality that will impact it's deployment.
> Perhaps rephrasing may help?  Here's the text I'm talking about:
>     A lack of data reduces the level of precision with which mechanisms
>     are applied, and this needs to be considered when evaluating the
>     impact of designs for transport encryption.  This could lead to
>     increased use of rate limiting, circuit breaker techniques [RFC8084],
>     or even blocking of uncharacterised traffic.  This would hinder
>     deployment of new mechanisms and/or protocols.
I would love a suggestion?
> Section 5.4
> I think you have a typo here:
>     Integrity checks can undetected modification of protocol fields by
>     network devices,
Indeed, and now resolved.