Network operators, especially those managing enterprise networks and data centers have expressed concern with deploying TLSv1.3, which is normal at the start of an adoption curve. Through much work – listening  to operators and their explicit concerns – deploying  TLSv1.3 on Internet-based sessions terminating at the edge of the corporate network or data center is a logical first step that should not be business impacting. This conclusion is based on discussion with operators in several venues and contributions to “The Effect of Pervasive Monitoring on Operations”, a survey of management and monitoring techniques in use by operators on service provider and enterprise networks. Deployments on internal networks may require further study by organizations evaluating their network architecture, security policies, monitoring and management tool sets.

Service providers share their monitoring techniques

Much insight was gleaned in the survey as service providers discussed their monitoring techniques on the Internet. A reliable and trusted operator contributed that most of the monitoring performed is kept to packet headers for the transport, network, and data link layers. This information continues to be available in TLSv1.3, although handshake messages after the SERVERHELO are encrypted via the EncryptedExtensions, leaving some previously available information encrypted.  One such example is the application-layer protocol negotiation (ALPN), where the request is in the clear and the response is encrypted. The ALPN response includes the protocol to be used as selected by the server, offering confidentiality of this information from anyone observing the traffic that might be used subsequently. This may have some impact on monitoring requiring a shift in practices based on available information or the point of monitoring, possibly the edge versus network if this type of observation is permitted by policy at the edge.

Figure 1: Network layers of packet headers observed by Service Providers

One of our learnings from the survey was that when troubleshooting customers’ requests  requires additional information to debug an issue, service providers typically request the session capture information from the customer close to the edge.  Network monitoring remained limited to the headers previously mentioned. If the customer is fine exposing that information and provides it via a packet capture from their point of visibility, this type of debugging is still possible with TLSv1.3, or even IPsec, with a lower level of on-the-wire visibility. You may want to consider redacting information from packet content to avoid unintended data leakage.

TLSv1.3 adoption and deployment options

TLSv1.3 is a more secure protocol than TLSv1.2, with improved protection against interception and should be strongly considered to better protect your customers’ Internet-based sessions. We are in the learning curve prior to an adoption phase, understanding the clear benefits and where to deploy first will assist with adoption. The balance of monitoring and encryption is up to each organization, as is understanding when and where to deploy TLSv1.3.

TLSv1.3 provides forward secrecy and is provably secure (when 0-RTT is not in use) and should strongly be considered to protect sessions from interception on the Internet. 0-RTT enhances performance on session renegotiation when pre-shared keys are in use. This addition included in TLSv1.3 to assist with enhanced performance, but may not be right for your TLSv1.3 sessions. I recommend taking a hard look, considering whether 0-RTT is good match for the applications and data you are hosting. If performance is critical and outweighs the possible threat of a replay attack and loss of forward secrecy, implement with 0-RTT and the mitigation options. If you run business-critical servers with sensitive data, think twice about relying on the mitigation options. Instead, favor using an implementation that separates out the streams for 0-RTT and 1-RTT to also avoid possible configuration errors. 

Contribute to monitoring solutions

Turning toward enterprise and data center networks, the monitoring performed does include inspection of the packet payload at times. This may be the case for intrusion detection and information leakage monitoring, as well as debugging application-level problems. The difference for the enterprise scenario is that once inside the data center, the enterprise owns the data on their servers and has access to it anyway. For user sessions to the Internet, users are typically subject to monitoring per policy and user agreements from the time of employment. Organizations often have exceptions to this monitoring and exclude financial sites. For example, Germany has a legal expectation that employees have a right to perform some personal business from the workplace without interception. There have been two drafts submitted to date to the IETF detailing the types of monitoring performed and techniques used specific to enterprise and data center settings for visibility. They are open for contribution via the authors or on an IETF mailing list and include: TLS 1.3 Impact on Network-Based Security and Why Enterprises Need Out-of-Band TLS Decryption. Having this type of information as accurate and representative of real operational networks assists protocol designers as they consider use cases and possible solutions.

A previous blog details this problem a bit better with the transition to TLSv1.3. The final blog in this series will dive into the proposals for visibility and alternate solutions.

This has originially been published on the RSA blog.