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

Ted Lemon <mellon@fugue.com> Sat, 15 July 2017 16:20 UTC

Return-Path: <mellon@fugue.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 004B51293E1 for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 09:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.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 RGpne9J5lQHu for <tls@ietfa.amsl.com>; Sat, 15 Jul 2017 09:20:02 -0700 (PDT)
Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (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 C000B128CFF for <tls@ietf.org>; Sat, 15 Jul 2017 09:20:02 -0700 (PDT)
Received: by mail-pg0-x22b.google.com with SMTP id k14so59390657pgr.0 for <tls@ietf.org>; Sat, 15 Jul 2017 09:20:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qJRBgTzT01OVfHzlDnfTywK/Y4Y7H6LDInfmNTCgwuw=; b=JhM614cMLkhNcK8l27lsYPfH2e3hTtVjdUH0gRQK9GEqqE1ZPsBn4J51wUcSONxFiz bFS7Il2JbX02mVR8yC7mHChyOSCQzahCdAJJilmuogmRDGZMZWOI70C3YnMuyOyhrbXw PfAkC39Kz7KwQnYKkUFNGWUGKzjiwfne4d/bgdluN//JbZNUmv+nTBJoxiNdOruiVzIq pU4XuM/ZVi99QQdR0Ho4EGxhKDgpYqxdftqs/aEDOM1tvoNqUQ4+O/aoXHVHRLbDv3If BcSSQcO9wdQgsJ1Wa3ukVm0NQsB7c9D47EzoeP2OjV4RPtVTdIM1lXZ+/JU0lCtVtRs9 RI5w==
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=qJRBgTzT01OVfHzlDnfTywK/Y4Y7H6LDInfmNTCgwuw=; b=iEsBbM6UskDgW6PEHUTPBxcIV8ft11KkzMl3cNyIbdxD8up21ccSARsUSu4RBt2Gxn BJ3aHQ8LOCLgo1cvUUqVgAJzb3Fr59EuVDf0HiS+sU88+nLxlMhdqpd5dt5JqsbazCom ZDE37Oneq51wcvI+oyb1bKYsdT3h2UEHjz0SCx+Vqci6y2Y3pNwW6ClXLm8RMb93pX93 AaFKcHxC08e5DqglJklL91aQURLjKmrYG9zit570fXTQtCF2b4vP1aJQo9/04qp/LNAR 7d/zgTWU+9m0M3WDipzVf2MT91oxtSN2NDNx42LoW57CxVtSnTfCbNmJ2uvo+GZIifDG qrzA==
X-Gm-Message-State: AIVw112OwQvpJ3HYdIUoYscuVz3kfemMWaVqofOPp7GuEdsRvDiroiId 4+O9GVjdsujhRhs5AbI6qE5qzHTMOjOL
X-Received: by 10.99.167.79 with SMTP id w15mr20407155pgo.22.1500135602125; Sat, 15 Jul 2017 09:20:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.100.181.42 with HTTP; Sat, 15 Jul 2017 09:19:21 -0700 (PDT)
In-Reply-To: <CY4PR14MB136850FD3287DEAD0CD44C78D7A20@CY4PR14MB1368.namprd14.prod.outlook.com>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAL02cgRJeauV9NQ2OrGK1ocQtg-M2tbWm2+5HUc4-Wc8KC3vxQ@mail.gmail.com> <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com> <39bad3e9-2e17-30f6-48a7-a035d449dce7@cs.tcd.ie> <CAJU8_nXBFkpncFDy4QFnd6hFpC7oOZn-F1-EuBC2vk3Y6QKq3A@mail.gmail.com> <f0554055-cdd3-a78c-8ab1-e84f9b624fda@cs.tcd.ie> <A0BEC2E3-8CF5-433D-BA77-E8474A2C922A@vigilsec.com> <87k23arzac.fsf@fifthhorseman.net> <D37DF005-4C6E-4EA8-9D9D-6016A04DF69E@arbor.net> <CAPt1N1nVhCQBnHd_MCm79e7c1gO6CY6vZG_rZSNePPvmmU_Bow@mail.gmail.com> <44AB7CB8-13C1-44A0-9EC4-B6824272A247@arbor.net> <CAPt1N1=rvtssKXCnsNmr1vy4ejb6YDUxO2kDcgh-ZMh5WGjfWg@mail.gmail.com> <CY4PR14MB136850FD3287DEAD0CD44C78D7A20@CY4PR14MB1368.namprd14.prod.outlook.com>
From: Ted Lemon <mellon@fugue.com>
Date: Sat, 15 Jul 2017 18:19:21 +0200
Message-ID: <CAPt1N1k+_1ndyhvzUkyRy_9TKmqHdkUNpLf9LS9YtLaULRDCsw@mail.gmail.com>
To: "Ackermann, Michael" <MAckermann@bcbsm.com>
Cc: "Dobbins, Roland" <rdobbins@arbor.net>, IETF TLS <tls@ietf.org>, Matthew Green <matthewdgreen@gmail.com>
Content-Type: multipart/alternative; boundary="94eb2c1bdaa4ae107805545d89f9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bYrDQpGt1SY3NA64zTxLvd49TPs>
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 16:20:05 -0000

On Sat, Jul 15, 2017 at 5:36 PM, Ackermann, Michael <MAckermann@bcbsm.com>
wrote:

> Your first sentence illustrates the disconnect between the Enterprise
> perspective and what many at IETF are saying.
>
> That being the unencrypted stream is available to the endpoints.   IT IS
> NOT.     When you run a packet trace at the endpoint,  you will see
> encrypted payloads and will need the keys to decrypt.
>
> So you can collect packet trace information at thousands or nodes,  or you
> can collect packet traces from network taps.   You still need the keys to
> derive meaningful diagnostic and monitoring information.
>

I agree that we have illustrated the disconnect here, in some sense.
However, from my perspective, what I see is that there is a problem: you
need to be able to look inside the stream.   I think we agree that this is
the problem.

There is a further problem: you have a set of tools that solves this
problem in a particular way, and for the moment, you are stuck with those
tools.   This is where I think the disconnect starts.   I am not
disagreeing with you that, for the moment, you are stuck with these tools.m
  But, I *am* disagreeing with you on the conclusion that this situation
leads to.

To me, it leads to the conclusion that you need two things.   First, you
need a plan for how to survive the situation you're stuck in right now.
Second, you need a plan for how you're going to approach this when next you
upgrade your infrastructure.  If I were in your position, my plan for the
first part would be to use TLS 1.2.   You already have what you want, and
you control the endpoints.   If it ain't broke, why fix it?

What I think is urgent, though, is that you be planning for how you're
going to handle this going forward.   There are a number of ways of doing
it.   One way would be to keep an appropriately-scaled log of keys.  If you
just need to look at active streams, it would be a rolling log, and your
snooping device would, when asked to snoop a stream, get the key.   This is
an improvement over TLS 1.2, because it increases accountability: you have
to ask for a key to decrypt a particular conversation, so it is known that
you decrypted that conversation.   Of course, if you are decrypting _every_
conversation, that's not so great.   Of course, key exfiltration is an
attack surface, but so is the static key.   Better get that right.

The other thing you can do is to do proper tooling on your servers, so that
you *can *access the raw stream.   This would require different tooling
than you have now, but there's no technical barrier to doing it.

Now, it's possible that either of these solutions would be less secure than
using a static key.   But I don't hear you arguing that.   You're still
back on tactics: how do I do what I need to do with the tools I have.   The
answer is, use TLS 1.2 until you upgrade.   Put the time in to shave off
all the attack surfaces from your TLS 1.2 installations that TLS 1.3 shaves
off--disable the deprecated algorithms, for example.  It's your site, you
control the endpoints, this shouldn't be a problem.   But basically, just
keep doing what you are doing for now.

Maybe this is a naive suggestion on my part, but what I haven't been
hearing in this discussion is serious consideration of the tactical problem
and the strategic problem.   What I've been hearing is "forget about
strategy, we want tactics."