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 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
