Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 09 November 2016 17:07 UTC
Return-Path: <dkg@fifthhorseman.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ADAA12946E for <tls@ietfa.amsl.com>; Wed, 9 Nov 2016 09:07:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 foCacL14kVcO for <tls@ietfa.amsl.com>; Wed, 9 Nov 2016 09:07:11 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA721294BB for <tls@ietf.org>; Wed, 9 Nov 2016 09:07:11 -0800 (PST)
Received: from fifthhorseman.net (unknown [148.204.216.119]) by che.mayfirst.org (Postfix) with ESMTPSA id 1885AF98C; Wed, 9 Nov 2016 12:07:09 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 2DBCA20955; Wed, 9 Nov 2016 11:05:30 -0600 (CST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: mrex@sap.com, "Salz, Rich" <rsalz@akamai.com>
In-Reply-To: <20161109093122.6D3111A579@ld9781.wdf.sap.corp>
References: <20161109093122.6D3111A579@ld9781.wdf.sap.corp>
Date: Wed, 09 Nov 2016 11:05:27 -0600
Message-ID: <87inrweg88.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/d_UHg0lDg9sXUa_OLgEtUzFO7kM>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 09 Nov 2016 17:07:13 -0000
On Wed 2016-11-09 03:31:22 -0600, Martin Rex wrote: > The problem here is that this breaks (network) flow control, existing > (network socket) event management, and direction-independent connection > closure, and does so completely without value. Martin, you keep saying things like "without value", while other people on this thread (Rich, Ilari, Yoav) have given you examples of the value it provides. You don't seem to be trying to understand those positions. Your description of the problems it causes you are difficult to follow, and it doesn't sound like they have been experienced by other implementors. But other people are actively trying to make sure they understand your concerns (like ekr's post downthread here). Could you offer the rest of the list the same courtesy? Your earlier argument that the hidden data is deducable by traffic analysis anyway isn't a satisfying argument, for two reasons: (a) if it were reliably true, then your implementations could simply adopt the traffic analysis approach instead of inspecting the cleartext content types. If it causes too much additional expense, then it should increase the expense for adversaries who are monitoring traffic for these same signals as well, which is a security+privacy win. (b) We're including mechanisms (like padding) to make traffic analysis harder. More research is needed to know how to best provide this sort of indistinguishability. But if we decide instead that it's ok to directly publish any data that could possibly be inferred by traffic analysis, we will never improve the security of TLS for its users against traffic analysis, which will only grow more sophisticated over time. Why should we accept this limitation on TLS? This WG isn't chartered to defend the engineering optimizations made by any particular middlebox vendor. It's chartered to improve the privacy and security guarantees offered to users of TLS. Regards, --dkg
- [TLS] Working Group Last Call for draft-ietf-tls-… Joseph Salowey
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Ilari Liusvaara
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Ilari Liusvaara
- Re: [TLS] Working Group Last Call for draft-ietf-… Sean Turner
- Re: [TLS] Working Group Last Call for draft-ietf-… Yoav Nir
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Yoav Nir
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Yoav Nir
- Re: [TLS] Working Group Last Call for draft-ietf-… Ilari Liusvaara
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Daniel Kahn Gillmor
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Adam Langley
- Re: [TLS] Working Group Last Call for draft-ietf-… Watson Ladd
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Benjamin Kaduk
- Re: [TLS] Working Group Last Call for draft-ietf-… Salz, Rich
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Rex
- Re: [TLS] Working Group Last Call for draft-ietf-… Peter Gutmann
- Re: [TLS] Working Group Last Call for draft-ietf-… Kaduk, Ben
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Kaduk, Ben
- Re: [TLS] Working Group Last Call for draft-ietf-… John Mattsson
- Re: [TLS] Working Group Last Call for draft-ietf-… John Mattsson
- Re: [TLS] Working Group Last Call for draft-ietf-… Yuhong Bao
- Re: [TLS] Working Group Last Call for draft-ietf-… Eric Rescorla
- Re: [TLS] Working Group Last Call for draft-ietf-… Martin Thomson