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

From: Matthew Green <[email-masked]>
Date: Wed, 16 Nov 2016 08:55:19 -0500

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, [email-masked] wrote:
> 
> Message: 4
> Date: Tue, 15 Nov 2016 10:28:05 +0900
> From: Yoav Nir <[email-masked] <mailto:[email-masked]>>
> To: Sean Turner <[email-masked] <mailto:[email-masked]>>
> Cc: "<[email-masked] <mailto:[email-masked]>>" <[email-masked] <mailto:[email-masked]>>
> Subject: Re: [TLS] TLS Visibility Inside the Data Center (was: I-D
> 	Action: draft-green-tls-static-dh-in-tls13-00.txt)
> Message-ID: <[email-masked] <mailto:[email-masked]>>
> 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

---

From: Dan Brown <[email-masked]>
Date: Wed, 16 Nov 2016 15:33:37 +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:[email-masked]] On Behalf Of Matthew Green
Sent: Wednesday, November 16, 2016 8:55 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [TLS] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt)

Matt

On Nov 14, 2016, at 10:50 PM, [email-masked]<mailto:[email-masked]> wrote:

Message: 4
Date: Tue, 15 Nov 2016 10:28:05 +0900
From: Yoav Nir <[email-masked]<mailto:[email-masked]>>
To: Sean Turner <[email-masked]<mailto:[email-masked]>>
Cc: "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [TLS] TLS Visibility Inside the Data Center (was: I-D
                Action: draft-green-tls-static-dh-in-tls13-00.txt)
Message-ID: <[email-masked]<mailto:[email-masked]>>
Content-Type: text/plain; charset=us-ascii

Yoav

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 16 Nov 2016 21:41:57 +0000

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

As an implementor (I'm a member of the OpenSSL dev team), I strongly prefer something that is honest about what it does, rather than something that appears to be more than that.  So while we might take on a PR that allows you to set a static key for the handshake, I would try very hard to veto something like the above.  And as a user, I would prefer to know what is going on; I can cache the secrets and if I see the same one more than once, I can take the appropriate action.

And while I'm here, I have a question on the draft.  Does the construct "(EC) DH" mean "ephemeral DH or ECDH", like a shorthand?
 
--  
Senior Architect, Akamai Technologies
Member, OpenSSL Dev Team
IM: [email-masked] Twitter: RichSalz