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

Richard Barnes <rlb@ipv.sx> Fri, 07 July 2017 17:13 UTC

Return-Path: <rlb@ipv.sx>
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 0A3D6131743 for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 10:13:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 0YSHfsuuYRtY for <tls@ietfa.amsl.com>; Fri, 7 Jul 2017 10:13:09 -0700 (PDT)
Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 64ABE13173B for <tls@ietf.org>; Fri, 7 Jul 2017 10:13:09 -0700 (PDT)
Received: by mail-wr0-x232.google.com with SMTP id r103so55518249wrb.0 for <tls@ietf.org>; Fri, 07 Jul 2017 10:13:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Aog63/Wq7zd1NuG4SyfzeVDpbzGcsO9/CIkEPcVK26E=; b=qQz7K4E7mwWu6ZrDZWVctglpHHvBeSKBD3uic3SPKpF88FvQS8lFZopVHTfYZT8GsE cZgPGJWqCOHRZKpC8zBFYbQKFhqnHazmiAsg80LdHAZyq5mC9BMP/sfRHldVcR11ImBa MQcQAUQCPBSjBOnbDjHuWHw9tQS4gfebLMTuAc/WclSHdJCjspbrJd4buA7Bu6VuTLxa 2VcO3WnPkhRZhdD7CnlJpNLzmAxYQ78h09BAxfTTUTdWFntDAdHQxUqFZdGE51t8vVNX CMKF8Bio6H1juq65SWlP8rp5FBeiR09mkiQPNz4wN/X7mwN+IlJF9yjUcJHx+BNje6Gm CfKQ==
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=Aog63/Wq7zd1NuG4SyfzeVDpbzGcsO9/CIkEPcVK26E=; b=kU/qbg4anuw17TJuE3wS9n0EHvwnqCMah9FXF3Eh2hPmeCeFbd81fF5q8zJSrDTT50 zyxPBDj8LmLqwGYFUJeVfcDTxoHQKKLXjKITE8jNhUEmINuwFF7q/zSkdMlFKwKolasY svqlIaqSi7I4cSvt8K4JCXn40StQQ+sDnly5DGev2c2tGpwLKAMP+SJfLfoou0l43r+K RwiQSC8VC3VFevi8wqz79bTImzMvaCJsQPtXZhMX5fEzmzxdfN4JexgO8fL1Y9iDY6KE GkSB7Gyhf+tjddeVsWhN5AN3NeE2gO+GQdtc7tav+PG4M/Ika+Mr1JzQBriBloAszs2Z uBCA==
X-Gm-Message-State: AIVw113fcgMOcGpi7GspGWuqSffQm3Op6DnmLY5x9sxB2u2PSHLZmNPV y1H7ex1grV/Fhwk7Sjm3KsdY7Rjzrv8S
X-Received: by 10.223.153.114 with SMTP id x105mr1454916wrb.18.1499447587731; Fri, 07 Jul 2017 10:13:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.28.72.4 with HTTP; Fri, 7 Jul 2017 10:13:07 -0700 (PDT)
In-Reply-To: <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com>
References: <CAPCANN-xgf3auqy+pFfL6VO5GpEsCCHYkROAwiB1u=8a4yj+Fg@mail.gmail.com> <CAL02cgRJeauV9NQ2OrGK1ocQtg-M2tbWm2+5HUc4-Wc8KC3vxQ@mail.gmail.com> <71E07F32-230F-447C-B85B-9B3B4146D386@vigilsec.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Fri, 7 Jul 2017 13:13:07 -0400
Message-ID: <CAL02cgT61gGDwNCu+AvAO-dPQYN1ty3Z-oiNpDXEfEUm7QhOww@mail.gmail.com>
To: Russ Housley <housley@vigilsec.com>
Cc: Matthew Green <matthewdgreen@gmail.com>, IETF TLS <tls@ietf.org>
Content-Type: multipart/alternative; boundary="f403045d5732d392550553bd584d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/CrXSqSXa4LLq2ZOTr1b3_HkIZW4>
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: Fri, 07 Jul 2017 17:13:12 -0000

On Fri, Jul 7, 2017 at 12:35 PM, Russ Housley <housley@vigilsec.com>; wrote:

> Richard:
>
> Without taking a position on whether this group should take on this work,
> a couple of questions about alternative approaches (sorry if these have
> been answered before):
>
> 1. It seems like the requirement here is that the DH private key be
> *predictable* by the monitoring box based on some static configuration.
> That is, it seems like you could have keys that are predictable to the
> monitoring device, but still vary over time, something like setting the
> private key from a KDF(SecretSharedWithMonitoringDevice, ServerRandom).
> Without having done much analysis, this seems more conservative than making
> things entirely static. Is there a reason to prefer the purely static
> approach besides simplicity?
>
>
> Please see Section 6 of the draft.  The non-ephemeral DH keys MUST have a
> validity period.  The keys are expected to change over time.
>

OK, then why not have this happen automatically (e.g., by folding in
ServerRandom) rather than doing the provisioning process over and over?



>
> 2. You could avoid changing how the DH works altogether by simply
> exporting the DH private key, encrypted with a key shared with the
> monitoring device, in a server extension.  (Not in EncryptedExtensions,
> obviously.)  This would also have the benefit of explicitly signaling when
> such monitoring is in use.  The only real challenge here is that the client
> would have to offer the extension in order for the server to be able to
> send it, which I expect things like browsers would be unlikely to do.
> However, given that the target of this draft seems to be intra-data-center
> TLS, perhaps this is a workable requirement?
>
>
> In most common deployment case, the load balancer at the edge of the
> enterprise datacenter will terminate the TLS session and start a new one.
> The TLS session that protects the traffic on the public Internet works
> exactly as described in draft-ietf-tls-tls13.  The non-ephemeral DH keys
> are associated only with sessions that are inside the enterprise
> datacenter.  So, you are right, no browser will be at either end of any of
> these TLS sessions.  There is no change to the way that the protocol makes
> use of the DH key.  The drft-green, the server need to look in a table to
> choose a valid non-ephemeral DH key.  In your proposal, the server need to
> wrap the ephemeral DH private key in a key-enceyption key.  Both solutions
> require the distribution of some key (either the non-ephemenral DH key or
> the key-encryption key) to the parties that are authorized to see the
> traffic.
>

Yes, I understand that all of the solutions in this space will require some
static configuration.  What I'm trying to do is minimize the degree to
which that static-ness reduces the entropy in the TLS handshake.

In the "fold in ServerRandom" version, the static information gets tempered
with per-session random information.  In the "smuggle out the private key"
version, the static information doesn't even touch the base TLS handshake;
it's only used for wrapping the DH private key.

I agree that the "smuggle out the private key" still has a static component
that you would want to refresh.  However, it's minimal, in the sense that
you're going to need to authenticate the monitoring box to the TLS server
somehow anyway (even if just for provisioning).  And it seems like a
cleaner separation to have the static component as something off to the
side of the main handshake, rather than having to make invasive changes to
the handshake code.

--Richard




>
>
> Stephen:
>
> I don't believe the WG should adopt this as it goes
> against rfc2804 and encourages bad behaviour. We
> ought not be helping to normalise broken crypto. I'm
> happy to repeat that at the mic in Prague but would
> be even happier if this draft were not discussed
> there - these attempts to weaken security have IMO
> already taken up too much time and too many cycles.
>
>
> Repeating from above, the non-ephemeral DH keys are associated only with
> sessions that are inside the enterprise datacenter.  In some industries,
> there are regulatory requirements that cannot be met without access to the
> plaintext.  Without some authorized access mechanism, the enterprise will
> be forced to use plaintext within the datacenter.  That seems like a worse
> alternative to me.
>
> Russ
>
>
> On Fri, Jul 7, 2017 at 3:02 AM, Matthew Green <matthewdgreen@gmail.com>;
> wrote:
>
>> The need for enterprise datacenters to access TLS 1.3 plaintext for
>> security and operational requirements has been under discussion since
>> shortly before the Seoul IETF meeting. This draft provides current thinking
>> about the way to facilitate plain text access based on the use of static
>> (EC)DH keys on the servers. These keys have a lifetime; they get replaced
>> on a regular schedule. A key manager in the datacenter generates and
>> distributes these keys.  The Asymmetric Key Package [RFC5958] format is
>> used to transfer and load the keys wherever they are authorized for use.
>>
>> We have asked for a few minutes to talk about this draft in the TLS WG
>> session at the upcoming Prague IETF. Please take a look so we can have a
>> productive discussion.  Of course, we're eager to start that discussion on
>> the mail list in advance of the meeting.
>>
>> The draft can be found here:
>>
>> https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-01
>>
>> Thanks for your attention,
>> Matt, Ralph, Paul, Steve, and Russ
>>
>
>