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

[Kathleen Moriarty <[e-mail]>]

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.

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

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

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.

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.

Section 5.4
I think you have a typo here:
   Integrity checks can undetected modification of protocol fields by
   network devices,

-- 

Best regards,
Kathleen