Strengthening Internet Security and Accommodating Data Center Requirements: Finding a Path Forward

This view is informed by a number of conversations with people involved in the discussion with different perspectives. However, the following does not represent nor is it intended to suggest an IETF position. The work to develop that remains to be done.

One of the strengths of the IETF process is that it brings together a diverse set of technical specialists—network operators, academics, developers, and protocol designers. The IETF seeks broad participation in its standards development processes because it leads to more robust standards—ones that work better and are more broadly applicable to the many different use cases found on the global Internet. However, it is not uncommon for implementers to learn about changes in protocols close to their publication date. This is an opportunity to encourage those using IETF standards to stay informed, at a minimum by reading the appropriate mailing lists.

In my opinion, unless voices are heard and solutions are found, the objective of end-to-end encryption to protect users privacy will be limited as a result of deployment challenges. I fully agree that end-to-end secure communications is necessary to protect the security of Internet sessions, end users privacy, and anonymity for human rights considerations. Unless we look at the obstacles and find ways to fix them, we won’t reach the goal of end-to-end security.

For the past several years, the IETF has been working to strengthen the Internet against pervasive monitoring. In line with that effort, the TLS Working Group has been developing Transport Layer Security (TLS) 1.3. TLS 1.3 is designed to improve security and protect information sent over the Internet that from being intercepted and decrypted by unauthorized entities. While RFC7258 had already recommended against use of static RSA keys for TLS 1.2, this was formally deprecated in TLS 1.3 in favor of the more secure key exchange based on the Elliptic Curve Diffie-Hellman algorithm. These are important steps towards protecting end user privacy and the security of TLS protected sites to keep pace with the evolving threat landscape.

In the case of TLS 1.3, which is nearing completion, enterprise data center operators have recently proposed a deployment method that would enable intercepting and decrypting traffic within a data center through the use of a static Diffie Hellman key. This proposal would continue a method of intercepting and monitoring traffic similar to what is in place for all previous versions of TLS and SSL with static RSA keys. The intention is to restrict the application of this method for use within a data center only, and not with connections to the Internet.  

Some data center operators need the ability to look at network traffic for transaction monitoring because of regulations. At the same time they want to adhere to best practices by encrypting network traffic and thereby protect against malicious interceptions. While the proposed scheme for TLS would address this need for monitoring and is applicable to existing techniques used in some data centers, it should be noted that this is not the only possible technical approach that could enable encrypted traffic transmission in data centers as well as regulatory-required monitoring.

Within this use case, client TLS sessions over the Internet are not intended to use this proposal, but rather to maintain forward secrecy (likely not using the 0-RTT option) with the sessions terminating at the edge of the data center. The proposal is intended for use within the data center where both ends of the encrypted sessions are managed by the enterprise.

Others within the TLS working group have voiced concerns about the proposed approach, as there is no technical way to limit it’s usage to the data center. In other words, the method could be used for wiretapping purposes by a third party if it were deployed for a connection over the Internet. The TLS working group agreed to continue to discuss the issue, but how to solve the problem is uncertain at the moment.  

The proposal is not likely to be further considered. With this in mind, a discussion on alternate approaches to meet the use case requirements could be quite useful. It may be possible to adapt existing work in the IETF, not necessarily TLS, to meet the requirement, should the IETF choose to work on this problem.  

If TLS 1.3 sessions were terminated at the network edge, another solution could be used within the data center. One possibility is the use of IPsec. While all data centers do not have the same needs, some are working toward use of protocols such as IPsec or tcpcrypt operating at the IP and TCP layers rather than the application layer. 

Could IPsec be adapted to meet requirements? IPsec transport mode isn’t well deployed, and has some interoperability issues, but this may present an opportunity to work towards a solution outside of TLS.  There are also multiple group keying solutions already defined for IPsec including Group Domain Of Interpretation (GDOI) [RFC6407] and Multimedia Internet KEYing (MIKEY) [RFC3830]. I haven’t seen a proposal yet for a protocol designed fit for purpose, but that could be of interest too. My impression from the set of requirements is that we do have time to work collaboratively to a solution. 

It may be of interest to know the I2NSF working group is reviewing a proposal from data center operators in cooperation with the IPSecME working group to automate deployment of IPsec tunnels within a data center; a very productive interim call took place on 6 September specific to this proposal.  

A third possibility is a multi-party session transport encryption protocol designed specifically for the data center monitoring use case, of which none have been proposed to date to my knowledge.  

A longer term solution is to determine what is missing from application logging and endpoint resources to maintain end-to-end encryption and eliminate monitoring via interception. There are scaling issues with pushing these functions out to the endpoint, so perhaps there are other methods that could be used to enable monitoring functions without exposing potentially sensitive information that may or may not be privacy related. This will take lots of work and I encourage application protocol developers to think toward solutions.

While the exact way forward is yet to be determined, I believe that by working collaboratively we can strengthen the Internet and accommodate a broader set of use cases to make IETF standards more relevant to the implementers and operators who put them into practice.

I personally think that we should be doing something to solve the data center use case and would like to see a separate solution from one that uses TLS. In doing so, the likelihood of TLS 1.3 being deployed as intended to protect users privacy increases, as does the security of the terminating site, and the data center operators would gain a solution fit for purpose within their closed environments. It should be noted that there is nothing that prevents the implementation strategy described in the proposal from being deployed; an RFC isn’t necessary for that to happen.

After reading lengthy email discussions, the TLS 1.3 draft and the proposal, and listening to the presentations at the WG session, it appears that there is motivation and expertise to address use cases not anticipated by TLS 1.3. Some are working toward this with the goal of draft adoption within the TLS working group with an extension based solution in which the client is aware of interception. But adoption is not guaranteed. 

If this issue affects you, and you believe you can contribute, I encourage you to read through the WG mailing list archive and propose ways forward either adapting a solution with TLS, via alternate encryption and decryption solutions for use within the data center, or through improvements to applications to eliminate the desire to intercept traffic. The use case presented is important to data center operators and working with those deploying IETF protocols increases the success of those protocols being deployed as intended. The IETF doesn’t need to take action, but I’d like to encourage those with ideas to advance the thinking in this problem space.