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

Matthew Green <matthewdgreen@gmail.com> Wed, 16 November 2016 13:55 UTC

Return-Path: <matthewdgreen@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 5D50F1297CF for <tls@ietfa.amsl.com>; Wed, 16 Nov 2016 05:55:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level:
X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no 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 K5GzM02RPuYu for <tls@ietfa.amsl.com>; Wed, 16 Nov 2016 05:55:31 -0800 (PST)
Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 BC7C512953D for <tls@ietf.org>; Wed, 16 Nov 2016 05:55:30 -0800 (PST)
Received: by mail-qk0-x230.google.com with SMTP id n21so175656026qka.3 for <tls@ietf.org>; Wed, 16 Nov 2016 05:55:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ArxL5mL+gicDxl7pZo7FCmkfrGzTMf0dXlkPTncjM1E=; b=moZkS7lWZ4py7M66QjMlJcu8FPi+hJBRS/S70DcyrFvxcw2i528df0yzbspDBrrD+Z Cw62xVjsm9YH/HBPreW+jMaMIV00XNv+jTv3g5aV9wLmyhXB5Ord6u1/vvXFcn+HmFCV 1XqMOx/G3oI/oXj/sjQwF5RyKfTN3yvnjayQD1OVAHMGIjd+cJEbvOTBsH3PYOqusYop FPDnNSWd5Kvg7ouoP2t2JfjPoy323bH1R0IoQmcPAOt3XKP+f1hJ9nJOfg70oAkYqUdE oFzfUTRi0MeHhQ7n0j4h8A0KacjP4olFyPA1PwWQgt23PpMSpqlxZJ2ViJZtSzFN7QGi 2Fsw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ArxL5mL+gicDxl7pZo7FCmkfrGzTMf0dXlkPTncjM1E=; b=KRg5r3Ifu14881FpwtC8RoOz4fuHqLz1bufuSKOcowHFirMnfh/jV9p521oKA4zs/q Xe94TVkmChI/jS2zT2HE9ycJGFsZt7Qs86Ie/ct/XHWxb+5nnvEha4+WPrn6yFt2Edho 3QEnx+rL8bgN9FEXYBtuEB9T9vMb+BbGtWK6qX1ChbdrMvgAU0Mp94RsCTe+ueH1jfPN 0CJuky4rMPJBhWk7www1eqFtGUsg5A8l+mPosGiSqQuLAGkNEdngGqDmP1eImrFdCsr6 yy8ghnmDB2Vy1i4Eb5SYp3lJJbB2FsEE8gVmrMeYPGW+rSBQXMEA6E8MNo7BDr+0tANR K9Hw==
X-Gm-Message-State: AKaTC01TQKXkxuSxo1PqXQ1qOHj8T8mUWeIKXTvPor1nOeNG4k7YAk6M3/pekGQ26GJTwA==
X-Received: by 10.55.7.17 with SMTP id 17mr3989991qkh.228.1479304529909; Wed, 16 Nov 2016 05:55:29 -0800 (PST)
Received: from [192.168.1.151] (c-73-173-147-199.hsd1.md.comcast.net. [73.173.147.199]) by smtp.gmail.com with ESMTPSA id y52sm17787583qty.11.2016.11.16.05.55.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Nov 2016 05:55:29 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_2FDEBD07-A09A-455B-BCDF-F1D69A21C0DD"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Matthew Green <matthewdgreen@gmail.com>
In-Reply-To: <mailman.3845.1479181859.4475.tls@ietf.org>
Date: Wed, 16 Nov 2016 08:55:19 -0500
Message-Id: <2BDF489D-E968-4C47-9E2B-2FEFA0217367@gmail.com>
References: <mailman.3845.1479181859.4475.tls@ietf.org>
To: ynir.ietf@gmail.com
X-Mailer: Apple Mail (2.2104)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/p6jwKKIbLaVSJquRv3TUM2QeC-0>
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)
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 13:55:32 -0000

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 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