Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019

[Gorry Fairhurst <[e-mail]>]

Thanks Joe for this, I'm keen to see if any of your understanding can be 
translated into a change, so I'd liek to continue this thread a little...

On 10/10/2019, 02:45, Joe Touch wrote:
>
>
>> On Oct 9, 2019, at 8:36 AM, Gorry Fairhurst <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> On 09/10/2019, 16:25, Joe Touch wrote:
>>>
>>>> On Oct 9, 2019, at 8:12 AM, Gorry Fairhurst<[e-mail] 
>>>> <mailto:[e-mail]>>  wrote:
>>>>
>>>> On 09/10/2019, 15:38, Joe Touch wrote:
>>>>> +1
>>>>>
>>>>> IMO, this isn’t a “tussle” so much as “I really want to do 
>>>>> something I know I shouldn’t be doing”.
>>>>>
>>>>> A lot of what transport security prevents is - from the middlebox 
>>>>> view - a problem.
>>>>>
>>>>> For many of us users, preventing middleboxes from doing things 
>>>>> like hijacking web, email, and DNS is *exactly* the protection we 
>>>>> were seeking.
>>>>>
>>>> I do not understand this particular comment with respect to this 
>>>> document: How does "hijacking web, email, and DNS" relate to 
>>>> whether transport headers are encrypted or not? I would have 
>>>> expected a comment like this had the document been talking about 
>>>> transport payload (e.g. whether to use TLS).
>>>>
>>>> Could you point me at some text that leads you to think the 
>>>> transport header encryption impacts application hi-jacking ?
>>> The doc mentions IPsec (encryption the transport headers and 
>>> payload), TCP AO (authenticating the header and contents), and 
>>> TLS/DTLS (authenticating contents based on headers).
>>>
>>> Any of these prevent HTTP from being hijacked and redirected, e.g., 
>>> as can occur on public WiFi. IMO,
>> So, in this respect we agree - but where did the text say otherwise?
>
> It doesn’t quite, but...
>
>>> DTLS or DNS over TCP with TLS would protect against DNS hijacking.
>> Again, we agree, which text do you think needs improved.
>
> I’m sorry to say it starts with the title - the impact of security on 
> network ops and the evolution of the Internet, which starts off on the 
> assumption that “security is getting in the way”, rather than 
> “exposure of TRANSPORT information to the network is a privilege”.
>
That was not intended. The scope we were given was not to describe what 
we think must be done, but to focus on what is currently being done with 
respect to how transport information is used.

The first para explicitly says "this document strongly supports the 
increased use of encryption in transport protocols". This document is 
intended to explicitly NOT say "don't encrypt" "don't use IPsec", "don't 
use other encryption".

- It should read more like if the majority of the traffic uses headers 
encryption, then there are some implications - (e.g. This news is not 
exactly new for those running networks that heavily use IPsec..) it this 
means some people need to think and do some things differently.
> Throughout, the assumption is that the network should have access to 
> this information and/or be able to modify it, rather than that users 
> have the right to lNOT let the network have that info or change it.
>
Wait!  Where does it say "should be able to modify it" ... that was also 
NOT intended as a part of this message, and if that can be read into 
what is said, then I'd like to re-address that.
> Encryption and privacy are spoken of as “benefits” and of “interest”, 
> rather than as rights. Access to transport is spoken of necessary and 
> denial of that access a threat to providing services.
>
> IMO, this is both incorrect and inappropriate to promote as an IETF 
> position. It leads to the very behavior discussed - that development 
> of legitimate transport protocol mechanisms being hampered by 
> middleboxes that violate whatever standard or policy interferes with 
> their revenue model.
>
I suggest such "middlebox" issues are covered in RFC 8404, and this was 
not the scope of this document. I had hoped that was already clear, but 
will look again.

The intended the focus is on providing transport and using network paths 
(which some SDO's also call "transport"). Examples of inputs received 
concern:  how to debug router queuing; understand congestion/VoIP 
performance/QoS/QoE/etc; detect and predict traffic patterns; layer 2 
interactions with radio; etc.
> It’s disingenuous to present this problem as merely two competing 
> viewpoints, and it’s hard to find a single way to address this issue 
> the way the document has evolved. It reads more like a warning to the 
> rest of us not to interfere with whatever middleboxes or network 
> operators want to do.
>
> I don’t know how to fix it, but I can’t stand idly by and endorse it 
> either.
>
> Joe
Sorry to hear that. We will take any comments and try to improve the words.

Gorry