Why is TLSv1.3 a better fit for Zero Trust?

The Zero Trust Architecture (ZTA), as defined by NIST Special Publication 800-207 includes two applicable tenets to TLS. The property of provable security makes a strong case in favor of TLSv1.3.

• The first tenet is strong ubiquitous encryption. Strong encryption is intended to be in transit, at rest, and during compute or compute is isolated in an enclave, a.k.a. trusted execution environment. TLSv1.3 applies to encrypted data in transit. This means encryption is in use that cannot be intercepted, including by an authorized service. The reason being is that this authorized service or mechanism to allow for interception creates a point of potential vulnerability. TLSv1.3 went through a lengthy review process to ensure the protocol is provably secure. There are regular updates made as needed to ensure that remains the case, this includes preparations for post-quantum cryptographic algorithms as well as addressing any vulnerabilities discovered over time. TLSv1.2 will not support post quantum encryption, a consideration for roadmap planning.
• The second is strong authentication. TLS (all versions) contains features that cross several layers of the protocol stack between the application layer at 7 and the transport layer (e.g. TCP) at layer 4. The session and presentation layer are both covered as encryption is negotiated between the two connecting hosts and the protocol implementation includes rich features such as strong authentication. Mutual TLS (mTLS) is an option that can be enabled from all TLS libraries that have been implemented to assist with building a secure connection with PKI certificate-based authentication. Mutual means that both ends of the connection (client and server) authenticate to each other. Password authentication is also possible, but it is not secure. You can add on additional forms of authentication such as one-time password (OTP) solutions or WebAuthn, with the use of additional libraries. WebAuthn, also known as passkeys, and PKI are considered phishing resistant.

While strong authentication is available in TLSv1.2, the protocol did not go through the rigorous research-based process to be called provably secure as was done for TLSv1.3. Several critical changes occurred in the TLSv1.3 standard to set these two versions apart, leading TLSv1.3 to be a better fit for meeting the requirements of a Zero Trust architecture. This is why NIST and others had set dates to deprecate use of anything earlier than TLSv1.3 several years back. Since TLSv1.2 is still secure with appropriate configurations, other governments have allowed for additional flexibility for roadmap panning.

Changes continue to be made, updating TLSv1.3 to prevent interception and ensuring connections using TLSv1.3 are strong and provably secure. As stated above, TLSv1.2 is still considered secure when configured correctly and can be used in environments considered as part of a Zero Trust architecture. The Zero Trust tenets on isolation to prevent lateral movement should be considered in the long-term roadmap towards implementing Zero Trust. The use of ZTNA to access individual applications that are on separate networks aid in providing the isolation properties as does the use of a routing overlay protocol such as GENEVE with IPsec to secure network traffic and provide the necessary levels of isolation.

Considerations to securely configure TLSv1.3 are documented in RFC9325, including cipher suite advice that is also maintained in the IANA registry for TLS Parameters. Please keep in mind that an IANA registry is the most up-to-date source for parameter information such as recommended cipher suites and key sizes as it is maintained over time. RFCs are point-in-time publications that may have errata filed to note corrections and may be updated in a new document that would be linked from the original, stating it updates or even obsolete an older document version.

TLSv1.3 coupled with strong authentication meets the requirements for Zero Trust application access. A core belief of Zero Trust is that you do not trust other layers, such as infrastructure or communication protocols. TLS provides that level of security so that, if configured correctly, organizations don’t need to rely on Wi-Fi (or avoiding Wi-Fi),  or other controls to protect their systems, applicationss , and data. If an organization still requires a VPN, it may still be in transition to a Zero Trust architecture. Once applications can all be accessed using strong encryption and authentication, the requirement for the universal access VPN should fall away in favor of isolated secure application access following zero trust tenets.

VPN concentrators have been subject to attacks, such as the 2020 attacks exploiting a known vulnerability. Financial institutions were the primary target in response to sanctions placed on Iran. Access via compromise to the VPN concentrator, meant access was then permitted to all unprotected resources behind that VPN concentrator. This provides an argument for dedicated application access in the Zero Trust architecture design, isolating each application to prevent lateral movement.

A deeper understanding of protocols enables simplified security policies, breaking away from older control recommendations and embracing advancements. Design in protocols, code, and systems where security is built-in and in cases where it has been designed to be provably secure transform our options to simplify security and make it invisible.  Enterprises should understand where their data transits and rests, including the potential aggregation points in order to assess business risk.

If you missed the first part of this blog series, you can find it here: Part 1: How Secure are my Sessions?