Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Nick Sullivan <nicholas.sullivan@gmail.com> Wed, 25 October 2017 19:34 UTC

Return-Path: <nicholas.sullivan@gmail.com>
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 8C4EC1386A1 for <tls@ietfa.amsl.com>; Wed, 25 Oct 2017 12:34:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 5HIJ7z7cpOsS for <tls@ietfa.amsl.com>; Wed, 25 Oct 2017 12:34:55 -0700 (PDT)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 C0118138103 for <tls@ietf.org>; Wed, 25 Oct 2017 12:34:54 -0700 (PDT)
Received: by mail-wm0-x229.google.com with SMTP id t139so4033066wmt.1 for <tls@ietf.org>; Wed, 25 Oct 2017 12:34:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4klK8FDZoRhLvaSlvZjszzh7YWcTku971iQW8G9ixk8=; b=jxn714yaRM1owq2DNqKalgDtbgGjWT8iiIsT/kpIYZoupR96z67KtbAAtlLFclQVCf 4wwF5Gito9GVTjmPpuBXVmavIuADxx4HKOO6jPu3nIBiuM+fGBokZale3aE+27OZbcum swvj3aRvqCXOp28wnI9QKv1RshMMgWIvYOllj3/JUYvNOootfluUzzt1Oe+qOydsiwpZ LlTa3Y4NAhZgB3aQKdxm3895JbPN/U4LU1D9J9ICrKinUhd5mj8Hovzw7adhqu8mukSn KP5pbS25dwBqq2AM+0yug1vtLI7Cb+0NRJ5NSqfKmnN0kgDR/yZ4txOuxbuY41u9JaOy 4JRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4klK8FDZoRhLvaSlvZjszzh7YWcTku971iQW8G9ixk8=; b=ts0bphTGHcyMp/bUdCiF47X4BPpgB1QaZ4QH2bXXj2lrmbdBL464A/BX3xRcEFzSpi tj09GVbAS27Tg1+RDP67e7y3buM2ES8uLdWLqdi4EqIV8Ty1wL636wmmkv+zh5Lfk3Wd aBoP5PxXD3ptDOP2RsDqKu2FWvCpI0ZkQX42Np5UWG2NLB9xABzjMYk38GXFIimlFNAM 3+lCNOa3vTWIfF28MPoccuq7XJ1K2RccFvPVFbigCfey+TqbNXZwJTa6BrNa5cweHmWn e7zcqdMCY0vjx+tV2WmCNe5CrtGGmqwTaLMmpfUgpGVDh36xDF/fzBiW0cCkvTzIpBL8 KkJg==
X-Gm-Message-State: AMCzsaXqP1RPFDZUqsbE/M0dsjEhBRnPU24XdvCO2+sPsAIr+Wq0F8Zr NhqOrTzJh6ZlaAu+n1jEeGXy6am7ppfp24ZqnZI=
X-Google-Smtp-Source: ABhQp+QG4PzYs9Y9qjKYQgSbJH2FeRWVc9cv7KnkN94jAlb3rp4tnvcXNkFXgynHwryZOl8LP+Bvw5CtszhjWtJ8mBg=
X-Received: by 10.28.25.129 with SMTP id 123mr2697101wmz.17.1508960093107; Wed, 25 Oct 2017 12:34:53 -0700 (PDT)
MIME-Version: 1.0
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <a599d6ad-54db-e525-17d6-6ea882880021@akamai.com> <71e75d23f4544735a9731c4ec3dc7048@venafi.com> <3D2E3E26-B2B9-4B04-9704-0BBEE2E2A8F7@akamai.com> <000501d348e5$1f273450$5d759cf0$@equio.com> <70837127-37AB-4132-9535-4A0EB072BA41@akamai.com> <e8417cc424fe4bf3b240416dfffd807a@venafi.com> <B11A4F30-2F87-4310-A2F0-397582E78E1D@akamai.com>
In-Reply-To: <B11A4F30-2F87-4310-A2F0-397582E78E1D@akamai.com>
From: Nick Sullivan <nicholas.sullivan@gmail.com>
Date: Wed, 25 Oct 2017 19:34:41 +0000
Message-ID: <CAOjisRy14byF=LA+bH=_pjfa6HQqVYH=Rcj=man6=qaCxpS3bA@mail.gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
Cc: Paul Turner <PAUL.TURNER@venafi.com>, "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a114d3cee547c64055c6426d7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/92RYevnsIoZC_S7xNLllRjleUmY>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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: Wed, 25 Oct 2017 19:34:57 -0000

I didn't want to stick my foot in this, but here we are.

The goal for an inspection service to be able to take a recording of the
network and a key (or corpus of keys) and be able to decrypt any TLS
connection to a server within that network.

There are multiple ways of getting these keys.
1) use TLS 1.2 with RSA -> one single key
2) use TLS 1.3 with DH key derived from seed -> one single key (similar to
draft-green)
3) use any version of TLS and export the session keys -> corpus of keys
equal to number of connections

The fundamental assumption of this draft is that that 3) is not feasible
for all enterprises because rearchitecting their systems for a multi-key
escrow is either too costly or that the requirement for TLS 1.3 will come
too soon. Ted Lemon had some convincing arguments earlier about why
enterprises should see this coming and invest in migrating to a model
closer to 3), which will always be possible in a system that uses symmetric
cryptography for encryption. Newer companies like the one mentioned by Tony
Arcieri have managed to architect their systems this way, so it’s not
impossible. Still, it’s usually cheaper to adapt an existing system rather
than re-architect your network (and buy more gear). As long as 2) is
possible, the moving to a model based on 3) is going to be a hard sell.

Given that enterprises would rather be standards-compliant, this draft is a
way to prevent enterprises from just going ahead and implementing 2), and
instead implement something that has similar benefits (a single master key
that can decrypt multiple connections), but with additional safeguards for
the user:
-the ability to opt out
-visibility into the fact that their connection is part of a pool of
connections protected by a single key

You can do neither with 2). This is a win. To Rich’s argument that network
domains will force browsers to implement this by blocking connections that
don’t advertise this support, I disagree. There are no passive firewalls
that I know of that drop TLS connections that don’t support escrow (in the
sense that non PFS-RSA and session ticket keys in TLS 1.2 are escrow).
Shouldn’t these be blocked by the GFW if someone is forcing RSA escrow?

On that note, so what if some browsers opt in? Servers need to also opt-in
to setting visibility keys. These will be visible by the browser, and
visible by network watchdogs. Visibility is good in the situation where
both parties want to be honest, and a dishonest escrow mechanism is
possible. Furthermore, large services that are internet-facing that see
this extension existence can simply disconnect when it's presented,
applying back-pressure in the event of this "escaping" the datacenter.

Until TLS is redesigned so that a single key escrow is not possible,
datacenter operators will choose to do 2). For the next version of TLS, we
should strive to eliminate a the ability for a server to escrow a single
key. I posit that this should be a fundamental design principle for TLS
going forward: *cross-connection secrecy*. Forward secrecy with respect to
the long term certificate key is something that has been addressed in TLS
1.3. Forward secrecy with respect to other keys, like the session ticket
key or other keys that can be generated centrally, are things that need to
be looked at more closely for TLS 1.4 (or whatever’s next).

This draft is an optional extension that allows a client and server to
agree that a single key held by the server should be able to decrypt the
data of multiple connections. I don’t think it’s something that belongs on
the Internet as a whole, but understood it as a lesser of two evils with
respect to the options people have.

To summarize:
- TLS 1.3 allows single-key escrow with no client opt-in by design (because
of ephemeral DH)
- This is something that requires fundamental changes to TLS to fix, but
should be looked into
- Enterprises should look into moving to a model where session keys are
exported to prepare for this eventuality
- draft-rhrd allows clients to opt-in to an extension-based escrow system
that doesn’t abuse the core protocol and it enables network watchdogs to
observe
- having such a system on the internet is a bad idea because it reduces the
security of multiple connections down to a single piece of data
- on the other hand using draft-rhrd is safer than allowing organizations
to hack single-key escrow into TLS 1.3 or continue to use TLS 1.2 with
non-forward-secret cipher suites

Nick

On Thu, Oct 19, 2017 at 7:26 AM Salz, Rich <rsalz@akamai.com>; wrote:

>
>     > I didn’t say easy, I said ‘easier’
>     >
>     Can you explain how it is easier?
>
> There’s no way to limit it to the use-case it was putatively intended
> for.  We now have a signaling mechanism that says “allow interception.”
> Firewalls can drop connections where the client doesn’t send that
> extension. Therefore they can force only tappable TLS traffic. This makes
> the job easier.
>
> I take it you want to see this draft adopted?
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>