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-boun...@ietf.org] On Behalf Of Matthew Green Sent: Wednesday, November 16, 2016 8:55 AM To: ynir.i...@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-requ...@ietf.org<mailto:tls-requ...@ietf.org> wrote: Message: 4 Date: Tue, 15 Nov 2016 10:28:05 +0900 From: Yoav Nir <ynir.i...@gmail.com<mailto:ynir.i...@gmail.com>> To: Sean Turner <s...@sn3rd.com<mailto:s...@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-e2f2581f8...@gmail.com<mailto:2f41d793-19e2-4c04-a914-e2f2581f8...@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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
