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

Joe Touch <> Thu, 10 October 2019 01:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3FC4312004C for <>; Wed, 9 Oct 2019 18:45:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.218
X-Spam-Status: No, score=-1.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] 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 RLptWrXHGY99 for <>; Wed, 9 Oct 2019 18:45:15 -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 7444F120020 for <>; Wed, 9 Oct 2019 18:45:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding: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=OY9u1F9+Zp9AVpa7HUofkaYms0ICYewQ3Em+hG4bOL4=; b=anXxS5paWLLCfSMw7sFjyyjat JFOR1MsbYPOdpd1h/yhBAnbNJ2k45AwWq40EYlKHHkgRxi9r1cQDY0sGP+pSKIPolPjvNczYaR8qe M/gZH2lFEFtHu19JsxV20ZKDFVH0g4REtNtzIoAAsNPSKSAiv4vlNNn/1Sw1MOkz/BmftVIs0d8ST Sscx0wO7OEamgxb9+zV4srnQ38tKjc82LZYtDmvrzG8hD1tdVKwcKvP7lg/Yp3H39xKK2Tiw8rRws wQHe2+ORtjUydTrLerLh9z4Y5/gijD9Y0Dr/Uu616Q2BrdahqZc+plS6X38prA1osabsK2zplgATj fX34UJkww==;
Received: from ([]:64044 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <>) id 1iINVu-004227-3z; Wed, 09 Oct 2019 21:45:14 -0400
Content-Type: multipart/alternative; boundary="Apple-Mail=_401B0210-A5AD-4F03-9316-043E0426BE51"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <>
In-Reply-To: <>
Date: Wed, 9 Oct 2019 18:45:09 -0700
Cc: Christian Huitema <>, "" <>
Message-Id: <>
References: <> <> <> <> <> <>
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: Thu, 10 Oct 2019 01:45:17 -0000

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