Re: [TLS] draft-green-tls-static-dh-in-tls13-01

[Russ Housley <[e-mail]>]

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