draft-ietf-taps-transport-security-09.txt | draft-ietf-taps-transport-security-10.txt | |||
---|---|---|---|---|
Network Working Group C. Wood, Ed. | Network Working Group T. Enghardt | |||
Internet-Draft Apple Inc. | Internet-Draft TU Berlin | |||
Intended status: Informational T. Enghardt | Intended status: Informational T. Pauly | |||
Expires: March 31, 2020 TU Berlin | Expires: May 21, 2020 Apple Inc. | |||
T. Pauly | ||||
Apple Inc. | ||||
C. Perkins | C. Perkins | |||
University of Glasgow | University of Glasgow | |||
K. Rose | K. Rose | |||
Akamai Technologies, Inc. | Akamai Technologies, Inc. | |||
September 28, 2019 | C. Wood, Ed. | |||
Apple Inc. | ||||
November 18, 2019 | ||||
A Survey of Transport Security Protocols | A Survey of the Interaction Between Security Protocols and Transport | |||
draft-ietf-taps-transport-security-09 | Services | |||
draft-ietf-taps-transport-security-10 | ||||
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 | |||
Services system may need to support. Moreover, this document defines | Services system may need to support. | |||
a minimal set of security features that a secure transport system | ||||
should provide. | ||||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
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 March 31, 2020. | This Internet-Draft will expire on May 21, 2020. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2019 IETF Trust and the persons identified as the | Copyright (c) 2019 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | ||||
1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 | ||||
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
3. Security Features . . . . . . . . . . . . . . . . . . . . . . 6 | 3. Transport Security Protocol Descriptions . . . . . . . . . . 6 | |||
4. Transport Security Protocol Descriptions . . . . . . . . . . 7 | 3.1. Application Payload Security Protocols . . . . . . . . . 6 | |||
4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 3.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
4.1.1. Protocol Description . . . . . . . . . . . . . . . . 8 | 3.1.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
4.1.2. Security Features . . . . . . . . . . . . . . . . . . 9 | 3.2. Application-Specific Security Protocols . . . . . . . . . 6 | |||
4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9 | 3.2.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . 6 | |||
4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 3.2.2. ZRTP for Media Path Key Agreement . . . . . . . . . . 7 | |||
4.2.1. Protocol Description . . . . . . . . . . . . . . . . 10 | 3.3. Transport-Layer Security Protocols . . . . . . . . . . . 7 | |||
4.2.2. Security Features . . . . . . . . . . . . . . . . . . 10 | 3.3.1. QUIC with TLS . . . . . . . . . . . . . . . . . . . . 7 | |||
4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 | 3.3.2. Google QUIC . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.3. QUIC with TLS . . . . . . . . . . . . . . . . . . . . . . 11 | 3.3.3. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11 | 3.3.4. MinimalT . . . . . . . . . . . . . . . . . . . . . . 7 | |||
4.3.2. Security Features . . . . . . . . . . . . . . . . . . 12 | 3.3.5. CurveCP . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12 | 3.4. Packet Security Protocols . . . . . . . . . . . . . . . . 8 | |||
4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 12 | 3.4.1. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . 8 | |||
4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12 | 3.4.2. WireGuard . . . . . . . . . . . . . . . . . . . . . . 8 | |||
4.4.1. IKEv2 Protocol Description . . . . . . . . . . . . . 12 | 3.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
4.4.2. ESP Protocol Description . . . . . . . . . . . . . . 13 | 4. Transport Dependencies . . . . . . . . . . . . . . . . . . . 9 | |||
4.4.3. IKEv2 Security Features . . . . . . . . . . . . . . . 14 | 4.1. Reliable Byte-Stream Transports . . . . . . . . . . . . . 9 | |||
4.4.4. ESP Security Features . . . . . . . . . . . . . . . . 14 | 4.2. Unreliable Datagram Transports . . . . . . . . . . . . . 9 | |||
4.4.5. IKEv2 Protocol Dependencies . . . . . . . . . . . . . 14 | 4.2.1. Datagram Protocols with Defined Byte-Stream Mappings 10 | |||
4.4.6. ESP Protocol Dependencies . . . . . . . . . . . . . . 15 | 4.3. Transport-Specific Dependencies . . . . . . . . . . . . . 10 | |||
4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15 | 5. Application Interface . . . . . . . . . . . . . . . . . . . . 10 | |||
4.5.1. Protocol description . . . . . . . . . . . . . . . . 15 | 5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 11 | |||
4.5.2. Security Features . . . . . . . . . . . . . . . . . . 16 | 5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 13 | |||
4.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16 | 5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 13 | |||
4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 17 | 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 | |||
4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 17 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 | |||
4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17 | 8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 15 | |||
4.6.2. Security Features . . . . . . . . . . . . . . . . . . 18 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18 | 10. Informative References . . . . . . . . . . . . . . . . . . . 15 | |||
4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 | |||
4.7.1. Protocol description . . . . . . . . . . . . . . . . 19 | ||||
4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19 | ||||
4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20 | ||||
4.8. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20 | ||||
4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20 | ||||
4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 21 | ||||
4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21 | ||||
4.9. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 22 | ||||
4.9.1. Protocol Description . . . . . . . . . . . . . . . . 22 | ||||
4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 23 | ||||
4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 23 | ||||
4.10. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . 23 | ||||
4.10.1. Protocol Description . . . . . . . . . . . . . . . . 23 | ||||
4.10.2. Protocol Features . . . . . . . . . . . . . . . . . 24 | ||||
4.10.3. Protocol Dependencies . . . . . . . . . . . . . . . 25 | ||||
5. Security Features and Application Dependencies . . . . . . . 25 | ||||
5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 25 | ||||
5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 26 | ||||
5.3. Optional Feature Availability . . . . . . . . . . . . . . 27 | ||||
6. Transport Security Protocol Interfaces . . . . . . . . . . . 29 | ||||
6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 29 | ||||
6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 30 | ||||
6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 30 | ||||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 | ||||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 | ||||
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 | ||||
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 | ||||
11. Informative References . . . . . . . . . . . . . . . . . . . 31 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 | ||||
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 services and features a Transport Services system (a | identifying the services and features a Transport Services system (a | |||
system that provides a transport API) needs to provide in order to | system that provides a transport API) needs to provide in order to | |||
add transport security. It examines Transport Layer Security (TLS), | add transport security. It examines Transport Layer Security (TLS), | |||
Datagram Transport Layer Security (DTLS), QUIC + TLS, tcpcrypt, | Datagram Transport Layer Security (DTLS), QUIC + TLS, tcpcrypt, | |||
Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + | Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + | |||
ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT. For each | ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT. For each | |||
protocol, this document provides a brief description, the security | protocol, this document provides a brief description, the | |||
features it provides, and the dependencies it has on the underlying | dependencies it has on the underlying transports, and the interfaces | |||
transport. This is followed by defining the set of transport | provided to applications. | |||
security features shared by these protocols. The document groups | ||||
these security features into a minimal set of features, which every | ||||
secure transport system should provide in addition to the transport | ||||
features described in [I-D.ietf-taps-minset], and additional optional | ||||
features, which may not be available in every secure transport | ||||
system. Finally, the document distills the application and transport | ||||
interfaces provided by the transport security protocols. | ||||
Selected protocols represent a superset of functionality and features | Selected protocols represent a superset of functionality and features | |||
a Transport Services system may need to support, both internally and | a Transport Services system may need to support, both internally and | |||
externally (via an API) for applications [I-D.ietf-taps-arch]. | externally (via an API) for applications [I-D.ietf-taps-arch]. | |||
Ubiquitous IETF protocols such as (D)TLS, as well as non-standard | Ubiquitous IETF protocols such as (D)TLS, as well as non-standard | |||
protocols such as Google QUIC, are both included despite overlapping | protocols such as Google QUIC, are both included despite overlapping | |||
features. As such, this survey is not limited to protocols developed | features. As such, this survey is not limited to protocols developed | |||
within the scope or context of the IETF. Outside of this candidate | within the scope or context of the IETF. Outside of this candidate | |||
set, protocols that do not offer new features are omitted. For | set, protocols that do not offer new features are omitted. For | |||
example, newer protocols such as WireGuard make unique design choices | example, newer protocols such as WireGuard make unique design choices | |||
that have important implications on applications, such as how to best | that have implications and limitations on application usage. In | |||
configure peer public keys and to delegate algorithm selection to the | contrast, protocols such as ALTS [ALTS] are omitted since they do not | |||
system. In contrast, protocols such as ALTS [ALTS] are omitted since | provide interfaces deemed unique. | |||
they do not represent features deemed unique. | ||||
Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH | Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH | |||
[RFC4302] are excluded from this survey. TCP-AO adds authenticity | [RFC4302] are excluded from this survey. TCP-AO adds authenticity | |||
protections to long-lived TCP connections, e.g., replay protection | protections to long-lived TCP connections, e.g., replay protection | |||
with per-packet Message Authentication Codes. (This protocol | with per-packet Message Authentication Codes. (This protocol | |||
obsoletes TCP MD5 "signature" options specified in [RFC2385].) One | obsoletes TCP MD5 "signature" options specified in [RFC2385].) One | |||
prime use case of TCP-AO is for protecting BGP connections. | prime use case of TCP-AO is for protecting BGP connections. | |||
Similarly, AH adds per-datagram authenticity and adds similar replay | Similarly, AH adds per-datagram authenticity and adds similar replay | |||
protection. Despite these improvements, neither protocol sees | protection. Despite these improvements, neither protocol sees | |||
general use and both lack critical properties important for emergent | general use and both lack critical properties important for emergent | |||
transport security protocols: confidentiality, privacy protections, | transport security protocols: confidentiality, privacy protections, | |||
and agility. Such protocols are thus omitted from this survey. | and agility. Such protocols are thus omitted from this survey. | |||
1.1. Goals | ||||
This survey is intended to help identify the most common interface | ||||
surfaces between security protocols and transport protocols, and | ||||
between security protocols and applications. | ||||
One of the goals of Transport Services is to define a common | ||||
interface for using transport protocols that allows software using | ||||
transport protocols to easily adopt new protocols that provide | ||||
similar feature-sets. The survey of the dependencies security | ||||
protocols have upon transport protocols can guide implementations in | ||||
determining which transport protocols are appropriate to be able to | ||||
use beneath a given security protocol. For example, a security | ||||
protocol that expects to run over a reliable stream of bytes, like | ||||
TLS, restrict the set of transport protocols that can be used to | ||||
those that offer a reliable stream of bytes. | ||||
Defining the common interfaces that security protocols provide to | ||||
applications also allows interfaces to be designed in a way that | ||||
common functionality can use the same APIs. For example, many | ||||
security protocols that provide authentication let the application be | ||||
involved in peer identity validation. Any interface to use a secure | ||||
transport protocol stack thus needs to allow applications to perform | ||||
this action during connection establishment. | ||||
1.2. Non-Goals | ||||
While this survey provides similar analysis to that which was | ||||
performed for transport protocols in [RFC8095], it is important to | ||||
distinguish that the use of security protocols requires more | ||||
consideration. | ||||
It is not a goal to allow software implementations to automatically | ||||
switch between different security protocols, even where their | ||||
interfaces to transport and applications are equivalent. Even | ||||
between versions, security protocols have subtly different guarantees | ||||
and vulnerabilities. Thus, any implementation needs to only use the | ||||
set of protocols and algorithms that are requested by applications or | ||||
by a system policy. | ||||
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: | |||
o Transport Feature: a specific end-to-end feature that the | o 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, message- | |||
versus-stream orientation, etc. | versus-stream orientation, etc. | |||
skipping to change at page 5, line 13 ¶ | skipping to change at page 5, line 19 ¶ | |||
functionality to an application. | functionality to an application. | |||
o Transport Protocol: an implementation that provides one or more | o 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. | |||
o Application: an entity that uses a transport protocol for end-to- | o 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. | |||
o Security Feature: a feature that a network security layer provides | ||||
to applications. Examples include authentication, encryption, key | ||||
generation, session resumption, and privacy. Features may be | ||||
Mandatory or Optional for an application's implementation. | ||||
Security Features extend the set of Transport Features described | ||||
in [RFC8095] and provided by Transport Services implementations. | ||||
o Security Protocol: a defined network protocol that implements one | o Security Protocol: a defined network protocol that implements one | |||
or more security features. Security protocols may be used | or more security features, such as authentication, encryption, key | |||
alongside transport protocols, and in combination with other | generation, session resumption, and privacy. Security protocols | |||
security protocols when appropriate. | may be used alongside transport protocols, and in combination with | |||
other security protocols when appropriate. | ||||
o Handshake Protocol: a protocol that enables peers to validate each | o Handshake Protocol: a protocol that enables peers to validate each | |||
other and to securely establish shared cryptographic context. | other and to securely establish shared cryptographic context. | |||
o Record: Framed protocol messages. | o Record: Framed protocol messages. | |||
o Record Protocol: a security protocol that allows data to be | o Record Protocol: a security protocol that allows data to be | |||
divided into manageable blocks and protected using shared | divided into manageable blocks and protected using shared | |||
cryptographic context. | cryptographic context. | |||
o Session: an ephemeral security association between applications. | o Session: an ephemeral security association between applications. | |||
o Cryptographic context: a set of cryptographic parameters, | ||||
including but not necessarily limited to keys for encryption, | ||||
authentication, and session resumption, enabling authorized | ||||
parties to a session to communicate securely. | ||||
o Connection: the shared state of two or more endpoints that | o Connection: the shared state of two or more endpoints that | |||
persists across messages that are transmitted between these | persists across messages that are transmitted between these | |||
endpoints. A connection is a transient participant of a session, | endpoints. A connection is a transient participant of a session, | |||
and a session generally lasts between connection instances. | and a session generally lasts between connection instances. | |||
o Peer: an endpoint application party to a session. | o Peer: an endpoint application party to a session. | |||
o Client: the peer responsible for initiating a session. | o Client: the peer responsible for initiating a session. | |||
o Server: the peer responsible for responding to a session | o Server: the peer responsible for responding to a session | |||
initiation. | initiation. | |||
3. Security Features | 3. Transport Security Protocol Descriptions | |||
In this section, we enumerate Security Features exposed by protocols | ||||
discussed in the remainder of this document. Protocol security (and | ||||
privacy) properties that are unrelated to the API surface exposed by | ||||
such protocols, such as client or server identity hiding, are not | ||||
listed here as features. | ||||
o Forward-secure session key establishment: Establishing | ||||
cryptographic keys with forward-secure properties. | ||||
o Cryptographic algorithm negotiation: Negotiating support of | ||||
protocol algorithms, including algorithms for encryption, hashing, | ||||
MAC (PRF), and digital signatures. | ||||
o Session caching and management: Managing session state caches used | ||||
for subsequent connections, with the aim of amortizing connection | ||||
establishment costs. | ||||
o Peer authentication: Authenticating peers using generic or | ||||
protocol-specific mechanisms, such as certificates, raw public | ||||
keys, pre-shared keys, or EAP methods. | ||||
o Unilateral responder authentication: Requiring authentication for | ||||
the responder of a connection. | ||||
o Mutual authentication: Establishing connections in which both | ||||
endpoints are authenticated. | ||||
o Application authentication delegation: Delegating to applications | ||||
out-of-band to perform peer authentication. | ||||
o Record (channel or datagram) confidentiality and integrity: | ||||
Encrypting and authenticating application plaintext bytes sent | ||||
between peers over a channel or in individual datagrams. | ||||
o Partial record confidentiality: Encrypting some portion of | ||||
records. | ||||
o Optional record integrity: Optionally authenticating certain | ||||
records. | ||||
o Record replay prevention: Detecting and defending against record | ||||
replays, which can be due to in-network retransmissions. | ||||
o Early data support: Transmitting application data prior to secure | ||||
connection establishment via a handshake. For TLS, this support | ||||
begins with TLS 1.3. | ||||
o Connection mobility: Allowing a connection to be multihomed or | ||||
resilient across network interface or address changes, such as NAT | ||||
rebindings that occur without an endpoint's knowledge. Mobility | ||||
allows cryptographic key material and other state information to | ||||
be reused in the event of a connection change. | ||||
o Application-layer feature negotiation: Securely negotiating | ||||
application-specific functionality. Such features may be | ||||
necessary for further application processing, such as the TLS | ||||
parent connection protocol type via ALPN [RFC7301] or desired | ||||
application identity via SNI [RFC6066]. | ||||
o Configuration extensions: Adding protocol features via extensions | ||||
or configuration options. TLS extensions are a primary example of | ||||
this feature. | ||||
o Out-of-order record receipt: Processing of records received out- | ||||
of-order. | ||||
o Source validation (cookie or puzzle based): Validating peers and | ||||
mitigating denial-of-service (DoS) attacks via explicit proof of | ||||
origin (cookies) or work mechanisms (puzzles). | ||||
o Length-hiding padding: Adding padding to records in order to hide | ||||
plaintext message length and mitigate amplification attack | ||||
vectors. | ||||
4. Transport Security Protocol Descriptions | This section contains brief descriptions of the various security | |||
protocols currently used to protect data being sent over a network. | ||||
The interfaces between these protocols and transports are described | ||||
in Section 4; the interfaces between these protocols and applications | ||||
are described in Section 5. | ||||
This section contains descriptions of security protocols currently | 3.1. Application Payload Security Protocols | |||
used to protect data being sent over a network. | ||||
For each protocol, we describe its provided features and dependencies | The following protocols provide security that protects application | |||
on other protocols. | payloads sent over a transport. They do not specifically protect any | |||
headers used for transport-layer functionality. | ||||
4.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 (possibly encrypted) data from one peer to the other. | |||
This data may contain handshake messages or raw application data. | This data may contain handshake messages or raw application data. | |||
4.1.1. Protocol Description | 3.1.2. DTLS | |||
TLS is the composition of a handshake and record protocol [RFC8446]. | ||||
The record protocol is designed to marshal an arbitrary, in-order | ||||
stream of bytes from one endpoint to the other. It handles | ||||
segmenting, compressing (when enabled), and encrypting data into | ||||
discrete records. When configured to use an authenticated encryption | ||||
with associated data (AEAD) algorithm, it also handles nonce | ||||
generation and encoding for each record. The record protocol is | ||||
hidden from the client behind a bytestream-oriented API. | ||||
The handshake protocol serves several purposes, including: peer | ||||
authentication, protocol option (key exchange algorithm and | ||||
ciphersuite) negotiation, and key derivation. Peer authentication | ||||
may be mutual; however, commonly, only the server is authenticated. | ||||
X.509 certificates are commonly used in this authentication step, | ||||
though other mechanisms, such as raw public keys [RFC7250], exist. | ||||
The client is not authenticated unless explicitly requested by the | ||||
server. | ||||
The handshake protocol is also extensible. It allows for a variety | ||||
of extensions to be included by either the client or server. These | ||||
extensions are used to specify client preferences, e.g., the | ||||
application-layer protocol to be driven with the TLS connection | ||||
[RFC7301], or signals to the server to aid operation, e.g., Server | ||||
Name Indication (SNI) [RFC6066]. Various extensions also exist to | ||||
tune the parameters of the record protocol, e.g., the maximum | ||||
fragment length [RFC6066] and record size limit [RFC8449]. | ||||
Alerts are used to convey errors and other atypical events to the | ||||
endpoints. There are two classes of alerts: closure and error | ||||
alerts. A closure alert is used to signal to the other peer that the | ||||
sender wishes to terminate the connection. The sender typically | ||||
follows a close alert with a TCP FIN segment to close the connection. | ||||
Error alerts are used to indicate problems with the handshake or | ||||
individual records. Most errors are fatal and are followed by | ||||
connection termination. However, warning alerts may be handled at | ||||
the discretion of the implementation. | ||||
Once a session is disconnected all session keying material must be | ||||
destroyed, with the exception of secrets previously established | ||||
expressly for purposes of session resumption. TLS supports stateful | ||||
and stateless resumption. (Here, "state" refers to bookkeeping on a | ||||
per-session basis by the server. It is assumed that the client must | ||||
always store some state information in order to resume a session.) | ||||
4.1.2. Security Features | ||||
o Forward-secure session key establishment. | ||||
o Cryptographic algorithm negotiation. | ||||
o Stateful and stateless cross-connection session resumption. | ||||
o Session caching and management. | ||||
o Peer authentication (Certificate, raw public key, and pre-shared | ||||
key). | ||||
o Unilateral responder authentication. | ||||
o Mutual authentication. | ||||
o Application authentication delegation. | ||||
o Record (channel) confidentiality and integrity. | ||||
o Record replay prevention. | ||||
o Application-layer feature negotiation. | ||||
o Configuration extensions. | ||||
o Early data support (starting with TLS 1.3). | ||||
o Optional record-layer padding (starting with TLS 1.3). | ||||
4.1.3. Protocol Dependencies | ||||
o In-order, reliable bytestream transport. | ||||
o (Optionally) A PKI trust store for certificate validation. | ||||
4.2. DTLS | ||||
DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, | DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, | |||
but differs in that it is designed to run over unreliable datagram | but differs in that it is designed to run over unreliable datagram | |||
protocols like UDP instead of TCP. DTLS modifies the protocol to | protocols like UDP instead of TCP. DTLS modifies the protocol to | |||
make sure it can still provide the same security guarantees as TLS | make sure it can still provide the same security guarantees as TLS | |||
even without reliability from the transport. DTLS was designed to be | even without reliability from the transport. DTLS was designed to be | |||
as similar to TLS as possible, so this document assumes that all | as similar to TLS as possible, so this document assumes that all | |||
properties from TLS are carried over except where specified. | properties from TLS are carried over except where specified. | |||
4.2.1. Protocol Description | 3.2. Application-Specific Security Protocols | |||
DTLS is modified from TLS to operate with the possibility of packet | ||||
loss, reordering, and duplication that may occur when operating over | ||||
UDP. To enable out-of-order delivery of application data, the DTLS | ||||
record protocol itself has no inter-record dependencies. However, as | ||||
the handshake requires reliability, each handshake message is | ||||
assigned an explicit sequence number to enable retransmissions of | ||||
lost packets and in-order processing by the receiver. Handshake | ||||
message loss is remedied by sender retransmission after a | ||||
configurable period in which the expected response has not yet been | ||||
received. | ||||
As the DTLS handshake protocol runs atop the record protocol, to | ||||
account for long handshake messages that cannot fit within a single | ||||
record, DTLS supports fragmentation and subsequent reconstruction of | ||||
handshake messages across records. The receiver must reassemble | ||||
records before processing. | ||||
DTLS relies on unique UDP 4-tuples to identify connections, or a | ||||
similar mechanism in other datagram transports. Since all | ||||
application-layer data is encrypted, demultiplexing over the same | ||||
4-tuple requires the use of a connection identifier extension | ||||
[I-D.ietf-tls-dtls-connection-id] to permit identification of the | ||||
correct connection-specific cryptographic context without the use of | ||||
trial decryption. (Note that this extension is only supported in | ||||
DTLS 1.2 and 1.3 [I-D.ietf-tls-dtls13].) | ||||
Since datagrams can be replayed, DTLS provides optional anti-replay | ||||
detection based on a window of acceptable sequence numbers [RFC6347]. | ||||
4.2.2. Security Features | ||||
o Record replay protection. | ||||
o Record (datagram) confidentiality and integrity. | ||||
o Out-of-order record receipt. | ||||
o DoS mitigation (cookie-based). | ||||
See also the features from TLS. | The following protocols provide application-specific security by | |||
protecting application payloads used for specific use-cases. Unlike | ||||
the protocols above, these are not intended for generic application | ||||
use. | ||||
4.2.3. Protocol Dependencies | 3.2.1. Secure RTP | |||
o DTLS relies on an unreliable datagram transport. | Secure RTP (SRTP) is a profile for RTP that provides confidentiality, | |||
message authentication, and replay protection for RTP data packets | ||||
and RTP control protocol (RTCP) packets [RFC3711]. | ||||
o The DTLS record protocol explicitly encodes record lengths, so | 3.2.2. ZRTP for Media Path Key Agreement | |||
although it runs over a datagram transport, it does not rely on | ||||
the transport protocol's framing beyond requiring transport-level | ||||
reconstruction of datagrams fragmented over packets. (Note: DTLS | ||||
1.3 short header records omit the explicit length field.) | ||||
o Uniqueness of the session within the transport flow (only one DTLS | ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It | |||
connection on a UDP 4-tuple, for example); or else support for the | uses standard SRTP to protect RTP data packets and RTCP packets, but | |||
connection identifier extension to enable demultiplexing. | provides alternative key agreement and identity management protocols. | |||
Key agreement is performed using a Diffie-Hellman key exchange that | ||||
runs on the media path. This generates a shared secret that is then | ||||
used to generate the master key and salt for SRTP. | ||||
o Path MTU discovery. | 3.3. Transport-Layer Security Protocols | |||
o For the handshake: Reliable, in-order transport. DTLS provides | The following security protocols provide protection for both | |||
its own reliability. | application payloads and headers that are used for transport | |||
services. | ||||
4.3. QUIC with TLS | 3.3.1. QUIC with TLS | |||
QUIC is a new standards-track transport protocol that runs over UDP, | QUIC is a new standards-track transport protocol that runs over UDP, | |||
loosely based on Google's original proprietary gQUIC protocol | loosely based on Google's original proprietary gQUIC protocol | |||
[I-D.ietf-quic-transport] (See Section 4.3.4 for more details). The | [I-D.ietf-quic-transport] (See Section 3.3.2 for more details). The | |||
QUIC transport layer itself provides support for data confidentiality | QUIC transport layer itself provides support for data confidentiality | |||
and integrity. This requires keys to be derived with a separate | and integrity. This requires keys to be derived with a separate | |||
handshake protocol. A mapping for QUIC of TLS 1.3 | handshake protocol. A mapping for QUIC of TLS 1.3 | |||
[I-D.ietf-quic-tls] has been specified to provide this handshake. | [I-D.ietf-quic-tls] has been specified to provide this handshake. | |||
4.3.1. Protocol Description | 3.3.2. Google QUIC | |||
As QUIC relies on TLS to secure its transport functions, it creates | ||||
specific integration points between its security and transport | ||||
functions: | ||||
o Starting the handshake to generate keys and provide authentication | ||||
(and providing the transport for the handshake). | ||||
o Client address validation. | ||||
o Key ready events from TLS to notify the QUIC transport. | ||||
o Exporting secrets from TLS to the QUIC transport. | ||||
The QUIC transport layer support multiple streams over a single | ||||
connection. QUIC implements a record protocol for TLS handshake | ||||
messages to establish a connection. These messages are sent in | ||||
CRYPTO frames [I-D.ietf-quic-transport] in Initial and Handshake | ||||
packets. Initial packets are encrypted using fixed keys derived from | ||||
the QUIC version and public packet information (Connection ID). | ||||
Handshake packets are encrypted using TLS handshake secrets. Once | ||||
TLS completes, QUIC uses the resulting traffic secrets to for the | ||||
QUIC connection to protect the rest of the frames. QUIC supports | ||||
0-RTT data using previously negotiated connection secrets Early data | ||||
is sent in 0-RTT packets, which may be included in the same datagram | ||||
as the Initial and Handshake packets. | ||||
4.3.2. Security Features | ||||
o DoS mitigation (cookie-based). | ||||
See also the properties of TLS. | ||||
4.3.3. Protocol Dependencies | ||||
o QUIC transport assumes an unreliable transport, e.g., UDP. | ||||
o QUIC transport relies on TLS 1.3 for key exchange, peer | ||||
authentication, and shared secret derivation. | ||||
o For the handshake: Reliable, in-order transport. QUIC provides | ||||
its own reliability. | ||||
4.3.4. Variant: Google QUIC | ||||
Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol | Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol | |||
designed and deployed by Google following experience from deploying | designed and deployed by Google following experience from deploying | |||
SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally | SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally | |||
known as "QUIC": this document uses gQUIC to unambiguously | known as "QUIC": this document uses gQUIC to unambiguously | |||
distinguish it from the standards-track IETF QUIC. The proprietary | distinguish it from the standards-track IETF QUIC. The proprietary | |||
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. | |||
4.4. IKEv2 with ESP | 3.3.3. tcpcrypt | |||
IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec | ||||
protocol suite that encrypts and authenticates IP packets, either for | ||||
creating tunnels (tunnel-mode) or for direct transport connections | ||||
(transport-mode). This suite of protocols separates out the key | ||||
generation protocol (IKEv2) from the transport encryption protocol | ||||
(ESP). Each protocol can be used independently, but this document | ||||
considers them together, since that is the most common pattern. | ||||
4.4.1. IKEv2 Protocol Description | ||||
IKEv2 is a control protocol that runs on UDP ports 500 or 4500 and | ||||
TCP port 4500. Its primary goal is to generate keys for Security | ||||
Associations (SAs). An SA contains shared (cryptographic) | ||||
information used for establishing other SAs or keying ESP; See | ||||
Section 4.4.2. IKEv2 first uses a Diffie-Hellman key exchange to | ||||
generate keys for the "IKE SA", which is a set of keys used to | ||||
encrypt further IKEv2 messages. IKE then performs a phase of | ||||
authentication in which both peers present blobs signed by a shared | ||||
secret or private key that authenticates the entire IKE exchange and | ||||
the IKE identities. IKE then derives further sets of keys on demand, | ||||
which together with traffic policies are referred to as the "Child | ||||
SA". These Child SA keys are used by ESP. | ||||
IKEv2 negotiates which protocols are acceptable to each peer for both | ||||
the IKE and Child SAs using "Proposals". Each proposal specifies an | ||||
encryption and authentication algorithm, or an AEAD algorithm, a | ||||
Diffie-Hellman group, and (for IKE SAs only) a pseudorandom function | ||||
algorithm. Each peer may support multiple proposals, and the most | ||||
preferred mutually supported proposal is chosen during the handshake. | ||||
The authentication phase of IKEv2 may use Shared Secrets, | ||||
Certificates, Digital Signatures, or an EAP (Extensible | ||||
Authentication Protocol) method. At a minimum, IKEv2 takes two round | ||||
trips to set up both an IKE SA and a Child SA. If EAP is used, this | ||||
exchange may be expanded. | ||||
Any SA used by IKEv2 can be re-keyed before expiration, which is | ||||
usually based either on time or number of bytes encrypted. | ||||
There is an extension to IKEv2 that allows session resumption | ||||
[RFC5723]. | ||||
MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a | ||||
set of Security Associations to migrate over different outer IP | ||||
addresses and interfaces [RFC4555]. | ||||
When UDP is not available or well-supported on a network, IKEv2 may | ||||
be encapsulated in TCP [RFC8229]. | ||||
4.4.2. ESP Protocol Description | ||||
ESP is a protocol that encrypts and authenticates IPv4 and IPv6 | ||||
packets. The keys used for both encryption and authentication can be | ||||
derived from an IKEv2 exchange. ESP Security Associations come as | ||||
pairs, one for each direction between two peers. Each SA is | ||||
identified by a Security Parameter Index (SPI), which is marked on | ||||
each encrypted ESP packet. | ||||
ESP packets include the SPI, a sequence number, an optional | ||||
Initialization Vector (IV), payload data, padding, a length and next | ||||
header field, and an Integrity Check Value. | ||||
From [RFC4303], "ESP is used to provide confidentiality, data origin | ||||
authentication, connectionless integrity, an anti-replay service (a | ||||
form of partial sequence integrity), and limited traffic flow | ||||
confidentiality." | ||||
Since ESP operates on IP packets, it is not directly tied to the | ||||
transport protocols it encrypts. This means it requires little or no | ||||
change from transports in order to provide security. | ||||
ESP packets may be sent directly over IP, but where network | ||||
conditions warrant (e.g., when a NAT is present or when a firewall | ||||
blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP | ||||
[RFC8229]. | ||||
4.4.3. IKEv2 Security Features | ||||
o Forward-secure session key establishment. | ||||
o Cryptographic algorithm negotiation. | ||||
o Peer authentication (certificate, raw public key, pre-shared key, | ||||
and EAP). | ||||
o Unilateral responder authentication. | ||||
o Mutual authentication. | ||||
o Record (datagram) confidentiality and integrity. | ||||
o Session resumption. | ||||
o Connection mobility. | ||||
o DoS mitigation (cookie-based). | ||||
4.4.4. ESP Security Features | ||||
o Record confidentiality and integrity. | ||||
o Record replay protection. | ||||
4.4.5. IKEv2 Protocol Dependencies | ||||
o Availability of UDP to negotiate, or implementation support for | ||||
TCP-encapsulation. | ||||
o Some EAP authentication types require accessing a hardware device, | ||||
such as a SIM card; or interacting with a user, such as password | ||||
prompting. | ||||
4.4.6. ESP Protocol Dependencies | ||||
o Since ESP is below transport protocols, it does not have any | ||||
dependencies on the transports themselves, other than on UDP or | ||||
TCP where encapsulation is employed. | ||||
4.5. Secure RTP (with DTLS) | ||||
Secure RTP (SRTP) is a profile for RTP that provides confidentiality, | ||||
message authentication, and replay protection for RTP data packets | ||||
and RTP control protocol (RTCP) packets [RFC3711]. | ||||
4.5.1. Protocol description | ||||
SRTP adds confidentiality and optional integrity protection to RTP | ||||
data packets, and adds confidentially and mandatory integrity | ||||
protection to RTCP packets. For RTP data packets, this is done by | ||||
encrypting the payload section of the packet and optionally appending | ||||
an authentication tag (MAC) as a packet trailer, with the RTP header | ||||
authenticated but not encrypted (the RTP header was left unencrypted | ||||
to enable RTP header compression [RFC2508] [RFC3545]). For RTCP | ||||
packets, the first packet in the compound RTCP packet is partially | ||||
encrypted, leaving the first eight octets of the header as clear-text | ||||
to allow identification of the packet as RTCP, while the remainder of | ||||
the compound packet is fully encrypted. The entire RTCP packet is | ||||
then authenticated by appending a MAC as packet trailer. | ||||
Packets are encrypted using session keys, which are ultimately | ||||
derived from a master key and an additional master salt and session | ||||
salt. SRTP packets carry a 2-byte sequence number to partially | ||||
identify the unique packet index. SRTP peers maintain a separate | ||||
roll-over counter (ROC) for RTP data packets that is incremented | ||||
whenever the sequence number wraps. The sequence number and ROC | ||||
together determine the packet index. RTCP packets have a similar, | ||||
yet differently named, field called the RTCP index which serves the | ||||
same purpose. | ||||
Numerous encryption modes are supported. For popular modes of | ||||
operation, e.g., AES-CTR, the (unique) initialization vector (IV) | ||||
used for each encryption mode is a function of the RTP SSRC | ||||
(synchronization source), packet index, and session "salting key". | ||||
SRTP offers replay detection by keeping a replay list of already seen | ||||
and processed packet indices. If a packet arrives with an index that | ||||
matches one in the replay list, it is silently discarded. | ||||
DTLS [RFC5764] is commonly used to perform mutual authentication and | ||||
key agreement for SRTP [RFC5763]. Peers use DTLS to perform mutual | ||||
certificate-based authentication on the media path, and to generate | ||||
the SRTP master key. Peer certificates can be issued and signed by a | ||||
certificate authority. Alternatively, certificates used in the DTLS | ||||
exchange can be self-signed. If they are self-signed, certificate | ||||
fingerprints are included in the signaling exchange (e.g., in SIP or | ||||
WebRTC), and used to bind the DTLS key exchange in the media plane to | ||||
the signaling plane. The combination of a mutually authenticated | ||||
DTLS key exchange on the media path and a fingerprint sent in the | ||||
signaling channel protects against active attacks on the media, | ||||
provided the signaling can be trusted. Signaling needs to be | ||||
protected as described in, for example, SIP [RFC3261] Authenticated | ||||
Identity Management [RFC8224] or the WebRTC security architecture | ||||
[I-D.ietf-rtcweb-security-arch], to provide complete system security. | ||||
4.5.2. Security Features | ||||
o Forward-secure session key establishment. | ||||
o Cryptographic algorithm negotiation. | ||||
o Mutual authentication. | ||||
o Partial datagram confidentiality. (Packet headers are not | ||||
encrypted.) | ||||
o Optional authentication of data packets. | ||||
o Mandatory authentication of control packets. | ||||
o Out-of-order record receipt. | ||||
4.5.3. Protocol Dependencies | ||||
o Secure RTP can run over UDP or TCP. | ||||
o External key derivation and management protocol, e.g., DTLS | ||||
[RFC5763]. | ||||
o External identity management protocol, e.g., SIP Authenticated | ||||
Identity Management [RFC8224], WebRTC Security Architecture | ||||
[I-D.ietf-rtcweb-security-arch]. | ||||
4.5.4. Variant: ZRTP for Media Path Key Agreement | ||||
ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It | ||||
uses standard SRTP to protect RTP data packets and RTCP packets, but | ||||
provides alternative key agreement and identity management protocols. | ||||
Key agreement is performed using a Diffie-Hellman key exchange that | ||||
runs on the media path. This generates a shared secret that is then | ||||
used to generate the master key and salt for SRTP. | ||||
ZRTP does not rely on a PKI or external identity management system. | ||||
Rather, it uses an ephemeral Diffie-Hellman key exchange with hash | ||||
commitment to allow detection of man-in-the-middle attacks. This | ||||
requires endpoints to display a short authentication string that the | ||||
users must read and verbally compare to validate the hashes and | ||||
ensure security. Endpoints cache some key material after the first | ||||
call to use in subsequent calls; this is mixed in with the Diffie- | ||||
Hellman shared secret, so the short authentication string need only | ||||
be checked once for a given user. This gives key continuity | ||||
properties analogous to the secure shell (ssh) [RFC4253]. | ||||
4.6. 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. | |||
4.6.1. Protocol Description | 3.3.4. MinimalT | |||
Tcpcrypt extends TCP to enable opportunistic encryption between the | ||||
two ends of a TCP connection [RFC8548]. It is a family of TCP | ||||
encryption protocols (TEP), distinguished by key exchange algorithm. | ||||
The use of a TEP is negotiated with a TCP option during the initial | ||||
TCP handshake via the mechanism described by TCP Encryption | ||||
Negotiation Option (ENO) [RFC8547]. In the case of initial session | ||||
establishment, once a tcpcrypt TEP has been negotiated the key | ||||
exchange occurs within the data segments of the first few packets | ||||
exchanged after the handshake completes. The initiator of a | ||||
connection sends a list of supported AEAD algorithms, a random nonce, | ||||
and an ephemeral public key share. The responder typically chooses a | ||||
mutually-supported AEAD algorithm and replies with this choice, its | ||||
own nonce, and ephemeral key share. An initial shared secret is | ||||
derived from the ENO handshake, the tcpcrypt handshake, and the | ||||
initial keying material resulting from the key exchange. The traffic | ||||
encryption keys on the initial connection are derived from the shared | ||||
secret. Connections can be re-keyed before the natural AEAD limit | ||||
for a single set of traffic encryption keys is reached. | ||||
Each tcpcrypt session is associated with a ladder of resumption IDs, | ||||
each derived from the respective entry in a ladder of shared secrets. | ||||
These resumption IDs can be used to negotiate a stateful resumption | ||||
of the session in a subsequent connection, resulting in use of a new | ||||
shared secret and traffic encryption keys without requiring a new key | ||||
exchange. Willingness to resume a session is signaled via the ENO | ||||
option during the TCP handshake. Given the length constraints | ||||
imposed by TCP options, unlike stateless resumption mechanisms (such | ||||
as that provided by session tickets in TLS) resumption in tcpcrypt | ||||
requires the maintenance of state on the server, and so successful | ||||
resumption across a pool of servers implies shared state. | ||||
Owing to middlebox ossification issues, tcpcrypt only protects the | ||||
payload portion of a TCP packet. It does not encrypt any header | ||||
information, such as the TCP sequence number. | ||||
4.6.2. Security Features | ||||
o Forward-secure session key establishment. | ||||
o Record (channel) confidentiality and integrity. | MinimalT is a UDP-based transport security protocol designed to offer | |||
confidentiality, mutual authentication, DoS prevention, and | ||||
connection mobility [MinimalT]. One major goal of the protocol is to | ||||
leverage existing protocols to obtain server-side configuration | ||||
information used to more quickly bootstrap a connection. MinimalT | ||||
uses a variant of TCP's congestion control algorithm. | ||||
o Stateful cross-connection session resumption. | 3.3.5. CurveCP | |||
o Session caching and management. | CurveCP [CurveCP] is a UDP-based transport security protocol from | |||
Daniel J. Bernstein. Unlike other security protocols, it is based | ||||
entirely upon highly efficient public key algorithms. This removes | ||||
many pitfalls associated with nonce reuse and key synchronization. | ||||
CurveCP provides its own reliability for application data as part of | ||||
its protocol. | ||||
o Application authentication delegation. | 3.4. Packet Security Protocols | |||
4.6.3. Protocol Dependencies | The following protocols provide protection for IP packets. These are | |||
generally used as tunnels, such as for Virtual Private Networks | ||||
(VPNs). Often, applications will not interact directly with these | ||||
protocols. However, applications that implement tunnels will | ||||
interact directly with these protocols. | ||||
o TCP for in-order, reliable transport. | 3.4.1. IKEv2 with ESP | |||
o TCP Encryption Negotiation Option (ENO). | IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec | |||
protocol suite that encrypts and authenticates IP packets, either for | ||||
creating tunnels (tunnel-mode) or for direct transport connections | ||||
(transport-mode). This suite of protocols separates out the key | ||||
generation protocol (IKEv2) from the transport encryption protocol | ||||
(ESP). Each protocol can be used independently, but this document | ||||
considers them together, since that is the most common pattern. | ||||
4.7. WireGuard | 3.4.2. WireGuard | |||
WireGuard is a layer 3 protocol designed as an alternative to IPsec | WireGuard is an IP-layer protocol designed as an alternative to IPsec | |||
[WireGuard] for certain use cases. It uses UDP to encapsulate IP | [WireGuard] for certain use cases. It uses UDP to encapsulate IP | |||
datagrams between peers. Unlike most transport security protocols, | datagrams between peers. Unlike most transport security protocols, | |||
which rely on PKI for peer authentication, WireGuard authenticates | which rely on PKI for peer authentication, WireGuard authenticates | |||
peers using pre-shared public keys delivered out-of-band, each of | peers using pre-shared public keys delivered out-of-band, each of | |||
which is bound to one or more IP addresses. Moreover, as a protocol | which is bound to one or more IP addresses. Moreover, as a protocol | |||
suited for VPNs, WireGuard offers no extensibility, negotiation, or | suited for VPNs, WireGuard offers no extensibility, negotiation, or | |||
cryptographic agility. | cryptographic agility. | |||
4.7.1. Protocol description | 3.4.3. OpenVPN | |||
WireGuard is a simple VPN protocol that binds a pre-shared public key | ||||
to one or more IP addresses. Users configure WireGuard by | ||||
associating peer public keys with IP addresses. These mappings are | ||||
stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard] | ||||
for more details and sample configurations.) These keys are used | ||||
upon WireGuard packet transmission and reception. For example, upon | ||||
receipt of a Handshake Initiation message, receivers use the static | ||||
public key in their CryptoKey routing table to perform necessary | ||||
cryptographic computations. | ||||
WireGuard builds on Noise [Noise] for 1-RTT key exchange with | ||||
identity hiding. The handshake hides peer identities as per the | ||||
SIGMA construction [SIGMA]. As a consequence of using Noise, | ||||
WireGuard comes with a fixed set of cryptographic algorithms: | ||||
o x25519 [Curve25519] and HKDF [RFC5869] for ECDH and key | ||||
derivation. | ||||
o ChaCha20+Poly1305 [RFC8439] for packet authenticated encryption. | ||||
o BLAKE2s [BLAKE2] for hashing. | ||||
There is no cryptographic agility. If weaknesses are found in any of | ||||
these algorithms, new message types using new algorithms must be | ||||
introduced. | ||||
If a WireGuard receiver is under heavy load and cannot process a | ||||
packet, e.g., cannot spare CPU cycles for expensive public key | ||||
cryptographic operations, it can reply with a cookie similar to DTLS | ||||
and IKEv2. This cookie only proves IP address ownership. Any rate | ||||
limiting scheme can be applied to packets coming from non-spoofed | ||||
addresses. | ||||
4.7.2. Security Features | ||||
o Forward-secure session key establishment. | ||||
o Peer authentication (public-key and PSK). | ||||
o Mutual authentication. | ||||
o Record replay prevention (Stateful, timestamp-based). | ||||
o Connection mobility. | ||||
o DoS mitigation (cookie-based). | ||||
4.7.3. Protocol Dependencies | ||||
o Datagram transport. | ||||
o Out-of-band key distribution and management. | ||||
4.8. CurveCP | ||||
CurveCP [CurveCP] is a UDP-based transport security protocol from | ||||
Daniel J. Bernstein. Unlike other transport security protocols, it | ||||
is based entirely upon highly efficient public key algorithms. This | ||||
removes many pitfalls associated with nonce reuse and key | ||||
synchronization. | ||||
4.8.1. Protocol Description | ||||
CurveCP is a UDP-based transport security protocol. It is built on | ||||
three principal features: exclusive use of public key authenticated | ||||
encryption of packets, server-chosen cookies to prohibit memory and | ||||
computation DoS at the server, and connection mobility with a client- | ||||
chosen ephemeral identifier. | ||||
There are two rounds in CurveCP. In the first round, the client | ||||
sends its first initialization packet to the server, carrying its | ||||
(possibly fresh) ephemeral public key C', with zero-padding encrypted | ||||
under the server's long-term public key. The server replies with a | ||||
cookie and its own ephemeral key S' and a cookie that is to be used | ||||
by the client. Upon receipt, the client then generates its second | ||||
initialization packet carrying: the ephemeral key C', cookie, and an | ||||
encryption of C', the server's domain name, and, optionally, some | ||||
message data. The server verifies the cookie and the encrypted | ||||
payload and, if valid, proceeds to send data in return. At this | ||||
point, the connection is established and the two parties can | ||||
communicate. | ||||
The use of public-key encryption and authentication, or "boxing", | ||||
simplifies problems that come with symmetric key management and nonce | ||||
synchronization. For example, it allows the sender of a message to | ||||
be in complete control of each message's nonce. It does not require | ||||
either end to share secret keying material. Furthermore, it allows | ||||
connections (or sessions) to be associated with unique ephemeral | ||||
public keys as a mechanism for enabling forward secrecy given the | ||||
risk of long-term private key compromise. | ||||
The client and server do not perform a standard key exchange. | ||||
Instead, in the initial exchange of packets, each party provides its | ||||
own ephemeral key to the other end. The client can choose a new | ||||
ephemeral key for every new connection. However, the server must | ||||
rotate these keys on a slower basis. Otherwise, it would be trivial | ||||
for an attacker to force the server to create and store ephemeral | ||||
keys with a fake client initialization packet. | ||||
Servers use cookies for source validation. After receiving a | ||||
client's initial packet, encrypted under the server's long-term | ||||
public key, a server generates and returns a stateless cookie that | ||||
must be echoed back in the client's following message. This cookie | ||||
is encrypted under the client's ephemeral public key. This stateless | ||||
technique prevents attackers from hijacking client initialization | ||||
packets to obtain cookie values to flood clients. (A client would | ||||
detect the duplicate cookies and reject the flooded packets.) | ||||
Similarly, replaying the client's second packet, carrying the cookie, | ||||
will be detected by the server. | ||||
CurveCP supports client authentication by allowing clients to send | ||||
their long-term public keys in the second initialization packet. A | ||||
server can verify this public key and, if untrusted, drop the | ||||
connection and subsequent data. | ||||
Unlike some other protocols, CurveCP data packets leave only the | ||||
ephemeral public key, connection ID, and per-message nonce in the | ||||
clear. All other data is encrypted. | ||||
4.8.2. Protocol Features | ||||
o Datagram confidentiality and integrity (via public key | ||||
encryption). | ||||
o Peer authentication (public-key). | ||||
o Unilateral responder authentication. | ||||
o Mutual authentication. | ||||
o Connection mobility (based on a client-chosen ephemeral | ||||
identifier). | ||||
o Optional length-hiding and anti-amplification padding. | ||||
o Source validation (cookie-based) | ||||
4.8.3. Protocol Dependencies | ||||
o An unreliable transport protocol such as UDP. | ||||
4.9. MinimalT | OpenVPN [OpenVPN] is a commonly used protocol designed as an | |||
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 | ||||
transports. OpenVPN encapsulates either IP packets or Ethernet | ||||
frames within a secure tunnel and can run over UDP or TCP. | ||||
MinimalT is a UDP-based transport security protocol designed to offer | 4. Transport Dependencies | |||
confidentiality, mutual authentication, DoS prevention, and | ||||
connection mobility [MinimalT]. One major goal of the protocol is to | ||||
leverage existing protocols to obtain server-side configuration | ||||
information used to more quickly bootstrap a connection. MinimalT | ||||
uses a variant of TCP's congestion control algorithm. | ||||
4.9.1. Protocol Description | Across the different security protocols listed above, the primary | |||
dependency on transport protocols is the presentation of data: either | ||||
an unbounded stream of bytes, or framed messages. Within protocols | ||||
that rely on the transport for message framing, most are built to run | ||||
over transports that inherently provide framing, like UDP, but some | ||||
also define how their messages can be framed over byte-stream | ||||
transports. | ||||
MinimalT is a secure transport protocol built on top of a widespread | 4.1. Reliable Byte-Stream Transports | |||
directory service. Clients and servers interact with local directory | ||||
services to (a) resolve server information and (b) publish ephemeral | ||||
state information, respectively. Clients connect to a local resolver | ||||
once at boot time. Through this resolver they recover the IP | ||||
address(es) and public key(s) of each server to which they want to | ||||
connect. | ||||
Connections are instances of user-authenticated, mobile sessions | The following protocols all depend upon running on a transport | |||
between two endpoints. Connections run within tunnels between hosts. | protocol that provides a reliable, in-order stream of bytes. This is | |||
A tunnel is a server-authenticated container that multiplexes | typically TCP. | |||
multiple connections between the same hosts. All connections in a | ||||
tunnel share the same transport state machine and encryption. Each | ||||
tunnel has a dedicated control connection used to configure and | ||||
manage the tunnel over time. Moreover, since tunnels are independent | ||||
of the network address information, they may be reused as both ends | ||||
of the tunnel move about the network. This does however imply that | ||||
connection establishment and packet encryption mechanisms are | ||||
coupled. | ||||
Before a client connects to a remote service, it must first establish | Application Payload Security Protocols: | |||
a tunnel to the host providing or offering the service. Tunnels are | ||||
established in 1-RTT using an ephemeral key obtained from the | ||||
directory service. Tunnel initiators provide their own ephemeral key | ||||
and, optionally, a DoS puzzle solution such that the recipient | ||||
(server) can verify the authenticity of the request and derive a | ||||
shared secret. Within a tunnel, new connections to services may be | ||||
established. | ||||
Additional (orthogonal) transport features include: connection | o TLS | |||
multiplexing between hosts across shared tunnels, and congestion | ||||
control state is shared across connections between the same host | ||||
pairs. | ||||
4.9.2. Protocol Features | Transport-Layer Security Protocols: | |||
o Record or datagram confidentiality and integrity. | o tcpcrypt | |||
o Forward-secure session key establishment. | Packet Security Protocols: | |||
o Peer authentication (public-key). | o OpenVPN | |||
o Unilateral responder authentication. | 4.2. Unreliable Datagram Transports | |||
o DoS mitigation (puzzle-based). | The following protocols all depend on the transport protocol to | |||
provide message framing to encapsulate their data. These protocols | ||||
are built to run using UDP, and thus do not have any requirement for | ||||
reliability. Running these protocols over a protocol that does | ||||
provide reliability will not break functionality, but may lead to | ||||
multiple layers of reliability if the security protocol is | ||||
encapsulating other transport protocol traffic. | ||||
o Out-of-order receipt record. | Application Payload Security Protocols: | |||
o Connection mobility (based on tunnel identifiers). | o DTLS | |||
4.9.3. Protocol Dependencies | o SRTP | |||
o An unreliable transport protocol such as UDP. | o ZRTP | |||
o A DNS-like resolution service to obtain location information (an | Transport-Layer Security Protocols: | |||
IP address) and ephemeral keys. | ||||
o A PKI trust store for certificate validation. | o QUIC | |||
4.10. OpenVPN | o MinimalT | |||
OpenVPN [OpenVPN] is a commonly used protocol designed as an | o CurveCP | |||
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 | ||||
transports. OpenVPN encapsulates either IP packets or Ethernet | ||||
frames within a secure tunnel and can run over UDP or TCP. | ||||
4.10.1. Protocol Description | Packet Security Protocols: | |||
OpenVPN facilitates authentication using either a pre-shared static | o IKEv2 and ESP | |||
key or using X.509 certificates and TLS. In pre-shared key mode, | ||||
OpenVPN derives keys for encryption and authentication directly from | ||||
one or multiple symmetric keys. In TLS mode, OpenVPN encapsulates a | ||||
TLS handshake, in which both peers must present a certificate for | ||||
authentication. After the handshake, both sides contribute random | ||||
source material to derive keys for encryption and authentication | ||||
using the TLS pseudo random function (PRF). OpenVPN provides the | ||||
possibility to authenticate and encrypt the TLS handshake itself | ||||
using a pre-shared key or passphrase. Furthermore, it supports re- | ||||
keying using TLS. | ||||
After authentication and key exchange, OpenVPN encrypts payload data, | o WireGuard | |||
i.e., IP packets or Ethernet frames, and authenticates the payload | ||||
using HMAC. Applications can select an arbitrary encryption | ||||
algorithm (cipher) and key size, as well hash function for HMAC. The | ||||
default cipher and hash functions are AES-GCM and SHA1, respectively. | ||||
Recent versions of the protocol support cipher negotiation. | ||||
OpenVPN can run over TCP or UDP. When running over UDP, OpenVPN | 4.2.1. Datagram Protocols with Defined Byte-Stream Mappings | |||
provides a simple reliability layer for control packets such as the | ||||
TLS handshake and key exchange. It assigns sequence numbers to | ||||
packets, acknowledges packets it receives, and retransmits packets it | ||||
deems lost. Similar to DTLS, this reliability layer is not used for | ||||
data packets, which prevents the problem of two reliability | ||||
mechanisms being encapsulated within each other. When running over | ||||
TCP, OpenVPN includes the packet length in the header, which allows | ||||
the peer to deframe the TCP stream into messages. | ||||
For replay protection, OpenVPN assigns an identifier to each outgoing | Of the protocols listed above that depend on the transport for | |||
packet, which is unique for the packet and the currently used key. | message framing, some do have well-defined mappings for sending their | |||
In pre-shared key mode or with a CFB or OFB mode cipher, OpenVPN | messages over byte-stream transports like TCP. | |||
combines a timestamp with an incrementing sequence number into a | ||||
64-bit identifier. In TLS mode with CBC cipher mode, OpenVPN omits | ||||
the timestamp, so identifiers are only 32-bit. This is sufficient | ||||
since OpenVPN can guarantee the uniqueness of this identifier for | ||||
each key, as it can trigger re-keying if needed. | ||||
OpenVPN supports connection mobility by allowing a peer to change its | Application Payload Security Protocols: | |||
IP address during an ongoing session. When configured accordingly, a | ||||
host will accept authenticated packets for a session from any IP | ||||
address. | ||||
4.10.2. Protocol Features | o SRTP [RFC7201] | |||
o Peer authentication using certificates or pre-shared key. | Packet Security Protocols: | |||
o Mandatory mutual authentication. | o IKEv2 and ESP [RFC8229] | |||
o Connection mobility. | 4.3. Transport-Specific Dependencies | |||
o Out-of-order record receipt. | One protocol surveyed, tcpcrypt, has an direct dependency on a | |||
feature in the transport that is needed for its functionality. | ||||
Specific, tcpcrypt is designed to run on top of TCP, and uses the TCP | ||||
Encryption Negotiation Option (ENO) [RFC8547] to negotiate its | ||||
protocol support. | ||||
o Length-hiding padding. | QUIC, CurveCP, and MinimalT provide both transport functionality and | |||
security functionality. They have a dependencies on running over a | ||||
framed protocol like UDP, but they add their own layers of | ||||
reliability and other transport services. Thus, an application that | ||||
uses one of these protocols cannot decouple the security from | ||||
transport functionality. | ||||
See also the properties of TLS. | 5. Application Interface | |||
4.10.3. Protocol Dependencies | This section describes the interface surface exposed by the security | |||
protocols described above. Note that not all protocols support each | ||||
interface. We partition these interfaces into pre-connection | ||||
(configuration), connection, and post-connection interfaces, | ||||
following conventions in [I-D.ietf-taps-interface] and | ||||
[I-D.ietf-taps-arch]. | ||||
o For control packets such as handshake and key exchange: Reliable, | 5.1. Pre-Connection Interfaces | |||
in-order transport. Reliability is provided either by TCP, or by | ||||
OpenVPN's own reliability layer when using UDP. | ||||
5. Security Features and Application Dependencies | Configuration interfaces are used to configure the security protocols | |||
before a handshake begins or the keys are negotiated. | ||||
There exists a common set of features shared across the transport | o Identities and Private Keys: The application can provide its | |||
protocols surveyed in this document. Mandatory features constitute a | identities (certificates) and private keys, or mechanisms to | |||
baseline of functionality that an application may assume for any | access these, to the security protocol to use during handshakes. | |||
Transport Services implementation. They were selected on the basis | ||||
that they are either (a) required for any secure transport protocol | ||||
or (b) nearly ubiquitous amongst common secure transport protocols. | ||||
Optional features by contrast may vary from implementation to | * TLS | |||
implementation, and so an application cannot simply assume they are | ||||
available. Applications learn of and use optional features by | ||||
querying for their presence and support. Optional features may not | ||||
be implemented, or may be disabled if their presence impacts | ||||
transport services or if a necessary transport service or application | ||||
dependency is unavailable. | ||||
In this context, an application dependency is an aspect of the | * DTLS | |||
security feature which can be exposed to the application. An | ||||
application dependency may be required for the security feature to | ||||
function, or it may provide additional information and control to the | ||||
application. For example, an application may need to provide | ||||
information such as keying material or authentication credentials, or | ||||
it may want to restrict which cryptographic algorithms to allow for | ||||
negotiation. | ||||
5.1. Mandatory Features | * SRTP | |||
Mandatory features must be supported regardless of transport and | * QUIC | |||
application services available. Note that not all mandatory features | ||||
are provided by each surveyed protocol above. For example, tcpcrypt | ||||
does not provide responder authentication and CurveCP does not | ||||
provide forward-secure session key establishment. | ||||
o Record or datagram confidentiality and integrity. | * MinimalT | |||
* Application dependency: None. | * CurveCP | |||
o Forward-secure session key establishment. | * IKEv2 | |||
* Application dependency: None. | * WireGuard | |||
o Unilateral responder authentication. | o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): | |||
The application can choose the algorithms that are supported for | ||||
key exchange, signatures, and ciphersuites. | ||||
* (Optional) Application dependency: Application-provided trust | * TLS | |||
information. System trust stores may also be used to | ||||
authenticate responders. | ||||
5.2. Optional Features | * DTLS | |||
In this section we list optional features along with their necessary | * SRTP | |||
application dependencies, if any. | ||||
o Pre-shared key support (PSK): | * QUIC | |||
* Application dependency: Application provisioning and | * tcpcrypt | |||
distribution of pre-shared keys. | ||||
o Mutual authentication (MA): | * MinimalT | |||
* Application dependency: Mutual authentication credentials | * IKEv2 | |||
required. | ||||
o Cryptographic algorithm negotiation (AN): | o Extensions (Application-Layer Protocol Negotiation): The | |||
application enables or configures extensions that are to be | ||||
negotiated by the security protocol, such as ALPN [RFC7301]. | ||||
* Application dependency: Application awareness of supported or | * TLS | |||
desired algorithms. | ||||
o Application authentication delegation (AD): | * DTLS | |||
* Application dependency: Application opt-in and policy for | * QUIC | |||
endpoint authentication. | ||||
o DoS mitigation (DM): | o Session Cache Management: The application provides the ability to | |||
save and retrieve session state (such as tickets, keying material, | ||||
and server parameters) that may be used to resume the security | ||||
session. | ||||
* Application dependency: None. | * TLS | |||
o Connection mobility (CM): | * DTLS | |||
* Application dependency: None. | * QUIC | |||
o Source validation (SV): | * MinimalT | |||
* Application dependency: None. | o Authentication Delegation: The application provides access to a | |||
separate module that will provide authentication, using EAP for | ||||
example. | ||||
o Application-layer feature negotiation (AFN): | * SRTP | |||
* Application dependency: Specification of application-layer | * IKEv2 | |||
features or functionality. | ||||
o Configuration extensions (CX): | o Pre-Shared Key Import: Either the handshake protocol or the | |||
application directly can supply pre-shared keys for the record | ||||
protocol use for encryption/decryption and authentication. If the | ||||
application can supply keys directly, this is considered explicit | ||||
import; if the handshake protocol traditionally provides the keys | ||||
directly, it is considered direct import; if the keys can only be | ||||
shared by the handshake, they are considered non-importable. | ||||
* Application dependency: Specification of application-specific | * Explicit import: QUIC, ESP | |||
extensions. | ||||
o Session caching and management (SC): | * Direct import: TLS, DTLS, tcpcrypt, MinimalT, WireGuard | |||
* Application dependency: None. | * Non-importable: CurveCP | |||
o Length-hiding padding (LHP): (Optional) Application dependency: | 5.2. Connection Interfaces | |||
Knowledge of desired padding policies. Some protocols, such as | ||||
IKE, can negotiate application-agnostic padding policies. | ||||
o Early data support (ED): | o Identity Validation: During a handshake, the security protocol | |||
will conduct identity validation of the peer. This can call into | ||||
the application to offload validation. | ||||
* Application dependency: Anti-replay protections or hints of | * TLS | |||
data idempotency. | ||||
o Record replay prevention (RP): | * DTLS | |||
* Application dependency: None. | * SRTP | |||
o Out-of-order receipt record (OO): | * QUIC | |||
* Application dependency: None. | * MinimalT | |||
5.3. Optional Feature Availability | * CurveCP | |||
The following table lists the availability of the above-listed | * IKEv2 | |||
optional features in each of the analyzed protocols. "Mandatory" | ||||
indicates that the feature is intrinsic to the protocol and cannot be | ||||
disabled. "Supported" indicates that the feature is optionally | ||||
provided natively or through a (standardized, where applicable) | ||||
extension. | ||||
+-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+ | * WireGuard | |||
| Pro | P | A | A | M | D | C | S | A | CX | SC | LH | ED | RP | OO | | ||||
| toc | S | N | D | A | M | M | V | F | | | P | | | | | ||||
| ol | K | | | | | | | N | | | | | | | | ||||
+-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+ | ||||
| TLS | S | S | S | S | S | U | M | S | S | S | S | S | U | U | | ||||
| | | | | | | * | | | | | | | | | | ||||
| | | | | | | | | | | | | | | | | ||||
| DTL | S | S | S | S | S | S | M | S | S | S | S | U | M | M | | ||||
| S | | | | | | | | | | | | | | | | ||||
| | | | | | | | | | | | | | | | | ||||
| QUI | S | S | S | S | S | S | M | S | S | S | S | S | M | M | | ||||
| C | | | | | | | | | | | | | | | | ||||
| | | | | | | | | | | | | | | | | ||||
| IKE | S | S | S | M | S | S | M | S | S | S | S | U | M | M | | ||||
| v2+ | | | | | | | | | | | | | | | | ||||
| ESP | | | | | | | | | | | | | | | | ||||
| | | | | | | | | | | | | | | | | ||||
| SRT | S | S | S | S | S | U | M | S | S | S | U | U | M | M | | ||||
| P+D | | | | | | | | | | | | | | | | ||||
| TLS | | | | | | | | | | | | | | | | ||||
| | | | | | | | | | | | | | | | | ||||
| tcp | U | S | M | U | U | U | M | U | U | S | U | U | U | U | | ||||
| cry | | | | | * | * | | | | | | | | | | ||||
| pt | | | | | * | | | | | | | | | | | ||||
| | | | | | | | | | | | | | | | | ||||
| Wir | S | U | S | M | S | U | M | U | U | U | S+ | U | M | M | | ||||
| eGu | | | | | | | | | | | | | | | | ||||
| ard | | | | | | | | | | | | | | | | ||||
| | | | | | | | | | | | | | | | | ||||
| Min | U | U | U | M | S | M | M | U | U | U | S | U | U | U | | ||||
| ima | | | | | | | | | | | | | | | | ||||
| lT | | | | | | | | | | | | | | | | ||||
| | | | | | | | | | | | | | | | | ||||
| Cur | U | U | U | S | S | M | M | U | U | U | S | U | M | M | | ||||
| veC | | | | | | | | | | | | | | | | ||||
| P | | | | | | | | | | | | | | | | ||||
+-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+ | ||||
M=Mandatory S=Supported but not required U=Unsupported *=On TCP; | * OpenVPN | |||
MPTCP would provide this ability **=TCP provides SYN cookies | ||||
natively, but these are not cryptographically strong +=For transport | ||||
packets only | ||||
6. Transport Security Protocol Interfaces | o Source Address Validation: The handshake protocol may delegate | |||
validation of the remote peer that has sent data to the transport | ||||
protocol or application. This involves sending a cookie exchange | ||||
to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard | ||||
This section describes the interface surface exposed by the security | * DTLS | |||
protocols described above. Note that not all protocols support each | ||||
interface. We partition these interfaces into pre-connection | ||||
(configuration), connection, and post-connection interfaces, | ||||
following conventions in [I-D.ietf-taps-interface] and | ||||
[I-D.ietf-taps-arch]. | ||||
6.1. Pre-Connection Interfaces | * QUIC | |||
Configuration interfaces are used to configure the security protocols | * WireGuard | |||
before a handshake begins or the keys are negotiated. | ||||
o Identities and Private Keys The application can provide its | 5.3. Post-Connection Interfaces | |||
identities (certificates) and private keys, or mechanisms to | ||||
access these, to the security protocol to use during handshakes. | ||||
Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, | ||||
WireGuard, SRTP | ||||
o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) | o Connection Termination: The security protocol may be instructed to | |||
The application can choose the algorithms that are supported for | tear down its connection and session information. This is needed | |||
key exchange, signatures, and ciphersuites. Protocols: TLS, DTLS, | by some protocols to prevent application data truncation attacks. | |||
QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP | ||||
o Extensions (Application-Layer Protocol Negotiation): The | * TLS | |||
application enables or configures extensions that are to be | ||||
negotiated by the security protocol, such as ALPN [RFC7301]. | ||||
Protocols: TLS, DTLS, QUIC + TLS | ||||
o Session Cache Management The application provides the ability to | * DTLS | |||
save and retrieve session state (such as tickets, keying material, | ||||
and server parameters) that may be used to resume the security | ||||
session. Protocols: TLS, DTLS, QUIC + TLS, MinimalT | ||||
o Authentication Delegation The application provides access to a | * QUIC | |||
separate module that will provide authentication, using EAP for | ||||
example. Protocols: IKEv2, SRTP | ||||
o Pre-Shared Key Import Either the handshake protocol or the | * tcpcrypt | |||
application directly can supply pre-shared keys for the record | * MinimalT | |||
protocol use for encryption/decryption and authentication. If the | ||||
application can supply keys directly, this is considered explicit | ||||
import; if the handshake protocol traditionally provides the keys | ||||
directly, it is considered direct import; if the keys can only be | ||||
shared by the handshake, they are considered non-importable. | ||||
* Explicit import: QUIC, ESP | * IKEv2 | |||
* Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard | ||||
* Non-importable: CurveCP | o Key Update: The handshake protocol may be instructed to update its | |||
keying material, either by the application directly or by the | ||||
record protocol sending a key expiration event. | ||||
6.2. Connection Interfaces | * TLS | |||
o Identity Validation During a handshake, the security protocol will | * DTLS | |||
conduct identity validation of the peer. This can call into the | ||||
application to offload validation. Protocols: All (TLS, DTLS, | ||||
QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) | ||||
o Source Address Validation The handshake protocol may delegate | * QUIC | |||
validation of the remote peer that has sent data to the transport | ||||
protocol or application. This involves sending a cookie exchange | ||||
to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard | ||||
6.3. Post-Connection Interfaces | * tcpcrypt | |||
o Connection Termination The security protocol may be instructed to | * MinimalT | |||
tear down its connection and session information. This is needed | ||||
by some protocols to prevent application data truncation attacks. | ||||
Protocols: TLS, DTLS, QUIC, tcpcrypt, IKEv2, MinimalT | ||||
o Key Update The handshake protocol may be instructed to update its | * IKEv2 | |||
keying material, either by the application directly or by the | ||||
record protocol sending a key expiration event. Protocols: TLS, | ||||
DTLS, QUIC, tcpcrypt, IKEv2, MinimalT | ||||
o Pre-Shared Key Export The handshake protocol will generate one or | o Pre-Shared Key Export: The handshake protocol will generate one or | |||
more keys to be used for record encryption/decryption and | more keys to be used for record encryption/decryption and | |||
authentication. These may be explicitly exportable to the | authentication. These may be explicitly exportable to the | |||
application, traditionally limited to direct export to the record | application, traditionally limited to direct export to the record | |||
protocol, or inherently non-exportable because the keys must be | protocol, or inherently non-exportable because the keys must be | |||
used directly in conjunction with the record protocol. | used directly in conjunction with the record protocol. | |||
* Explicit export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for | * Explicit export: TLS (for QUIC), DTLS (for SRTP), tcpcrypt, | |||
SRTP) | IKEv2 | |||
* Direct export: TLS, DTLS, MinimalT | * Direct export: TLS, DTLS, MinimalT | |||
* Non-exportable: CurveCP | * Non-exportable: CurveCP | |||
o Key Expiration The record protocol can signal that its keys are | o Key Expiration: The record protocol can signal that its keys are | |||
expiring due to reaching a time-based deadline, or a use-based | 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. Protocols: ESP ((Editor's note: | layer and the handshake layer. | |||
One may consider TLS/DTLS to also have this interface)) | ||||
o Mobility Events The record protocol can be signaled that it is | * ESP | |||
o Mobility Events: The record protocol can be signaled that it is | ||||
being migrated to another transport or interface due to connection | being migrated to another transport or interface due to connection | |||
mobility, which may reset address and state validation and induce | mobility, which may reset address and state validation and induce | |||
state changes such as use of a new Connection Identifier (CID). | state changes such as use of a new Connection Identifier (CID). | |||
Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming) | ||||
7. IANA Considerations | * QUIC | |||
* MinimalT | ||||
* CurveCP | ||||
* ESP | ||||
* WireGuard | ||||
6. IANA Considerations | ||||
This document has no request to IANA. | This document has no request to IANA. | |||
8. Security Considerations | 7. Security Considerations | |||
This document summarizes existing transport security protocols and | This document summarizes existing transport security protocols and | |||
their interfaces. It does not propose changes to or recommend usage | their interfaces. It does not propose changes to or recommend usage | |||
of reference protocols. Moreover, no claims of security and privacy | of reference protocols. Moreover, no claims of security and privacy | |||
properties beyond those guaranteed by the protocols discussed are | properties beyond those guaranteed by the protocols discussed are | |||
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. | |||
9. 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 reducing information leakage via encryption. | |||
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. | |||
10. 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 | |||
their input and feedback on this draft. | their input and feedback on this draft. | |||
11. Informative References | 10. Informative References | |||
[ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt, | [ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt, | |||
B., and J. Boeuf, "Application Layer Transport Security", | B., and J. Boeuf, "Application Layer Transport Security", | |||
<https://cloud.google.com/security/encryption-in-transit/ | <https://cloud.google.com/security/encryption-in-transit/ | |||
application-layer-transport-security/>. | application-layer-transport-security/>. | |||
[BLAKE2] Aumasson, J., Neves, S., Wilcox-O'Hearn, Z., and C. | ||||
Winnerlein, "BLAKE2 -- simpler, smaller, fast as MD5", | ||||
<https://blake2.net/blake2.pdf>. | ||||
[Curve25519] | ||||
Bernstein, D., "Curve25519 - new Diffie-Hellman speed | ||||
records", <https://cr.yp.to/ecdh/curve25519-20060209.pdf>. | ||||
[CurveCP] Bernstein, D., "CurveCP -- Usable security for the | [CurveCP] Bernstein, D., "CurveCP -- Usable security for the | |||
Internet", <http://curvecp.org>. | Internet", <http://curvecp.org>. | |||
[I-D.ietf-quic-tls] | [I-D.ietf-quic-tls] | |||
Thomson, M. and S. Turner, "Using TLS to Secure QUIC", | Thomson, M. and S. Turner, "Using TLS to Secure QUIC", | |||
draft-ietf-quic-tls-23 (work in progress), September 2019. | draft-ietf-quic-tls-23 (work in progress), September 2019. | |||
[I-D.ietf-quic-transport] | [I-D.ietf-quic-transport] | |||
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed | Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed | |||
and Secure Transport", draft-ietf-quic-transport-23 (work | and Secure Transport", draft-ietf-quic-transport-23 (work | |||
in progress), September 2019. | in progress), September 2019. | |||
[I-D.ietf-rtcweb-security-arch] | ||||
Rescorla, E., "WebRTC Security Architecture", draft-ietf- | ||||
rtcweb-security-arch-20 (work in progress), July 2019. | ||||
[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", draft-ietf-taps-arch-04 (work in | Transport Services", draft-ietf-taps-arch-04 (work in | |||
progress), July 2019. | progress), July 2019. | |||
[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", draft-ietf-taps-interface-04 (work in | Transport Services", draft-ietf-taps-interface-04 (work in | |||
progress), July 2019. | progress), July 2019. | |||
[I-D.ietf-taps-minset] | ||||
Welzl, M. and S. Gjessing, "A Minimal Set of Transport | ||||
Services for End Systems", draft-ietf-taps-minset-11 (work | ||||
in progress), September 2018. | ||||
[I-D.ietf-tls-dtls-connection-id] | ||||
Rescorla, E., Tschofenig, H., and T. Fossati, "Connection | ||||
Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- | ||||
id-06 (work in progress), July 2019. | ||||
[I-D.ietf-tls-dtls13] | ||||
Rescorla, E., Tschofenig, H., and N. Modadugu, "The | ||||
Datagram Transport Layer Security (DTLS) Protocol Version | ||||
1.3", draft-ietf-tls-dtls13-32 (work in progress), July | ||||
2019. | ||||
[MinimalT] | [MinimalT] | |||
Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and | Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and | |||
T. Lange, "MinimaLT -- Minimal-latency Networking Through | T. Lange, "MinimaLT -- Minimal-latency Networking Through | |||
Better Security", | Better Security", | |||
<http://dl.acm.org/citation.cfm?id=2516737>. | <http://dl.acm.org/citation.cfm?id=2516737>. | |||
[Noise] Perrin, T., "The Noise Protocol Framework", | ||||
<http://noiseprotocol.org/noise.pdf>. | ||||
[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>. | |||
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP | ||||
Headers for Low-Speed Serial Links", RFC 2508, | ||||
DOI 10.17487/RFC2508, February 1999, | ||||
<https://www.rfc-editor.org/info/rfc2508>. | ||||
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, | ||||
A., Peterson, J., Sparks, R., Handley, M., and E. | ||||
Schooler, "SIP: Session Initiation Protocol", RFC 3261, | ||||
DOI 10.17487/RFC3261, June 2002, | ||||
<https://www.rfc-editor.org/info/rfc3261>. | ||||
[RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and | ||||
P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with | ||||
High Delay, Packet Loss and Reordering", RFC 3545, | ||||
DOI 10.17487/RFC3545, July 2003, | ||||
<https://www.rfc-editor.org/info/rfc3545>. | ||||
[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>. | |||
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. | ||||
Stenberg, "UDP Encapsulation of IPsec ESP Packets", | ||||
RFC 3948, DOI 10.17487/RFC3948, January 2005, | ||||
<https://www.rfc-editor.org/info/rfc3948>. | ||||
[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 | ||||
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, | ||||
<https://www.rfc-editor.org/info/rfc4555>. | ||||
[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>. | |||
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange | ||||
Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, | ||||
DOI 10.17487/RFC5723, January 2010, | ||||
<https://www.rfc-editor.org/info/rfc5723>. | ||||
[RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework | ||||
for Establishing a Secure Real-time Transport Protocol | ||||
(SRTP) Security Context Using Datagram Transport Layer | ||||
Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May | ||||
2010, <https://www.rfc-editor.org/info/rfc5763>. | ||||
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer | ||||
Security (DTLS) Extension to Establish Keys for the Secure | ||||
Real-time Transport Protocol (SRTP)", RFC 5764, | ||||
DOI 10.17487/RFC5764, May 2010, | ||||
<https://www.rfc-editor.org/info/rfc5764>. | ||||
[RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand | ||||
Key Derivation Function (HKDF)", RFC 5869, | ||||
DOI 10.17487/RFC5869, May 2010, | ||||
<https://www.rfc-editor.org/info/rfc5869>. | ||||
[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>. | |||
[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>. | ||||
[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: | [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: | |||
Media Path Key Agreement for Unicast Secure RTP", | Media Path Key Agreement for Unicast Secure RTP", | |||
RFC 6189, DOI 10.17487/RFC6189, April 2011, | RFC 6189, DOI 10.17487/RFC6189, April 2011, | |||
<https://www.rfc-editor.org/info/rfc6189>. | <https://www.rfc-editor.org/info/rfc6189>. | |||
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer | |||
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, | Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, | |||
January 2012, <https://www.rfc-editor.org/info/rfc6347>. | January 2012, <https://www.rfc-editor.org/info/rfc6347>. | |||
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., | [RFC7201] Westerlund, M. and C. Perkins, "Options for Securing RTP | |||
Weiler, S., and T. Kivinen, "Using Raw Public Keys in | Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014, | |||
Transport Layer Security (TLS) and Datagram Transport | <https://www.rfc-editor.org/info/rfc7201>. | |||
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, | ||||
June 2014, <https://www.rfc-editor.org/info/rfc7250>. | ||||
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. | |||
Kivinen, "Internet Key Exchange Protocol Version 2 | Kivinen, "Internet Key Exchange Protocol Version 2 | |||
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October | (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October | |||
2014, <https://www.rfc-editor.org/info/rfc7296>. | 2014, <https://www.rfc-editor.org/info/rfc7296>. | |||
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, | [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, | |||
"Transport Layer Security (TLS) Application-Layer Protocol | "Transport Layer Security (TLS) Application-Layer Protocol | |||
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, | Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, | |||
July 2014, <https://www.rfc-editor.org/info/rfc7301>. | July 2014, <https://www.rfc-editor.org/info/rfc7301>. | |||
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, | [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, | |||
Ed., "Services Provided by IETF Transport Protocols and | Ed., "Services Provided by IETF Transport Protocols and | |||
Congestion Control Mechanisms", RFC 8095, | Congestion Control Mechanisms", RFC 8095, | |||
DOI 10.17487/RFC8095, March 2017, | DOI 10.17487/RFC8095, March 2017, | |||
<https://www.rfc-editor.org/info/rfc8095>. | <https://www.rfc-editor.org/info/rfc8095>. | |||
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, | ||||
"Authenticated Identity Management in the Session | ||||
Initiation Protocol (SIP)", RFC 8224, | ||||
DOI 10.17487/RFC8224, February 2018, | ||||
<https://www.rfc-editor.org/info/rfc8224>. | ||||
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation | [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation | |||
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, | of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, | |||
August 2017, <https://www.rfc-editor.org/info/rfc8229>. | August 2017, <https://www.rfc-editor.org/info/rfc8229>. | |||
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF | ||||
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018, | ||||
<https://www.rfc-editor.org/info/rfc8439>. | ||||
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol | |||
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, | |||
<https://www.rfc-editor.org/info/rfc8446>. | <https://www.rfc-editor.org/info/rfc8446>. | |||
[RFC8449] Thomson, M., "Record Size Limit Extension for TLS", | ||||
RFC 8449, DOI 10.17487/RFC8449, August 2018, | ||||
<https://www.rfc-editor.org/info/rfc8449>. | ||||
[RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. | [RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. | |||
Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547, | Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547, | |||
DOI 10.17487/RFC8547, May 2019, | DOI 10.17487/RFC8547, May 2019, | |||
<https://www.rfc-editor.org/info/rfc8547>. | <https://www.rfc-editor.org/info/rfc8547>. | |||
[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, | [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, | |||
Q., and E. Smith, "Cryptographic Protection of TCP Streams | Q., and E. Smith, "Cryptographic Protection of TCP Streams | |||
(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, | (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, | |||
<https://www.rfc-editor.org/info/rfc8548>. | <https://www.rfc-editor.org/info/rfc8548>. | |||
[SIGMA] Krawczyk, H., "SIGMA -- The 'SIGn-and-MAc' Approach to | ||||
Authenticated Diffie-Hellman and Its Use in the IKE- | ||||
Protocols", <http://www.iacr.org/cryptodb/archive/2003/ | ||||
CRYPTO/1495/1495.pdf>. | ||||
[WireGuard] | [WireGuard] | |||
Donenfeld, J., "WireGuard -- Next Generation Kernel | Donenfeld, J., "WireGuard -- Next Generation Kernel | |||
Network Tunnel", | Network Tunnel", | |||
<https://www.wireguard.com/papers/wireguard.pdf>. | <https://www.wireguard.com/papers/wireguard.pdf>. | |||
Authors' Addresses | Authors' Addresses | |||
Christopher A. Wood (editor) | ||||
Apple Inc. | ||||
One Apple Park Way | ||||
Cupertino, California 95014 | ||||
United States of America | ||||
Email: cawood@apple.com | ||||
Theresa Enghardt | Theresa Enghardt | |||
TU Berlin | TU Berlin | |||
Marchstr. 23 | Marchstr. 23 | |||
10587 Berlin | 10587 Berlin | |||
Germany | Germany | |||
Email: theresa@inet.tu-berlin.de | Email: theresa@inet.tu-berlin.de | |||
Tommy Pauly | Tommy Pauly | |||
Apple Inc. | Apple Inc. | |||
skipping to change at page 37, line 27 ¶ | skipping to change at page 19, line 4 ¶ | |||
Email: tpauly@apple.com | Email: tpauly@apple.com | |||
Colin Perkins | Colin Perkins | |||
University of Glasgow | University of Glasgow | |||
School of Computing Science | School of Computing Science | |||
Glasgow G12 8QQ | Glasgow G12 8QQ | |||
United Kingdom | United Kingdom | |||
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) | ||||
Apple Inc. | ||||
One Apple Park Way | ||||
Cupertino, California 95014 | ||||
United States of America | ||||
Email: cawood@apple.com | ||||
End of changes. 169 change blocks. | ||||
1208 lines changed or deleted | 349 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/ |