Re: [TLS] draft-green-tls-static-dh-in-tls13-01

Jacob Hoffman-Andrews <jsha@eff.org> Sat, 08 July 2017 22:08 UTC

Return-Path: <jsha@eff.org>
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 DC907126E64 for <tls@ietfa.amsl.com>; Sat, 8 Jul 2017 15:08:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.003
X-Spam-Level:
X-Spam-Status: No, score=-7.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=eff.org
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 vWd6UC9Z4TRz for <tls@ietfa.amsl.com>; Sat, 8 Jul 2017 15:08:10 -0700 (PDT)
Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 340D6126C3D for <tls@ietf.org>; Sat, 8 Jul 2017 15:08:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:To:From:References:Subject; bh=6LPHU5MUQARf2oXu/BQtzagdNeBe7dEEFXsazeH9b14=; b=IV2OMiNYj5GY5Aj5kMevgsOfRFZk2D7AzFPKnycFq5fDBO0Wa5tUGarMHiFwGvLzx+ggZOKHurrSEKERktwE9ypaaP5lxAjCLgnXQ7esLmvOHi9TcitumasYo5ONCZnVu8A6iMPhEidZ2g76FrGJffmB1ue7JLXXLm4uceP+SfI=;
Received: ; Sat, 08 Jul 2017 15:08:08 -0700
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com>
From: Jacob Hoffman-Andrews <jsha@eff.org>
To: Matthew Green <matthewdgreen@gmail.com>, tls@ietf.org
Message-ID: <a71d565f-bb61-729b-cc12-28c409c0d713@eff.org>
Date: Sat, 8 Jul 2017 15:08:09 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1
MIME-Version: 1.0
In-Reply-To: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Received-SPF: skipped for local relay
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/x4An2ELcfHWkuIfWioXdTdFiDHo>
Subject: Re: [TLS] draft-green-tls-static-dh-in-tls13-01
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Sat, 08 Jul 2017 22:08:12 -0000

With all respect to the authors for a well-written paper, this draft
should not be adopted by TLS WG, because it would weaken the security of
TLS as deployed in practice.

If the TLS WG were to adopt this draft, one of the likely outcomes would
be implementation in a variety of popular TLS libraries, like OpenSSL
and SChannel. Unfortunately, including interception capability in
off-the-shelf software is like keeping your plutonium next to your
potato chips; something is bound to go wrong. For instance, performance
advocates may suggest turning on the interception capability in order to
save cycles. If such advice is broadly adopted, we will effectively have
reintroduced non-forward secret sessions to TLS. In TLS 1.3 there are no
NULL cipher suites. Why should there be a commonly implemented mode that
breaks forward secrecy?

The "Weaknesses of Alternative Solutions" section nicely sums up the
tradeoffs of various techniques. Under "Export of ephemeral keys," it says:

> The complexity of the solution is a problem that adds risk.

This is absolutely true, but doesn't mention the bearer. The enterprise
that requires the interception bears the risk (or, more likely, the
vendors who sell interception software). I think when balancing the
monetary risk to the enterprise against the privacy risk to billions of
consumer Internet users, the consumers should win.

I would also point out that retrospectively decrypting pcaps asks TLS to
do double duty: as at-rest encryption in addition to transit encryption.
If, instead, each TLS server shares a copy of its plaintext via a TLS
connection to an encrypted storage service, the enterprise gets much
better security properties. Not only does it retain forward secrecy for
in-datacenter traffic, it can control the keys for at-rest data much
more tightly. Instead of every TLS frontend having the keys for
retrospective decryption, those keys can be limited to auditors or
security team members.