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