Return-Path: 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 ; 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 ; 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 ; Wed, 16 Nov 2016 05:55:30 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id n21so175656026qka.3 for ; 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 In-Reply-To: Date: Wed, 16 Nov 2016 08:55:19 -0500 Message-Id: <2BDF489D-E968-4C47-9E2B-2FEFA0217367@gmail.com> References: To: ynir.ietf@gmail.com X-Mailer: Apple Mail (2.2104) Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2016 13:55:32 -0000 --Apple-Mail=_2FDEBD07-A09A-455B-BCDF-F1D69A21C0DD Content-Type: multipart/alternative; boundary="Apple-Mail=_A5A86B39-7595-4EF7-95C3-E1CDB07EB6AF" --Apple-Mail=_A5A86B39-7595-4EF7-95C3-E1CDB07EB6AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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=E2=80=99t 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 =E2=80=94 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: >=20 > Message: 4 > Date: Tue, 15 Nov 2016 10:28:05 +0900 > From: Yoav Nir > > To: Sean Turner > > Cc: ">" > > 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 = > > Content-Type: text/plain; charset=3Dus-ascii >=20 > 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. >=20 > 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: >=20 > If fresh (EC)DHE keys are used for each connection, then the output = keys are forward secret. >=20 > 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. >=20 > 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? >=20 > Yoav --Apple-Mail=_A5A86B39-7595-4EF7-95C3-E1CDB07EB6AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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=E2=80=99t 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 =E2=80=94 = 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>
To: Sean Turner = <sean@sn3rd.com>
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)
Message-ID: <2F41D793-19E2-4C04-A914-E2F2581F844E@gmail.com>
Content-Type: text/plain; = charset=3Dus-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

= --Apple-Mail=_A5A86B39-7595-4EF7-95C3-E1CDB07EB6AF-- --Apple-Mail=_2FDEBD07-A09A-455B-BCDF-F1D69A21C0DD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYLGVPAAoJEDgwLl99RanZCeYIALIk6SmN47ffjuncSKJiPtVx pXcIqekyTHSaRp5xYe20ipOE9KHPiBa297pI0bUwU0i9U9OkAH/VC68Zuvfip5ya j6rBg6RfwS8bSZ7gMGeqYyA55ld8WJpnWorAy/8QMv5ek3Aq/laTWnzzR8YOtq+m Wfo0V+swrmZNJQwrRWYBKKanhSTMew5zIgoir1vZO8oED2zj/k70DmEnDeVAebON l9m2FXVi7S4SJJ0OVU+kewtxv40p5xbcu5jsV+JMtel6Rfd1n5UIRhNaH7Ojib8J tP0zBXJ8TdFxxQ0NtqnmlEUMryDhe3lP6OLvx/Ncj6Ye/hK8ybLck9lXrya2ngo= =HwV1 -----END PGP SIGNATURE----- --Apple-Mail=_2FDEBD07-A09A-455B-BCDF-F1D69A21C0DD--