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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Thu, 17 May 2018 05:52 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE41312E8EF for <tsvwg@ietfa.amsl.com>; Wed, 16 May 2018 22:52:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCaM05_lMgYp for <tsvwg@ietfa.amsl.com>; Wed, 16 May 2018 22:52:52 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 42FDE12EA8D for <tsvwg@ietf.org>; Wed, 16 May 2018 22:52:52 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 1A5111B0015C; Thu, 17 May 2018 06:52:15 +0100 (BST)
Message-ID: <5AFD188F.2050309@erg.abdn.ac.uk>
Date: Thu, 17 May 2018 06:52:15 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
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 <kathleen.moriarty.ietf@gmail.com>
CC: tsvwg@ietf.org, Colin Perkins <csp@csperkins.org>
References: <CAHbuEH7DND0uz9bv9YSD_9BW02AfWB+YmONHMBMV+Xg7w-RDPw@mail.gmail.com>
In-Reply-To: <CAHbuEH7DND0uz9bv9YSD_9BW02AfWB+YmONHMBMV+Xg7w-RDPw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/BoURX_Ww-Z8e21GM8bahdwHfk_g>
Subject: Re: [tsvwg] Review of draft-fairhurst-tsvwg-transport-encrypt
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=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 
subscribers.
> 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.
Gorry