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

Colm MacCárthaigh <colm@allcosts.net> Sat, 15 July 2017 17:34 UTC

Return-Path: <colm@allcosts.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 2FD7712702E for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 10:34:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.com
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 kyU646iiDWu5 for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 10:34:03 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87D9F126C2F for <tls@ietf.org>; Sat, 15 Jul 2017 10:34:03 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id v193so35455697ywg.2 for <tls@ietf.org>; Sat, 15 Jul 2017 10:34:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b/u7nDIImQYOuzSAmVjwODkw5D6TZnpRRn1ZAo6gWUY=; b=KMWRmnXIAzloxtUF/fv3LcPj3mzh0o2ehgvRrl+5R4A/alw+Hw+wXBgPQpU5kNM2w1 dbxHU5ur6BAQVpweOaB/suWBFwtSkk24yd1FHNSntUrTBMhM2IEg9dPZT3cdyXUMD5ug GnMBND5eRcCRM+uTLP/yNW1cNRcmUaxLdikxu8AD0juEFrBrJlcYlfY5oVu+2G4GIzSp ttjRZA53LNodtnWee4PAFn6g+RlHLl2NUcyVw10lBYz7+HNmdGYBWGOOUAwgHUY4XAVI jtBA5pef9iowmesptkIQlVCuEyV9QY6U2DLCUZp1H5ENC6Fj7YUnbYLPm3lG7BA1tCxC QP4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=b/u7nDIImQYOuzSAmVjwODkw5D6TZnpRRn1ZAo6gWUY=; b=HoT3DcPiPvx2rdJY7KgQ7jHrx1YTTN0sbVmzjryPai035vPxzXnR2/IDSnKOrdU2kt dZgVeQMyxCLQuUxJZQv8CwelYQ1q3bz2O0/JZyiieJB7YNXzj4z/Qs+jtWz5YZnHhyJ4 DSPooU+bBdl465277uXdtg96THj3YCKRii93Y1aPGB9M3svJlk+6o4JRyX+KLdW1TfcN MbzM/C7BjyEenWuO+CIzVLxuNH9uIqIBadL+3UmDScn7gqBHvU1WolQeLDnMywYJMEFI SyWxpsoFmX9nnSuiqLe5IMhkjssxUhcl9lEqSR+Q4RtECnrpsxfNci9MqMUD3fqHdSzd r2SQ==
X-Gm-Message-State: AIVw111pTFj4OZMZGgBX+YMALvTa8DAnUIkBuAcK6kYT+dkHNx2ueMBm Ic0+XCjDa+1mMpOcTGm/YMWc+781aO8i
X-Received: by 10.129.90.85 with SMTP id o82mr5287408ywb.251.1500140042599; Sat, 15 Jul 2017 10:34:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.27.4 with HTTP; Sat, 15 Jul 2017 10:34:01 -0700 (PDT)
In-Reply-To: <87o9smrzxh.fsf@fifthhorseman.net>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAOjisRxxN9QjCqmDpkBOsEhEc7XCpM9Hk9QSSAO65XDPNegy0w@mail.gmail.com> <CABtrr-XbJMYQ+FTQQiSw2gmDVjnpuhgJb3GTWXvLkNewwuJmUg@mail.gmail.com> <8b502340b84f48e99814ae0f16b6b3ef@usma1ex-dag1mb1.msg.corp.akamai.com> <87o9smrzxh.fsf@fifthhorseman.net>
From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= <colm@allcosts.net>
Date: Sat, 15 Jul 2017 10:34:01 -0700
Message-ID: <CAAF6GDc7e4k5ze3JpS3oOWeixDnyg8CK30iBCEZj-GWzZFv_zg@mail.gmail.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: "Salz, Rich" <rsalz@akamai.com>, Joseph Lorenzo Hall <joe@cdt.org>, Matthew Green <matthewdgreen@gmail.com>, Nick Sullivan <nicholas.sullivan@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114924265a78c405545e92b3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Do9MnNnmi4WSEZnQj58LEVKdg8E>
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, 15 Jul 2017 17:34:05 -0000

On Fri, Jul 14, 2017 at 11:12 PM, Daniel Kahn Gillmor <dkg@fifthhorseman.net
> wrote:

>  * This proposed TLS variant is *never* acceptable for use on the public
>    Internet.  At most it's acceptable only between two endpoints within
>    a datacenter under a single zone of administrative control.
>

>  * Forward secrecy is in general a valuable property for encrypted
>    communications in transit.


> If there's anyone on the list who disagrees with the above two
> statements, please speak up!
>

I agree with the second statement, but I don't really follow the logic of
the first. On the public internet, it's increasingly common for traffic to
be MITMd in the form of a CDN. Many commenters here have also responded
"Just use proxies". I don't get how that's better.

A proxy sees all of the plaintext, not just selected amounts. All of the
same coercion and compromise risks apply to a proxy too, but since it
undetectably sees everything,  that would seem objectively worse from a
security/privacy risk POV.

Or put another way: if these organizations need to occasionally inspect
plaintext, would I prefer that it's the kind of system where they have to
go pull a key from a store, and decrypt specific ciphertexts on demand
offline, or do I want them recording plaintext *all* of the time inline? It
seems utterly bizarre that we would collectively favor the latter. We end
up recommending the kinds of systems that are an attacker's dream.

Here's what I'd prefer:

 * Don't allow static DH. In fact, forbid it, and recommend that clients
check for changing DH params.
 * For the pcap-folks, define an extension that exports the session key or
PMS, encrypted under another key. Make this part of the post-handshake
transcript.
 * pcap-folks can do what they want, but clients will know and can issue
security warnings if they desire. Forbiding static DH enforces this
mechanism, and we can collectively land in a better place than we are
today.


-- 
Colm