draft-ietf-opsec-ns-impact-02.txt   draft-ietf-opsec-ns-impact-03.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 29, 2021 R. Danyliw Expires: April 28, 2021 R. Danyliw
Software Engineering Institute Software Engineering Institute
R. DuToit R. DuToit
Broadcom Broadcom
July 28, 2020 October 25, 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-02 draft-ietf-opsec-ns-impact-03
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 29, 2021. This Internet-Draft will expire on April 28, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . 4
3. How TLS is used to enable Network-Based Security Solutions . 4 3. How TLS is used to enable Network-Based Security Solutions . 4
4. Changes in TLS 1.3 Relevant to Security Operations . . . . . 5 4. Changes in TLS 1.3 Relevant to Security Operations . . . . . 5
4.1. Perfect Forward Secrecy (PFS) . . . . . . . . . . . . . . 5 4.1. Perfect Forward Secrecy (PFS) . . . . . . . . . . . . . . 5
4.2. Encrypted Server Certificate . . . . . . . . . . . . . . 5 4.2. Encrypted Server Certificate . . . . . . . . . . . . . . 5
5. Network Security Operational Practices . . . . . . . . . . . 6 5. Network Security Operational Practices . . . . . . . . . . . 6
5.1. Passive TLS Inspection . . . . . . . . . . . . . . . . . 6 5.1. Passive TLS Inspection . . . . . . . . . . . . . . . . . 7
5.1.1. OP-1. Acceptable Use Policy (AUP) Enforcement (via 5.1.1. OP-1. Acceptable Use Policy (AUP) Enforcement (via
header inspection). . . . . . . . . . . . . . . . . . 7 header inspection). . . . . . . . . . . . . . . . . . 7
5.1.2. OP-2. Network Behavior Analytics . . . . . . . . . . 7 5.1.2. OP-2. Network Behavior Analytics . . . . . . . . . . 8
5.1.3. OP-3. Crypto, Security and Security Policy 5.1.3. OP-3. Crypto, Security and Security Policy
Compliance (server) . . . . . . . . . . . . . . . . . 8 Compliance (server) . . . . . . . . . . . . . . . . . 8
5.1.4. OP-4. Crypto and Security Policy Compliance (client) 8 5.1.4. OP-4. Crypto and Security Policy Compliance (client) 8
5.2. Outbound TLS Proxy . . . . . . . . . . . . . . . . . . . 9 5.2. Outbound TLS Proxy . . . . . . . . . . . . . . . . . . . 9
5.2.1. OP-5: Acceptable Use Policy (AUP) Enforcement (via 5.2.1. OP-5: Acceptable Use Policy (AUP) Enforcement (via
payload inspection) . . . . . . . . . . . . . . . . . 10 payload inspection) . . . . . . . . . . . . . . . . . 10
5.2.2. OP-6: Data Loss Prevention Compliance . . . . . . . . 10 5.2.2. OP-6: Data Loss Prevention Compliance . . . . . . . . 10
5.2.3. OP-7: Granular Network Segmentation . . . . . . . . . 10 5.2.3. OP-7: Granular Network Segmentation . . . . . . . . . 11
5.2.4. OP-8: Network-based Threat Protection (client) . . . 10 5.2.4. OP-8: Network-based Threat Protection (client) . . . 11
5.2.5. OP-9: Protecting Challenging End Points . . . . . . . 11 5.2.5. OP-9: Protecting Challenging End Points . . . . . . . 11
5.2.6. OP-10: Content Injection . . . . . . . . . . . . . . 11 5.2.6. OP-10: Content Injection . . . . . . . . . . . . . . 12
5.3. Inbound TLS Proxy . . . . . . . . . . . . . . . . . . . . 11 5.3. Inbound TLS Proxy . . . . . . . . . . . . . . . . . . . . 12
5.3.1. OP-11: TLS offloading . . . . . . . . . . . . . . . . 12 5.3.1. OP-11: TLS offloading . . . . . . . . . . . . . . . . 13
5.3.2. OP-12. Content distribution and application load 5.3.2. OP-12. Content distribution and application load
balancing . . . . . . . . . . . . . . . . . . . . . . 13 balancing . . . . . . . . . . . . . . . . . . . . . . 13
5.3.3. OP-13: Network-based Threat Protection (server) . . . 13 5.3.3. OP-13: Network-based Threat Protection (server) . . . 14
5.3.4. OP-14: Full Packet Capture . . . . . . . . . . . . . 13 5.3.4. OP-14: Full Packet Capture . . . . . . . . . . . . . 14
5.3.5. OP-15: Application Layer Gateway (ALG) . . . . . . . 14 5.3.5. OP-15: Application Layer Gateway (ALG) . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Appendix A: Summary Impact to Operational Practices with TLS 8. Appendix A: Summary Impact to Operational Practices with TLS
1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
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
and in the network; and collaborative watch-and-warning practices to and in the network; and collaborative watch-and-warning practices to
realize this defense. realize this defense.
skipping to change at page 3, line 46 skipping to change at page 3, line 46
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 1.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 1.3 the impact on these practices with improvements made in TLS 1.3
[RFC8446]. [RFC8446]. The document is not intended to endorse the use of TLS
inspection, rather it describes current practice and its implications
as observed at the time of this writing to help the IETF community
understand the perspective of network operators. The goal is to help
further the need to evolve such solutions as protocols evolve, in
particular TLS [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.
Specific operational practices are numbered as "OP-##", operational Specific operational practices are numbered as "OP-##", operational
practice 1 (i.e., OP-1), 2 (i.e., OP-2), etc. practice 1 (i.e., OP-1), 2 (i.e., OP-2), etc.
3. How TLS is used to enable Network-Based Security Solutions 3. How TLS is used to enable Network-Based Security Solutions
Network-based security solutions come in many forms, most commonly as Network-based security solutions come in many forms, most commonly as
Firewalls, Web Proxies, Intrusion Detection Systems (IDS), Intrusion Firewalls, Web Proxies, Intrusion Detection Systems (IDS), Intrusion
Prevention Systems (IPS) and Network Security Visibility and Prevention Systems (IPS) and Network Security Visibility and
Analytics systems. They inspect the network traffic, and then based Analytics systems. They inspect the network traffic, and then based
on their function, log their observation and/or act on the traffic to on their function, log their observation and/or act on the traffic to
implement security policy. When these devices act on the network implement security policy. The conditions under which TLS visibility
traffic, they are typically deployed inline as middleboxes (e.g. is required is specific to the network security vendor and deployment
firewalls) or as explicit proxies (e.g. web proxies). If their and out of scope for this document but the use of visibility and
function is only to observe, they can be deployed either as inspection are common and described herein. When these devices act
on the network traffic, they are typically deployed inline as
middleboxes (e.g. firewalls) or as explicit proxies (e.g. web
proxies).
If their function is only to observe, they can be deployed either as
middleboxes or given access to the network traffic out-of-band (OOB), middleboxes or given access to the network traffic out-of-band (OOB),
through the network fabric (e.g., network tap or span port). through the network fabric (e.g., network tap or span port).
Depending on their function, network-based security devices use Depending on their function, network-based security devices use
different degrees of visibility into the TLS traffic. Some different degrees of visibility into the TLS traffic. Some
operational practices require only access to the unencrypted protocol operational practices require only access to the unencrypted protocol
headers and associated meta-data of the TLS traffic. Other practices headers and associated meta-data of the TLS traffic. Other practices
require full visibility into the encrypted session (payload). require full visibility into the encrypted session (payload).
The practices that inspect only the unencrypted headers and meta-data The practices that inspect only the unencrypted headers and meta-data
skipping to change at page 5, line 27 skipping to change at page 5, line 37
TLS 1.2 (and earlier versions) supports static RSA and Diffie-Hellman TLS 1.2 (and earlier versions) supports static RSA and Diffie-Hellman
(DH) cipher suites, which enables the server's private key to be (DH) cipher suites, which enables the server's private key to be
shared with a TLS proxy. [RFC7525] initiated the recommendation of shared with a TLS proxy. [RFC7525] initiated the recommendation of
using AEAD cipher suites and specifically decoupling the cipher suite using AEAD cipher suites and specifically decoupling the cipher suite
negotiation based on the RSA key transport; this followed with TLS negotiation based on the RSA key transport; this followed with TLS
1.3 explicitly removing support for these cipher suites in favor of 1.3 explicitly removing support for these cipher suites in favor of
supporting only ephemeral mode Diffie-Hellman to provide perfect supporting only ephemeral mode Diffie-Hellman to provide perfect
forward secrecy (PFS). As a result of this enhancement, it would no 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 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 advance, which in turn implies that the middlebox cannot gain access
to the TLS session data.ss to the TLS session data.
4.2. Encrypted Server Certificate 4.2. Encrypted Server Certificate
TLS 1.2 (and earlier versions) sends the ClientHello, ServerHello and TLS 1.2 (and earlier versions) sends the ClientHello, ServerHello and
Certificate messages in clear-text. In TLS 1.3, the Certificate Certificate messages in clear-text. In TLS 1.3, the Certificate
message is encrypted whereby hiding the server identity from any message is encrypted whereby hiding the server identity from any
intermediary. As a result of this enhancement, it would no longer be intermediary. As a result of this enhancement, it would no longer be
possible to observe the server certificate without inspection the possible to observe the server certificate without inspection the
encrypted TLS payload. encrypted TLS payload.
 End of changes. 16 change blocks. 
27 lines changed or deleted 36 lines changed or added

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