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

[Gorry Fairhurst <[e-mail]>]

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