draft-ietf-taps-transport-security-12.txt   rfc8922.txt 
Network Working Group T. Enghardt Internet Engineering Task Force (IETF) T. Enghardt
Internet-Draft TU Berlin Request for Comments: 8922 TU Berlin
Intended status: Informational T. Pauly Category: Informational T. Pauly
Expires: 25 October 2020 Apple Inc. ISSN: 2070-1721 Apple Inc.
C. Perkins C. Perkins
University of Glasgow University of Glasgow
K. Rose K. Rose
Akamai Technologies, Inc. Akamai Technologies, Inc.
C.A. Wood C. Wood
Cloudflare Cloudflare
23 April 2020 October 2020
A Survey of the Interaction Between Security Protocols and Transport A Survey of the Interaction between Security Protocols and Transport
Services Services
draft-ietf-taps-transport-security-12
Abstract Abstract
This document provides a survey of commonly used or notable network This document provides a survey of commonly used or notable network
security protocols, with a focus on how they interact and integrate security protocols, with a focus on how they interact and integrate
with applications and transport protocols. Its goal is to supplement with applications and transport protocols. Its goal is to supplement
efforts to define and catalog transport services by describing the efforts to define and catalog Transport Services by describing the
interfaces required to add security protocols. This survey is not interfaces required to add security protocols. This survey is not
limited to protocols developed within the scope or context of the limited to protocols developed within the scope or context of the
IETF, and those included represent a superset of features a Transport IETF, and those included represent a superset of features a Transport
Services system may need to support. Services system may need to support.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for informational purposes.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Not all documents
approved by the IESG are candidates for any level of Internet
Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 25 October 2020. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8922.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Simplified BSD License text as described in Section 4.e of
provided without warranty as described in the Simplified BSD License. the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Goals
1.2. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Non-goals
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology
3. Transport Security Protocol Descriptions . . . . . . . . . . 6 3. Transport Security Protocol Descriptions
3.1. Application Payload Security Protocols . . . . . . . . . 7 3.1. Application Payload Security Protocols
3.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. TLS
3.1.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. DTLS
3.2. Application-Specific Security Protocols . . . . . . . . . 8 3.2. Application-Specific Security Protocols
3.2.1. Secure RTP . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Secure RTP
3.3. Transport-Layer Security Protocols . . . . . . . . . . . 8 3.3. Transport-Layer Security Protocols
3.3.1. IETF QUIC . . . . . . . . . . . . . . . . . . . . . . 8 3.3.1. IETF QUIC
3.3.2. Google QUIC . . . . . . . . . . . . . . . . . . . . . 9 3.3.2. Google QUIC
3.3.3. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . 9 3.3.3. tcpcrypt
3.3.4. MinimaLT . . . . . . . . . . . . . . . . . . . . . . 9 3.3.4. MinimaLT
3.3.5. CurveCP . . . . . . . . . . . . . . . . . . . . . . . 9 3.3.5. CurveCP
3.4. Packet Security Protocols . . . . . . . . . . . . . . . . 9 3.4. Packet Security Protocols
3.4.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.1. IPsec
3.4.2. WireGuard . . . . . . . . . . . . . . . . . . . . . . 10 3.4.2. WireGuard
3.4.3. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.3. OpenVPN
4. Transport Dependencies . . . . . . . . . . . . . . . . . . . 10 4. Transport Dependencies
4.1. Reliable Byte-Stream Transports . . . . . . . . . . . . . 10 4.1. Reliable Byte-Stream Transports
4.2. Unreliable Datagram Transports . . . . . . . . . . . . . 11 4.2. Unreliable Datagram Transports
4.2.1. Datagram Protocols with Defined Byte-Stream 4.2.1. Datagram Protocols with Defined Byte-Stream Mappings
Mappings . . . . . . . . . . . . . . . . . . . . . . 11 4.3. Transport-Specific Dependencies
4.3. Transport-Specific Dependencies . . . . . . . . . . . . . 12 5. Application Interface
5. Application Interface . . . . . . . . . . . . . . . . . . . . 12 5.1. Pre-connection Interfaces
5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 12 5.2. Connection Interfaces
5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 15 5.3. Post-connection Interfaces
5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 16 5.4. Summary of Interfaces Exposed by Protocols
5.4. Summary of Interfaces Exposed by Protocols . . . . . . . 17 6. IANA Considerations
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. Privacy Considerations
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 9. Informative References
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 Acknowledgments
10. Informative References . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Services and features provided by transport protocols have been Services and features provided by transport protocols have been
cataloged in [RFC8095]. This document supplements that work by cataloged in [RFC8095]. This document supplements that work by
surveying commonly used and notable network security protocols, and surveying commonly used and notable network security protocols, and
identifying the interfaces between these protocols and both transport identifying the interfaces between these protocols and both transport
protocols and applications. It examines Transport Layer Security protocols and applications. It examines Transport Layer Security
(TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google
QUIC (gQUIC), tcpcrypt, Internet Protocol Security (IPsec), Secure QUIC (gQUIC), tcpcrypt, Internet Protocol Security (IPsec), Secure
Real-time Transport Protocol (SRTP) with DTLS, WireGuard, CurveCP, Real-time Transport Protocol (SRTP) with DTLS, WireGuard, CurveCP,
and MinimaLT. For each protocol, this document provides a brief and MinimaLT. For each protocol, this document provides a brief
description. Then, it describes the interfaces between these description. Then, it describes the interfaces between these
protocols and transports in Section 4 and the interfaces between protocols and transports in Section 4 and the interfaces between
these protocols and applications in Section 5. these protocols and applications in Section 5.
A Transport Services system exposes an interface for applications to A Transport Services system exposes an interface for applications to
access various (secure) transport protocol features. The security access various (secure) transport protocol features. The security
protocols included in this survey represent a superset of protocols included in this survey represent a superset of
functionality and features a Transport Services system may need to functionality and features a Transport Services system may need to
support, both internally and externally (via an API) for applications support both internally and externally (via an API) for applications
[I-D.ietf-taps-arch]. Ubiquitous IETF protocols such as (D)TLS, as [TAPS-ARCH]. Ubiquitous IETF protocols such as (D)TLS, as well as
well as non-standard protocols such as gQUIC, are included despite non-standard protocols such as gQUIC, are included despite
overlapping features. As such, this survey is not limited to overlapping features. As such, this survey is not limited to
protocols developed within the scope or context of the IETF. Outside protocols developed within the scope or context of the IETF. Outside
of this candidate set, protocols that do not offer new features are of this candidate set, protocols that do not offer new features are
omitted. For example, newer protocols such as WireGuard make unique omitted. For example, newer protocols such as WireGuard make unique
design choices that have implications for and limitations on design choices that have implications for and limitations on
application usage. In contrast, protocols such as SSH [RFC4253], GRE application usage. In contrast, protocols such as secure shell (SSH)
[RFC2890], L2TP [RFC5641], and ALTS [ALTS] are omitted since they do [RFC4253], GRE [RFC2890], the Layer 2 Tunneling Protocol (L2TP)
not provide interfaces deemed unique. [RFC5641], and Application Layer Transport Security (ALTS) [ALTS] are
omitted since they do not provide interfaces deemed unique.
Authentication-only protocols such as TCP-AO [RFC5925] and IPsec Authentication-only protocols such as the TCP Authentication Option
Authentication Header (AH) [RFC4302] are excluded from this survey. (TCP-AO) [RFC5925] and the IPsec Authentication Header (AH) [RFC4302]
TCP-AO adds authentication to long-lived TCP connections, e.g., are excluded from this survey. TCP-AO adds authentication to long-
replay protection with per-packet Message Authentication Codes. lived TCP connections, e.g., replay protection with per-packet
(TCP-AO obsoletes TCP MD5 "signature" options specified in Message Authentication Codes. (TCP-AO obsoletes TCP MD5 "signature"
[RFC2385].) One primary use case of TCP-AO is for protecting BGP options specified in [RFC2385].) One primary use case of TCP-AO is
connections. Similarly, AH adds per-datagram authentication and for protecting BGP connections. Similarly, AH adds per-datagram
integrity, along with replay protection. Despite these improvements, authentication and integrity, along with replay protection. Despite
neither protocol sees general use and both lack critical properties these improvements, neither protocol sees general use and both lack
important for emergent transport security protocols, such as critical properties important for emergent transport security
confidentiality and privacy protections. Such protocols are thus protocols, such as confidentiality and privacy protections. Such
omitted from this survey. protocols are thus omitted from this survey.
This document only surveys point-to-point protocols; multicast This document only surveys point-to-point protocols; multicast
protocols are out of scope. protocols are out of scope.
1.1. Goals 1.1. Goals
This survey is intended to help identify the most common interface This survey is intended to help identify the most common interface
surfaces between security protocols and transport protocols, and surfaces between security protocols and transport protocols, and
between security protocols and applications. between security protocols and applications.
One of the goals of the Transport Services effort is to define a One of the goals of the Transport Services effort is to define a
common interface for using transport protocols that allows software common interface for using transport protocols that allows software
using transport protocols to easily adopt new protocols that provide using transport protocols to easily adopt new protocols that provide
similar feature-sets. The survey of the dependencies security similar feature sets. The survey of the dependencies security
protocols have upon transport protocols can guide implementations in protocols have upon transport protocols can guide implementations in
determining which transport protocols are appropriate to be able to determining which transport protocols are appropriate to be able to
use beneath a given security protocol. For example, a security use beneath a given security protocol. For example, a security
protocol that expects to run over a reliable stream of bytes, like protocol that expects to run over a reliable stream of bytes, like
TLS, restricts the set of transport protocols that can be used to TLS, restricts the set of transport protocols that can be used to
those that offer a reliable stream of bytes. those that offer a reliable stream of bytes.
Defining the common interfaces that security protocols provide to Defining the common interfaces that security protocols provide to
applications also allows interfaces to be designed in a way that applications also allows interfaces to be designed in a way that
common functionality can use the same APIs. For example, many common functionality can use the same APIs. For example, many
security protocols that provide authentication let the application be security protocols that provide authentication let the application be
involved in peer identity validation. Any interface to use a secure involved in peer identity validation. Any interface to use a secure
transport protocol stack thus needs to allow applications to perform transport protocol stack thus needs to allow applications to perform
this action during connection establishment. this action during connection establishment.
1.2. Non-Goals 1.2. Non-goals
While this survey provides similar analysis to that which was While this survey provides similar analysis to that which was
performed for transport protocols in [RFC8095], it is important to performed for transport protocols in [RFC8095], it is important to
distinguish that the use of security protocols requires more distinguish that the use of security protocols requires more
consideration. consideration.
It is not a goal to allow software implementations to automatically It is not a goal to allow software implementations to automatically
switch between different security protocols, even where their switch between different security protocols, even where their
interfaces to transport and applications are equivalent. Even interfaces to transport and applications are equivalent. Even
between versions, security protocols have subtly different guarantees between versions, security protocols have subtly different guarantees
skipping to change at page 5, line 35 skipping to change at line 208
protocol that provides the described features. In doing so, it may protocol that provides the described features. In doing so, it may
need to expose an interface to the application to configure these need to expose an interface to the application to configure these
features. features.
2. Terminology 2. Terminology
The following terms are used throughout this document to describe the The following terms are used throughout this document to describe the
roles and interactions of transport security protocols (some of which roles and interactions of transport security protocols (some of which
are also defined in [RFC8095]): are also defined in [RFC8095]):
* Transport Feature: a specific end-to-end feature that the Transport Feature: a specific end-to-end feature that the transport
transport layer provides to an application. Examples include layer provides to an application. Examples include
confidentiality, reliable delivery, ordered delivery, and message- confidentiality, reliable delivery, ordered delivery, and message-
versus-stream orientation. versus-stream orientation.
* Transport Service: a set of Transport Features, without an Transport Service: a set of Transport Features, without an
association to any given framing protocol, which provides association to any given framing protocol, that provides
functionality to an application. functionality to an application.
* Transport Services system: a software component that exposes an Transport Services system: a software component that exposes an
interface to different Transport Services to an application. interface to different Transport Services to an application.
* Transport Protocol: an implementation that provides one or more Transport Protocol: an implementation that provides one or more
different transport services using a specific framing and header different Transport Services using a specific framing and header
format on the wire. A Transport Protocol services an application, format on the wire. A Transport Protocol services an application,
whether directly or in conjunction with a security protocol. whether directly or in conjunction with a security protocol.
* Application: an entity that uses a transport protocol for end-to- Application: an entity that uses a transport protocol for end-to-end
end delivery of data across the network. This may also be an delivery of data across the network. This may also be an upper
upper layer protocol or tunnel encapsulation. layer protocol or tunnel encapsulation.
* Security Protocol: a defined network protocol that implements one Security Protocol: a defined network protocol that implements one or
or more security features, such as authentication, encryption, key more security features, such as authentication, encryption, key
generation, session resumption, and privacy. Security protocols generation, session resumption, and privacy. Security protocols
may be used alongside transport protocols, and in combination with may be used alongside transport protocols, and in combination with
other security protocols when appropriate. other security protocols when appropriate.
* Handshake Protocol: a protocol that enables peers to validate each 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.
* Record: Framed protocol messages. Record: framed protocol messages.
* Record Protocol: a security protocol that allows data to be Record Protocol: a security protocol that allows data to be divided
divided into manageable blocks and protected using shared into manageable blocks and protected using shared cryptographic
cryptographic context. context.
* Session: an ephemeral security association between applications. Session: an ephemeral security association between applications.
* Connection: the shared state of two or more endpoints that Connection: the shared state of two or more endpoints that persists
persists across messages that are transmitted between these across messages that are transmitted between these endpoints. A
endpoints. A connection is a transient participant of a session, connection is a transient participant of a session, and a session
and a session generally lasts between connection instances. generally lasts between connection instances.
* Peer: an endpoint application party to a session. Peer: an endpoint application party to a session.
* Client: the peer responsible for initiating a session. Client: the peer responsible for initiating a session.
* Server: the peer responsible for responding to a session Server: the peer responsible for responding to a session initiation.
initiation.
3. Transport Security Protocol Descriptions 3. Transport Security Protocol Descriptions
This section contains brief transport and security descriptions of This section contains brief transport and security descriptions of
various security protocols currently used to protect data being sent various security protocols currently used to protect data being sent
over a network. These protocols are grouped based on where in the over a network. These protocols are grouped based on where in the
protocol stack they are implemented, which influences which parts of protocol stack they are implemented, which influences which parts of
a packet they protect: Generic application payload, application a packet they protect: Generic application payload, application
payload for specific application-layer protocols, both application payload for specific application-layer protocols, both application
payload and transport headers, or entire IP packets. payload and transport headers, or entire IP packets.
skipping to change at page 7, line 14 skipping to change at line 281
* A handshake protocol, which is responsible for negotiating * A handshake protocol, which is responsible for negotiating
parameters, authenticating the endpoints, and establishing shared parameters, authenticating the endpoints, and establishing shared
keys. keys.
* A record protocol, which is used to encrypt traffic using keys and * A record protocol, which is used to encrypt traffic using keys and
parameters provided by the handshake protocol. parameters provided by the handshake protocol.
For some protocols, such as tcpcrypt, these two components are For some protocols, such as tcpcrypt, these two components are
tightly integrated. In contrast, for IPsec, these components are tightly integrated. In contrast, for IPsec, these components are
implemented in separate protocols: AH and ESP are record protocols, implemented in separate protocols: AH and the Encapsulating Security
which can use keys supplied by the handshake protocol IKEv2, by other Payload (ESP) are record protocols, which can use keys supplied by
handshake protocols, or by manual configuration. Moreover, some the handshake protocol Internet Key Exchange Protocol Version 2
protocols can be used in different ways: While the base TLS protocol (IKEv2), by other handshake protocols, or by manual configuration.
as defined in [RFC8446] has an integrated handshake and record Moreover, some protocols can be used in different ways: While the
protocol, TLS or DTLS can also be used to negotiate keys for other base TLS protocol as defined in [RFC8446] has an integrated handshake
protocols, as in DTLS-SRTP, or the handshake protocol can be used and record protocol, TLS or DTLS can also be used to negotiate keys
with a separate record layer, as in QUIC [I-D.ietf-quic-transport]. for other protocols, as in DTLS-SRTP, or the handshake protocol can
be used with a separate record layer, as in QUIC [QUIC-TRANSPORT].
3.1. Application Payload Security Protocols 3.1. Application Payload Security Protocols
The following protocols provide security that protects application The following protocols provide security that protects application
payloads sent over a transport. They do not specifically protect any payloads sent over a transport. They do not specifically protect any
headers used for transport-layer functionality. headers used for transport-layer functionality.
3.1.1. TLS 3.1.1. TLS
TLS (Transport Layer Security) [RFC8446] is a common protocol used to TLS (Transport Layer Security) [RFC8446] is a common protocol used to
establish a secure session between two endpoints. Communication over establish a secure session between two endpoints. Communication over
this session "prevents eavesdropping, tampering, and message this session prevents "eavesdropping, tampering, and message
forgery." TLS consists of a tightly coupled handshake and record forgery." TLS consists of a tightly coupled handshake and record
protocol. The handshake protocol is used to authenticate peers, protocol. The handshake protocol is used to authenticate peers,
negotiate protocol options, such as cryptographic algorithms, and negotiate protocol options such as cryptographic algorithms, and
derive session-specific keying material. The record protocol is used derive session-specific keying material. The record protocol is used
to marshal and, once the handshake has sufficiently progressed, to marshal and, once the handshake has sufficiently progressed,
encrypt, data from one peer to the other. This data may contain encrypt data from one peer to the other. This data may contain
handshake messages or raw application data. handshake messages or raw application data.
3.1.2. DTLS 3.1.2. DTLS
DTLS (Datagram Transport Layer Security) [RFC6347] DTLS (Datagram Transport Layer Security) [RFC6347] [DTLS-1.3] is
[I-D.ietf-tls-dtls13] is based on TLS, but differs in that it is based on TLS, but differs in that it is designed to run over
designed to run over unreliable datagram protocols like UDP instead unreliable datagram protocols like UDP instead of TCP. DTLS modifies
of TCP. DTLS modifies the protocol to make sure it can still provide the protocol to make sure it can still provide equivalent security
equivalent security guarantees to TLS with the exception of order guarantees to TLS with the exception of order protection/non-
protection/non-replayability. DTLS was designed to be as similar to replayability. DTLS was designed to be as similar to TLS as
TLS as possible, so this document assumes that all properties from possible, so this document assumes that all properties from TLS are
TLS are carried over except where specified. carried over except where specified.
3.2. Application-Specific Security Protocols 3.2. Application-Specific Security Protocols
The following protocols provide application-specific security by The following protocols provide application-specific security by
protecting application payloads used for specific use-cases. Unlike protecting application payloads used for specific use cases. Unlike
the protocols above, these are not intended for generic application the protocols above, these are not intended for generic application
use. use.
3.2.1. Secure RTP 3.2.1. Secure RTP
Secure RTP (SRTP) is a profile for RTP that provides confidentiality, Secure RTP (SRTP) is a profile for RTP that provides confidentiality,
message authentication, and replay protection for RTP data packets message authentication, and replay protection for RTP data packets
and RTP control protocol (RTCP) packets [RFC3711]. SRTP provides a and RTP control protocol (RTCP) packets [RFC3711]. SRTP provides a
record layer only, and requires a separate handshake protocol to record layer only, and requires a separate handshake protocol to
provide key agreement and identity management. provide key agreement and identity management.
The commonly used handshake protocol for SRTP is DTLS, in the form of The commonly used handshake protocol for SRTP is DTLS, in the form of
DTLS-SRTP [RFC5764]. This is an extension to DTLS that negotiates DTLS-SRTP [RFC5764]. This is an extension to DTLS that negotiates
the use of SRTP as the record layer, and describes how to export keys the use of SRTP as the record layer and describes how to export keys
for use with SRTP. for use with SRTP.
ZRTP [RFC6189] is an alternative key agreement and identity ZRTP [RFC6189] is an alternative key agreement and identity
management protocol for SRTP. ZRTP Key agreement is performed using management protocol for SRTP. ZRTP Key agreement is performed using
a Diffie-Hellman key exchange that runs on the media path. This a Diffie-Hellman key exchange that runs on the media path. This
generates a shared secret that is then used to generate the master generates a shared secret that is then used to generate the master
key and salt for SRTP. key and salt for SRTP.
3.3. Transport-Layer Security Protocols 3.3. Transport-Layer Security Protocols
The following security protocols provide protection for both The following security protocols provide protection for both
application payloads and headers that are used for transport application payloads and headers that are used for Transport
services. Services.
3.3.1. IETF QUIC 3.3.1. IETF QUIC
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 3.3.2 for more details). The [QUIC-TRANSPORT] (See Section 3.3.2 for more details). The QUIC
QUIC transport layer itself provides support for data confidentiality transport layer itself provides support for data confidentiality and
and integrity. This requires keys to be derived with a separate 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 [QUIC-TLS] has
[I-D.ietf-quic-tls] has been specified to provide this handshake. been specified to provide this handshake.
3.3.2. Google QUIC 3.3.2. 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.
3.3.3. tcpcrypt 3.3.3. tcpcrypt
Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for
opportunistic encryption. Applications may use tcpcrypt's unique opportunistic encryption. Applications may use tcpcrypt's unique
session ID for further application-level authentication. Absent this session ID for further application-level authentication. Absent this
authentication, tcpcrypt is vulnerable to active attacks. authentication, tcpcrypt is vulnerable to active attacks.
3.3.4. MinimaLT 3.3.4. MinimaLT
skipping to change at page 10, line 22 skipping to change at line 421
(ESP). Each protocol can be used independently, but this document (ESP). Each protocol can be used independently, but this document
considers them together, since that is the most common pattern. considers them together, since that is the most common pattern.
3.4.2. WireGuard 3.4.2. WireGuard
WireGuard [WireGuard] is an IP-layer protocol designed as an WireGuard [WireGuard] is an IP-layer protocol designed as an
alternative to IPsec for certain use cases. It uses UDP to alternative to IPsec for certain use cases. It uses UDP to
encapsulate IP datagrams between peers. Unlike most transport encapsulate IP datagrams between peers. Unlike most transport
security protocols, which rely on Public Key Infrastructure (PKI) for security protocols, which rely on Public Key Infrastructure (PKI) for
peer authentication, WireGuard authenticates peers using pre-shared peer authentication, WireGuard authenticates peers using pre-shared
public keys delivered out-of-band, each of which is bound to one or public keys delivered out of band, each of which is bound to one or
more IP addresses. Moreover, as a protocol suited for VPNs, more IP addresses. Moreover, as a protocol suited for VPNs,
WireGuard offers no extensibility, negotiation, or cryptographic WireGuard offers no extensibility, negotiation, or cryptographic
agility. agility.
3.4.3. OpenVPN 3.4.3. OpenVPN
OpenVPN [OpenVPN] is a commonly used protocol designed as an OpenVPN [OpenVPN] is a commonly used protocol designed as an
alternative to IPsec. A major goal of this protocol is to provide a alternative to IPsec. A major goal of this protocol is to provide a
VPN that is simple to configure and works over a variety of VPN that is simple to configure and works over a variety of
transports. OpenVPN encapsulates either IP packets or Ethernet transports. OpenVPN encapsulates either IP packets or Ethernet
skipping to change at page 11, line 19 skipping to change at line 466
Transport-Layer Security Protocols: Transport-Layer Security Protocols:
* tcpcrypt * tcpcrypt
4.2. Unreliable Datagram Transports 4.2. Unreliable Datagram Transports
The following protocols all depend on the transport protocol to The following protocols all depend on the transport protocol to
provide message framing to encapsulate their data. These protocols provide message framing to encapsulate their data. These protocols
are built to run using UDP, and thus do not have any requirement for are built to run using UDP, and thus do not have any requirement for
reliability. Running these protocols over a protocol that does reliability. Running these protocols over a protocol that does
provide reliability will not break functionality, but may lead to provide reliability will not break functionality but may lead to
multiple layers of reliability if the security protocol is multiple layers of reliability if the security protocol is
encapsulating other transport protocol traffic. encapsulating other transport protocol traffic.
Application Payload Security Protocols: Application Payload Security Protocols:
* DTLS * DTLS
* ZRTP * ZRTP
* SRTP * SRTP
skipping to change at page 12, line 19 skipping to change at line 514
* ZRTP [RFC6189] * ZRTP [RFC6189]
* SRTP [RFC4571][RFC3711] * SRTP [RFC4571][RFC3711]
Packet Security Protocols: Packet Security Protocols:
* IPsec [RFC8229] * IPsec [RFC8229]
4.3. Transport-Specific Dependencies 4.3. Transport-Specific Dependencies
One protocol surveyed, tcpcrypt, has an direct dependency on a One protocol surveyed, tcpcrypt, has a direct dependency on a feature
feature in the transport that is needed for its functionality. in the transport that is needed for its functionality. Specifically,
Specifically, tcpcrypt is designed to run on top of TCP, and uses the tcpcrypt is designed to run on top of TCP and uses the TCP Encryption
TCP Encryption Negotiation Option (ENO) [RFC8547] to negotiate its Negotiation Option (TCP-ENO) [RFC8547] to negotiate its protocol
protocol support. support.
QUIC, CurveCP, and MinimaLT provide both transport functionality and QUIC, CurveCP, and MinimaLT provide both transport functionality and
security functionality. They depend on running over a framed security functionality. They depend on running over a framed
protocol like UDP, but they add their own layers of reliability and protocol like UDP, but they add their own layers of reliability and
other transport services. Thus, an application that uses one of other Transport Services. Thus, an application that uses one of
these protocols cannot decouple the security from transport these protocols cannot decouple the security from transport
functionality. functionality.
5. Application Interface 5. Application Interface
This section describes the interface exposed by the security This section describes the interface exposed by the security
protocols described above. We partition these interfaces into pre- protocols described above. We partition these interfaces into pre-
connection (configuration), connection, and post-connection connection (configuration), connection, and post-connection
interfaces, following conventions in [I-D.ietf-taps-interface] and interfaces, following conventions in [TAPS-INTERFACE] and
[I-D.ietf-taps-arch]. [TAPS-ARCH].
Note that not all protocols support each interface. The table in Note that not all protocols support each interface. The table in
Section 5.4 summarizes which protocol exposes which of the Section 5.4 summarizes which protocol exposes which of the
interfaces. In the following sections, we provide abbreviations of interfaces. In the following sections, we provide abbreviations of
the interface names to use in the summary table. the interface names to use in the summary table.
5.1. Pre-Connection Interfaces 5.1. Pre-connection Interfaces
Configuration interfaces are used to configure the security protocols Configuration interfaces are used to configure the security protocols
before a handshake begins or keys are negotiated. before a handshake begins or keys are negotiated.
* Identities and Private Keys (IPK): The application can provide its Identities and Private Keys (IPK): The application can provide its
identity, credentials (e.g., certificates), and private keys, or identity, credentials (e.g., certificates), and private keys, or
mechanisms to access these, to the security protocol to use during mechanisms to access these, to the security protocol to use during
handshakes. handshakes.
- TLS * TLS
- DTLS * DTLS
- ZRTP * ZRTP
- QUIC * QUIC
- MinimaLT * MinimaLT
- CurveCP * CurveCP
- IPsec * IPsec
- WireGuard * WireGuard
- OpenVPN * OpenVPN
* Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) Supported Algorithms (Key Exchange, Signatures, and Ciphersuites)
(ALG): The application can choose the algorithms that are (ALG): The application can choose the algorithms that are supported
supported for key exchange, signatures, and ciphersuites. for key exchange, signatures, and ciphersuites.
- TLS * TLS
- DTLS * DTLS
- ZRTP * ZRTP
- QUIC * QUIC
- tcpcrypt * tcpcrypt
- MinimaLT * MinimaLT
- IPsec * IPsec
- OpenVPN * OpenVPN
* Extensions (EXT): The application enables or configures extensions Extensions (EXT): The application enables or configures extensions
that are to be negotiated by the security protocol, such as that are to be negotiated by the security protocol, such as
Application-Layer Protocol Negotiation (ALPN) [RFC7301]. Application-Layer Protocol Negotiation (ALPN) [RFC7301].
- TLS * TLS
- DTLS
- QUIC * DTLS
* Session Cache Management (CM): The application provides the * QUIC
ability to save and retrieve session state (such as tickets,
keying material, and server parameters) that may be used to resume
the security session.
- TLS Session Cache Management (CM): 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.
- DTLS * TLS
- ZRTP * DTLS
- QUIC * ZRTP
- tcpcrypt * QUIC
- MinimaLT * tcpcrypt
* Authentication Delegation (AD): The application provides access to * MinimaLT
a separate module that will provide authentication, using
Authentication Delegation (AD): The application provides access to a
separate module that will provide authentication, using the
Extensible Authentication Protocol (EAP) [RFC3748] for example. Extensible Authentication Protocol (EAP) [RFC3748] for example.
- IPsec * IPsec
- tcpcrypt * tcpcrypt
* Pre-Shared Key Import (PSKI): Either the handshake protocol or the Pre-Shared Key Import (PSKI): Either the handshake protocol or the
application directly can supply pre-shared keys for use in application directly can supply pre-shared keys for use in
encrypting (and authenticating) communication with a peer. encrypting (and authenticating) communication with a peer.
- TLS * TLS
- DTLS * DTLS
- ZRTP * ZRTP
- QUIC * QUIC
- tcpcrypt * tcpcrypt
- MinimaLT * MinimaLT
- IPsec * IPsec
- WireGuard * WireGuard
- OpenVPN
* OpenVPN
5.2. Connection Interfaces 5.2. Connection Interfaces
* Identity Validation (IV): During a handshake, the security Identity Validation (IV): During a handshake, the security protocol
protocol will conduct identity validation of the peer. This can will conduct identity validation of the peer. This can offload
offload validation or occur transparently to the application. validation or occur transparently to the application.
- TLS * TLS
- DTLS * DTLS
- ZRTP * ZRTP
- QUIC * QUIC
- MinimaLT * MinimaLT
- CurveCP * CurveCP
- IPsec * IPsec
- WireGuard * WireGuard
- OpenVPN * OpenVPN
* Source Address Validation (SAV): The handshake protocol may Source Address Validation (SAV): The handshake protocol may interact
interact with the transport protocol or application to validate with the transport protocol or application to validate the address
the address of the remote peer that has sent data. This involves of the remote peer that has sent data. This involves sending a
sending a cookie exchange to avoid DoS attacks. (This list omits cookie exchange to avoid DoS attacks. (This list omits protocols
protocols which depend on TCP and therefore implicitly perform that depend on TCP and therefore implicitly perform SAV.)
SAV.)
- DTLS * DTLS
- QUIC * QUIC
- IPsec * IPsec
- WireGuard * WireGuard
5.3. Post-Connection Interfaces 5.3. Post-connection Interfaces
* Connection Termination (CT): The security protocol may be Connection Termination (CT): The security protocol may be instructed
instructed to tear down its connection and session information. to tear down its connection and session information. This is
This is needed by some protocols, e.g., to prevent application needed by some protocols, e.g., to prevent application data
data truncation attacks in which an attacker terminates an truncation attacks in which an attacker terminates an underlying
underlying insecure connection-oriented protocol to terminate the insecure connection-oriented protocol to terminate the session.
session.
- TLS * TLS
- DTLS * DTLS
- ZRTP * ZRTP
- QUIC * QUIC
- tcpcrypt * tcpcrypt
- MinimaLT * MinimaLT
- IPsec * IPsec
- OpenVPN * OpenVPN
* Key Update (KU): The handshake protocol may be instructed to Key Update (KU): The handshake protocol may be instructed to update
update its keying material, either by the application directly or its keying material, either by the application directly or by the
by the record protocol sending a key expiration event. record protocol sending a key expiration event.
- TLS * TLS
- DTLS * DTLS
- QUIC * QUIC
- tcpcrypt * tcpcrypt
- MinimaLT * MinimaLT
- IPsec * IPsec
* Shared Secret Export (PSKE): The handshake protocol may provide an Shared Secret Key Export (SSKE): The handshake protocol may provide
interface for producing shared secrets for application-specific an interface for producing shared secrets for application-specific
uses. uses.
- TLS * TLS
- DTLS * DTLS
- tcpcrypt
- IPsec * tcpcrypt
- OpenVPN * IPsec
- MinimaLT * OpenVPN
* Key Expiration (KE): The record protocol can signal that its keys * MinimaLT
are expiring due to reaching a time-based deadline, or a use-based
Key Expiration (KE): The record protocol can signal that its keys
are expiring due to reaching a time-based deadline or a use-based
deadline (number of bytes that have been encrypted with the key). deadline (number of bytes that have been encrypted with the key).
This interaction is often limited to signaling between the record This interaction is often limited to signaling between the record
layer and the handshake layer. layer and the handshake layer.
- IPsec * IPsec
* Mobility Events (ME): The record protocol can be signaled that it Mobility Events (ME): The record protocol can be signaled that it is
is being migrated to another transport or interface due to being migrated to another transport or interface due to connection
connection mobility, which may reset address and state validation mobility, which may reset address and state validation and induce
and induce state changes such as use of a new Connection state changes such as use of a new Connection Identifier (CID).
Identifier (CID).
- DTLS (version 1.3 only [I-D.ietf-tls-dtls13]) * DTLS (version 1.3 only [DTLS-1.3])
- QUIC * QUIC
- MinimaLT * MinimaLT
- CurveCP * CurveCP
- IPsec [RFC4555] * IPsec [RFC4555]
- WireGuard * WireGuard
5.4. Summary of Interfaces Exposed by Protocols 5.4. Summary of Interfaces Exposed by Protocols
The following table summarizes which protocol exposes which The following table summarizes which protocol exposes which
interface. interface.
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+
| Protocol |IPK|ALG | EXT |CM|AD| PSKI |IV| SAV |CT|KU| PSKE |KE|ME| | Protocol |IPK|ALG | EXT |CM|AD| PSKI |IV| SAV |CT|KU| SSKE |KE|ME|
+===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+ +===========+===+====+=====+==+==+======+==+=====+==+==+======+==+==+
| TLS | x | x | x |x | | x |x | |x |x | x | | | | TLS | x | x | x |x | | x |x | |x |x | x | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| DTLS | x | x | x |x | | x |x | x |x |x | x | |x | | DTLS | x | x | x |x | | x |x | x |x |x | x | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| ZRTP | x | x | |x | | x |x | |x | | | | | | ZRTP | x | x | |x | | x |x | |x | | | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| QUIC | x | x | x |x | | x |x | x |x |x | | |x | | QUIC | x | x | x |x | | x |x | x |x |x | | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| tcpcrypt | | x | |x |x | x | | |x |x | x | | | | tcpcrypt | | x | |x |x | x | | |x |x | x | | |
skipping to change at page 18, line 31 skipping to change at line 795
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| IPsec | x | x | | |x | x |x | x |x |x | x |x |x | | IPsec | x | x | | |x | x |x | x |x |x | x |x |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| WireGuard | x | | | | | x |x | x | | | | |x | | WireGuard | x | | | | | x |x | x | | | | |x |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
| OpenVPN | x | x | | | | x |x | |x | | x | | | | OpenVPN | x | x | | | | x |x | |x | | x | | |
+-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+ +-----------+---+----+-----+--+--+------+--+-----+--+--+------+--+--+
Table 1 Table 1
x=Interface is exposed (blank)=Interface is not exposed x = Interface is exposed
(blank) = Interface is not exposed
6. IANA Considerations 6. IANA Considerations
This document has no request to IANA. This document has no IANA actions.
7. 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
skipping to change at page 19, line 16 skipping to change at line 825
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 using encryption to reduce information leakage. improve privacy by using encryption to reduce information leakage.
However, varying amounts of metadata remain in the clear across each However, varying amounts of metadata remain in the clear across each
protocol. For example, client and server certificates are sent in protocol. For example, client and server certificates are sent in
cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3 cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3
[RFC8446]. A survey of privacy features, or lack thereof, for [RFC8446]. A survey of privacy features, or lack thereof, for
various security protocols could be addressed in a separate document. various security protocols could be addressed in a separate document.
9. Acknowledgments 9. Informative References
The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja
Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for
their input and feedback on this draft.
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/>.
[CurveCP] Bernstein, D.J., "CurveCP -- Usable security for the [CurveCP] Bernstein, D., "CurveCP: Usable security for the
Internet", <http://curvecp.org>. Internet", <https://curvecp.org/>.
[I-D.ietf-quic-tls]
Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
Work in Progress, Internet-Draft, draft-ietf-quic-tls-27,
21 February 2020, <http://www.ietf.org/internet-drafts/
draft-ietf-quic-tls-27.txt>.
[I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-27, 21 February 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-quic-
transport-27.txt>.
[I-D.ietf-taps-arch]
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
Perkins, C., Tiesel, P., and C. Wood, "An Architecture for
Transport Services", Work in Progress, Internet-Draft,
draft-ietf-taps-arch-07, 9 March 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-taps-arch-
07.txt>.
[I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T.
Pauly, "An Abstract Application Layer Interface to
Transport Services", Work in Progress, Internet-Draft,
draft-ietf-taps-interface-06, 9 March 2020,
<http://www.ietf.org/internet-drafts/draft-ietf-taps-
interface-06.txt>.
[I-D.ietf-tls-dtls13] [DTLS-1.3] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
dtls13-37, 9 March 2020, <http://www.ietf.org/internet- dtls13-38, 29 May 2020,
drafts/draft-ietf-tls-dtls13-37.txt>. <https://tools.ietf.org/html/draft-ietf-tls-dtls13-38>.
[MinimaLT] Petullo, W.M., Zhang, X., Solworth, J.A., Bernstein, D.J., [MinimaLT] Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and
and T. Lange, "MinimaLT -- Minimal-latency Networking T. Lange, "MinimaLT: minimal-latency networking through
Through Better Security", better security", DOI 10.1145/2508859.2516737,
<http://dl.acm.org/citation.cfm?id=2516737>. <https://dl.acm.org/citation.cfm?id=2516737>.
[OpenVPN] "OpenVPN cryptographic layer", <https://openvpn.net/ [OpenVPN] OpenVPN, "OpenVPN cryptographic layer",
community-resources/openvpn-cryptographic-layer/>. <https://openvpn.net/community-resources/openvpn-
cryptographic-layer/>.
[QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
Work in Progress, Internet-Draft, draft-ietf-quic-tls-31,
24 September 2020,
<https://tools.ietf.org/html/draft-ietf-quic-tls-31>.
[QUIC-TRANSPORT]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", Work in Progress, Internet-Draft,
draft-ietf-quic-transport-31, 24 September 2020,
<https://tools.ietf.org/html/draft-ietf-quic-transport-
31>.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, DOI 10.17487/RFC2385, August Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
1998, <https://www.rfc-editor.org/info/rfc2385>. 1998, <https://www.rfc-editor.org/info/rfc2385>.
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, DOI 10.17487/RFC2890, September 2000, RFC 2890, DOI 10.17487/RFC2890, September 2000,
<https://www.rfc-editor.org/info/rfc2890>. <https://www.rfc-editor.org/info/rfc2890>.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
skipping to change at page 22, line 44 skipping to change at line 969
[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>.
[TAPS-ARCH]
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
Perkins, C., Tiesel, P. S., and C. A. Wood, "An
Architecture for Transport Services", Work in Progress,
Internet-Draft, draft-ietf-taps-arch-08, 13 July 2020,
<https://tools.ietf.org/html/draft-ietf-taps-arch-08>.
[TAPS-INTERFACE]
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
Kuehlewind, M., Perkins, C., Tiesel, P. S., Wood, C. A.,
and T. Pauly, "An Abstract Application Layer Interface to
Transport Services", Work in Progress, Internet-Draft,
draft-ietf-taps-interface-09, 27 July 2020,
<https://tools.ietf.org/html/draft-ietf-taps-interface-
09>.
[WireGuard] [WireGuard]
Donenfeld, J.A., "WireGuard -- Next Generation Kernel Donenfeld, J., "WireGuard: Next Generation Kernel Network
Network Tunnel", Tunnel", <https://www.wireguard.com/papers/wireguard.pdf>.
<https://www.wireguard.com/papers/wireguard.pdf>.
Acknowledgments
The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja
K├╝hlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for
their input and feedback on this document.
Authors' Addresses Authors' Addresses
Theresa Enghardt Theresa Enghardt
TU Berlin TU Berlin
Marchstr. 23 Marchstr. 23
10587 Berlin 10587 Berlin
Germany Germany
Email: ietf@tenghardt.net Email: ietf@tenghardt.net
Tommy Pauly Tommy Pauly
Apple Inc. Apple Inc.
skipping to change at page 23, line 15 skipping to change at line 1008
TU Berlin TU Berlin
Marchstr. 23 Marchstr. 23
10587 Berlin 10587 Berlin
Germany Germany
Email: ietf@tenghardt.net Email: ietf@tenghardt.net
Tommy Pauly Tommy Pauly
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014, Cupertino, California 95014
United States of America United States of America
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 Christopher A. Wood
Cloudflare Cloudflare
101 Townsend St 101 Townsend St
San Francisco, San Francisco,
United States of America United States of America
 End of changes. 150 change blocks. 
329 lines changed or deleted 328 lines changed or added

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