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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Kathleen,
On Thu, May 17, 2018 at 12:53 AM Gorry Fairhurst <[e-mail]>
wrote:

> Thanks Kathleen,
>
> it really helps to receive reviews,


My thanks for your review as well. One point for Gorry, which might or
might not be helpful ...


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

In discussions about
https://datatracker.ietf.org/doc/draft-dawkins-panrg-what-not-to-do/, I've
been reminded that the IAB RFC on "What Makes for a Successful Protocol?"
would be a good thing for me to include as a reference (
https://datatracker.ietf.org/doc/rfc5218/).

Perhaps that would be useful for this draft as well?

Spencer


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