draft-ietf-opsec-ns-impact-01.txt   draft-ietf-opsec-ns-impact-02.txt 
OPSEC Working Group N. Cam-Winget OPSEC Working Group N. Cam-Winget
Internet-Draft E. Wang Internet-Draft E. Wang
Intended status: Informational Cisco Systems, Inc. Intended status: Informational Cisco Systems, Inc.
Expires: January 28, 2021 R. Danyliw Expires: January 29, 2021 R. Danyliw
Software Engineering Institute Software Engineering Institute
R. DuToit R. DuToit
Broadcom Broadcom
July 27, 2020 July 28, 2020
Impact of TLS 1.3 to Operational Network Security Practices Impact of TLS 1.3 to Operational Network Security Practices
draft-ietf-opsec-ns-impact-01 draft-ietf-opsec-ns-impact-02
Abstract Abstract
Network-based security solutions are used by enterprises, the public Network-based security solutions are used by enterprises, the public
sector, internet-service providers, and cloud-service providers to sector, internet-service providers, and cloud-service providers to
both complement and enhance host-based security solutions. As TLS is both complement and enhance host-based security solutions. As TLS is
a widely deployed protocol to secure communication, these network- a widely deployed protocol to secure communication, these network-
based security solutions must necessarily interact with it. This based security solutions must necessarily interact with it. This
document describes this interaction for current operational security document describes this interaction for current operational security
practices and notes the impact of TLS 1.3 on them. practices and notes the impact of TLS 1.3 on them.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 28, 2021. This Internet-Draft will expire on January 29, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. How TLS is used to enable Network-Based Security Solutions . 4 3. How TLS is used to enable Network-Based Security Solutions . 4
3.1. Passive TLS Inspection . . . . . . . . . . . . . . . . . 5 4. Changes in TLS 1.3 Relevant to Security Operations . . . . . 5
3.1.1. OP-1. Acceptable Use Policy (AUP) Enforcement (via 4.1. Perfect Forward Secrecy (PFS) . . . . . . . . . . . . . . 5
header inspection). . . . . . . . . . . . . . . . . . 6 4.2. Encrypted Server Certificate . . . . . . . . . . . . . . 5
3.1.2. OP-2. Network Behavior Analytics . . . . . . . . . . 6 5. Network Security Operational Practices . . . . . . . . . . . 6
3.1.3. OP-3. Crypto, Security and Security Policy 5.1. Passive TLS Inspection . . . . . . . . . . . . . . . . . 6
Compliance (server) . . . . . . . . . . . . . . . . . 7 5.1.1. OP-1. Acceptable Use Policy (AUP) Enforcement (via
3.1.4. OP-4. Crypto and Security Policy Compliance (client) 7 header inspection). . . . . . . . . . . . . . . . . . 7
3.2. Outbound TLS Proxy . . . . . . . . . . . . . . . . . . . 8 5.1.2. OP-2. Network Behavior Analytics . . . . . . . . . . 7
3.2.1. OP-5: Acceptable Use Policy (AUP) Enforcement (via 5.1.3. OP-3. Crypto, Security and Security Policy
payload inspection) . . . . . . . . . . . . . . . . . 9 Compliance (server) . . . . . . . . . . . . . . . . . 8
3.2.2. OP-6: Data Loss Prevention Compliance . . . . . . . . 9 5.1.4. OP-4. Crypto and Security Policy Compliance (client) 8
3.2.3. OP-7: Granular Network Segmentation . . . . . . . . . 9 5.2. Outbound TLS Proxy . . . . . . . . . . . . . . . . . . . 9
3.2.4. OP-8: Network-based Threat Protection (client) . . . 9 5.2.1. OP-5: Acceptable Use Policy (AUP) Enforcement (via
3.2.5. OP-9: Protecting Challenging End Points . . . . . . . 10 payload inspection) . . . . . . . . . . . . . . . . . 10
3.2.6. OP-10: Content Injection . . . . . . . . . . . . . . 10 5.2.2. OP-6: Data Loss Prevention Compliance . . . . . . . . 10
3.3. Inbound TLS Proxy . . . . . . . . . . . . . . . . . . . . 10 5.2.3. OP-7: Granular Network Segmentation . . . . . . . . . 10
3.3.1. OP-11: TLS offloading . . . . . . . . . . . . . . . . 11 5.2.4. OP-8: Network-based Threat Protection (client) . . . 10
3.3.2. OP-12. Content distribution and application load 5.2.5. OP-9: Protecting Challenging End Points . . . . . . . 11
balancing . . . . . . . . . . . . . . . . . . . . . . 12 5.2.6. OP-10: Content Injection . . . . . . . . . . . . . . 11
3.3.3. OP-13: Network-based Threat Protection (server) . . . 12 5.3. Inbound TLS Proxy . . . . . . . . . . . . . . . . . . . . 11
3.3.4. OP-14: Full Packet Capture . . . . . . . . . . . . . 12 5.3.1. OP-11: TLS offloading . . . . . . . . . . . . . . . . 12
3.3.5. OP-15: Application Layer Gateway (ALG) . . . . . . . 13 5.3.2. OP-12. Content distribution and application load
4. Changes in TLS v1.3 Relevant to Security Operations . . . . . 13 balancing . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Perfect Forward Secrecy (PFS) . . . . . . . . . . . . . . 13 5.3.3. OP-13: Network-based Threat Protection (server) . . . 13
4.2. Encrypted Server Certificate . . . . . . . . . . . . . . 13 5.3.4. OP-14: Full Packet Capture . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5.3.5. OP-15: Application Layer Gateway (ALG) . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. Appendix A: Summary Impact to Operational Practices with TLS 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Appendix A: Summary Impact to Operational Practices with TLS
1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
Enterprises, public sector organizations, internet service providers Enterprises, public sector organizations, internet service providers
and cloud service providers defend their networks and information and cloud service providers defend their networks and information
systems from attacks that originate from inside and outside their systems from attacks that originate from inside and outside their
networks. These organizations commonly employ security architectures networks. These organizations commonly employ security architectures
that involve complementary technologies deployed on both endpoints that involve complementary technologies deployed on both endpoints
skipping to change at page 3, line 43 skipping to change at page 3, line 43
disk and computing) independent of the systems it is protecting disk and computing) independent of the systems it is protecting
o by itself, a single system may not be able to detect and mitigate o by itself, a single system may not be able to detect and mitigate
threats threats
In response to the adoption of new technologies, protocols and In response to the adoption of new technologies, protocols and
threats, these security architectures must evolve to remain threats, these security architectures must evolve to remain
effective. [RFC8404] documented a need to evolve with the effect of effective. [RFC8404] documented a need to evolve with the effect of
pervasive encryption on operations. This document takes a narrower pervasive encryption on operations. This document takes a narrower
focus by documenting the interaction of existing network-based focus by documenting the interaction of existing network-based
security practices with TLS v1.2 [RFC5246] (and earlier) traffic to security practices with TLS 1.2 [RFC5246] (and earlier) traffic to
implement security policy, detection or mitigation of threats; and implement security policy, detection or mitigation of threats; and
the impact on these practices with improvements made in TLS v1.3 the impact on these practices with improvements made in TLS 1.3
[RFC8446]. [RFC8446].
2. Conventions and Definitions 2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 4, line 50 skipping to change at page 4, line 50
CONNECT to request a tunnel to the server, the web proxy may insert a CONNECT to request a tunnel to the server, the web proxy may insert a
TLS Proxy function to proxy the TLS session without awareness by the TLS Proxy function to proxy the TLS session without awareness by the
client or server. The TLS operation afterwards remains the same as a client or server. The TLS operation afterwards remains the same as a
middlebox. middlebox.
To proxy a TLS session, a TLS Proxy must be able to present a valid To proxy a TLS session, a TLS Proxy must be able to present a valid
X.509 certificate to the TLS client to appear as a valid TLS Server; X.509 certificate to the TLS client to appear as a valid TLS Server;
similarly, the client must be able to validate the X.509 certificate similarly, the client must be able to validate the X.509 certificate
using the appropriate trust anchor for that TLS connection. To using the appropriate trust anchor for that TLS connection. To
achieve this, a deployment must properly provision their systems (TLS achieve this, a deployment must properly provision their systems (TLS
Proxies and TLS clients). Proxies and TLS clients). A TLS Proxy is unable to proxy a PSK based
session unless it is on-path and has proxied the session leading to
the PSK. TLS client authentication requires additional provisioning
for X.509 certificate on the TLS Server side. It does not have
impact on the deployment scenarios though.
Specific network security operational practices applied to TLS v1.2 4. Changes in TLS 1.3 Relevant to Security Operations
TLS 1.3 introduces a number of protocol design changes to improve
security and privacy. However, these enhancements impact current
network security operational practices that rely on the protocol
behavior of earlier TLS versions.
4.1. Perfect Forward Secrecy (PFS)
TLS 1.2 (and earlier versions) supports static RSA and Diffie-Hellman
(DH) cipher suites, which enables the server's private key to be
shared with a TLS proxy. [RFC7525] initiated the recommendation of
using AEAD cipher suites and specifically decoupling the cipher suite
negotiation based on the RSA key transport; this followed with TLS
1.3 explicitly removing support for these cipher suites in favor of
supporting only ephemeral mode Diffie-Hellman to provide perfect
forward secrecy (PFS). As a result of this enhancement, it would no
longer be possible for a server to share a key with the middlebox in
advance, which in turn implies that the middlebox cannot gain access
to the TLS session data.ss
4.2. Encrypted Server Certificate
TLS 1.2 (and earlier versions) sends the ClientHello, ServerHello and
Certificate messages in clear-text. In TLS 1.3, the Certificate
message is encrypted whereby hiding the server identity from any
intermediary. As a result of this enhancement, it would no longer be
possible to observe the server certificate without inspection the
encrypted TLS payload.
TLS proxies which implement a selective decryption policy will need
to alter their behavior to accommodate TLS 1.3. In TLS 1.2 (and
earlier), the proxy could observe the TLS handshake till seeing the
clear text server certificate to make the decryption policy decision.
For example, a proxy may not be permitted to decrypt certain types of
traffic such as those going to a banking and health care service.
However, in TLS 1.3, the TLS proxy must participate in both
handshakes (i.e., client-to-proxy; and proxy-to-server) in order to
view the server certificate. This change will impose a slight
increase in load per connection on the proxy.
5. Network Security Operational Practices
Specific network security operational practices applied to TLS 1.2
(and earlier) are described in subsequent sub-sections. They are (and earlier) are described in subsequent sub-sections. They are
categorized into the following deployment scenarios: categorized into the following deployment scenarios:
1. Passive TLS inspection, where the network-based security function 1. Passive TLS inspection, where the network-based security function
is inspecting either the inbound or outbound TLS header or meta- is inspecting either the inbound or outbound TLS header or meta-
data traffic data traffic
2. Outbound TLS Proxy, where a TLS proxy mediates a TLS session 2. Outbound TLS Proxy, where a TLS proxy mediates a TLS session
originating from a client inside the enterprise administrative originating from a client inside the enterprise administrative
domain (and in the same administrative domain as the proxy) domain (and in the same administrative domain as the proxy)
towards an entity on the outside towards an entity on the outside
3. Inbound TLS Proxy, where a TLS proxy mediates a TLS session from 3. Inbound TLS Proxy, where a TLS proxy mediates a TLS session from
a client outside the enterprise administrative domain towards an a client outside the enterprise administrative domain towards an
entity on the inside (and in the same administrative domain as entity on the inside (and in the same administrative domain as
the proxy) the proxy)
Each deployment scenario describes current operational practices. Each deployment scenario describes current operational practices.
For each operational practice, possible deployment modes (e.g., For each operational practice, possible deployment modes (e.g.,
inline, out-of-band), a description of the practice, and the impact inline, out-of-band), a description of the practice, and the impact
of TLS v1.3 is categorized and explained. The categorized impacts to of TLS 1.3 is categorized and explained. The categorized impacts to
practices when migrating to TLS v1.3 are as follows: practices when migrating to TLS 1.3 are as follows:
o no impact - no change in capability or performance is expected o no impact - no change in capability or performance is expected
with this practice with this practice
o no capability impact - no change in capability is expected; but o no capability impact - no change in capability is expected; but
there may be a performance or implementation change required for there may be a performance or implementation change required for
this practice this practice
o reduced effectiveness - this practice will not be as effective on o reduced effectiveness - this practice will not be as effective on
TLS v1.3 traffic TLS 1.3 traffic
o alternative approach required - this practice will not work with o alternative approach required - this practice will not work with
TLS v1.3 traffic TLS 1.3 traffic
3.1. Passive TLS Inspection It should be noted that [ECH] will further reduce the effectiveness
(passive inspection) or prevent certain practices (outbound proxy)
from being deployed. More study is required in this area.
5.1. Passive TLS Inspection
Passive TLS inspection is the deployment scenario where a network Passive TLS inspection is the deployment scenario where a network
security device passively inspects inbound or outbound TLS traffic to security device passively inspects inbound or outbound TLS traffic to
make visibility inferences or take policy actions. The network make visibility inferences or take policy actions. The network
security device examines only the unencrypted TLS protocol headers security device examines only the unencrypted TLS protocol headers
and does not have access to the encrypted content of the payload. and does not have access to the encrypted content of the payload.
The TLS proxy deployment scenarios may also incorporate these The TLS proxy deployment scenarios may also incorporate these
practices. practices.
3.1.1. OP-1. Acceptable Use Policy (AUP) Enforcement (via header 5.1.1. OP-1. Acceptable Use Policy (AUP) Enforcement (via header
inspection). inspection).
Deployment mode: inline Deployment mode: inline
A firewall or web proxy restricts a client in the same administrative A firewall or web proxy restricts a client in the same administrative
domain from accessing sites or services outside that domain per an domain from accessing sites or services outside that domain per an
acceptable use policy. The identification of the destination server acceptable use policy. The identification of the destination server
is performed through the inspection of either the SNI field in the is performed through the inspection of either the SNI field in the
TLS ClientHello message from the client; or by extracting the server TLS ClientHello message from the client; or by extracting the server
identity from the Common Name (CN) or Subject Alternative Name (SAN) identity from the Common Name (CN) or Subject Alternative Name (SAN)
skipping to change at page 6, line 39 skipping to change at page 7, line 44
While an SNI is mandatory in TLS 1.3, there is no guarantee that the While an SNI is mandatory in TLS 1.3, there is no guarantee that the
server responding is the one indicated in the SNI from the client. A server responding is the one indicated in the SNI from the client. A
SNI alone, without comparison of the server certificate, does not SNI alone, without comparison of the server certificate, does not
provide reliable information about the server that the client is provide reliable information about the server that the client is
attempting to reach. Where a client has been compromised by malware, attempting to reach. Where a client has been compromised by malware,
it may present an innocuous SNI to bypass protective filters (e.g., it may present an innocuous SNI to bypass protective filters (e.g.,
to reach a command and control server), and this will be undetectable to reach a command and control server), and this will be undetectable
under TLS 1.3. under TLS 1.3.
[ESNI] will further reduce the effectiveness of passive TLS 5.1.2. OP-2. Network Behavior Analytics
inspection, limiting the available information to IP addresses and
possible correlation with DNS.
3.1.2. OP-2. Network Behavior Analytics
Deployment mode: inline and out-of-band Deployment mode: inline and out-of-band
Network behavior analysis and machine learning engines in IDSs, IPSs Network behavior analysis and machine learning engines in IDSs, IPSs
and firewalls observe the cleartext fields of the TLS handshake and firewalls observe the cleartext fields of the TLS handshake
(e.g., session cipher suites) and conducts traffic analysis by (e.g., session cipher suites) and conducts traffic analysis by
observing encrypted record sizes, packet rates and their inter- observing encrypted record sizes, packet rates and their inter-
arrival times, and similar outer connection behavior. They match arrival times, and similar outer connection behavior. They match
encrypted connections against known application patterns; identify encrypted connections against known application patterns; identify
anomalies; and identify or block those without payload inspection. anomalies; and identify or block those without payload inspection.
skipping to change at page 7, line 17 skipping to change at page 8, line 19
rates, and vary payload sizes in order to circumvent detection. rates, and vary payload sizes in order to circumvent detection.
Through traffic analysis, researchers have detected devastating Through traffic analysis, researchers have detected devastating
pseudo-random number generator failures [TLS_VULNERABILITY], nonce pseudo-random number generator failures [TLS_VULNERABILITY], nonce
failures [NONCE_FAIL], and deeply flawed random number generators in failures [NONCE_FAIL], and deeply flawed random number generators in
products in [WEAK_KEY] and [WEAK_K2]. products in [WEAK_KEY] and [WEAK_K2].
TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, any TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, any
features relying on Certificate information will not be available. features relying on Certificate information will not be available.
3.1.3. OP-3. Crypto, Security and Security Policy Compliance (server) 5.1.3. OP-3. Crypto, Security and Security Policy Compliance (server)
Deployment: out-of-band Deployment: out-of-band
A network security device observes TLS handshake traffic to audit A network security device observes TLS handshake traffic to audit
that TLS server configuration conforms to policy. This compliance that TLS server configuration conforms to policy. This compliance
monitoring commonly examines ciphersuites (e.g., use of weak monitoring commonly examines ciphersuites (e.g., use of weak
ciphersuites) and certificate properties (e.g., no self-signed ciphersuites) and certificate properties (e.g., no self-signed
certificates, black or white list of certificate authorities, certificates, black or white list of certificate authorities,
certificate expiration times). certificate expiration times).
TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, only TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, only
TLS ClientHello and ServerHello parameters can be audited. TLS ClientHello and ServerHello parameters can be audited.
Certification information will not be visible. Certification information will not be visible.
3.1.4. OP-4. Crypto and Security Policy Compliance (client) 5.1.4. OP-4. Crypto and Security Policy Compliance (client)
Deployment: inline Deployment: inline
A network security device observes TLS handshake traffic to ensure A network security device observes TLS handshake traffic to ensure
that clients negotiating TLS connections have configurations (e.g., that clients negotiating TLS connections have configurations (e.g.,
only make connections with TLS 1.2+) and server certificate (e.g., only make connections with TLS 1.2+) and server certificate (e.g.,
black-listed CAs) that adhere to policy. This is a variant of OP-3. black-listed CAs) that adhere to policy. This is a variant of OP-3.
It is commonly used in deployments where an organization may have It is commonly used in deployments where an organization may have
reduced configuration control of end points (e.g., lab environments, reduced configuration control of end points (e.g., lab environments,
Bring Your Own Device arrangements, and IoT). Bring Your Own Device arrangements, and IoT).
TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, only TLS 1.3 considerations: reduced effectiveness. Per Section 4.2, only
TLS ClientHello and ServerHello parameters can be audited. TLS ClientHello and ServerHello parameters can be audited.
Certification information will not be visible. Certification information will not be visible.
3.2. Outbound TLS Proxy 5.2. Outbound TLS Proxy
Outbound TLS proxy is the deployment scenario where a security device Outbound TLS proxy is the deployment scenario where a security device
that performs the TLS proxy function is in the same administrative that performs the TLS proxy function is in the same administrative
domain as the TLS client, and the TLS server is located in an domain as the TLS client, and the TLS server is located in an
external zone such as the Internet or in another policy zone of the external zone such as the Internet or in another policy zone of the
same administrative domain. Usually the goal is to protect the same administrative domain. Usually the goal is to protect the
client endpoint and the organization by controlling application client endpoint and the organization by controlling application
behaviors and enforcing an acceptable use policy for the behaviors and enforcing an acceptable use policy for the
organizational network. See Figure 1. organizational network. See Figure 1.
skipping to change at page 9, line 5 skipping to change at page 10, line 5
|C|... | \_.+---------+ ) |C|... | \_.+---------+ )
| | | \.. / | | | \.. /
+-+ / \____--' +-+ / \____--'
/ /
Administrative / Internet Administrative / Internet
Domain, Zone 1 / Domain, Zone 1 /
_________/ _________/
Figure 1: Outbound TLS proxy Figure 1: Outbound TLS proxy
3.2.1. OP-5: Acceptable Use Policy (AUP) Enforcement (via payload 5.2.1. OP-5: Acceptable Use Policy (AUP) Enforcement (via payload
inspection) inspection)
Deployment: inline Deployment: inline
A firewall or web proxy restricts a client in the same administrative A firewall or web proxy restricts a client in the same administrative
domain from accessing sites or services outside that domain per an domain from accessing sites or services outside that domain per an
acceptable use policy. Similar in intent to OP-1, but the policy acceptable use policy. Similar in intent to OP-1, but the policy
enforcement in this practice requires access to data in the TLS enforcement in this practice requires access to data in the TLS
session (e.g., URL). session (e.g., URL).
TLS 1.3 considerations: no capability impact. See Section 4.2 if a TLS 1.3 considerations: no capability impact. See Section 4.2 if a
selective decryption policy is used. selective decryption policy is used.
3.2.2. OP-6: Data Loss Prevention Compliance 5.2.2. OP-6: Data Loss Prevention Compliance
Deployment: inline Deployment: inline
A firewall enforces a Data Loss Prevention (DLP) policy by monitoring A firewall enforces a Data Loss Prevention (DLP) policy by monitoring
the TLS sessions content of outbound communication for systems the TLS sessions content of outbound communication for systems
sending organizational proprietary content or other restricted sending organizational proprietary content or other restricted
information. Note that the firewall may be implemented and enforced information. Note that the firewall may be implemented and enforced
either at the endpoint or by the network infrastructure. either at the endpoint or by the network infrastructure.
TLS 1.3 considerations: no capability impact. See Section 4.2 if a TLS 1.3 considerations: no capability impact. See Section 4.2 if a
selective decryption policy is used. selective decryption policy is used.
3.2.3. OP-7: Granular Network Segmentation 5.2.3. OP-7: Granular Network Segmentation
Deployment: inline Deployment: inline
A firewall mediates the traffic between different policy zones in an A firewall mediates the traffic between different policy zones in an
organization. The access policies between these zones may be based organization. The access policies between these zones may be based
on application names and categories rather than static IP addresses on application names and categories rather than static IP addresses
and TCP/UDP port numbers. Through a TLS proxy, the firewall can and TCP/UDP port numbers. Through a TLS proxy, the firewall can
inspect URLs and other application parameters based on data in the inspect URLs and other application parameters based on data in the
TLS session. TLS session.
TLS 1.3 considerations: no capability impact. See Section 4.2 if a TLS 1.3 considerations: no capability impact. See Section 4.2 if a
selective decryption policy is used. selective decryption policy is used.
3.2.4. OP-8: Network-based Threat Protection (client) 5.2.4. OP-8: Network-based Threat Protection (client)
Deployment: inline or out-of-band (depending on functionality) Deployment: inline or out-of-band (depending on functionality)
Web proxies and firewalls protect end-users against a range of Web proxies and firewalls protect end-users against a range of
threats by inspecting the data in the TLS session with a variety of threats by inspecting the data in the TLS session with a variety of
analytical techniques (e.g., signatures, heuristics, statistical analytical techniques (e.g., signatures, heuristics, statistical
models, machine learning). This practice is a superset of OP-2. models, machine learning). This practice is a superset of OP-2.
Common goals are to prevent malware from reaching the endpoint, Common goals are to prevent malware from reaching the endpoint,
preventing malware communication from a compromised host, restricting preventing malware communication from a compromised host, restricting
lateral network movement of an intruder and gathering insight into lateral network movement of an intruder and gathering insight into
the behavior of threat activity on the network. the behavior of threat activity on the network.
In certain deployments these technologies are also used to act as a In certain deployments these technologies are also used to act as a
last line of defense against software vulnerabilities on endpoints - last line of defense against software vulnerabilities on endpoints -
either for 0-days for which there is no patch, or simply unpatched either for 0-days for which there is no patch, or simply unpatched
clients. clients.
TLS 1.3 considerations: no capability impact. See Section 4.2 if a TLS 1.3 considerations: no capability impact. See Section 4.2 if a
selective decryption policy is used. selective decryption policy is used.
3.2.5. OP-9: Protecting Challenging End Points 5.2.5. OP-9: Protecting Challenging End Points
Deployment mode: inline Deployment mode: inline
Web proxies, IPS and firewalls implement security policy and afford Web proxies, IPS and firewalls implement security policy and afford
protection to devices for which it is not feasible to run an end- protection to devices for which it is not feasible to run an end-
point solution (e.g., IoT); or that are end-of-life and will not point solution (e.g., IoT); or that are end-of-life and will not
receive patches. This is a specialized instance of OP-8 targeting receive patches. This is a specialized instance of OP-8 targeting
these disadvantaged classes of devices. these disadvantaged classes of devices.
These practices ensure that that older endpoints (and in some cases These practices ensure that that older endpoints (and in some cases
even new ones) are not permanently vulnerable to newly discovered even new ones) are not permanently vulnerable to newly discovered
vulnerabilities. vulnerabilities.
TLS 1.3 considerations: no capability impact. See Section 4.2 if a TLS 1.3 considerations: no capability impact. See Section 4.2 if a
selective decryption policy is used. selective decryption policy is used.
3.2.6. OP-10: Content Injection 5.2.6. OP-10: Content Injection
Deployment: inline Deployment: inline
A firewall or web proxy restricts message manipulation or insertion, A firewall or web proxy restricts message manipulation or insertion,
such as a block page or an interactive authentication portal such as a block page or an interactive authentication portal
redirect, into the encrypted flow for the client to see. This may be redirect, into the encrypted flow for the client to see. This may be
used in conjunction with OP-1, OP-5, and OP-7. used in conjunction with OP-1, OP-5, and OP-7.
TLS 1.3 considerations: no capability impact. See Section 4.2 if a TLS 1.3 considerations: no capability impact. See Section 4.2 if a
selective decryption policy is used. selective decryption policy is used.
3.3. Inbound TLS Proxy 5.3. Inbound TLS Proxy
Inbound TLS proxy is the deployment scenario where the TLS proxy is Inbound TLS proxy is the deployment scenario where the TLS proxy is
deployed in front of one or a set of servers or services. The deployed in front of one or a set of servers or services. The
network device that implements the TLS proxy function is located in network device that implements the TLS proxy function is located in
the same administrative domain as the server(s) or service(s) it is the same administrative domain as the server(s) or service(s) it is
protecting. Usually it is not predictable or controllable as to protecting. Usually it is not predictable or controllable as to
which TLS client will initiate a connection. See Figure 2. which TLS client will initiate a connection. See Figure 2.
The TLS proxy is provisioned with the server's certificates and The TLS proxy is provisioned with the server's certificates and
private keys so that it may either decrypt or terminate the TLS private keys so that it may either decrypt or terminate the TLS
skipping to change at page 11, line 40 skipping to change at page 12, line 40
\_. ) | . |--| |__| \_. ) | . |--| |__|
\.. / | ..|==| " " \.. / | ..|==| " "
\____--' \ |--| \____--' \ |--|
\ |::| Administrative \ |::| Administrative
External Network \ |__| Domain External Network \ |__| Domain
\ " " \ " "
\____________ \____________
Figure 2: Inbound TLS proxy Figure 2: Inbound TLS proxy
3.3.1. OP-11: TLS offloading 5.3.1. OP-11: TLS offloading
Deployment mode: inline Deployment mode: inline
Offloads crypto operations from the application server to a TLS Offloads crypto operations from the application server to a TLS
Proxy. This is not a typical security function on its own, but it Proxy. This is not a typical security function on its own, but it
facilitates security control insertion downstream. As this is in the facilitates security control insertion downstream. As this is in the
same administrative domain, it is presumed that a TLS Proxy can be same administrative domain, it is presumed that a TLS Proxy can be
provisioned with the appropriate keys when the TLS Server is provisioned with the appropriate keys when the TLS Server is
configured or managed. configured or managed.
TLS 1.3 considerations: no impact. TLS 1.3 considerations: no impact.
3.3.2. OP-12. Content distribution and application load balancing 5.3.2. OP-12. Content distribution and application load balancing
Deployment mode: inline Deployment mode: inline
Load balancers deployed in front of services provide resiliency Load balancers deployed in front of services provide resiliency
against denial of service attacks. TLS proxy functionality provides against denial of service attacks. TLS proxy functionality provides
access to the cleartext application layer data to enable service- access to the cleartext application layer data to enable service-
tailored load balancing. Similar to OP-11, it is presumed that a TLS tailored load balancing. Similar to OP-11, it is presumed that a TLS
Proxy can be provisioned with the appropriate keys when the TLS Proxy can be provisioned with the appropriate keys when the TLS
Server is configured or managed. Server is configured or managed.
This practice may be combined with OP-11. This practice may be combined with OP-11.
TLS 1.3 considerations: no impact. TLS 1.3 considerations: no impact.
3.3.3. OP-13: Network-based Threat Protection (server) 5.3.3. OP-13: Network-based Threat Protection (server)
Deployment mode: inline and out-of-band Deployment mode: inline and out-of-band
Web application firewalls (WAF) and firewalls protect servers and Web application firewalls (WAF) and firewalls protect servers and
services against a range of threats by inspecting the data in the TLS services against a range of threats by inspecting the data in the TLS
session with a variety of analytical techniques (e.g., signatures, session with a variety of analytical techniques (e.g., signatures,
heuristics, statistical models, machine learning). This practice is heuristics, statistical models, machine learning). This practice is
identical in function to OP-8, but focused on threat prevention of identical in function to OP-8, but focused on threat prevention of
inbound requests to servers and services. inbound requests to servers and services.
TLS 1.3 considerations for inline deployment mode: no capability TLS 1.3 considerations for inline deployment mode: no capability
impact. Per Section 4.1, the network security device must explicitly impact. Per Section 4.1, the network security device must explicitly
terminate the TLS connection from the client. terminate the TLS connection from the client.
TLS 1.3 considerations for out-of-band mode: alternative approach TLS 1.3 considerations for out-of-band mode: alternative approach
required. Per Section 4.1, active participation in the TLS exchange required. Per Section 4.1, active participation in the TLS exchange
is required to inspect the session. is required to inspect the session.
3.3.4. OP-14: Full Packet Capture 5.3.4. OP-14: Full Packet Capture
Deployment mode: inline and out-of-band Deployment mode: inline and out-of-band
A network security device stores a copy of all decrypted traffic that A network security device stores a copy of all decrypted traffic that
meets a given filter. This traffic may be continuously captured in a meets a given filter. This traffic may be continuously captured in a
rolling buffer for use in future forensic analysis, incident rolling buffer for use in future forensic analysis, incident
response, or computationally intensive retrospective analysis. This response, or computationally intensive retrospective analysis. This
collection may also be selectively enabled to support application collection may also be selectively enabled to support application
troubleshooting. troubleshooting.
TLS 1.3 considerations for inline deployment mode: no capability TLS 1.3 considerations for inline deployment mode: no capability
impact. Per Section 4.1, the network security device must explicitly impact. Per Section 4.1, the network security device must explicitly
terminate the TLS connection from the client. terminate the TLS connection from the client.
TLS 1.3 considerations for out-of-band mode: alternative approach TLS 1.3 considerations for out-of-band mode: alternative approach
required. Per Section 4.1, offline decryption is not possible. required. Per Section 4.1, offline decryption is not possible.
3.3.5. OP-15: Application Layer Gateway (ALG) 5.3.5. OP-15: Application Layer Gateway (ALG)
Deployment mode: inline Deployment mode: inline
To conduct protocol conformance checks and rewrite embedded IP To conduct protocol conformance checks and rewrite embedded IP
addresses and TCP/UDP ports within the application layer payload for addresses and TCP/UDP ports within the application layer payload for
traffic traversing a NAT boundary. While not strictly a security traffic traversing a NAT boundary. While not strictly a security
function, this capability may typically be found in firewalls along function, this capability may typically be found in firewalls along
with the NAT supporting functions. with the NAT supporting functions.
TLS 1.3 considerations: no impact. TLS 1.3 considerations: no impact.
4. Changes in TLS v1.3 Relevant to Security Operations 6. Security Considerations
TLS v1.3 introduces a number of protocol design changes to improve
security and privacy. However, these enhancements impact current
network security operational practices that rely on the protocol
behavior of earlier TLS versions.
4.1. Perfect Forward Secrecy (PFS)
TLS 1.2 (and earlier versions) supports static RSA and Diffie-Hellman
(DH) cipher suites, which enables the server's private key to be
shared with a TLS proxy. [RFC7525] initiated the recommendation of
using AEAD cipher suites and specifically decoupling the cipher suite
negotiation based on the RSA key transport; this followed with TLS
1.3 explicitly removing support for these cipher suites in favor of
supporting only ephemeral mode Diffie-Hellman to provide perfect
forward secrecy (PFS). As a result of this enhancement, it would no
longer be possible for a server to share a key with the middlebox in
advance, which in turn implies that the middlebox cannot gain access
to the TLS session data.ss
4.2. Encrypted Server Certificate
TLS 1.2 (and earlier versions) sends the ClientHello, ServerHello and
Certificate messages in clear-text. In TLS 1.3, the Certificate
message is encrypted whereby hiding the server identity from any
intermediary. As a result of this enhancement, it would no longer be
possible to observe the server certificate without inspection the
encrypted TLS payload.
TLS proxies which implement a selective decryption policy will need
to alter their behavior to accommodate TLS 1.3. In TLS 1.2 (and
earlier), the proxy could observe the TLS handshake till seeing the
clear text server certificate to make the decryption policy decision.
For example, a proxy may not be permitted to decrypt certain types of
traffic such as those going to a banking and health care service.
However, in TLS 1.3, the TLS proxy must participate in both
handshakes (i.e., client-to-proxy; and proxy-to-server) in order to
view the server certificate. This change will impose a slight
increase in load per connection on the proxy.
5. Security Considerations
This document presents common and existing security monitoring and This document presents common and existing security monitoring and
detection functionality and how it interacts with TLS. It further detection functionality and how it interacts with TLS. It further
notes where existing practices will have to be adjusted to remain notes where existing practices will have to be adjusted to remain
effective as these solutions transition to include TLS v1.3 effective as these solutions transition to include TLS 1.3
improvements. improvements.
These operational practices involve both good faith and malicious These operational practices involve both good faith and malicious
client applications. The former category typically exhibits client applications. The former category typically exhibits
consistently identifiable behavior and does not actively prevent any consistently identifiable behavior and does not actively prevent any
transit inspection devices from performing application identification transit inspection devices from performing application identification
for visibility and control purposes. The latter category of for visibility and control purposes. The latter category of
applications actively attempts to circumvent network security applications actively attempts to circumvent network security
controls by deliberately manipulating various protocol headers, controls by deliberately manipulating various protocol headers,
injecting specific messages, and varying payload sizes in order to injecting specific messages, and varying payload sizes in order to
avoid identification or to masquerade as a different permitted avoid identification or to masquerade as a different permitted
application. application.
6. IANA Considerations 7. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
7. Appendix A: Summary Impact to Operational Practices with TLS 1.3 8. Appendix A: Summary Impact to Operational Practices with TLS 1.3
+---------------------------------------------+-----------------------+ +---------------------------------------------+-----------------------+
| Operational Practice | Impact with TLS 1.3 | | Operational Practice | Impact with TLS 1.3 |
+---------------------------------------------+-----------------------+ +---------------------------------------------+-----------------------+
| OP-1: AUP enforcement (headers only) | reduced effectiveness | | OP-1: AUP enforcement (headers only) | reduced effectiveness |
| OP-2: Behavior analytics (headers only) | reduced effectiveness | | OP-2: Behavior analytics (headers only) | reduced effectiveness |
| OP-3: Crypto compliance monitoring (server) | reduced effectiveness | | OP-3: Crypto compliance monitoring (server) | reduced effectiveness |
| OP-4: Crypto compliance monitoring (client) | reduced effectiveness | | OP-4: Crypto compliance monitoring (client) | reduced effectiveness |
| OP-5: AUP enforcement (payload) | no capability impact | | OP-5: AUP enforcement (payload) | no capability impact |
| OP-6: Data loss prevention compliance | no capability impact | | OP-6: Data loss prevention compliance | no capability impact |
| OP-7: Granular network segmentation | no capability impact | | OP-7: Granular network segmentation | no capability impact |
skipping to change at page 15, line 26 skipping to change at page 15, line 26
| OP-10: Content Injection | no capability impact | | OP-10: Content Injection | no capability impact |
| OP-11: TLS offloading | no impact | | OP-11: TLS offloading | no impact |
| OP-12: Application load balancing | no impact | | OP-12: Application load balancing | no impact |
| OP-13: inline: Network protection (server) | no operational impact | | OP-13: inline: Network protection (server) | no operational impact |
| OP-13: oob: Network protection (server) | alternative required | | OP-13: oob: Network protection (server) | alternative required |
| OP-14: inline: Full packet capture | no operational impact | | OP-14: inline: Full packet capture | no operational impact |
| OP-14: oob: Full packet capture | alternative required | | OP-14: oob: Full packet capture | alternative required |
| OP-15: Application layer gateway | no impact | | OP-15: Application layer gateway | no impact |
+---------------------------------------------+-----------------------+ +---------------------------------------------+-----------------------+
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
skipping to change at page 16, line 14 skipping to change at page 16, line 14
[RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of [RFC8404] Moriarty, K., Ed. and A. Morton, Ed., "Effects of
Pervasive Encryption on Operators", RFC 8404, Pervasive Encryption on Operators", RFC 8404,
DOI 10.17487/RFC8404, July 2018, DOI 10.17487/RFC8404, July 2018,
<https://www.rfc-editor.org/info/rfc8404>. <https://www.rfc-editor.org/info/rfc8404>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
8.2. Informative References 9.2. Informative References
[ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, [ECH] Rescorla, E., Oku, K., Sullivan, N., and C. Wood, "TLS
"Encrypted Server Name Indication for TLS 1.3", draft- Encrypted Client Hello", draft-ietf-tls-esni-07 (work in
ietf-tls-esni-05 (work in progress), November 2019. progress), June 2020.
[NONCE_FAIL] [NONCE_FAIL]
Jovanovic, P., "Nonce-disrespecting adversaries: Practical Jovanovic, P., "Nonce-disrespecting adversaries: Practical
forgery attacks on GCM in TLS", 2016, forgery attacks on GCM in TLS", 2016,
<https://www.usenix.org/conference/woot16/workshop- <https://www.usenix.org/conference/woot16/workshop-
program/presentation/bock>. program/presentation/bock>.
[TLS_VULNERABILITY] [TLS_VULNERABILITY]
Shenefiel, C., "PRNG Failures and TLS Vulnerabilities in Shenefiel, C., "PRNG Failures and TLS Vulnerabilities in
the Wild", 2017, the Wild", 2017,
 End of changes. 39 change blocks. 
116 lines changed or deleted 123 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/