Supporting libraries and browsers are ready for this upcoming release. As the former IETF Area Director responsible for TLSv1.3, I assisted with managing the tough conversations, and making sure they could occur, around monitoring and managing networks with TLSv1.3.

Options exist to maintain visibility, but identifying and implementing the most appropriate choice for your network requires careful planning. In an ideal world, organizations would be able to upgrade usage of TLSv1.2 to TLSv1.3 in their internal networks seamlessly. This will happen for some enterprises, where they have already shifted to a network without a perimeter, or no singe discernable firewalled gateway point of access. These networks already rely upon secure TLS sessions – which are more difficult to intercept – following the deployment best practices for TLSv1.2 in RFC7525. In other cases, where possible, the enterprise moved away from a reliance on out-of-band or passive TLS interception middleboxes to rely on the information available at the end point and active interception for monitoring via a proxy-based solution. If your organization still relies upon TLSv1.0 or TLSv1.1, you should minimally move to TLSv1.2 configured according to best practices as that deprecates older crypto algorithms and cipher suites and provides forward secrecy.

Still others have network architectures that would incur great costs to overhaul and move away from the ability to intercept encrypted traffic, yet still desire to apply the best practice of session encryption on their internal networks. As such, work has been proposed unsuccessfully to date in the IETF to allow for visibility in TLSv1.3. These enterprises may need a technology bridge allowing them to continue monitoring the way they are today while considering a shift to session protocols for which session interception is more difficult. Neither of the proposals to date have gone forward toward adoption. The proposals included Data Center Use of Static Diffie-Hellman in TLS 1.3 and TLS 1.3 Option for Negotiation of Visibility in the Datacenter. The two technical arguments, or hurdles, preventing them from moving forward include the working group’s desire to ensure the technique or extension could be bound to the datacenter or enterprise and a requirement for client opt-in. The concern is if there is a way to intercept traffic, it may be done by unknown or malicious parties, in addition to those who already have access to the data at the server or point of termination for the TLS session.

Planning to continue to use TLSv1.2?

Those planning continued use of passive interception using TLSv1.2 with RSA static keys for management and monitoring functions today have a few choices:

Stay with TLSv1.2, deprecation is likely a long way off!

• Current regulations do not require session encryption on internal networks, so it’s unlikely to see this specific version be called out as not approved for use on an internal network. Your organization’s security policy and architecture may guide the selection of the appropriate session encryption protocol.
• Protection of the data through object-level encryption or tokenization are required and will offer the protection mandated by current regulations.
• It is best practice to use session encryption on internal networks and there is no currently known vulnerability in TLSv1.2 that would force its deprecation.
• TLSv1.1 was standardized 12 years ago, and will be deprecated by browser vendors and content delivery networks June 2018 along with TLSv1.0.

SSLv3 enjoyed 20 years of deployment before POODLE forced it to be deprecated by industry and the IETF. Unless there is a major vulnerability and support remains in browsers and libraries, there should be no rush to remove TLSv1.2 from use in your internal network.

• NIST’s 800-52 draft revision “requires that TLS 1.2 configured with FIPS-based cipher suites be supported by all government TLS servers and clients and recommends that agencies develop migration plans to support TLS 1.3 by January 1, 2020”. This recommendation is in line with the best practices for deploying TLSv1.2.  NIST also deprecates TLSv1.0 and recommends against the use of TLSv1.1 in the draft guidance.
• Note: Be sure to phase out any use of TLSv1.0 and TLSv1.1 as support for these protocols that have not been deprecated by the IETF may dwindle in the June/July timeframe as CDNs and other organizations will deprecate their support of these protocols. Browser support plans are not clear, but web traffic statistics from the Alexa top 1 million show that TLSv1.0 compromises 0.8% of traffic and TLSv1.1 is even lower.

Transform your network and security architecture to perform monitoring at the end points to prepare for a transition to TLSv1.3

• Evaluate logs and debug level logs of your applications and systems. Work with vendors to fill the gaps in visibility.
• Eliminate the use of middleboxes that observe and decrypt traffic passively. See if these functions are needed or could be performed at some other point in the network, preferably the edge. Monitoring via a proxy (active) is still possible with TLSv1.3 and will appear similar to end users as in your TLSv1.2 deployments. Proxy-based monitoring is where you terminate a TLS session, perform monitoring, then initiate a new session.

Look for artificial intelligence and machine learning solutions to process logs and alerts from the endpoint.

There is room for innovation here to better scale security and system management. Future and emerging protocol options to better suit your internal network management and monitoring requirements could be considered for longer term solutions. The following two of three possibilities assume TLS is terminated at the Internet-facing edge of your network and alternate encryption protocols can be deployed internally in a server-to-server configuration, the third would run in parallel to TLS.

• TCPcrypt
  • Opportunistic security applied to TCP sessions, leaving the header exposed. Opportunistic security means the session is not authenticated, which eases deployment as it can easily be automated, but also leaves it open to interception.
  • Libraries are available; however, the standard is not yet approved for publication, therefore modifications are possible.
• IPsec
  • IPsec transport mode leaves the source and destination address information exposed for network management.
  • Group keying options are already standardized: GDOI and MIKEY.
  •  It’s little known, but many implementations allow for a debug session to provide full clear text of a session to be collected at the endpoint for troubleshooting.
  • Interoperability work is needed between implementations to make IPsec transport mode a real contender, but it’s possible for this work to occur if there is demand.  The IPsec Maintenance (IPsecMe) working group is fairly active. This would require a push from customers to their vendors to see support. Alternatively, IPsec tunnel mode could be used from endpoints to preserve the source and destination address information in the packet header.
  • There’s active work in the IETF’s Interface to Network Service function (I2NSF) working group to automate IPsec provisioning through a Software Defined Network (SDN) controller within your data center or even a hosted environment.  See “Software-Defined Networking (SDN)-based IPsec Flow Protection”.
• Multi-party protocol designed for datacenter use             
  • Candidate solutions are intended to run in parallel to TLS.  As I understand it, the PATIENT effort is looking for solutions that enable visibility from all monitoring points where the client can see what points of monitoring exist, while maintaining forward secrecy.
  • There are a few candidate solutions and it’s possible an effort will form in the IETF where a protocol is designed specifically for this use case.
  • If interested, you can follow along and contribute on the PATIENT mailing list (https://www.ietf.org/mailman/listinfo/Patient ) to see if the work can be shaped into a secure solution to meet the needs of enterprises and data centers.

Recently, at RSA Conference 2018 and Dell Technologies World 2018, the audiences for the TLSv1.3 sessions were polled regarding planned adoption. There were few deployments of TLSv1.3 planned for internal networks. I see this as a technology gap problem. Standards efforts and industry have put forth the tools for maintaining secure sessions, but still must provide a path for network and security management functions that have operated via middlebox technologies intercepting traffic passively. We are at a learning curve prior to an adoption phase. However, the tools are ready, implementations have been well tested for interoperability, and the security benefits are clear for some use cases including Internet-based sessions.

This has originially been published on the RSA blog.