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