OPSEC Working Group E. Wang
Internet-Draft A. Ossipov
Intended status: Informational Cisco Systems, Inc.
Expires: May 7, 2020 R. DuToit
Symantec
November 04, 2019
TLS Proxy Best Practice
draft-wang-tls-proxy-best-practice-00
Abstract
TLS proxies are widely deployed by organizations to enable security
features and apply enterprise policies. This document defines a TLS
proxy and discusses a wide range of security requirements to guide
TLS proxy implementations.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 7, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
Wang, et al. Expires May 7, 2020 [Page 1]
Internet-Draft tlsp-bp November 2019
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Security and Privacy Requirements . . . . . . . . . . . . . . 4
4.1. Securely provision within the administrative domain . . . 4
4.2. Maintain security posture and limit modifications . . . . 5
4.3. Be secure by default . . . . . . . . . . . . . . . . . . 6
4.4. Use independent key material . . . . . . . . . . . . . . 6
4.5. Protect against known vulnerabilities . . . . . . . . . . 6
4.6. Detect and propagate protocol version downgrade markers . 7
4.7. Implement special measures to handle session resumption . 7
4.8. Adapt to protocol changes . . . . . . . . . . . . . . . . 8
4.9. Respect regulations and privacy . . . . . . . . . . . . . 8
4.10. Respect sensitivity of decrypted payload . . . . . . . . 8
4.11. Enforce certificate validation standards . . . . . . . . 8
4.12. Provide a secure operating environment . . . . . . . . . 9
5. Usability and Functional Requirements . . . . . . . . . . . . 9
5.1. Provide the ability to enforce policy without intercept . 9
5.2. Selectively decrypt based on policy . . . . . . . . . . . 10
5.3. Limit performance impact . . . . . . . . . . . . . . . . 11
6. Security & Privacy Considerations . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
A TLS proxy refers to a set of network functions and products that
intercept TLS sessions per an organizational security policy. A TLS
proxy is deployed between endpoints such as TLS clients and servers.
Based on an organizational policy, it may proxy a TLS handshake by
terminating it on the client side and starting a new handshake with
the server. As a result, the TLS proxy is able to decrypt the
traffic from each side of the TLS session for various purposes, and
then optionally re-encrypt the traffic before forwarding it to the
other side of the session. A TLS proxy may leverage the session
handshake information as well as decrypted traffic data to satisfy
organization's policy requirements.
Wang, et al. Expires May 7, 2020 [Page 2]
Internet-Draft tlsp-bp November 2019
+---------------------------+
| Application Stack |
+---------------------------+
...............................
+------------+ . +----------+-----+----------+ . +------------+
| | . | | | | . | |
| | . |TLS Server|Proxy|TLS Client| . | |
| TLS CLIENT |-------| Stack | | Stack |--------| TLS SERVER |
| | . | | | | . | |
| | . +----------+-----+----------+ . | |
+------------+ . TLS PROXY . +------------+
...............................
+---------------------------+
| Network Stack |
+---------------------------+
Figure 1: TLS Proxy
Industrial and academic studies have been conducted on TLS proxies
and the associated benefits and risks [SECURITY_IMPACT]
[APPLIANCE_ANALYSIS] [PROXY_DETECTION]. Readers are encouraged to
refer to those studies to better understand the trade-offs in the
design, implementation and deployment of a TLS proxy.
This document does not attempt to establish a position on whether a
TLS proxy is "good" or "bad". However, it is important to have a
clear set of requirements for a TLS proxy implementation, given its
sensitive nature with regards to the TLS client and server data being
intercepted, and the fact that many vendors and providers have
offered such functions to their customers.
This document specifies such requirements and best practices for
implementing TLS proxy functions. Discussions and guidelines in this
document cover proxy for TLS 1.3 [RFC8446] and earlier versions (e.g.
[RFC5246]).
A detailed explanation of use cases and functions utilizing TLS proxy
can be found in [TLS_IMPACT]*. This document does not address any
malicious use of the proxy techniques. However, readers would be
able to benefit from the discussion for a better understanding and
mitigation against unintentional or deliberate misuse. Last but not
least, we acknowledge that some of the problems that a TLS proxy
solves can be addressed through other methods; however, this document
assumes that the reader has already made an implementation decision
to pursue a TLS proxy network function.
* (Editor's note: Update the reference to draft-camwinget-tls-proxy-
impact)
Wang, et al. Expires May 7, 2020 [Page 3]
Internet-Draft tlsp-bp November 2019
2. Conventions and Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3. Terminology
We adopt the following definitions for TLS proxy deployments in the
network.
An outbound TLS proxy serves a scenario where a device that performs
the TLS proxy function is in the same administrative domain as the
TLS client, and the TLS server is located in an external zone such as
the Internet. Usually the goal is to protect the client endpoint and
the organization by controlling application behaviors and enforcing
an acceptable use policy for the organizational network.
An inbound TLS proxy is deployed in front of one or a set of
application services. A network device that implements the TLS proxy
function is located in the same administrative domain as the
application which provides a network service to clients. Usually it
is not predictable or controllable which TLS client would initiate a
connection.
4. Security and Privacy Requirements
A TLS proxy acts as both a TLS server (to the TLS client) and a TLS
client (to the TLS server). Its design MUST abide by the general TLS
server and client endpoint requirements. This section does not
repeat the requirements from [RFC8446] and [RFC5246], and assumes
full compliance with those TLS RFCs. Instead, it highlights those
specific to the proxy behavior.
4.1. Securely provision within the administrative domain
The TLS proxy MUST be provisioned as a trusted party for the TLS
client. It MAY also be provisioned as a trusted party for the
server. In most cases, only the client side needs to be provisioned
for TLS server authentication, excluding TLS applications that use
client certificate authentication.
During a TLS handshake, the proxy needs to supply a certificate on
behalf of the server with the same identity (e.g. subjectAltName) as
the server. This is to ensure the same client-side experience while
the proxy negotiates a session with the client.
Wang, et al. Expires May 7, 2020 [Page 4]
Internet-Draft tlsp-bp November 2019
For the outbound TLS proxy scenario, the administrator has no control
of the TLS server side since it is typically outside of their
administrative domain. The administrator may provision an enterprise
CA certificate on each client, either into the shared trust store of
the operating system or individual applications, such as a web
browser; describing a specific provisioning process falls outside of
the scope of this document.
The proxy uses the CA certificate to issue a proxy certificate for
each of the unique TLS servers that are accessed through it. Once
the proxy generates a certificate on behalf of a particular server,
these are typically cached locally and re-used for connections to the
same server for some period of time. It has to be noted that this
scenario does not work if the application uses client certificate
authentication or if the client obtains and stores the actual
server's public key and the corresponding certificate through a
network path that does not include the TLS proxy in question (a.k.a.
certificate pinning); in those cases, the proxy SHOULD be able to
either block the connection or bypass decryption based on a
configured policy.
Provisioning for inbound TLS proxy is much more straightforward. The
administrator may export servers' certificates with private keys and
import them into the proxy. Alternatively, the proxy may need to
periodically retrieve server key pairs and corresponding certificates
from a shared secure repository (e.g. an HSM). Frequent server key
rotation helps to minimize security exposure if a participating TLS
proxy device is compromised. The proxy may also enroll for a
certificate on behalf of the server. Once the proxy has been
provisioned, the TLS client will be able to complete TLS handshakes
with the server through the TLS proxy.
4.2. Maintain security posture and limit modifications
Because a TLS proxy effectively builds two TLS sessions, one with a
TLS client and one with a server respectively, the two sessions MUST
maintain the same or higher level security posture (such as using
stronger ciphers) than the direct session between the client and the
server. The TLS server and client stacks in the TLS proxy MUST be
conformant to [RFC8446] and [RFC5246].
The proxy MAY remove cipher suites from a client-initiated Client
Hello message, add new cipher suites, and re-order them in the proxy-
initiated Client Hello message. The purpose may be to increase the
security posture of the combined sessions by removing weak cipher
suites, or to optimize decryption and encryption performance (e.g.
due to hardware acceleration capabilities), or from other business
Wang, et al. Expires May 7, 2020 [Page 5]
Internet-Draft tlsp-bp November 2019
policy criteria. These changes MUST NOT negatively impact the
security posture of the session.
TLS proxy stacks MAY provide user configurable options, such as an
option to accept self-signed server certificates, an option to let
the handshake continue with expired but otherwise valid server
certificates, etc. However, the administrator MUST be provided with
full information about any associated risks, such as from accepting a
self-signed server certificate. The administrator MUST have complete
control over the use of such options.
4.3. Be secure by default
The TLS proxy configuration and policy should be secure by default.
The configuration of a TLS proxy requires special knowledge, and few
users have the skillset to do it securely and correctly. TLS proxy
vendors SHOULD educate users and TLS proxy developers SHOULD
anticipate areas of configuration that could potentially create
confusion. TLS proxy developers SHOULD simplify decisions that a
user must make as long as sufficient configuration flexibility is
maintained. A product that implements a TLS proxy MUST also provide
default configuration settings that guarantee a high level of
security. Configuration choices that deviate from the secure
defaults SHOULD be presented alongside clear explanations of the
impact of each option.
4.4. Use independent key material
The server and client sides of a TLS stack in a TLS proxy MUST
negotiate key material independently. The proxy MUST NOT reuse and
propagate key material or nonces received from the TLS client or the
server. The TLS proxy MUST NOT inadvertently reuse the same random
values for different TLS sessions; for example, the random generator
MUST be fork-safe.
4.5. Protect against known vulnerabilities
Malicious entities rapidly exploit vulnerabilities in applications
and protocols. TLS proxy vendors, and the developers in particular,
SHOULD actively track vulnerabilities and respond with fixes in a
timely manner. Issues in TLS stack implementations, or the TLS
protocol itself, usually have far-reaching implications because other
applications depend on the confidentiality, authentication, and data
integrity properties of TLS. TLS proxy developers should go beyond
just reading technical news articles, and should also follow
discussions about current and future TLS related standards, track
changes in open source TLS stacks as well as major open source TLS
endpoint applications (e.g., Chrome, Firefox), and be familiar with
Wang, et al. Expires May 7, 2020 [Page 6]
Internet-Draft tlsp-bp November 2019
application level protocols, especially in the context of how
endpoint applications integrate with the TLS protocol.
4.6. Detect and propagate protocol version downgrade markers
An in-path attacker may downgrade a TLS session to a protocol version
lower than what is supported by both endpoints in order to exploit
some known vulnerability in the lower version. The recommended
downgrade protection mechanism for TLS 1.2 is the TLS_FALLBACK_SCSV,
as described in [RFC7507]. The TLS 1.3 downgrade detection mechanism
in [RFC8446] utilizes markers in the Server Hello random field. A
TLS proxy MUST implement both mechanisms, correctly process downgrade
markers sent by [RFC8446] compliant TLS servers, and be able to
generate such markers toward a compliant TLS client.
The TLS proxy MUST ignore the TLS 1.3 downgrade marker if it has
generated a TLS 1.2 ClientHello. Similarly, if the TLS proxy prefers
to generate a TLS 1.2 ServerHello, it MUST include the TLS 1.3
downgrade marker in response to a TLS 1.2 ClientHello, and it MUST
NOT include the marker in response to a TLS 1.3 ClientHello.
4.7. Implement special measures to handle session resumption
If a TLS client attempts to resume a TLS session with an identifier
(ID/ticket/PSK) that is not known to the TLS proxy then the TLS proxy
MUST NOT indiscriminately exempt those sessions from decryption. At
a minimum, the TLS proxy SHOULD enforce a configured policy for such
sessions, and SHOULD preferably ignore the resumption attempt and use
a full TLS handshake instead.
Should a TLS client use another network path to the TLS server, or
should the TLS proxy be removed from its on-path network position
then TLS session resumption attempts using TLS key material
previously negotiated between the TLS client and TLS proxy SHOULD NOT
result in TLS session resumption failures on the TLS server.
Applications that send TLS 1.3 early data rely on specific knowledge
about the security properties of said payload. A TLS proxy most
likely does not have access to the application level security
properties of the payload, which implies that the TLS proxy MUST NOT
inadvertently upgrade the security properties of early data received
from the TLS client by forwarding it to the TLS server as post-
handshake payload. The TLS proxy upper network stack SHOULD take
into account the security properties of the decrypted early data as
part of payload processing.
Wang, et al. Expires May 7, 2020 [Page 7]
Internet-Draft tlsp-bp November 2019
4.8. Adapt to protocol changes
The TLS proxy SHOULD be able to identify the start of a new TLS
handshake. The static approach is through a pre-configured list of
destination ports such as 443, 8443, etc. Dynamic approaches include
parsing the application layer protocols to identify the STARTTLS
message, and using signatures to identify TLS handshake messages.
Those functions MAY be provided by the underlying platform, not part
of the TLS proxy implementation. However, the TLS proxy MUST conduct
proper TLS protocol checks to avoid false identification of TLS
handshakes, while taking special care not to contribute to protocol
ossification.
4.9. Respect regulations and privacy
Due to the privileged network location of the TLS proxy it
potentially has access to a user's PII (Personally identifiable
information) and PHI (Protected Health Information). The TLS proxy
MUST act responsibly to protect the privacy of the user and SHOULD
allow masking of PII by all the security tools that touch the
decrypted payload. A product implementing TLS proxy SHOULD also
allow to limit interception of certain categories of data, which
could include evaluation of risk level and geolocation.
4.10. Respect sensitivity of decrypted payload
The TLS proxy SHOULD, similarly to respecting privacy and
regulations, respect the sensitivity of the decrypted payload.
Unless specifically required by an upper-level function per the
organizational security policy, the decrypted payload MUST NOT be
stored on the product that implements TLS proxy beyond lifetime of
the TLS session. The decrypted data SHOULD be securely destroyed
upon completing any necessary inspection functions of that particular
application message. The TLS proxy SHOULD also provide an option
that guarantees that changes to decrypted content are not propagated
to the endpoints, which would limit the impact of misbehaving upper-
level functions while also simplifying compliance with regulations.
4.11. Enforce certificate validation standards
A TLS proxy MUST maintain a local certificate truststore populated
with well-known public CA certificates. It MUST allow an
administrator to populate this store with locally trusted
certificates or remove an existing certificate from the store. The
proxy MUST validate a presented server's X.509 certificate against
this trust store according to [RFC5280], including but not limited to
validating the certificate path and checking the stated validity
range.
Wang, et al. Expires May 7, 2020 [Page 8]
Internet-Draft tlsp-bp November 2019
The TLS proxy MAY also validate the certificate against a locally
configured or specified Certificate Revocation List (CRL) repository,
and MAY also use online status checking as specified in [RFC6960].
The TLS proxy SHOULD favor in-band OCSP over the out-of-band
[RFC6960] mechanism, as specified in [RFC6066] and [RFC8446]. The
TLS proxy SHOULD provide an option to configure a policy for handling
certificate validation failures and specifying exceptions.
Client applications, especially browsers, also validate a server name
against names listed in the presented X.509 certificate. TLS proxies
SHOULD follow the guidelines in [RFC6125] and MAY provide an option
to enforce checks that would prevent look-alike (e.g. Cyrillic)
international domain names from spoofing legitimate domain names.
4.12. Provide a secure operating environment
As a single device in the network that can decrypt encrypted
transmissions, the TLS proxy would be a high value target for a bad
actor. Therefore, a device implementing the TLS proxy function MUST
provide a secure environment. It MUST comply with any organizational
product security baseline requirements to achieve a high level of
product integrity and trust. While an exact list of such product
requirements may vary from implementer to implementer and lies
outside of the scope of this document, some commonly acceptable
protection elements include: * Hardware and software authenticity
attestation (Secure Boot) * Digitally signed software images and
configuration files * Utilize a hardware security module, such as
Trusted Platform Module (TPM), when appropriate and available * No
predefined authentication credential (password, certificates, keys) *
Secure storage of keys, passwords, and other sensitive data * Use
well-established and validated cryptographic libraries * Use an
effective random number generator [RFC4086]
5. Usability and Functional Requirements
5.1. Provide the ability to enforce policy without intercept
A TLS proxy MAY facilitate an ability to enforce security policies
without the need for intercepting the handshake. Examples are deny
or blacklist policies based on an observed SNI, cipher suites and
certificates exchanged during the handshake (when in the clear).
The TLS proxy MUST use caution when applying security policies other
than deny or blacklist based on the TLS handshake information. The
TLS proxy SHOULD NOT use the handshake information for permit,
whitelist, or security exemptions. This is because the information
from the handshake may not accurately reflect actual intentions or
content carried in the encrypted session.
Wang, et al. Expires May 7, 2020 [Page 9]
Internet-Draft tlsp-bp November 2019
Even if not intercepting the session, the TLS proxy SHOULD passively
observe the handshake until its successful completion before acting
on the data from the handshake. By doing so, the TLS proxy avoids
acting on data that may be spoofed, such as SNI.
Completion of a TLS handshake does not guarantee the information
observed is trustworthy. A typical example is non-conformant or
colluding TLS clients and servers that do not enforce an SNI
extension to match the actual resource that is being accessed. The
TLS client may use an SNI that passes a Fully Qualified Domain Name
(FQDN) reputation check, while the TLS server ignores the SNI and
sends malicious content to the colluding client.
SNI is not a trustworthy policy information element even with
conformant TLS servers. A TLS client may deliberately set the SNI
with a host name with "good enough" reputation. If the TLS proxy
relies solely on the SNI for its access policy decision, it may allow
the handshake to go through based on the reputation score of the host
name. Because [RFC6066] does not mandate a TLS server to abort the
handshake when the server does not recognize the server name, the
handshake may continue with the server sending a certificate that
contains the real CN with a low reputation. Finally, because the
client is non-conformant, it will finish the handshake and proceed
with accessing the "bad" host. This scenario applies even if the SNI
is encrypted by the TLS client ([ESNI]).
5.2. Selectively decrypt based on policy
A TLS proxy SHOULD be able to make policy decisions on whether to
decrypt a particular session or not. Such a policy is referred to as
"decryption policy". Decryption policy allows the TLS proxy to
selectively decrypt certain sessions while exempting others, for
efficiency, privacy and compliance considerations.
A decryption policy decision MAY be made based on the server
certificate or other trustworthy parameters. To verify possession of
private keys that are associated with a particular server
certificate, the proxy SHOULD complete an out-of-band TLS handshake
with the same TLS server IP address and TCP port as targeted by the
TLS client.
A decryption policy decision MUST NOT be made solely based on an SNI
extension for reasons discussed in the previous section.
The TLS Proxy SHOULD provide a configurable option for how to handle
sessions that it is not able to decrypt.
Wang, et al. Expires May 7, 2020 [Page 10]
Internet-Draft tlsp-bp November 2019
The TLS proxy MUST be able to disengage from a proxy session and
allow the TLS client and server to negotiate a new session directly.
A use case is to avoid decryption of certain types of traffic such as
banking, as required by privacy laws.
There are several points where the TLS proxy can make a "not-to-
decrypt" or "disengagement" decision. The decision MAY be made based
on identifying the server by its IP address or the certificate or
other techniques. In any of the cases, the user on the client side
SHOULD NOT experience any disruption (e.g. a "connection lost"
error).
5.3. Limit performance impact
A TLS proxy SHOULD limit the impact of its functionality on network
throughput, latency and jitter. Algorithm selection should be driven
by security as well as performance, such as using X25519 as a named
curve in the calculation of a TLS 1.3 Client Hello key_share value.
TLS proxies SHOULD cache locally issued server certificates for a
period of time in order to service similar sessions without the
additional performance impact from re-issuing the certificate. A
specific timeout for certificate cache entries MUST be configurable
by the TLS proxy administrator.
6. Security & Privacy Considerations
This document is about security related requirements for TLS proxy
implementations. A TLS proxy by itself is not a security function.
However, it enables organizations to apply security functions and
enforce organizational policy on the traffic. In that sense, the TLS
proxy is part of an integrated security solution. Implementations
must satisfy the requirements described in this document to achieve
this goal.
This document also lays out privacy requirements for TLS proxy
implementations. A TLS proxy does not introduce new or modify
existing TLS protocols that would change the privacy posture of the
protocols. Many of the security practices described in this
document, for example, decrypted data handling, help ensure that TLS
proxy does not weaken the privacy posture of the overall system.
7. IANA Considerations
This document has no IANA actions.
Wang, et al. Expires May 7, 2020 [Page 11]
Internet-Draft tlsp-bp November 2019
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
DOI 10.17487/RFC4086, June 2005,
<https://www.rfc-editor.org/info/rfc4086>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<https://www.rfc-editor.org/info/rfc6960>.
[RFC7507] Moeller, B. and A. Langley, "TLS Fallback Signaling Cipher
Suite Value (SCSV) for Preventing Protocol Downgrade
Attacks", RFC 7507, DOI 10.17487/RFC7507, April 2015,
<https://www.rfc-editor.org/info/rfc7507>.
Wang, et al. Expires May 7, 2020 [Page 12]
Internet-Draft tlsp-bp November 2019
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
8.2. Informative References
[APPLIANCE_ANALYSIS]
Waked, L., Mannan, M., and A. Youssef, "To Intercept or
Not to Intercept: Analyzing TLS Interception in Network
Appliances", 2018,
<https://users.encs.concordia.ca/~mmannan/publications/
enterprise-interception-asiaccs2018.pdf>.
[ESNI] Rescorla, E., Oku, K., Sullivan, N., and C. Wood,
"Encrypted Server Name Indication for TLS 1.3", draft-
ietf-tls-esni-04 (work in progress), July 2019.
[PROXY_DETECTION]
O'Neill, M., Ruoti, S., Seamons, K., and D. Zappala, "TLS
Proxies: Friend or Foe?", 2016,
<https://isrl.byu.edu/pubs/imc2016.pdf>.
[SECURITY_IMPACT]
Durumeric, Z., Ma, Z., Springall, D., Barnes, R.,
Sullivan, N., Bursztein, E., Bailey, M., Halderman, J.,
and V. Paxson, "The Security Impact of HTTPS
Interception", 2017, <https://www.ndss-symposium.org/wp-
content/uploads/2017/09/
ndss2017_04A-4_Durumeric_paper_0.pdf>.
[TLS_IMPACT]
Andreasen, F., Cam-Winget, N., and E. Wang, "TLS 1.3
Impact on Network-Based Security", draft-camwinget-tls-
use-cases-05 (work in progress), July 2019.
Acknowledgments
The authors thank Bill Hudson for his contributions. The authors
thank Flemming Andreasen, Richard Barnes, Nancy Cam-Winget, Jay Iyer,
James Kasper and David McGrew for their comments.
Wang, et al. Expires May 7, 2020 [Page 13]
Internet-Draft tlsp-bp November 2019
Authors' Addresses
Eric Wang
Cisco Systems, Inc.
3550 Cisco Way
San Jose, CA 95134
USA
Email: ejwang@cisco.com
Andrew Ossipov
Cisco Systems, Inc.
3550 Cisco Way
San Jose, CA 95134
USA
Email: aossipov@cisco.com
Roelof DuToit
Symantec
Email: r@nerd.ninja
Wang, et al. Expires May 7, 2020 [Page 14]