Re: [tsvwg] New Version Notification for draft-fairhurst-tsvwg-transport-encrypt-07.txt

Joe Touch <> Fri, 11 May 2018 04:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 763FD12D86F for <>; Thu, 10 May 2018 21:20:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.99
X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dYzm2gKxi2mi for <>; Thu, 10 May 2018 21:20:46 -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 960BB12D86D for <>; Thu, 10 May 2018 21:20:46 -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=+HTcCTqqsiVUoapOIZBqFY8KsRuBBwzUYanxdU/SvJk=; b=lctdNAd49hBULy12QRbJ+ujBG XG3s0U0fJBhaphn7AXFVBXzcRIvg66nJCOuCyB7VVWleriNY4Hp0Dz6Hckg2W6PvUikoIeuo8m1y6 lIZcrep7ByfE4Jwf+2EfWIzi887/z2cvA2Tj1eRk/2HOYqYBlR5Zs6bGPUrdao5tXXMJR19PT2QrF IkRTGQuYj8U+p+VgOKjJJG1EghSaYWR/WLq/NKaBW35iR7FLB9VVoMu6bjCWCxfr+udXe+C4pJMDq R/uybjjKyrzVAkKf66XL9O93KQoik8dMLQNssBh1WXy4w6E4f0tfgWOQffr0SwS/rW+RbZB2l5JKT bKnlE52+g==;
Received: from ([]:51438 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from <>) id 1fGzXu-004BTg-1t; Fri, 11 May 2018 00:20:42 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Joe Touch <>
In-Reply-To: <>
Date: Thu, 10 May 2018 21:20:40 -0700
Cc: "" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
X-Mailer: Apple Mail (2.3445.6.18)
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] New Version Notification for draft-fairhurst-tsvwg-transport-encrypt-07.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Transport Area Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 11 May 2018 04:20:48 -0000

Hi, Gorry, et al.,

I disagree with the tone and focus of this document.

It appears to give many reasons why hiding transport info from on-path observers is bad - bad for the network, bad for operators, and bad for everyone.

It reads like an Orwellian propaganda brochure on how Big Brother is only here to help - won’t you leave the cameras on?

The doc fails to recognize:
	- the fact that encryption (via tunneling, esp) is already undermining a lot of this sort of “help” 
	- the fact that users can - and should - find a lot of what passes for “help” quite a bit creepy
	- the fact that transport protocols were never intended to have any meaning anywhere but the endpoints
		and that, in fact, that’s the only place where they do have meaning anyway

If this doc goes forward, I sincerely hope there will be a more balanced presentation of the CONS of the kind of on-path snooping of traffic that this document largely presents as beneficial.



Some details follow:

- the title and abstract focus on transport header confidentiality; this begs the need for sections 3.1, 3.2, and parts of 3.4 - which have nothing to do with *transport header* confidentiality
	- the doc reports in other ways to address transport encryption in general; that’s a much larger issue to include, with entirely different implications

- the doc speaks of ossification as if it is only harmful; that same ossification provides the stability on which other upper layer protocols often rely, so having a “stable” (ossified) protocol could be considered an advantage too (beyond merely allowing in-network devices to predict their location)
	- I disagree that encryption of transport headers would prevent ossification; they could similarly be ossified by being the only ones supported using encryption at the endpoints

- the doc focuses on the impact of transport header encryption on a number of “features” that have emerged, but fails to address whether those “features” are desirable (i.e., just because we CAN do certain things, and HAVE DONE certain things, is independent of whether we should continue to design protocols to support those things)

- the intro fails to address the valid privacy motivations for obscuring transport information, esp. given transport protocols are themselves meaningful ONLY at the endpoints
	e.g., I could easily modify two hosts to exchange packets that look like UDP but are actually TCP
	this is akin to port renumbering at the endpoints
	fundamentally, in the Internet, transport headers have meaning ONLY at the two endpoints engaging in a given communication, so we really are “living on borrowed time” to assume that in-network devices can - or should - be able to interpret them at all, even when they appear not to be encrypted

- I do NOT agree of nearly anything in section 2.1, especially as it is then used to justify the remainder of section 2
	this entire section reads a lot like “the government needs to track your every move so we can build better roads for you”; it’s quite creepy.

- section 3 omits discussions of encrypted tunnels (IPsec or otherwise), all of which obscure access to transport headers

- sec 3.2 (if retained, and I hope it is not), should include tcp-ao-enc (yes, still a draft, but relevant to the discussion if retained)

- sec 3 omits TCPcrypt too (not sure where to put it because I haven’t cared to track how it has (d)evolved).

- not sure I agree that the transport layer is the first end-to-end interaction across the Internet; the same is true for the IP layer (esp, e.g., IPv6 Destination Options, among other things).

- finally, this doc seems oblivious to the reality that encryption is coming, like it or not - esp across the backbone, and that this has been the case for a while now (with VPNs)