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

[Kathleen Moriarty <[e-mail]>]

Hi Gory,



On Thu, May 17, 2018 at 9:05 AM, Spencer Dawkins at IETF
<[e-mail]> wrote:
> Hi, Kathleen,
> On Thu, May 17, 2018 at 12:53 AM Gorry Fairhurst <[e-mail]>
> wrote:
>>
>> Thanks Kathleen,
>>
>> it really helps to receive reviews,

Very happy to help as this type of draft can be tricky and you've done
a nice job!

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

I'll try to do the same and thank Spencer in advance for providing a
very good solution on one of the points.

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

Great, did you continue the use of the word help or find another way
to phrase it?  I could see that getting objections/comments in the
IESG.

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

I think this would be a very good solution to the point as it's early
and we don't know what will happen yet longer term.  A business
imperative could arise in time.

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

Thanks.

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

This is a tough one.  I think the second paragraph will be read as a
threat to someone in the apps area, providing additional motivation to
encrypt session headers.  You may want to mention in the previous
paragraph that the use of overlay protocols may be deployed to assist
with evaluations performed.

The second paragraph is a slippery slope.  Is there a better way to
bridge from the first to the second sentence in the last paragraph?
There's a leap there where the first sentence would probably be fine
on it's own, but the second either needs to be expanded with
proceeding text or removed.

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

Thanks!

>> Gorry
>>
>



-- 

Best regards,
Kathleen