Russ, You didn't refer to 2804 and the standards track. As an author do you really think this can be on the standards track and yet not obsolete 2804?
If you do, then I don't understand that. (And would argue you are holding a counter-factual opinion.) If you do not, then why does the draft say "standards track"? S. PS: I disagree with other assertions below but the above has to come first as we need to know if the authors are or are not asking the IETF to change a major policy. On 07/07/17 21:04, Russ Housley wrote: > Stephen: > >> On 07/07/17 19:40, Kyle Rose wrote: >>> an informational draft submitted via the ISE >> >> ...has nothing to to with this WG and ought consume >> no cycles on this list or in meetings. >> >> Yes, the ISE is the route 2804 envisages for documenting >> wiretapping schemes such as this. >> >> The authors of this draft however chose to put "standards >> track" in the header and some of those authors are very >> very well aware of all the nuances here so that was not >> a mistake is my conclusion. So I stand by my statement >> that 2804 says no to this. > > As Kyle quoted, RFC 2804 says that we should be talking about the design. It > seems to me the only way to make this proposal more secure is to talk about > it. And, the TLS WG has the people with the proper expertise for that > discussion. > > The enterprise wants forward secrecy on the public Internet. Terminating the > TLS session at the load balancer preserves forward secrecy on the public > Internet. > > We already had a discussion on this list about requiring a fresh ephemeral DH > key for every session. The consensus was not to require it. I understand > that there are already servers that use the same "ephemeral" DH key for more > than one session. I gather that this is done for performance reasons. > > The conventions described in draft-green-tls-static-dh-in-tls13-01 for using > non-ephemeral DH keys has no impact on interoperability. Discussion of that > topic could easily go in an Informational RFC. Many Informational RFCs > describe crypto algorithms. On the other hand, the protocol between the key > manager and the server for installing the non-ephemeral DH key has an impact > on interoperability, so it could be in a standards-track document. > > In your response, you ignored a fairly significant point in my previous post. > > In some industries, there are regulatory requirements that cannot be > met without access to the plaintext. Without some authorized access > mechanism, the enterprise will be forced to use plaintext within the > datacenter. That seems like a worse alternative to me. > > From my perspective, draft-green-tls-static-dh-in-tls13 is not advocating > outdated crypto, like RC4 or MD5. Instead, it is using exactly the same > crypto algorithms and key sizes as draft-ietf-tls-tls13. Again, this seems > like a much better way forward than plaintext throughout the datacenter. > > Russ >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
