draft-ietf-opsec-ns-impact-00.txt   draft-ietf-opsec-ns-impact-01.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: December 25, 2020 R. Danyliw Expires: January 28, 2021 R. Danyliw
Software Engineering Institute Software Engineering Institute
R. DuToit R. DuToit
Broadcom Broadcom
June 23, 2020 July 27, 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-00 draft-ietf-opsec-ns-impact-01
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 December 25, 2020. This Internet-Draft will expire on January 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
skipping to change at page 3, line 35 skipping to change at page 3, line 35
desktop systems on a modern operating system; unpatched function- desktop systems on a modern operating system; unpatched function-
specific industrial control system) specific industrial control system)
o enforce policy on a system even if it is compromised, o enforce policy on a system even if it is compromised,
misconfigured, not under configuration control or had its endpoint misconfigured, not under configuration control or had its endpoint
protection disabled protection disabled
o be managed (e.g. updates) and provisioned with resources (e.g. o be managed (e.g. updates) and provisioned with resources (e.g.
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
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 such a need 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 v1.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 v1.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",
skipping to change at page 5, line 19 skipping to change at page 5, line 23
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 relevant 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 v1.3 is categorized and explained. The categorized impacts to
practices when migrating to TLS v1.3 are as follows: practices when migrating to TLS v1.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
skipping to change at page 6, line 25 skipping to change at page 6, line 25
identity from the Common Name (CN) or Subject Alternative Name (SAN) identity from the Common Name (CN) or Subject Alternative Name (SAN)
fields of an X.509 certificate that is presented in the server's fields of an X.509 certificate that is presented in the server's
Certificate TLS message. This data is used for domain categorization Certificate TLS message. This data is used for domain categorization
or application identification. or application identification.
This meta-data can also inform decryption eligibility decisions by a This meta-data can also inform decryption eligibility decisions by a
firewall, in OP-4. For instance, a firewall may bypass traffic firewall, in OP-4. For instance, a firewall may bypass traffic
decryption for a connection destined to a healthcare web service due decryption for a connection destined to a healthcare web service due
to privacy compliance requirements. to privacy compliance requirements.
TLS 1.3 impact: reduced effectiveness. Per Section 4.2, domain TLS 1.3 considerations: reduced effectiveness. Per Section 4.2,
categorization and application identification will be limited to IP domain categorization and application identification will be limited
address and SNI information (beyond additional correlation possible to IP address and SNI information (beyond additional correlation
with other means such as DNS). possible with other means such as DNS).
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.
skipping to change at page 9, line 26 skipping to change at page 9, line 26
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 3.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. information. Note that the firewall may be implemented and enforced
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 3.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
skipping to change at page 13, line 31 skipping to change at page 13, line 31
TLS v1.3 introduces a number of protocol design changes to improve TLS v1.3 introduces a number of protocol design changes to improve
security and privacy. However, these enhancements impact current security and privacy. However, these enhancements impact current
network security operational practices that rely on the protocol network security operational practices that rely on the protocol
behavior of earlier TLS versions. behavior of earlier TLS versions.
4.1. Perfect Forward Secrecy (PFS) 4.1. Perfect Forward Secrecy (PFS)
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. TLS 1.3 has removed support for these shared with a TLS proxy. [RFC7525] initiated the recommendation of
cipher suites in favor of supporting only ephemeral mode Diffie- using AEAD cipher suites and specifically decoupling the cipher suite
Hellman to provide perfect forward secrecy (PFS). As a result of negotiation based on the RSA key transport; this followed with TLS
this enhancement, it would no longer possible for a server to share a 1.3 explicitly removing support for these cipher suites in favor of
key with the middlebox in advance, which in turn implies that the supporting only ephemeral mode Diffie-Hellman to provide perfect
middlebox cannot gain access to the TLS session data. 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 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.
skipping to change at page 14, line 4 skipping to change at page 14, line 7
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.
TLS proxies which implement a selective decryption policy will need TLS proxies which implement a selective decryption policy will need
to alter their behavior to accommodate TLS 1.3. In TLS 1.2 (and 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 earlier), the proxy could observe the TLS handshake till seeing the
clear text server certificate to make the decryption policy decision. clear text server certificate to make the decryption policy decision.
For example, a proxy may not be permitted to decrypt certain types of 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. traffic such as those going to a banking and health care service.
However, in TLS 1.3, the TLS proxy must participate in both 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 handshakes (i.e., client-to-proxy; and proxy-to-server) in order to
view the server certificate. This change will impose a slight view the server certificate. This change will impose a slight
increase in load per connection on the proxy. increase in load per connection on the proxy.
5. Security Considerations 5. Security Considerations
This entire document discusses security considerations in existing This document presents common and existing security monitoring and
operational security practices interacting with TLS. It notes where detection functionality and how it interacts with TLS. It further
existing practices will have to be adjusted to remain effective due notes where existing practices will have to be adjusted to remain
to TLS v1.3 improvements. effective as these solutions transition to include TLS v1.3
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
skipping to change at page 15, line 40 skipping to change at page 15, line 40
[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>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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
 End of changes. 13 change blocks. 
22 lines changed or deleted 35 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/