Protocols are evolving to meet the demands of the future. As such, we must continue to strengthen the security of these protocols to keep pace with the threat landscape.
Over the course of four years, Transport Layer Security (TLS) 1.3 has been designed to be more secure in order to prevent the interception of sessions over the Internet. It has a more secure key exchange, based on the Elliptic Curve Diffie-Hellman algorithm, formally deprecating the use of RSA static keys to ensure forward secrecy (FS). The end user and privacy were top-of-mind with this and other TLS working group consensus decisions when the zero round trip time (0-RTT) option is not in use.
It’s not uncommon for implementers to learn about changes in protocols close to their publication date. Ideally, implementers would be aware earlier in the process and contribute to the standards process, reading the email list to keep abreast of upcoming changes.
In the case of TLS 1.3’s impending publication, enterprise data centre operators are voicing concerns over the changes between it and TLS 1.2, and have proposed a solution to enable monitoring within data centres.
The working group agreed to continue discussing the issue, but there is uncertainty at the moment surrounding how best to solve the monitoring problem. While the current revision of the proposal uses the protocol as written (no on-the-wire changes), the client is not aware of the use of interception and decryption and could be subject to monitoring. This is fine within a data centre, but if it were used for Internet-based connections, it is not acceptable.
The proposal states a restriction of use to the data centre, but there is no technical guarantee of that restriction. This leaves the current proposal dead in the water. In the interest of finding a solution for monitoring within the data centre while preserving FS in TLS 1.3, let’s explore this a bit further.
Here’s a very simple diagram to help explain the use case for monitoring within the data centre:
In the use case depicted, client-initiated sessions (your web browser connecting to a banking or retail site) terminate TLS sessions at the edge of a data centre, typically at a load balancer. This use of TLS 1.3 preserves FS as there is no planned monitoring in the use case of this portion of the session. New encrypted sessions are then used for the connections between systems inside of the data centre.
Some enterprises currently use TLS 1.2 with RSA static keys to intercept and monitor traffic. The use of static RSA keys goes away in TLS 1.3, resulting in the need for a new solution for the data centre use case. It should be noted that the use of RSA static keys in TLS 1.2 was no longer recommended at the time of publication for the TLS 1.2 Best Practices document.
Regulations are one of the drivers, as transaction monitoring is sometimes required. Current regulations require encryption on the Internet, but not necessarily within a data centre. Encrypting or using tokenization on sensitive data elements, such as Payment Card Industry (PCI) data or personally identifiable information (PII) at the object level, meet many of the regulatory requirements for protecting data within the data centre.
The addition of session encryption is a best practice and may help with limiting the spread of advanced persistent threat attacks once inside a network, but isn’t required. It’s very positive that enterprises want to deploy session encryption and it would be good to assist with finding a way forward to enable monitoring and the use of secure session encryption within a data centre.
The PCI regulation will not require the use of TLS 1.2 until June 2018. That means, we have time to devise an appropriate solution for use within the data centre if TLS 1.3 (as-is) won’t work, or data centre operators want a standardized solution.
It should be noted that nothing prevents the deployment option used in the static Diffie-Hellman proposal; standardization is not necessary since the proposal does not alter the standard.
After reading through lengthy email threads on the TLS mailing list, following discussions, reading the TLS 1.3 proposal drafts, and listening to the presentations, I believe it is possible that we can work collaboratively with enterprises to meet their use case while preserving security properties for TLS 1.3. I’m aware of a TLS extension proposal that requires client opt-in that will be submitted soon and encourage others to think more on ways forward.
Here’s an option I’ve been pondering outside of the TLS Working Group
TLS 1.3 improves user security as well as security for organizations and should be adopted and deployed for Internet-facing connections. Solutions for use within a data centre can remain on TLS 1.2, for the time being. We have time before regulatory bodies will require TLS 1.2 to be phased out. Additionally, the regulations I’ve looked at list TLS as an option among several, including IPsec and SSH, for encrypting Internet sessions. With that in mind, it is possible for TLS 1.3 to terminate at the data-centre edge with a different encryption protocol being used within the data centre.
IPsec transport mode offers some hope here as a viable alternative. I’m suggesting IPsec transport mode for a few reasons:
- With IPsec Transport mode, the IP header is not encrypted, leaving visibility to the source and destination IP addresses. This offers some troubleshooting capability without the need to decrypt traffic.
- Group key management for secure group communication has already been defined and deployed by multiple vendors with ‘The Group Domain of Interpretation (GDOI)’. For applications requiring lower latency, such as real-time application, we also have ‘Multimedia Internet KEYing (MIKEY)’.
- IPsec transport mode isn’t widely deployed. While this means there is work needed to improve interoperability, there may be more acceptance with developing the protocol to meet the needs of data centre operators.
- IPsec terminates at the system level, not the application layer like TLS. This offers a point of visibility for traffic streams not available for TLS without group keys or interception techniques (shared keys – not advised, but possible). A little-known feature in many IPsec implementations is the ability to dump clear text traffic at an endpoint. Since this is within a single administrative zone, the use of this feature for troubleshooting is not uncommon.
- Issues with Network Address Translation (NAT) have been documented and fixed in some implementations.
Separate from the data centre use cases presented to the TLS working group, there is a new draft in the Interface to Network Security (I2NSF) working group, which proposes a way to automate IPsec connections within service provider networks. A YANG model has been proposed to assist with customers of cloud offerings to automate the deployment of IPsec encrypted sessions (tunnel and transport mode) within their hosted environments. The draft has not yet been adopted as a working group item, but there is work starting between the I2NSF and IPsec Maintenance (IPsecMe) working groups to improve the proposal.
Not all data centres have the same needs, so this may not be a fit for all, but it would be good to consider for the reasons stated above.
A third option is multi-party encryption/decryption protocols designed for data centre use, however, I am not aware of such a proposal to date.
What does this all mean?
It means there is motivation and expertise available to work towards a solution while maintaining TLS 1.3 deployment models that better protect end users’ traffic on the Internet. In other words, keep TLS 1.3 safe for people using the Internet as well as the organizations they access over the Internet.
Some are working toward this with the goal of draft adoption within the TLS working group that includes an extension based solution in which the client is aware of interception. But adoption is not guaranteed.
Will this be costly? Possibly, as upgrading and changes within a data centre are not trivial. However, the costs associated are likely to be much smaller than the potential costs of TLS 1.3 not being maintained as a secure protocol for Internet use.
Ideally, we’d get to a point where endpoint servers have adequate capabilities to provide transaction monitoring and logging to enable end-to-end encryption within data centres too. Assistance from the application and other developers is needed though, to close the gap.
Comments are welcome as is your input and ideas to help advance this work to meet the use case described. Join the discussion on the TLS list.
Original post appeared on RSA Blog. Kathleen is speaking for herself and not as the IETF Security Area Director or for her employer, Dell EMC.
Kathleen Moriarty is Security Area Director for the IETF and Global Lead Security Architect with Dell EMC.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.