Re: [TLS] Enforcing Protocol Invariants

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Mon, 12 November 2018 14:15 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 0C982130DCA for <tls@ietfa.amsl.com>; Mon, 12 Nov 2018 06:15:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_PERMERROR=0.01] 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 2HmYtEjkNwFs for <tls@ietfa.amsl.com>; Mon, 12 Nov 2018 06:15:50 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0CE91274D0 for <tls@ietf.org>; Mon, 12 Nov 2018 06:15:50 -0800 (PST)
Received: from fifthhorseman.net (ool-6c3a0662.static.optonline.net [108.58.6.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id C80A2F99A; Mon, 12 Nov 2018 09:15:48 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 9870520C0C; Mon, 12 Nov 2018 19:06:59 +0700 (+07)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Ryan Carboni <ryacko@gmail.com>, Eric Rescorla <ekr@rtfm.com>
Cc: "\<tls\@ietf.org\>" <tls@ietf.org>
In-Reply-To: <CAO7N=i2L9mY1kdZNhgSV90e5FN64VBh0miApQv_9ws9fCdaGVg@mail.gmail.com>
References: <CAO7N=i0g9d9x5RdF_guKm3GDAxVRHSV+eHffs6kiJm6dWO7tvw@mail.gmail.com> <CABcZeBPb2aPE3eXsqD5-qvWO88W=iMRxZ9YgCXZiTSGAPBDMxQ@mail.gmail.com> <CAO7N=i2L9mY1kdZNhgSV90e5FN64VBh0miApQv_9ws9fCdaGVg@mail.gmail.com>
Date: Mon, 12 Nov 2018 07:06:59 -0500
Message-ID: <87k1lia49o.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MC0YwaXpWIcMY0ubjOGlmkRRICE>
Subject: Re: [TLS] Enforcing Protocol Invariants
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 12 Nov 2018 14:15:52 -0000

On Thu 2018-11-08 18:31:28 -0800, Ryan Carboni wrote:
> Encrypting common knowledge is cargo cult fetishism for cryptography. The
> files could be sent unencrypted, and protected using subresource integrity.
> If you are sharing the same data to multiple second parties to serve to a
> single third party, the value of encryption is less than zero.

I agree that the widespread move to CDNs makes those CDNs a point of
vulnerability and potential compromise.

But from a harm reduction point of view, encrypting data that transits a
CDN does protect that traffic from surveillance by non-CDN network-based
adversaries.

There is more research and development work to be done to make that
protection even more robust: anti-traffic analysis work, for example.
But simply reverting to cleartext would be a mistake.

Ryan, your posts in this thread suggest an understandable frustration
with cryptographic deployment on the public Internet, and perhaps an
even more understandable frustration with cryptographic *deprecation* on
the public Internet.  However, the web suffers from the same two
problems as much of the public Internet: the curse of the deployed base,
and a small but non-negligible fraction of confused, interfering
middleboxes.

I love proposals that happily ignore these problems, because they tend
to be elegant, and more often correct than janky old stuff!  But, if we
want our protocol designs to actually eventually replace old, worse
protocol designs, we need to look at deployment/upgrade/deprecation
paths, which involves a *lot* of ugliness -- the main job of the TLS WG,
afaict.  Otherwise, our beautiful new designs will get rolled out, and
will simply co-exist alongside the old brokenness :/

     --dkg