Re: [tsvwg] New Version of draft-ietf-tsvwg-transport-encrypt (12)

[Gorry Fairhurst <[e-mail]>]

On 16/03/2020 15:33, Eric Rescorla wrote:
>
>
> On Mon, Mar 16, 2020 at 7:51 AM Gorry Fairhurst <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>
>     On 16/03/2020 13:06, Eric Rescorla wrote:
>>
>>
>>     On Mon, Mar 16, 2020 at 2:36 AM Gorry Fairhurst
>>     <[e-mail] <mailto:[e-mail]>> wrote:
>>
>>         Ekr,
>>
>>         On 15/03/2020 13:19, Eric Rescorla wrote:
>>>         Let me try to expand my point a bit.
>>>
>>>         Longstanding practice is for entities in the middle of the
>>>         network to
>>>         use signals that were intended for the endpoint for their own
>>>         purposes.  With QUIC (and a lesser extent SCTP/DTLS), those
>>>         signals
>>>         are being encrypted and thus unavailable to those non-endpoint
>>>         entities; this draft is mostly devoted to documenting the
>>>         negative
>>>         impact of that change on the operations of those entities.
>>>
>>         I disagree that this is "documenting the negative impact of
>>         that change".
>>
>>         The draft is about how this protocol information has and is
>>         being used. As long as I can remember, there has been devices
>>         that utilise some of this information, at the edge of an
>>         enterprise there is often at least one device with this role;
>>         within a managed network there are devices; etc. If the trend
>>         to use encrypted methods continues, some of these practices
>>         need to be re-assessed, and the functions more widely
>>         understood than in an era when nearly everything was thought
>>         to be TCP or "multimedia".
>>
>>
>>     I'm not sure what you're arguing here. What I said above is that
>>     this draft was "mostly devoted to documenting the negative
>>     impact of that change on the operations of those entities."
>>     In other words, it lists a bunch of things that people do now
>>     that will stop working. Do you not think that much of the
>>     material in this draft is of that form?
>>
>>     -Ekr
>>
>     So the conclusion, para 2 states:
>
>     "   This document has described some current practises, and the
>        implications for some stakeholders, when transport layer header
>        encryption is used.  It does not judge whether these practises are
>        necessary, or endorse the use of any specific practise.
>
>
> I don't really see how this addresses the question we are presently
> discussing, which is where I said
>
> "this draft is mostly devoted to documenting the negative
> impact of that change on the operations of those entities."
>
> It seems like you disagree with that characterization, but it's not
> clear to me why, and this text certainly doesn't address that.
>
>
>     I agree many existing tools would stop working if IPsec formed the
>     majority of traffic, same for QUIC. I think when considering what
>     to do next, it can be useful to work from the current position and
>     understand the implications of changes that are being
>     proposed/used/whatever.
>
>
>     At least from my personal position, this document was providing
>     some input to that thinking. So, I do not understand your issue.
>
> Well, it's pretty far upthread, but see the second paragraph of my review:
>
>    First, it's really not clear what purpose this document serves.  While
>    superficially an analysis of the impact of transport layer encryption
>    as a guide to designers, in the context of the design and deployment
>    of QUIC and SCTP/DTLS, both of which encrypt most or all of the
>    transport header, it's hard not to read this document as an implicit
>    critique of those decisions. It's not like there's some other big
>    transport protocol design effort going on in IETF that would be
>    informed by these considerations.
>
> I'm not really sure how to state this more clearly.
>
> -Ekr
>
Well, thanks for trying. Either we don't understand one another, or we 
differ. Other people have commented in the same thread, and I concur 
with what Spencer said.

Gorry

Also: I will resolve that specific text issue you raised, because that 
was open to very wrong interpretation.