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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 09 October 2019 15:36 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D7E1120839 for <tsvwg@ietfa.amsl.com>; Wed, 9 Oct 2019 08:36:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeDvhN5qmRLT for <tsvwg@ietfa.amsl.com>; Wed, 9 Oct 2019 08:36:28 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by ietfa.amsl.com (Postfix) with ESMTP id 35E2A12080B for <tsvwg@ietf.org>; Wed, 9 Oct 2019 08:36:27 -0700 (PDT)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 999C41B00111; Wed, 9 Oct 2019 16:36:23 +0100 (BST)
Message-ID: <5D9DFE77.9010504@erg.abdn.ac.uk>
Date: Wed, 09 Oct 2019 16:36:23 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Joe Touch <touch@strayalpha.com>
CC: Christian Huitema <huitema@huitema.net>, "tsvwg@ietf.org" <tsvwg@ietf.org>
References: <CE03DB3D7B45C245BCA0D2432779493630766752@MX307CL04.corp.emc.com> <e8c30f3f-606f-0c0d-a7dd-b2bb6f31a9fd@huitema.net> <A2F184BB-E352-4AE6-B7A0-FDF6D8851DFB@strayalpha.com> <5D9DF8E3.3020200@erg.abdn.ac.uk> <2D74F74C-C785-4AED-8390-9102FEBCC9F7@strayalpha.com>
In-Reply-To: <2D74F74C-C785-4AED-8390-9102FEBCC9F7@strayalpha.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/c2FGCXg5Hc60uPh8upD5ZEOKaE8>
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Oct 2019 15:36:37 -0000

On 09/10/2019, 16:25, Joe Touch wrote:
>
>> On Oct 9, 2019, at 8:12 AM, Gorry Fairhurst<gorry@erg.abdn.ac.uk>  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?
> DTLS or DNS over TCP with TLS would protect against DNS hijacking.
Again, we agree, which text do you think needs improved.
> Encrypted is only one part of the equation; authenticated is another (TLS/DTLS doesn’t encrypt headers). But all of these help protect against hijacking.
>
> I’m supporting Christian’s position - the doc is too biased towards “intermediate boxes have rights” than “endpoint users have rights”.
>
> Joe
Gorry