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

[Joe Touch <[e-mail]>]

> On Oct 9, 2019, at 8:36 AM, Gorry Fairhurst <[e-mail]> wrote:
> 
> On 09/10/2019, 16:25, Joe Touch wrote:
>> 
>>> On Oct 9, 2019, at 8:12 AM, Gorry Fairhurst<[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”.

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.

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.

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