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

Joe Touch <> Wed, 09 October 2019 15:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 52FF21200B7 for <>; Wed, 9 Oct 2019 08:25:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5UUPcAvmy3FE for <>; Wed, 9 Oct 2019 08:25:19 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DFE1D120089 for <>; Wed, 9 Oct 2019 08:25:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=dSVRRLTWlrSgNxP77qGqIBlHSTLXj/zxsxEIv0O/uZc=; b=fGzmPfC/vQkDgw6qhODRS8ltI xsD/SETZjAzPpp40PeLY8GAhKvBcoOuJ4Kv8FuEEW5f0NLMLARjq8qL5mbKeIas7kSf6IhTnraN3U XeRYjkoFAW+xH9HZ5+02gm+hCBfNOeOY7ftSsc4nxFxpvQFDdk/WG1H7A4kqDct83v+q7yuwxr0o/ ZT2nhp04dNfps2EefHND03PkFuEoHCQ3VhCkkExe0WKhtJkDQJcvE5pGUaYAkWZuQMwPdp7VZTKIP +VmKJCwOV0lQnGn12rVyGUUHScbxd/Gb8/OZhoClPTyVsUNivHPZJIaEfVS0htyqy5oEd0xeQVn/Y L/lALkOBQ==;
Received: from ([]:63220 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1iIDpy-001SAx-11; Wed, 09 Oct 2019 11:25:18 -0400
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <>
In-Reply-To: <>
Date: Wed, 9 Oct 2019 08:25:13 -0700
Cc: Christian Huitema <>, "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <>
To: Gorry Fairhurst <>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, closes 23 October 2019
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Oct 2019 15:25:22 -0000

> On Oct 9, 2019, at 8:12 AM, Gorry Fairhurst <> 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,

DTLS or DNS over TCP with TLS would protect against DNS hijacking.

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