>>>> Second, using TLS1.2 does not technically address the issue. If the client >>>> were to exclusively offer DHE-based ciphersuites, then the visibility >>>> techniques that have been used in the past are thwarted. >>> >>> The client in this case is under the control of the operator, so this is a >>> non-issue. >> >> In some cases, the client in the load balancer is under the control of the >> enterprise. In other cases, the client is in the customer browser, and >> opt-in is very significant. > > When you say customer browser, do you mean the users on the enterprise > network behind the firewall, all within the control of the enterprise > that owns the data? I think this is what is meant since the Internet > sessions from customers could be terminated at a load balancer on the > enterprise edge and then this extension may be used between servers > internal to the enterprise and from what you are saying, browsers as > well. Or is the plan for this to be opt-in from the customer external > to the enterprise (I didn't think that was the case and it would be > good to clarify). This distinction would be helpful to know where > traffic may be intercepted if there were another party that might be > malicious.
I was trying to separate these two cases. If the TLS session is terminated at a load balancer, then the client within the load balancer is (as Ted says) under control of the operator. The operator can include any extensions that it wishes. If the TLS session is not terminated at a load balancer, then the client needs to opt-in for decryption points in the enterprise data center to get the needed keying material. Russ _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls