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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
