draft-ietf-taps-transport-security-11.txt | draft-ietf-taps-transport-security-12.txt | |||
---|---|---|---|---|
Network Working Group T. Enghardt | Network Working Group T. Enghardt | |||
Internet-Draft TU Berlin | Internet-Draft TU Berlin | |||
Intended status: Informational T. Pauly | Intended status: Informational T. Pauly | |||
Expires: 6 September 2020 Apple Inc. | Expires: 25 October 2020 Apple Inc. | |||
C. Perkins | C. Perkins | |||
University of Glasgow | University of Glasgow | |||
K. Rose | K. Rose | |||
Akamai Technologies, Inc. | Akamai Technologies, Inc. | |||
C.A. Wood, Ed. | C.A. Wood | |||
Apple Inc. | Cloudflare | |||
5 March 2020 | 23 April 2020 | |||
A Survey of the Interaction Between Security Protocols and Transport | A Survey of the Interaction Between Security Protocols and Transport | |||
Services | Services | |||
draft-ietf-taps-transport-security-11 | draft-ietf-taps-transport-security-12 | |||
Abstract | Abstract | |||
This document provides a survey of commonly used or notable network | This document provides a survey of commonly used or notable network | |||
security protocols, with a focus on how they interact and integrate | security protocols, with a focus on how they interact and integrate | |||
with applications and transport protocols. Its goal is to supplement | with applications and transport protocols. Its goal is to supplement | |||
efforts to define and catalog transport services by describing the | efforts to define and catalog transport services by describing the | |||
interfaces required to add security protocols. This survey is not | interfaces required to add security protocols. This survey is not | |||
limited to protocols developed within the scope or context of the | limited to protocols developed within the scope or context of the | |||
IETF, and those included represent a superset of features a Transport | IETF, and those included represent a superset of features a Transport | |||
skipping to change at page 1, line 45 ¶ | skipping to change at page 1, line 45 ¶ | |||
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 6 September 2020. | This Internet-Draft will expire on 25 October 2020. | |||
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 (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
and restrictions with respect to this document. Code Components | and restrictions with respect to this document. Code Components | |||
extracted from this document must include Simplified BSD License text | extracted from this document must include Simplified BSD License text | |||
as described in Section 4.e of the Trust Legal Provisions and are | as described in Section 4.e of the Trust Legal Provisions and are | |||
provided without warranty as described in the Simplified BSD License. | provided without warranty as described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
3. Transport Security Protocol Descriptions . . . . . . . . . . 6 | 3. Transport Security Protocol Descriptions . . . . . . . . . . 6 | |||
3.1. Application Payload Security Protocols . . . . . . . . . 6 | 3.1. Application Payload Security Protocols . . . . . . . . . 7 | |||
3.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 3.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.1.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.1.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
3.2. Application-Specific Security Protocols . . . . . . . . . 7 | 3.2. Application-Specific Security Protocols . . . . . . . . . 8 | |||
3.2.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . 7 | 3.2.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.3. Transport-Layer Security Protocols . . . . . . . . . . . 7 | 3.3. Transport-Layer Security Protocols . . . . . . . . . . . 8 | |||
3.3.1. IETF QUIC . . . . . . . . . . . . . . . . . . . . . . 8 | 3.3.1. IETF QUIC . . . . . . . . . . . . . . . . . . . . . . 8 | |||
3.3.2. Google QUIC . . . . . . . . . . . . . . . . . . . . . 8 | 3.3.2. Google QUIC . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.3.3. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . 8 | 3.3.3. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.3.4. MinimalT . . . . . . . . . . . . . . . . . . . . . . 8 | 3.3.4. MinimaLT . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.3.5. CurveCP . . . . . . . . . . . . . . . . . . . . . . . 8 | 3.3.5. CurveCP . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
3.4. Packet Security Protocols . . . . . . . . . . . . . . . . 9 | 3.4. Packet Security Protocols . . . . . . . . . . . . . . . . 9 | |||
3.4.1. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . 9 | 3.4.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.4.2. WireGuard . . . . . . . . . . . . . . . . . . . . . . 9 | 3.4.2. WireGuard . . . . . . . . . . . . . . . . . . . . . . 10 | |||
3.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 9 | 3.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
4. Transport Dependencies . . . . . . . . . . . . . . . . . . . 9 | 4. Transport Dependencies . . . . . . . . . . . . . . . . . . . 10 | |||
4.1. Reliable Byte-Stream Transports . . . . . . . . . . . . . 10 | 4.1. Reliable Byte-Stream Transports . . . . . . . . . . . . . 10 | |||
4.2. Unreliable Datagram Transports . . . . . . . . . . . . . 10 | 4.2. Unreliable Datagram Transports . . . . . . . . . . . . . 11 | |||
4.2.1. Datagram Protocols with Defined Byte-Stream | 4.2.1. Datagram Protocols with Defined Byte-Stream | |||
Mappings . . . . . . . . . . . . . . . . . . . . . . 11 | Mappings . . . . . . . . . . . . . . . . . . . . . . 11 | |||
4.3. Transport-Specific Dependencies . . . . . . . . . . . . . 11 | 4.3. Transport-Specific Dependencies . . . . . . . . . . . . . 12 | |||
5. Application Interface . . . . . . . . . . . . . . . . . . . . 11 | 5. Application Interface . . . . . . . . . . . . . . . . . . . . 12 | |||
5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 12 | 5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 12 | |||
5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 14 | 5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 15 | |||
5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 15 | 5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 16 | |||
5.4. Summary of Interfaces Exposed by Protocols . . . . . . . 16 | 5.4. Summary of Interfaces Exposed by Protocols . . . . . . . 17 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 | |||
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 | |||
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 18 | 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
10. Informative References . . . . . . . . . . . . . . . . . . . 18 | 10. Informative References . . . . . . . . . . . . . . . . . . . 19 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
1. Introduction | 1. Introduction | |||
Services and features provided by transport protocols have been | Services and features provided by transport protocols have been | |||
cataloged in [RFC8095]. This document supplements that work by | cataloged in [RFC8095]. This document supplements that work by | |||
surveying commonly used and notable network security protocols, and | surveying commonly used and notable network security protocols, and | |||
identifying the interfaces between these protocols and both transport | identifying the interfaces between these protocols and both transport | |||
protocols and applications. It examines Transport Layer Security | protocols and applications. It examines Transport Layer Security | |||
(TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google | (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google | |||
QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating | QUIC (gQUIC), tcpcrypt, Internet Protocol Security (IPsec), Secure | |||
Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, | Real-time Transport Protocol (SRTP) with DTLS, WireGuard, CurveCP, | |||
CurveCP, and MinimalT. For each protocol, this document provides a | and MinimaLT. For each protocol, this document provides a brief | |||
brief description. Then, it describes the interfaces between these | description. Then, it describes the interfaces between these | |||
protocols and transports in Section 4 and the interfaces between | protocols and transports in Section 4 and the interfaces between | |||
these protocols and applications in Section 5. | these protocols and applications in Section 5. | |||
Selected protocols represent a superset of functionality and features | A Transport Services system exposes an interface for applications to | |||
a Transport Services system may need to support, both internally and | access various (secure) transport protocol features. The security | |||
externally (via an API) for applications [I-D.ietf-taps-arch]. | protocols included in this survey represent a superset of | |||
Ubiquitous IETF protocols such as (D)TLS, as well as non-standard | functionality and features a Transport Services system may need to | |||
protocols such as gQUIC, are both included despite overlapping | support, both internally and externally (via an API) for applications | |||
features. As such, this survey is not limited to protocols developed | [I-D.ietf-taps-arch]. Ubiquitous IETF protocols such as (D)TLS, as | |||
within the scope or context of the IETF. Outside of this candidate | well as non-standard protocols such as gQUIC, are included despite | |||
set, protocols that do not offer new features are omitted. For | overlapping features. As such, this survey is not limited to | |||
example, newer protocols such as WireGuard make unique design choices | protocols developed within the scope or context of the IETF. Outside | |||
that have implications and limitations on application usage. In | of this candidate set, protocols that do not offer new features are | |||
contrast, protocols such as ALTS [ALTS] are omitted since they do not | omitted. For example, newer protocols such as WireGuard make unique | |||
provide interfaces deemed unique. | design choices that have implications for and limitations on | |||
application usage. In contrast, protocols such as SSH [RFC4253], GRE | ||||
[RFC2890], L2TP [RFC5641], and ALTS [ALTS] are omitted since they do | ||||
not provide interfaces deemed unique. | ||||
Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH | Authentication-only protocols such as TCP-AO [RFC5925] and IPsec | |||
[RFC4302] are excluded from this survey. TCP-AO adds authenticity | Authentication Header (AH) [RFC4302] are excluded from this survey. | |||
protections to long-lived TCP connections, e.g., replay protection | TCP-AO adds authentication to long-lived TCP connections, e.g., | |||
with per-packet Message Authentication Codes. (This protocol | replay protection with per-packet Message Authentication Codes. | |||
obsoletes TCP MD5 "signature" options specified in [RFC2385].) One | (TCP-AO obsoletes TCP MD5 "signature" options specified in | |||
prime use case of TCP-AO is for protecting BGP connections. | [RFC2385].) One primary use case of TCP-AO is for protecting BGP | |||
Similarly, AH adds per-datagram authenticity and adds similar replay | connections. Similarly, AH adds per-datagram authentication and | |||
protection. Despite these improvements, neither protocol sees | integrity, along with replay protection. Despite these improvements, | |||
general use and both lack critical properties important for emergent | neither protocol sees general use and both lack critical properties | |||
transport security protocols: confidentiality, privacy protections, | important for emergent transport security protocols, such as | |||
and agility. Such protocols are thus omitted from this survey. | confidentiality and privacy protections. Such protocols are thus | |||
omitted from this survey. | ||||
This document only surveys point-to-point protocols; multicast | ||||
protocols are out of scope. | ||||
1.1. Goals | 1.1. Goals | |||
This survey is intended to help identify the most common interface | This survey is intended to help identify the most common interface | |||
surfaces between security protocols and transport protocols, and | surfaces between security protocols and transport protocols, and | |||
between security protocols and applications. | between security protocols and applications. | |||
One of the goals of Transport Services is to define a common | One of the goals of the Transport Services effort is to define a | |||
interface for using transport protocols that allows software using | common interface for using transport protocols that allows software | |||
transport protocols to easily adopt new protocols that provide | using transport protocols to easily adopt new protocols that provide | |||
similar feature-sets. The survey of the dependencies security | similar feature-sets. The survey of the dependencies security | |||
protocols have upon transport protocols can guide implementations in | protocols have upon transport protocols can guide implementations in | |||
determining which transport protocols are appropriate to be able to | determining which transport protocols are appropriate to be able to | |||
use beneath a given security protocol. For example, a security | use beneath a given security protocol. For example, a security | |||
protocol that expects to run over a reliable stream of bytes, like | protocol that expects to run over a reliable stream of bytes, like | |||
TLS, restrict the set of transport protocols that can be used to | TLS, restricts the set of transport protocols that can be used to | |||
those that offer a reliable stream of bytes. | those that offer a reliable stream of bytes. | |||
Defining the common interfaces that security protocols provide to | Defining the common interfaces that security protocols provide to | |||
applications also allows interfaces to be designed in a way that | applications also allows interfaces to be designed in a way that | |||
common functionality can use the same APIs. For example, many | common functionality can use the same APIs. For example, many | |||
security protocols that provide authentication let the application be | security protocols that provide authentication let the application be | |||
involved in peer identity validation. Any interface to use a secure | involved in peer identity validation. Any interface to use a secure | |||
transport protocol stack thus needs to allow applications to perform | transport protocol stack thus needs to allow applications to perform | |||
this action during connection establishment. | this action during connection establishment. | |||
skipping to change at page 4, line 45 ¶ | skipping to change at page 5, line 13 ¶ | |||
consideration. | consideration. | |||
It is not a goal to allow software implementations to automatically | It is not a goal to allow software implementations to automatically | |||
switch between different security protocols, even where their | switch between different security protocols, even where their | |||
interfaces to transport and applications are equivalent. Even | interfaces to transport and applications are equivalent. Even | |||
between versions, security protocols have subtly different guarantees | between versions, security protocols have subtly different guarantees | |||
and vulnerabilities. Thus, any implementation needs to only use the | and vulnerabilities. Thus, any implementation needs to only use the | |||
set of protocols and algorithms that are requested by applications or | set of protocols and algorithms that are requested by applications or | |||
by a system policy. | by a system policy. | |||
Different security protocols also can use incompatible notions of | ||||
peer identity and authentication, and cryptographic options. It is | ||||
not a goal to identify a common set of representations for these | ||||
concepts. | ||||
The protocols surveyed in this document represent a superset of | ||||
functionality and features a Transport Services system may need to | ||||
support. It does not list all transport protocols that a Transport | ||||
Services system may need to implement, nor does it mandate that a | ||||
Transport Service system implement any particular protocol. | ||||
A Transport Services system may implement any secure transport | ||||
protocol that provides the described features. In doing so, it may | ||||
need to expose an interface to the application to configure these | ||||
features. | ||||
2. Terminology | 2. Terminology | |||
The following terms are used throughout this document to describe the | The following terms are used throughout this document to describe the | |||
roles and interactions of transport security protocols: | roles and interactions of transport security protocols (some of which | |||
are also defined in [RFC8095]): | ||||
* Transport Feature: a specific end-to-end feature that the | * Transport Feature: a specific end-to-end feature that the | |||
transport layer provides to an application. Examples include | transport layer provides to an application. Examples include | |||
confidentiality, reliable delivery, ordered delivery, message- | confidentiality, reliable delivery, ordered delivery, and message- | |||
versus-stream orientation, etc. | versus-stream orientation. | |||
* Transport Service: a set of Transport Features, without an | * Transport Service: a set of Transport Features, without an | |||
association to any given framing protocol, which provides | association to any given framing protocol, which provides | |||
functionality to an application. | functionality to an application. | |||
* Transport Services system: a software component that exposes an | ||||
interface to different Transport Services to an application. | ||||
* Transport Protocol: an implementation that provides one or more | * Transport Protocol: an implementation that provides one or more | |||
different transport services using a specific framing and header | different transport services using a specific framing and header | |||
format on the wire. A Transport Protocol services an application. | format on the wire. A Transport Protocol services an application, | |||
whether directly or in conjunction with a security protocol. | ||||
* Application: an entity that uses a transport protocol for end-to- | * Application: an entity that uses a transport protocol for end-to- | |||
end delivery of data across the network. This may also be an | end delivery of data across the network. This may also be an | |||
upper layer protocol or tunnel encapsulation. | upper layer protocol or tunnel encapsulation. | |||
* Security Protocol: a defined network protocol that implements one | * Security Protocol: a defined network protocol that implements one | |||
or more security features, such as authentication, encryption, key | or more security features, such as authentication, encryption, key | |||
generation, session resumption, and privacy. Security protocols | generation, session resumption, and privacy. Security protocols | |||
may be used alongside transport protocols, and in combination with | may be used alongside transport protocols, and in combination with | |||
other security protocols when appropriate. | other security protocols when appropriate. | |||
skipping to change at page 6, line 7 ¶ | skipping to change at page 6, line 40 ¶ | |||
* Peer: an endpoint application party to a session. | * Peer: an endpoint application party to a session. | |||
* Client: the peer responsible for initiating a session. | * Client: the peer responsible for initiating a session. | |||
* Server: the peer responsible for responding to a session | * Server: the peer responsible for responding to a session | |||
initiation. | initiation. | |||
3. Transport Security Protocol Descriptions | 3. Transport Security Protocol Descriptions | |||
This section contains brief descriptions of the various security | This section contains brief transport and security descriptions of | |||
protocols currently used to protect data being sent over a network. | various security protocols currently used to protect data being sent | |||
These protocols are grouped based on where in the protocol stack they | over a network. These protocols are grouped based on where in the | |||
are implemented, which influences which parts of a packet they | protocol stack they are implemented, which influences which parts of | |||
protect: Generic application payload, application payload for | a packet they protect: Generic application payload, application | |||
specific application-layer protocols, both application payload and | payload for specific application-layer protocols, both application | |||
transport headers, or entire IP packets. | payload and transport headers, or entire IP packets. | |||
Note that not all security protocols can be easily categorized, e.g., | Note that not all security protocols can be easily categorized, e.g., | |||
as some protocols can be used in different ways or in combination | as some protocols can be used in different ways or in combination | |||
with other protocols. One major reason for this is that channel | with other protocols. One major reason for this is that channel | |||
security protocols often consist of two components: | security protocols often consist of two components: | |||
* A handshake protocol, which is responsible for negotiating | * A handshake protocol, which is responsible for negotiating | |||
parameters, authenticating the endpoints, and establishing shared | parameters, authenticating the endpoints, and establishing shared | |||
keys. | keys. | |||
skipping to change at page 6, line 36 ¶ | skipping to change at page 7, line 21 ¶ | |||
For some protocols, such as tcpcrypt, these two components are | For some protocols, such as tcpcrypt, these two components are | |||
tightly integrated. In contrast, for IPsec, these components are | tightly integrated. In contrast, for IPsec, these components are | |||
implemented in separate protocols: AH and ESP are record protocols, | implemented in separate protocols: AH and ESP are record protocols, | |||
which can use keys supplied by the handshake protocol IKEv2, by other | which can use keys supplied by the handshake protocol IKEv2, by other | |||
handshake protocols, or by manual configuration. Moreover, some | handshake protocols, or by manual configuration. Moreover, some | |||
protocols can be used in different ways: While the base TLS protocol | protocols can be used in different ways: While the base TLS protocol | |||
as defined in [RFC8446] has an integrated handshake and record | as defined in [RFC8446] has an integrated handshake and record | |||
protocol, TLS or DTLS can also be used to negotiate keys for other | protocol, TLS or DTLS can also be used to negotiate keys for other | |||
protocols, as in DTLS-SRTP, or the handshake protocol can be used | protocols, as in DTLS-SRTP, or the handshake protocol can be used | |||
with a separate record layer, as in QUIC. | with a separate record layer, as in QUIC [I-D.ietf-quic-transport]. | |||
3.1. Application Payload Security Protocols | 3.1. Application Payload Security Protocols | |||
The following protocols provide security that protects application | The following protocols provide security that protects application | |||
payloads sent over a transport. They do not specifically protect any | payloads sent over a transport. They do not specifically protect any | |||
headers used for transport-layer functionality. | headers used for transport-layer functionality. | |||
3.1.1. TLS | 3.1.1. TLS | |||
TLS (Transport Layer Security) [RFC8446] is a common protocol used to | TLS (Transport Layer Security) [RFC8446] is a common protocol used to | |||
establish a secure session between two endpoints. Communication over | establish a secure session between two endpoints. Communication over | |||
this session "prevents eavesdropping, tampering, and message | this session "prevents eavesdropping, tampering, and message | |||
forgery." TLS consists of a tightly coupled handshake and record | forgery." TLS consists of a tightly coupled handshake and record | |||
protocol. The handshake protocol is used to authenticate peers, | protocol. The handshake protocol is used to authenticate peers, | |||
negotiate protocol options, such as cryptographic algorithms, and | negotiate protocol options, such as cryptographic algorithms, and | |||
derive session-specific keying material. The record protocol is used | derive session-specific keying material. The record protocol is used | |||
to marshal (possibly encrypted) data from one peer to the other. | to marshal and, once the handshake has sufficiently progressed, | |||
This data may contain handshake messages or raw application data. | encrypt, data from one peer to the other. This data may contain | |||
handshake messages or raw application data. | ||||
3.1.2. DTLS | 3.1.2. DTLS | |||
DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, | DTLS (Datagram Transport Layer Security) [RFC6347] | |||
but differs in that it is designed to run over unreliable datagram | [I-D.ietf-tls-dtls13] is based on TLS, but differs in that it is | |||
protocols like UDP instead of TCP. DTLS modifies the protocol to | designed to run over unreliable datagram protocols like UDP instead | |||
make sure it can still provide the same security guarantees as TLS | of TCP. DTLS modifies the protocol to make sure it can still provide | |||
even without reliability from the transport. DTLS was designed to be | equivalent security guarantees to TLS with the exception of order | |||
as similar to TLS as possible, so this document assumes that all | protection/non-replayability. DTLS was designed to be as similar to | |||
properties from TLS are carried over except where specified. | TLS as possible, so this document assumes that all properties from | |||
TLS are carried over except where specified. | ||||
3.2. Application-Specific Security Protocols | 3.2. Application-Specific Security Protocols | |||
The following protocols provide application-specific security by | The following protocols provide application-specific security by | |||
protecting application payloads used for specific use-cases. Unlike | protecting application payloads used for specific use-cases. Unlike | |||
the protocols above, these are not intended for generic application | the protocols above, these are not intended for generic application | |||
use. | use. | |||
3.2.1. Secure RTP | 3.2.1. Secure RTP | |||
skipping to change at page 7, line 38 ¶ | skipping to change at page 8, line 26 ¶ | |||
and RTP control protocol (RTCP) packets [RFC3711]. SRTP provides a | and RTP control protocol (RTCP) packets [RFC3711]. SRTP provides a | |||
record layer only, and requires a separate handshake protocol to | record layer only, and requires a separate handshake protocol to | |||
provide key agreement and identity management. | provide key agreement and identity management. | |||
The commonly used handshake protocol for SRTP is DTLS, in the form of | The commonly used handshake protocol for SRTP is DTLS, in the form of | |||
DTLS-SRTP [RFC5764]. This is an extension to DTLS that negotiates | DTLS-SRTP [RFC5764]. This is an extension to DTLS that negotiates | |||
the use of SRTP as the record layer, and describes how to export keys | the use of SRTP as the record layer, and describes how to export keys | |||
for use with SRTP. | for use with SRTP. | |||
ZRTP [RFC6189] is an alternative key agreement and identity | ZRTP [RFC6189] is an alternative key agreement and identity | |||
management protocols for SRTP. ZRTP Key agreement is performed using | management protocol for SRTP. ZRTP Key agreement is performed using | |||
a Diffie-Hellman key exchange that runs on the media path. This | a Diffie-Hellman key exchange that runs on the media path. This | |||
generates a shared secret that is then used to generate the master | generates a shared secret that is then used to generate the master | |||
key and salt for SRTP. | key and salt for SRTP. | |||
3.3. Transport-Layer Security Protocols | 3.3. Transport-Layer Security Protocols | |||
The following security protocols provide protection for both | The following security protocols provide protection for both | |||
application payloads and headers that are used for transport | application payloads and headers that are used for transport | |||
services. | services. | |||
skipping to change at page 8, line 32 ¶ | skipping to change at page 9, line 22 ¶ | |||
technical forebear of IETF QUIC, gQUIC was originally designed with | technical forebear of IETF QUIC, gQUIC was originally designed with | |||
tightly-integrated security and application data transport protocols. | tightly-integrated security and application data transport protocols. | |||
3.3.3. tcpcrypt | 3.3.3. tcpcrypt | |||
Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for | Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for | |||
opportunistic encryption. Applications may use tcpcrypt's unique | opportunistic encryption. Applications may use tcpcrypt's unique | |||
session ID for further application-level authentication. Absent this | session ID for further application-level authentication. Absent this | |||
authentication, tcpcrypt is vulnerable to active attacks. | authentication, tcpcrypt is vulnerable to active attacks. | |||
3.3.4. MinimalT | 3.3.4. MinimaLT | |||
MinimalT is a UDP-based transport security protocol designed to offer | MinimaLT [MinimaLT] is a UDP-based transport security protocol | |||
confidentiality, mutual authentication, DoS prevention, and | designed to offer confidentiality, mutual authentication, DoS | |||
connection mobility [MinimalT]. One major goal of the protocol is to | prevention, and connection mobility. One major goal of the protocol | |||
leverage existing protocols to obtain server-side configuration | is to leverage existing protocols to obtain server-side configuration | |||
information used to more quickly bootstrap a connection. MinimalT | information used to more quickly bootstrap a connection. MinimaLT | |||
uses a variant of TCP's congestion control algorithm. | uses a variant of TCP's congestion control algorithm. | |||
3.3.5. CurveCP | 3.3.5. CurveCP | |||
CurveCP [CurveCP] is a UDP-based transport security protocol from | CurveCP [CurveCP] is a UDP-based transport security that, unlike many | |||
Daniel J. Bernstein. Unlike many other security protocols, it is | other security protocols, is based entirely upon public key | |||
based entirely upon public key algorithms. CurveCP provides its own | algorithms. CurveCP provides its own reliability for application | |||
reliability for application data as part of its protocol. | data as part of its protocol. | |||
3.4. Packet Security Protocols | 3.4. Packet Security Protocols | |||
The following protocols provide protection for IP packets. These are | The following protocols provide protection for IP packets. These are | |||
generally used as tunnels, such as for Virtual Private Networks | generally used as tunnels, such as for Virtual Private Networks | |||
(VPNs). Often, applications will not interact directly with these | (VPNs). Often, applications will not interact directly with these | |||
protocols. However, applications that implement tunnels will | protocols. However, applications that implement tunnels will | |||
interact directly with these protocols. | interact directly with these protocols. | |||
3.4.1. IKEv2 with ESP | 3.4.1. IPsec | |||
IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec | IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec | |||
protocol suite that encrypts and authenticates IP packets, either for | protocol suite that encrypts and authenticates IP packets, either for | |||
creating tunnels (tunnel-mode) or for direct transport connections | creating tunnels (tunnel-mode) or for direct transport connections | |||
(transport-mode). This suite of protocols separates out the key | (transport-mode). This suite of protocols separates out the key | |||
generation protocol (IKEv2) from the transport encryption protocol | generation protocol (IKEv2) from the transport encryption protocol | |||
(ESP). Each protocol can be used independently, but this document | (ESP). Each protocol can be used independently, but this document | |||
considers them together, since that is the most common pattern. | considers them together, since that is the most common pattern. | |||
3.4.2. WireGuard | 3.4.2. WireGuard | |||
WireGuard is an IP-layer protocol designed as an alternative to IPsec | WireGuard [WireGuard] is an IP-layer protocol designed as an | |||
[WireGuard] for certain use cases. It uses UDP to encapsulate IP | alternative to IPsec for certain use cases. It uses UDP to | |||
datagrams between peers. Unlike most transport security protocols, | encapsulate IP datagrams between peers. Unlike most transport | |||
which rely on Public Key Infrastructure (PKI) for peer | security protocols, which rely on Public Key Infrastructure (PKI) for | |||
authentication, WireGuard authenticates peers using pre-shared public | peer authentication, WireGuard authenticates peers using pre-shared | |||
keys delivered out-of-band, each of which is bound to one or more IP | public keys delivered out-of-band, each of which is bound to one or | |||
addresses. Moreover, as a protocol suited for VPNs, WireGuard offers | more IP addresses. Moreover, as a protocol suited for VPNs, | |||
no extensibility, negotiation, or cryptographic agility. | WireGuard offers no extensibility, negotiation, or cryptographic | |||
agility. | ||||
3.4.3. OpenVPN | 3.4.3. OpenVPN | |||
OpenVPN [OpenVPN] is a commonly used protocol designed as an | OpenVPN [OpenVPN] is a commonly used protocol designed as an | |||
alternative to IPsec. A major goal of this protocol is to provide a | alternative to IPsec. A major goal of this protocol is to provide a | |||
VPN that is simple to configure and works over a variety of | VPN that is simple to configure and works over a variety of | |||
transports. OpenVPN encapsulates either IP packets or Ethernet | transports. OpenVPN encapsulates either IP packets or Ethernet | |||
frames within a secure tunnel and can run over either UDP or TCP. | frames within a secure tunnel and can run over either UDP or TCP. | |||
For key establishment, OpenVPN can use TLS as a handshake protocol or | For key establishment, OpenVPN can either use TLS as a handshake | |||
pre-shared keys. | protocol or use pre-shared keys. | |||
4. Transport Dependencies | 4. Transport Dependencies | |||
Across the different security protocols listed above, the primary | Across the different security protocols listed above, the primary | |||
dependency on transport protocols is the presentation of data: either | dependency on transport protocols is the presentation of data: either | |||
an unbounded stream of bytes, or framed messages. Within protocols | an unbounded stream of bytes, or framed messages. Within protocols | |||
that rely on the transport for message framing, most are built to run | that rely on the transport for message framing, most are built to run | |||
over transports that inherently provide framing, like UDP, but some | over transports that inherently provide framing, like UDP, but some | |||
also define how their messages can be framed over byte-stream | also define how their messages can be framed over byte-stream | |||
transports. | transports. | |||
skipping to change at page 10, line 41 ¶ | skipping to change at page 11, line 35 ¶ | |||
* DTLS | * DTLS | |||
* ZRTP | * ZRTP | |||
* SRTP | * SRTP | |||
Transport-Layer Security Protocols: | Transport-Layer Security Protocols: | |||
* QUIC | * QUIC | |||
* MinimalT | * MinimaLT | |||
* CurveCP | * CurveCP | |||
Packet Security Protocols: | Packet Security Protocols: | |||
* IKEv2 and ESP | * IPsec | |||
* WireGuard | * WireGuard | |||
* OpenVPN | * OpenVPN | |||
4.2.1. Datagram Protocols with Defined Byte-Stream Mappings | 4.2.1. Datagram Protocols with Defined Byte-Stream Mappings | |||
Of the protocols listed above that depend on the transport for | Of the protocols listed above that depend on the transport for | |||
message framing, some do have well-defined mappings for sending their | message framing, some do have well-defined mappings for sending their | |||
messages over byte-stream transports like TCP. | messages over byte-stream transports like TCP. | |||
Application Payload Security Protocols: | Application Payload Security Protocols: | |||
* DTLS when used as a handshake protocol for SRTP [RFC7850] | * DTLS when used as a handshake protocol for SRTP [RFC7850] | |||
* ZRTP [RFC4571] | * ZRTP [RFC6189] | |||
* SRTP [RFC4571] | * SRTP [RFC4571][RFC3711] | |||
Packet Security Protocols: | Packet Security Protocols: | |||
* IKEv2 and ESP [RFC8229] | * IPsec [RFC8229] | |||
4.3. Transport-Specific Dependencies | 4.3. Transport-Specific Dependencies | |||
One protocol surveyed, tcpcrypt, has an direct dependency on a | One protocol surveyed, tcpcrypt, has an direct dependency on a | |||
feature in the transport that is needed for its functionality. | feature in the transport that is needed for its functionality. | |||
Specific, tcpcrypt is designed to run on top of TCP, and uses the TCP | Specifically, tcpcrypt is designed to run on top of TCP, and uses the | |||
Encryption Negotiation Option (ENO) [RFC8547] to negotiate its | TCP Encryption Negotiation Option (ENO) [RFC8547] to negotiate its | |||
protocol support. | protocol support. | |||
QUIC, CurveCP, and MinimalT provide both transport functionality and | QUIC, CurveCP, and MinimaLT provide both transport functionality and | |||
security functionality. They have a dependencies on running over a | security functionality. They depend on running over a framed | |||
framed protocol like UDP, but they add their own layers of | protocol like UDP, but they add their own layers of reliability and | |||
reliability and other transport services. Thus, an application that | other transport services. Thus, an application that uses one of | |||
uses one of these protocols cannot decouple the security from | these protocols cannot decouple the security from transport | |||
transport functionality. | functionality. | |||
5. Application Interface | 5. Application Interface | |||
This section describes the interface surface exposed by the security | This section describes the interface exposed by the security | |||
protocols described above. We partition these interfaces into pre- | protocols described above. We partition these interfaces into pre- | |||
connection (configuration), connection, and post-connection | connection (configuration), connection, and post-connection | |||
interfaces, following conventions in [I-D.ietf-taps-interface] and | interfaces, following conventions in [I-D.ietf-taps-interface] and | |||
[I-D.ietf-taps-arch]. | [I-D.ietf-taps-arch]. | |||
Note that not all protocols support each interface. The table in | Note that not all protocols support each interface. The table in | |||
Section 5.4 summarizes which protocol exposes which of the | Section 5.4 summarizes which protocol exposes which of the | |||
interfaces. In the following sections, we provide abbreviations of | interfaces. In the following sections, we provide abbreviations of | |||
the interface names to use in the summary table. | the interface names to use in the summary table. | |||
5.1. Pre-Connection Interfaces | 5.1. Pre-Connection Interfaces | |||
Configuration interfaces are used to configure the security protocols | Configuration interfaces are used to configure the security protocols | |||
before a handshake begins or the keys are negotiated. | before a handshake begins or keys are negotiated. | |||
* Identities and Private Keys (IPK): The application can provide its | * Identities and Private Keys (IPK): The application can provide its | |||
identities (certificates) and private keys, or mechanisms to | identity, credentials (e.g., certificates), and private keys, or | |||
access these, to the security protocol to use during handshakes. | mechanisms to access these, to the security protocol to use during | |||
handshakes. | ||||
- TLS | - TLS | |||
- DTLS | - DTLS | |||
- ZRTP | - ZRTP | |||
- QUIC | - QUIC | |||
- MinimalT | - MinimaLT | |||
- CurveCP | - CurveCP | |||
- IKEv2 | - IPsec | |||
- WireGuard | - WireGuard | |||
- OpenVPN | - OpenVPN | |||
* Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) | * Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) | |||
(ALG): The application can choose the algorithms that are | (ALG): The application can choose the algorithms that are | |||
supported for key exchange, signatures, and ciphersuites. | supported for key exchange, signatures, and ciphersuites. | |||
- TLS | - TLS | |||
- DTLS | - DTLS | |||
- ZRTP | - ZRTP | |||
- QUIC | - QUIC | |||
- tcpcrypt | - tcpcrypt | |||
- MinimalT | - MinimaLT | |||
- IKEv2 | - IPsec | |||
- OpenVPN | - OpenVPN | |||
* Extensions (Application-Layer Protocol Negotiation) (EXT): The | * Extensions (EXT): The application enables or configures extensions | |||
application enables or configures extensions that are to be | that are to be negotiated by the security protocol, such as | |||
negotiated by the security protocol, such as ALPN [RFC7301]. | Application-Layer Protocol Negotiation (ALPN) [RFC7301]. | |||
- TLS | - TLS | |||
- DTLS | - DTLS | |||
- QUIC | - QUIC | |||
* Session Cache Management (CM): The application provides the | * Session Cache Management (CM): The application provides the | |||
ability to save and retrieve session state (such as tickets, | ability to save and retrieve session state (such as tickets, | |||
keying material, and server parameters) that may be used to resume | keying material, and server parameters) that may be used to resume | |||
the security session. | the security session. | |||
- TLS | - TLS | |||
skipping to change at page 13, line 30 ¶ | skipping to change at page 14, line 23 ¶ | |||
- TLS | - TLS | |||
- DTLS | - DTLS | |||
- ZRTP | - ZRTP | |||
- QUIC | - QUIC | |||
- tcpcrypt | - tcpcrypt | |||
- MinimalT | - MinimaLT | |||
* Authentication Delegation (AD): The application provides access to | * Authentication Delegation (AD): The application provides access to | |||
a separate module that will provide authentication, using EAP for | a separate module that will provide authentication, using | |||
example. | Extensible Authentication Protocol (EAP) [RFC3748] for example. | |||
- IKEv2 | - IPsec | |||
- tcpcrypt | - tcpcrypt | |||
* Pre-Shared Key Import (PSKI): Either the handshake protocol or the | * Pre-Shared Key Import (PSKI): Either the handshake protocol or the | |||
application directly can supply pre-shared keys for use in | application directly can supply pre-shared keys for use in | |||
encrypting (and authenticating) communication with a peer. | encrypting (and authenticating) communication with a peer. | |||
- TLS | - TLS | |||
- DTLS | - DTLS | |||
- ZRTP | - ZRTP | |||
- QUIC | - QUIC | |||
- ESP | ||||
- IKEv2 | ||||
- OpenVPN | ||||
- tcpcrypt | - tcpcrypt | |||
- MinimalT | - MinimaLT | |||
- IPsec | ||||
- WireGuard | - WireGuard | |||
- OpenVPN | ||||
5.2. Connection Interfaces | 5.2. Connection Interfaces | |||
* Identity Validation (IV): During a handshake, the security | * Identity Validation (IV): During a handshake, the security | |||
protocol will conduct identity validation of the peer. This can | protocol will conduct identity validation of the peer. This can | |||
call into the application to offload validation. | offload validation or occur transparently to the application. | |||
- TLS | - TLS | |||
- DTLS | - DTLS | |||
- ZRTP | - ZRTP | |||
- QUIC | - QUIC | |||
- MinimalT | - MinimaLT | |||
- CurveCP | - CurveCP | |||
- IKEv2 | - IPsec | |||
- WireGuard | - WireGuard | |||
- OpenVPN | - OpenVPN | |||
* Source Address Validation (SAV): The handshake protocol may | * Source Address Validation (SAV): The handshake protocol may | |||
delegate validation of the remote peer that has sent data to the | interact with the transport protocol or application to validate | |||
transport protocol or application. This involves sending a cookie | the address of the remote peer that has sent data. This involves | |||
exchange to avoid DoS attacks. | sending a cookie exchange to avoid DoS attacks. (This list omits | |||
protocols which depend on TCP and therefore implicitly perform | ||||
SAV.) | ||||
- DTLS | - DTLS | |||
- QUIC | - QUIC | |||
- IKEv2 | - IPsec | |||
- WireGuard | - WireGuard | |||
5.3. Post-Connection Interfaces | 5.3. Post-Connection Interfaces | |||
* Connection Termination (CT): The security protocol may be | * Connection Termination (CT): The security protocol may be | |||
instructed to tear down its connection and session information. | instructed to tear down its connection and session information. | |||
This is needed by some protocols, e.g., to prevent application | This is needed by some protocols, e.g., to prevent application | |||
data truncation attacks in which an attacker terminates an | data truncation attacks in which an attacker terminates an | |||
underlying insecure connection-oriented protocol to terminate the | underlying insecure connection-oriented protocol to terminate the | |||
skipping to change at page 15, line 24 ¶ | skipping to change at page 16, line 24 ¶ | |||
- TLS | - TLS | |||
- DTLS | - DTLS | |||
- ZRTP | - ZRTP | |||
- QUIC | - QUIC | |||
- tcpcrypt | - tcpcrypt | |||
- MinimalT | - MinimaLT | |||
- IKEv2 | - IPsec | |||
- OpenVPN | - OpenVPN | |||
* Key Update (KU): The handshake protocol may be instructed to | * Key Update (KU): The handshake protocol may be instructed to | |||
update its keying material, either by the application directly or | update its keying material, either by the application directly or | |||
by the record protocol sending a key expiration event. | by the record protocol sending a key expiration event. | |||
- TLS | - TLS | |||
- DTLS | - DTLS | |||
- QUIC | - QUIC | |||
- tcpcrypt | - tcpcrypt | |||
- MinimalT | - MinimaLT | |||
- IKEv2 | - IPsec | |||
* Shared Secret Export (PSKE): The handshake protocol may provide an | * Shared Secret Export (PSKE): The handshake protocol may provide an | |||
interface for producing shared secrets for application-specific | interface for producing shared secrets for application-specific | |||
uses. | uses. | |||
- TLS | - TLS | |||
- DTLS | - DTLS | |||
- tcpcrypt | - tcpcrypt | |||
- IKEv2 | - IPsec | |||
- OpenVPN | - OpenVPN | |||
- MinimalT | - MinimaLT | |||
* Key Expiration (KE): The record protocol can signal that its keys | * Key Expiration (KE): The record protocol can signal that its keys | |||
are expiring due to reaching a time-based deadline, or a use-based | are expiring due to reaching a time-based deadline, or a use-based | |||
deadline (number of bytes that have been encrypted with the key). | deadline (number of bytes that have been encrypted with the key). | |||
This interaction is often limited to signaling between the record | This interaction is often limited to signaling between the record | |||
layer and the handshake layer. | layer and the handshake layer. | |||
- ESP | - IPsec | |||
* Mobility Events (ME): The record protocol can be signaled that it | * Mobility Events (ME): The record protocol can be signaled that it | |||
is being migrated to another transport or interface due to | is being migrated to another transport or interface due to | |||
connection mobility, which may reset address and state validation | connection mobility, which may reset address and state validation | |||
and induce state changes such as use of a new Connection | and induce state changes such as use of a new Connection | |||
Identifier (CID). | Identifier (CID). | |||
- DTLS (version 1.3 only [I-D.ietf-tls-dtls13]) | ||||
- QUIC | - QUIC | |||
- MinimalT | - MinimaLT | |||
- CurveCP | - CurveCP | |||
- IKEv2 [RFC4555] | - IPsec [RFC4555] | |||
- WireGuard | - WireGuard | |||
5.4. Summary of Interfaces Exposed by Protocols | 5.4. Summary of Interfaces Exposed by Protocols | |||
The following table summarizes which protocol exposes which | The following table summarizes which protocol exposes which | |||
interface. | interface. | |||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | |||
| Protocol |IPK|ALG | EXT |CM|AD| PSKI |IV| SAV |CT|KU| PSKE |KE|ME| | | Protocol |IPK|ALG | EXT |CM|AD| PSKI |IV| SAV |CT|KU| PSKE |KE|ME| | |||
+===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+ | +===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+ | |||
| TLS | x | x | x |x | | x |x | |x |x | x | | | | | TLS | x | x | x |x | | x |x | |x |x | x | | | | |||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | |||
| DTLS | x | x | x |x | | x |x | x |x |x | x | | | | | DTLS | x | x | x |x | | x |x | x |x |x | x | |x | | |||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | |||
| ZRTP | x | x | |x | | x |x | |x | | | | | | | ZRTP | x | x | |x | | x |x | |x | | | | | | |||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | |||
| QUIC | x | x | x |x | | x |x | x |x |x | | |x | | | QUIC | x | x | x |x | | x |x | x |x |x | | |x | | |||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | |||
| tcpcrypt | | x | |x |x | x | | |x |x | x | | | | | tcpcrypt | | x | |x |x | x | | |x |x | x | | | | |||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | |||
| MinimalT | x | x | |x | | x |x | |x |x | x | |x | | | MinimaLT | x | x | |x | | x |x | |x |x | x | |x | | |||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | |||
| CurveCP | x | | | | | |x | | | | | |x | | | CurveCP | x | | | | | |x | | | | | |x | | |||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | |||
| IKEv2 | x | x | | |x | x |x | x |x |x | x | |x | | | IPsec | x | x | | |x | x |x | x |x |x | x |x |x | | |||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | ||||
| ESP | | | | | | x | | | | | |x | | | ||||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | |||
| WireGuard | x | | | | | x |x | x | | | | |x | | | WireGuard | x | | | | | x |x | x | | | | |x | | |||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | |||
| OpenVPN | x | x | | | | x |x | |x | | x | | | | | OpenVPN | x | x | | | | x |x | |x | | x | | | | |||
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ | |||
Table 1 | Table 1 | |||
x=Interface is exposed (blank)=Interface is not exposed | x=Interface is exposed (blank)=Interface is not exposed | |||
skipping to change at page 18, line 9 ¶ | skipping to change at page 19, line 9 ¶ | |||
made. For example, metadata leakage via timing side channels and | made. For example, metadata leakage via timing side channels and | |||
traffic analysis may compromise any protocol discussed in this | traffic analysis may compromise any protocol discussed in this | |||
survey. Applications using Security Interfaces should take such | survey. Applications using Security Interfaces should take such | |||
limitations into consideration when using a particular protocol | limitations into consideration when using a particular protocol | |||
implementation. | implementation. | |||
8. Privacy Considerations | 8. Privacy Considerations | |||
Analysis of how features improve or degrade privacy is intentionally | Analysis of how features improve or degrade privacy is intentionally | |||
omitted from this survey. All security protocols surveyed generally | omitted from this survey. All security protocols surveyed generally | |||
improve privacy by reducing information leakage via encryption. | improve privacy by using encryption to reduce information leakage. | |||
However, varying amounts of metadata remain in the clear across each | However, varying amounts of metadata remain in the clear across each | |||
protocol. For example, client and server certificates are sent in | protocol. For example, client and server certificates are sent in | |||
cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3 | cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3 | |||
[RFC8446]. A survey of privacy features, or lack thereof, for | [RFC8446]. A survey of privacy features, or lack thereof, for | |||
various security protocols could be addressed in a separate document. | various security protocols could be addressed in a separate document. | |||
9. Acknowledgments | 9. Acknowledgments | |||
The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja | The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja | |||
Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for | Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for | |||
skipping to change at page 18, line 49 ¶ | skipping to change at page 19, line 49 ¶ | |||
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed | Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed | |||
and Secure Transport", Work in Progress, Internet-Draft, | and Secure Transport", Work in Progress, Internet-Draft, | |||
draft-ietf-quic-transport-27, 21 February 2020, | draft-ietf-quic-transport-27, 21 February 2020, | |||
<http://www.ietf.org/internet-drafts/draft-ietf-quic- | <http://www.ietf.org/internet-drafts/draft-ietf-quic- | |||
transport-27.txt>. | transport-27.txt>. | |||
[I-D.ietf-taps-arch] | [I-D.ietf-taps-arch] | |||
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., | Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., | |||
Perkins, C., Tiesel, P., and C. Wood, "An Architecture for | Perkins, C., Tiesel, P., and C. Wood, "An Architecture for | |||
Transport Services", Work in Progress, Internet-Draft, | Transport Services", Work in Progress, Internet-Draft, | |||
draft-ietf-taps-arch-06, 23 December 2019, | draft-ietf-taps-arch-07, 9 March 2020, | |||
<http://www.ietf.org/internet-drafts/draft-ietf-taps-arch- | <http://www.ietf.org/internet-drafts/draft-ietf-taps-arch- | |||
06.txt>. | 07.txt>. | |||
[I-D.ietf-taps-interface] | [I-D.ietf-taps-interface] | |||
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., | Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., | |||
Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. | Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. | |||
Pauly, "An Abstract Application Layer Interface to | Pauly, "An Abstract Application Layer Interface to | |||
Transport Services", Work in Progress, Internet-Draft, | Transport Services", Work in Progress, Internet-Draft, | |||
draft-ietf-taps-interface-05, 4 November 2019, | draft-ietf-taps-interface-06, 9 March 2020, | |||
<http://www.ietf.org/internet-drafts/draft-ietf-taps- | <http://www.ietf.org/internet-drafts/draft-ietf-taps- | |||
interface-05.txt>. | interface-06.txt>. | |||
[MinimalT] Petullo, W.M., Zhang, X., Solworth, J.A., Bernstein, D.J., | [I-D.ietf-tls-dtls13] | |||
Rescorla, E., Tschofenig, H., and N. Modadugu, "The | ||||
Datagram Transport Layer Security (DTLS) Protocol Version | ||||
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- | ||||
dtls13-37, 9 March 2020, <http://www.ietf.org/internet- | ||||
drafts/draft-ietf-tls-dtls13-37.txt>. | ||||
[MinimaLT] Petullo, W.M., Zhang, X., Solworth, J.A., Bernstein, D.J., | ||||
and T. Lange, "MinimaLT -- Minimal-latency Networking | and T. Lange, "MinimaLT -- Minimal-latency Networking | |||
Through Better Security", | Through Better Security", | |||
<http://dl.acm.org/citation.cfm?id=2516737>. | <http://dl.acm.org/citation.cfm?id=2516737>. | |||
[OpenVPN] "OpenVPN cryptographic layer", <https://openvpn.net/ | [OpenVPN] "OpenVPN cryptographic layer", <https://openvpn.net/ | |||
community-resources/openvpn-cryptographic-layer/>. | community-resources/openvpn-cryptographic-layer/>. | |||
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 | [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 | |||
Signature Option", RFC 2385, DOI 10.17487/RFC2385, August | Signature Option", RFC 2385, DOI 10.17487/RFC2385, August | |||
1998, <https://www.rfc-editor.org/info/rfc2385>. | 1998, <https://www.rfc-editor.org/info/rfc2385>. | |||
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", | ||||
RFC 2890, DOI 10.17487/RFC2890, September 2000, | ||||
<https://www.rfc-editor.org/info/rfc2890>. | ||||
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. | |||
Norrman, "The Secure Real-time Transport Protocol (SRTP)", | Norrman, "The Secure Real-time Transport Protocol (SRTP)", | |||
RFC 3711, DOI 10.17487/RFC3711, March 2004, | RFC 3711, DOI 10.17487/RFC3711, March 2004, | |||
<https://www.rfc-editor.org/info/rfc3711>. | <https://www.rfc-editor.org/info/rfc3711>. | |||
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. | ||||
Levkowetz, Ed., "Extensible Authentication Protocol | ||||
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004, | ||||
<https://www.rfc-editor.org/info/rfc3748>. | ||||
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) | ||||
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, | ||||
January 2006, <https://www.rfc-editor.org/info/rfc4253>. | ||||
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, | [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, | |||
DOI 10.17487/RFC4302, December 2005, | DOI 10.17487/RFC4302, December 2005, | |||
<https://www.rfc-editor.org/info/rfc4302>. | <https://www.rfc-editor.org/info/rfc4302>. | |||
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", | [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", | |||
RFC 4303, DOI 10.17487/RFC4303, December 2005, | RFC 4303, DOI 10.17487/RFC4303, December 2005, | |||
<https://www.rfc-editor.org/info/rfc4303>. | <https://www.rfc-editor.org/info/rfc4303>. | |||
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol | [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol | |||
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, | (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, | |||
skipping to change at page 20, line 5 ¶ | skipping to change at page 21, line 27 ¶ | |||
[RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) | [RFC4571] Lazzaro, J., "Framing Real-time Transport Protocol (RTP) | |||
and RTP Control Protocol (RTCP) Packets over Connection- | and RTP Control Protocol (RTCP) Packets over Connection- | |||
Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July | Oriented Transport", RFC 4571, DOI 10.17487/RFC4571, July | |||
2006, <https://www.rfc-editor.org/info/rfc4571>. | 2006, <https://www.rfc-editor.org/info/rfc4571>. | |||
[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>. | |||
[RFC5641] McGill, N. and C. Pignataro, "Layer 2 Tunneling Protocol | ||||
Version 3 (L2TPv3) Extended Circuit Status Values", | ||||
RFC 5641, DOI 10.17487/RFC5641, August 2009, | ||||
<https://www.rfc-editor.org/info/rfc5641>. | ||||
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer | [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer | |||
Security (DTLS) Extension to Establish Keys for the Secure | Security (DTLS) Extension to Establish Keys for the Secure | |||
Real-time Transport Protocol (SRTP)", RFC 5764, | Real-time Transport Protocol (SRTP)", RFC 5764, | |||
DOI 10.17487/RFC5764, May 2010, | DOI 10.17487/RFC5764, May 2010, | |||
<https://www.rfc-editor.org/info/rfc5764>. | <https://www.rfc-editor.org/info/rfc5764>. | |||
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP | [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP | |||
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, | Authentication Option", RFC 5925, DOI 10.17487/RFC5925, | |||
June 2010, <https://www.rfc-editor.org/info/rfc5925>. | June 2010, <https://www.rfc-editor.org/info/rfc5925>. | |||
skipping to change at page 22, line 8 ¶ | skipping to change at page 23, line 36 ¶ | |||
Email: csp@csperkins.org | Email: csp@csperkins.org | |||
Kyle Rose | Kyle Rose | |||
Akamai Technologies, Inc. | Akamai Technologies, Inc. | |||
150 Broadway | 150 Broadway | |||
Cambridge, MA 02144, | Cambridge, MA 02144, | |||
United States of America | United States of America | |||
Email: krose@krose.org | Email: krose@krose.org | |||
Christopher A. Wood (editor) | Christopher A. Wood | |||
Apple Inc. | Cloudflare | |||
One Apple Park Way | 101 Townsend St | |||
Cupertino, California 95014, | San Francisco, | |||
United States of America | United States of America | |||
Email: cawood@apple.com | Email: caw@heapingbits.net | |||
End of changes. 84 change blocks. | ||||
172 lines changed or deleted | 228 lines changed or added | |||
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |