Re: [TLS] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt)

Dan Brown <danibrown@blackberry.com> Wed, 16 November 2016 15:33 UTC

Return-Path: <danibrown@blackberry.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 2961D1294B7 for <tls@ietfa.amsl.com>; Wed, 16 Nov 2016 07:33:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.117
X-Spam-Level:
X-Spam-Status: No, score=-4.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 I_irYFAxvZpw for <tls@ietfa.amsl.com>; Wed, 16 Nov 2016 07:33:40 -0800 (PST)
Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886A9129652 for <tls@ietf.org>; Wed, 16 Nov 2016 07:33:39 -0800 (PST)
Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs211cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2016 10:33:39 -0500
Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT107CNC.rim.net ([fe80::b815:71ef:9f8f:e07c%16]) with mapi id 14.03.0319.002; Wed, 16 Nov 2016 10:33:38 -0500
From: Dan Brown <danibrown@blackberry.com>
To: Matthew Green <matthewdgreen@gmail.com>, "ynir.ietf@gmail.com" <ynir.ietf@gmail.com>
Thread-Topic: [TLS] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt)
Thread-Index: AQHSQBEQSiqxIb/8rEKeKScrOWkvZaDbvB3Q
Date: Wed, 16 Nov 2016 15:33:37 +0000
Message-ID: <810C31990B57ED40B2062BA10D43FBF50107C88C@XMB116CNC.rim.net>
References: <mailman.3845.1479181859.4475.tls@ietf.org> <2BDF489D-E968-4C47-9E2B-2FEFA0217367@gmail.com>
In-Reply-To: <2BDF489D-E968-4C47-9E2B-2FEFA0217367@gmail.com>
Accept-Language: en-US, en-CA
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.65.160.248]
Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF50107C88CXMB116CNCrimnet_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lNodPQGh04Hwg7srLmBY6np-puk>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 16 Nov 2016 15:33:42 -0000

Isn’t possible to achieve the goals of this proposal without re-using DH secrets?

For example, let DH_secret = KDF ( monitoring_key, server.hello , client.hello), or something similar.  Ideally, the monitoring_key should be updated frequently as possible (while keeping it synchronized).

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Matthew Green
Sent: Wednesday, November 16, 2016 8:55 AM
To: ynir.ietf@gmail.com
Cc: tls@ietf.org
Subject: Re: [TLS] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt)

Thanks for pointing out the line in Appendix D.1. I also agree that the proposal requires no changes to the current 1.3 specification, which is very much a point in its favor.

I don’t think there is a desired action from the TLS-WG. The goal is simply to have a document that other implementers can reference and work from, and preferably one that is developed openly within view of the working group — rather than having the implementers do this in another forum. A side benefit is that this Draft also help to drive some thinking on the part of the TLS protocol designers around how TLS 1.3 will actually be deployed in certain environments (see e.g., related thread on point validation).

Matt

On Nov 14, 2016, at 10:50 PM, tls-request@ietf.org<mailto:tls-request@ietf.org> wrote:

Message: 4
Date: Tue, 15 Nov 2016 10:28:05 +0900
From: Yoav Nir <ynir.ietf@gmail.com<mailto:ynir.ietf@gmail.com>>
To: Sean Turner <sean@sn3rd.com<mailto:sean@sn3rd.com>>
Cc: "<tls@ietf.org<mailto:tls@ietf.org>>" <tls@ietf.org<mailto:tls@ietf.org>>
Subject: Re: [TLS] TLS Visibility Inside the Data Center (was: I-D
                Action: draft-green-tls-static-dh-in-tls13-00.txt)
Message-ID: <2F41D793-19E2-4C04-A914-E2F2581F844E@gmail.com<mailto:2F41D793-19E2-4C04-A914-E2F2581F844E@gmail.com>>
Content-Type: text/plain; charset=us-ascii

If I understand this draft correctly, this draft describes server behavior. It does not change anything within the TLS 1.3 protocol. IOW a server doing this will interoperate with any client.

I searched the tls13 draft to see if it has anything to say about this, and the only thing I found was this line in appendix D.1:

  If fresh (EC)DHE keys are used for each connection, then the output keys are forward secret.

So a server is not required to generate fresh (EC)DHE keys for each connection. In fact, generating fresh keys periodically and discarding the old ones are a legitimate way to achieve forward secrecy. What this draft does differently is to save the old (EC)DHE private keys, which loses the forward secrecy.

So given that what the draft proposes is possible with the current TLS 1.3, what do the proponents want? Is it just to have a document that describes this server behavior?

Yoav