draft-ietf-taps-transport-security-06.txt   draft-ietf-taps-transport-security-07.txt 
Network Working Group C. Wood, Ed. Network Working Group C. Wood, Ed.
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Informational T. Enghardt Intended status: Informational T. Enghardt
Expires: September 12, 2019 TU Berlin Expires: January 25, 2020 TU Berlin
T. Pauly T. Pauly
Apple Inc. Apple Inc.
C. Perkins C. Perkins
University of Glasgow University of Glasgow
K. Rose K. Rose
Akamai Technologies, Inc. Akamai Technologies, Inc.
March 11, 2019 July 24, 2019
A Survey of Transport Security Protocols A Survey of Transport Security Protocols
draft-ietf-taps-transport-security-06 draft-ietf-taps-transport-security-07
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 [RFC8095] by efforts to define and catalog transport services by describing the
describing the interfaces required to add security protocols. It interfaces required to add security protocols. This survey is not
examines Transport Layer Security (TLS), Datagram Transport Layer limited to protocols developed within the scope or context of the
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + IETF, and those included represent a superset of features a Transport
TLS), tcpcrypt, Internet Key Exchange with Encapsulating Security Services system may need to support.
Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP,
MinimalT. This survey is not limited to protocols developed within
the scope or context of the IETF, and those included represent a
superset of features a TAPS system may need to support.
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 September 12, 2019. This Internet-Draft will expire on January 25, 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
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security Features . . . . . . . . . . . . . . . . . . . . . . 5 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 6
4. Transport Security Protocol Descriptions . . . . . . . . . . 7 4. Transport Security Protocol Descriptions . . . . . . . . . . 7
4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Protocol Description . . . . . . . . . . . . . . . . 7 4.1.1. Protocol Description . . . . . . . . . . . . . . . . 8
4.1.2. Security Features . . . . . . . . . . . . . . . . . . 8 4.1.2. Security Features . . . . . . . . . . . . . . . . . . 9
4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9 4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9
4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Protocol Description . . . . . . . . . . . . . . . . 9 4.2.1. Protocol Description . . . . . . . . . . . . . . . . 10
4.2.2. Security Features . . . . . . . . . . . . . . . . . . 10 4.2.2. Security Features . . . . . . . . . . . . . . . . . . 10
4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10
4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 11 4.3. QUIC with TLS . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11 4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11
4.3.2. Security Features . . . . . . . . . . . . . . . . . . 11 4.3.2. Security Features . . . . . . . . . . . . . . . . . . 12
4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12 4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12
4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 12 4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 12
4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12 4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12
4.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 12 4.4.1. IKEv2 Protocol Description . . . . . . . . . . . . . 12
4.4.2. Security Features . . . . . . . . . . . . . . . . . . 14 4.4.2. ESP Protocol Description . . . . . . . . . . . . . . 13
4.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 14 4.4.3. IKEv2 Security Features . . . . . . . . . . . . . . . 14
4.4.4. ESP Security Features . . . . . . . . . . . . . . . . 14
4.4.5. IKEv2 Protocol Dependencies . . . . . . . . . . . . . 14
4.4.6. ESP Protocol Dependencies . . . . . . . . . . . . . . 15
4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15 4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15
4.5.1. Protocol description . . . . . . . . . . . . . . . . 15 4.5.1. Protocol description . . . . . . . . . . . . . . . . 15
4.5.2. Security Features . . . . . . . . . . . . . . . . . . 16 4.5.2. Security Features . . . . . . . . . . . . . . . . . . 16
4.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16 4.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16
4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 16 4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 17
4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 17 4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 17
4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17 4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17
4.6.2. Security Features . . . . . . . . . . . . . . . . . . 18 4.6.2. Security Features . . . . . . . . . . . . . . . . . . 18
4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18 4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18
4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18 4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18
4.7.1. Protocol description . . . . . . . . . . . . . . . . 18 4.7.1. Protocol description . . . . . . . . . . . . . . . . 19
4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19 4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19
4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19 4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20
4.8. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.8. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20 4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20
4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 21 4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 21
4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21 4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21
4.9. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 21 4.9. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 22
4.9.1. Protocol Description . . . . . . . . . . . . . . . . 22 4.9.1. Protocol Description . . . . . . . . . . . . . . . . 22
4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22 4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 23
4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 23 4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 23
4.10. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.10. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.10.1. Protocol Description . . . . . . . . . . . . . . . . 23 4.10.1. Protocol Description . . . . . . . . . . . . . . . . 23
4.10.2. Protocol Features . . . . . . . . . . . . . . . . . 24 4.10.2. Protocol Features . . . . . . . . . . . . . . . . . 24
4.10.3. Protocol Dependencies . . . . . . . . . . . . . . . 24 4.10.3. Protocol Dependencies . . . . . . . . . . . . . . . 25
5. Security Features and Application Dependencies . . . . . . . 24 5. Security Features and Application Dependencies . . . . . . . 25
5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 25 5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 25
5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 25 5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 26
5.3. Optional Feature Availability . . . . . . . . . . . . . . 27 5.3. Optional Feature Availability . . . . . . . . . . . . . . 27
6. Transport Security Protocol Interfaces . . . . . . . . . . . 29 6. Transport Security Protocol Interfaces . . . . . . . . . . . 29
6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 29 6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 29
6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 30 6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 30
6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 30 6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31
11. Normative References . . . . . . . . . . . . . . . . . . . . 31 11. Informative References . . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
This document provides a survey of commonly used or notable network Services and features provided by transport protocols have been
security protocols, with a focus on how they interact and integrate cataloged in [RFC8095]. This document supplements that work by
with applications and transport protocols. Its goal is to supplement surveying commonly used and notable network security protocols, and
efforts to define and catalog transport services [RFC8095] by identifying the services and features a Transport Services system (a
describing the interfaces required to add security protocols. It system that provides a transport API) needs to provide in order to
examines Transport Layer Security (TLS), Datagram Transport Layer add transport security. It examines Transport Layer Security (TLS),
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + Datagram Transport Layer Security (DTLS), QUIC + TLS, tcpcrypt,
TLS), tcpcrypt, Internet Key Exchange with Encapsulating Security Internet Key Exchange with Encapsulating Security Protocol (IKEv2 +
Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT. For each
MinimalT. For each protocol, this document provides a brief protocol, this document provides a brief description, the security
description, the security features it provides, and the dependencies features it provides, and the dependencies it has on the underlying
it has on the underlying transport. This is followed by defining the transport. This is followed by defining the set of transport
set of transport security features shared by these protocols. security features shared by these protocols. Finally, the document
Finally, we distill the application and transport interfaces provided distills the application and transport interfaces provided by the
by the transport security protocols. transport security protocols.
Selected protocols represent a superset of functionality and features Selected protocols represent a superset of functionality and features
a TAPS system may need to support, both internally and externally - a Transport Services system may need to support, both internally and
via an API - for applications [I-D.ietf-taps-arch]. Ubiquitous IETF externally (via an API) for applications [I-D.ietf-taps-arch].
protocols such as (D)TLS, as well as non-standard protocols such as Ubiquitous IETF protocols such as (D)TLS, as well as non-standard
Google QUIC, are both included despite overlapping features. As protocols such as Google QUIC, are both included despite overlapping
such, this survey is not limited to protocols developed within the features. As such, this survey is not limited to protocols developed
scope or context of the IETF. Outside of this candidate set, within the scope or context of the IETF. Outside of this candidate
protocols that do not offer new features are omitted. For example, set, protocols that do not offer new features are omitted. For
newer protocols such as WireGuard make unique design choices that example, newer protocols such as WireGuard make unique design choices
have important implications on applications, such as how to best that have important implications on applications, such as how to best
configure peer public keys and to delegate algorithm selection to the configure peer public keys and to delegate algorithm selection to the
system. In contrast, protocols such as ALTS [ALTS] are omitted since system. In contrast, protocols such as ALTS [ALTS] are omitted since
they do not represent features deemed unique. they do not represent features deemed unique.
Also, authentication-only protocols such as TCP-AO [RFC5925] and Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH
IPsec AH [RFC4302] are excluded from this survey. TCP-AO adds [RFC4302] are excluded from this survey. TCP-AO adds authenticity
authenticity protections to long-lived TCP connections, e.g., replay protections to long-lived TCP connections, e.g., replay protection
protection with per-packet Message Authentication Codes. (This with per-packet Message Authentication Codes. (This protocol
protocol obsoletes TCP MD5 "signature" options specified in obsoletes TCP MD5 "signature" options specified in [RFC2385].) One
[RFC2385].) One prime use case of TCP-AO is for protecting BGP prime use case of TCP-AO is for protecting BGP connections.
connections. Similarly, AH adds per-datagram authenticity and adds Similarly, AH adds per-datagram authenticity and adds similar replay
similar replay protection. Despite these improvements, neither protection. Despite these improvements, neither protocol sees
protocol sees general use and both lack critical properties important general use and both lack critical properties important for emergent
for emergent transport security protocols: confidentiality, privacy transport security protocols: confidentiality, privacy protections,
protections, and agility. Thus, we omit these and related protocols and agility. Such protocols are thus omitted from this survey.
from our survey.
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 6, line 5 skipping to change at page 6, line 13
initiation. initiation.
3. Security Features 3. Security Features
In this section, we enumerate Security Features exposed by protocols In this section, we enumerate Security Features exposed by protocols
discussed in the remainder of this document. Protocol security (and discussed in the remainder of this document. Protocol security (and
privacy) properties that are unrelated to the API surface exposed by privacy) properties that are unrelated to the API surface exposed by
such protocols, such as client or server identity hiding, are not such protocols, such as client or server identity hiding, are not
listed here as features. listed here as features.
o Forward-secure session key establishment: Cryptographic key o Forward-secure session key establishment: Establishing
establishment with forward secure properties. cryptographic keys with forward-secure properties.
o Cryptographic algorithm negotiation: Negotiate support of protocol o Cryptographic algorithm negotiation: Negotiating support of
algorithms, including: encryption, hash, MAC (PRF), and digital protocol algorithms, including algorithms for encryption, hashing,
signature algorithms. MAC (PRF), and digital signatures.
o Session caching and management: Manage session state cache used o Session caching and management: Managing session state caches used
for subsequent connections aimed towards amortizing connection for subsequent connections, with the aim of amortizing connection
establishment costs. establishment costs.
o Peer authentication (certificate, raw public key, pre-shared key, o Peer authentication: Authenticating peers using generic or
or EAP-based): Peer authentication using select or protocol- protocol-specific mechanisms, such as certificates, raw public
specific mechanisms. keys, pre-shared keys, or EAP methods.
o Unilateral responder authentication: Required authentication for o Unilateral responder authentication: Requiring authentication for
the responder of a connection. the responder of a connection.
o Mutual authentication: Connection establishment wherein both o Mutual authentication: Establishing connections in which both
endpoints are authenticated. endpoints are authenticated.
o Application authentication delegation: Out-of-band peer o Application authentication delegation: Delegating to applications
authentication performed by applications outside of the connection out-of-band to perform peer authentication.
establishment.
o Record (channel or datagram) confidentiality and integrity: o Record (channel or datagram) confidentiality and integrity:
Encryption and authentication of application plaintext bytes sent Encrypting and authenticating application plaintext bytes sent
between peers over a channel or in individual datagrams. between peers over a channel or in individual datagrams.
o Partial record confidentiality: Encryption of some portion of o Partial record confidentiality: Encrypting some portion of
records. records.
o Optional record integrity: Optional authentication of certain o Optional record integrity: Optionally authenticating certain
records. records.
o Record replay prevention: Protocol detection and defense against o Record replay prevention: Detecting and defending against record
record replays, e.g., due to in-network retransmissions. replays, which can be due to in-network retransmissions.
o Early data support (starting with TLS 1.3): Transmission of o Early data support: Transmitting application data prior to secure
application data prior to connection (handshake) establishment. connection establishment via a handshake. For TLS, this support
begins with TLS 1.3.
o Connection mobility: a property of a connection that allows it to o Connection mobility: Allowing a connection to be multihomed or
be multihomed or resilient across network interface or address resilient across network interface or address changes, such as NAT
changes, e.g., NAT rebindings that occur without an endpoint's rebindings that occur without an endpoint's knowledge. Mobility
knowledge. Mobility allows cryptographic key material and other allows cryptographic key material and other state information to
state information to be reused in the event of a connection be reused in the event of a connection change.
change.
o Application-layer feature negotiation: Securely negotiate o Application-layer feature negotiation: Securely negotiating
application-specific functionality, including those necessary for application-specific functionality. Such features may be
connection handling and management, e.g., the TLS parent necessary for further application processing, such as the TLS
connection protocol type via ALPN [RFC7301] or desired application parent connection protocol type via ALPN [RFC7301] or desired
identity via SNI [RFC6066]. application identity via SNI [RFC6066].
o Configuration extensions: Add protocol features via extensions or o Configuration extensions: Adding protocol features via extensions
configuration options. TLS extensions are a primary example of or configuration options. TLS extensions are a primary example of
this feature. this feature.
o Out-of-order record receipt: Processing of records received out- o Out-of-order record receipt: Processing of records received out-
of-order. of-order.
o Source validation (cookie or puzzle based): Peer source validation o Source validation (cookie or puzzle based): Validating peers and
and DoS mitigation via explicit proof of origin (cookie) or work mitigating denial-of-service (DoS) attacks via explicit proof of
mechanisms (puzzles). origin (cookies) or work mechanisms (puzzles).
o Length-hiding padding: Protocol-drive record padding aimed at o Length-hiding padding: Adding padding to records in order to hide
hiding plaintext message length and mitigating amplification plaintext message length and mitigate amplification attack
attack vectors. vectors.
4. Transport Security Protocol Descriptions 4. Transport Security Protocol Descriptions
This section contains descriptions of security protocols currently This section contains descriptions of security protocols currently
used to protect data being sent over a network. used to protect data being sent over a network.
For each protocol, we describe its provided features and dependencies For each protocol, we describe its provided features and dependencies
on other protocols. on other protocols.
4.1. TLS 4.1. TLS
skipping to change at page 7, line 48 skipping to change at page 8, line 7
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 4.1.1. Protocol Description
TLS is the composition of a handshake and record protocol TLS is the composition of a handshake and record protocol [RFC8446].
[I-D.ietf-tls-tls13]. The record protocol is designed to marshal an The record protocol is designed to marshal an arbitrary, in-order
arbitrary, in-order stream of bytes from one endpoint to the other. stream of bytes from one endpoint to the other. It handles
It handles segmenting, compressing (when enabled), and encrypting segmenting, compressing (when enabled), and encrypting data into
data into discrete records. When configured to use an authenticated discrete records. When configured to use an authenticated encryption
encryption with associated data (AEAD) algorithm, it also handles with associated data (AEAD) algorithm, it also handles nonce
nonce generation and encoding for each record. The record protocol generation and encoding for each record. The record protocol is
is hidden from the client behind a bytestream-oriented API. hidden from the client behind a bytestream-oriented API.
The handshake protocol serves several purposes, including: peer The handshake protocol serves several purposes, including: peer
authentication, protocol option (key exchange algorithm and authentication, protocol option (key exchange algorithm and
ciphersuite) negotiation, and key derivation. Peer authentication ciphersuite) negotiation, and key derivation. Peer authentication
may be mutual; however, commonly, only the server is authenticated. may be mutual; however, commonly, only the server is authenticated.
X.509 certificates are commonly used in this authentication step, X.509 certificates are commonly used in this authentication step,
though other mechanisms, such as raw public keys [RFC7250], exist. though other mechanisms, such as raw public keys [RFC7250], exist.
The client is not authenticated unless explicitly requested by the The client is not authenticated unless explicitly requested by the
server. server.
The handshake protocol is also extensible. It allows for a variety The handshake protocol is also extensible. It allows for a variety
of extensions to be included by either the client or server. These of extensions to be included by either the client or server. These
extensions are used to specify client preferences, e.g., the extensions are used to specify client preferences, e.g., the
application-layer protocol to be driven with the TLS connection application-layer protocol to be driven with the TLS connection
[RFC7301], or signals to the server to aid operation, e.g., Server [RFC7301], or signals to the server to aid operation, e.g., Server
Name Indication (SNI) [RFC6066]. Various extensions also exist to Name Indication (SNI) [RFC6066]. Various extensions also exist to
tune the parameters of the record protocol, e.g., the maximum tune the parameters of the record protocol, e.g., the maximum
fragment length [RFC6066] and record size limit fragment length [RFC6066] and record size limit [RFC8449].
[I-D.ietf-tls-record-limit].
Alerts are used to convey errors and other atypical events to the Alerts are used to convey errors and other atypical events to the
endpoints. There are two classes of alerts: closure and error endpoints. There are two classes of alerts: closure and error
alerts. A closure alert is used to signal to the other peer that the alerts. A closure alert is used to signal to the other peer that the
sender wishes to terminate the connection. The sender typically sender wishes to terminate the connection. The sender typically
follows a close alert with a TCP FIN segment to close the connection. follows a close alert with a TCP FIN segment to close the connection.
Error alerts are used to indicate problems with the handshake or Error alerts are used to indicate problems with the handshake or
individual records. Most errors are fatal and are followed by individual records. Most errors are fatal and are followed by
connection termination. However, warning alerts may be handled at connection termination. However, warning alerts may be handled at
the discretion of the implementation. the discretion of the implementation.
skipping to change at page 9, line 30 skipping to change at page 9, line 38
o Application-layer feature negotiation. o Application-layer feature negotiation.
o Configuration extensions. o Configuration extensions.
o Early data support (starting with TLS 1.3). o Early data support (starting with TLS 1.3).
o Optional record-layer padding (starting with TLS 1.3). o Optional record-layer padding (starting with TLS 1.3).
4.1.3. Protocol Dependencies 4.1.3. Protocol Dependencies
o TCP for in-order, reliable transport. o In-order, reliable bytestream transport.
o (Optionally) A PKI trust store for certificate validation. o (Optionally) A PKI trust store for certificate validation.
4.2. DTLS 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 UDP instead of TCP. but differs in that it is designed to run over unrelaible datagram
Since UDP does not guarantee datagram ordering or reliability, DTLS protocols like UDP instead of TCP. DTLS modifies the protocol to
modifies the protocol to make sure it can still provide the same make sure it can still provide the same security guarantees as TLS
security guarantees as TLS. DTLS was designed to be as close to TLS even without reliability from the transport. DTLS was designed to be
as possible, so this document will assume that all properties from as similar to TLS as possible, so this document assumes that all
TLS are carried over except where specified. properties from TLS are carried over except where specified.
4.2.1. Protocol Description 4.2.1. Protocol Description
DTLS is modified from TLS to operate with the possibility of packet DTLS is modified from TLS to operate with the possibility of packet
loss, reordering, and duplication that may occur when operating over loss, reordering, and duplication that may occur when operating over
UDP. To enable out-of-order delivery of application data, the DTLS UDP. To enable out-of-order delivery of application data, the DTLS
record protocol itself has no inter-record dependencies. However, as record protocol itself has no inter-record dependencies. However, as
the handshake requires reliability, each handshake message is the handshake requires reliability, each handshake message is
assigned an explicit sequence number to enable retransmissions of assigned an explicit sequence number to enable retransmissions of
lost packets and in-order processing by the receiver. Handshake lost packets and in-order processing by the receiver. Handshake
message loss is remedied by sender retransmission after a message loss is remedied by sender retransmission after a
configurable period in which the expected response has not yet been configurable period in which the expected response has not yet been
received. received.
As the DTLS handshake protocol runs atop the record protocol, to As the DTLS handshake protocol runs atop the record protocol, to
account for long handshake messages that cannot fit within a single account for long handshake messages that cannot fit within a single
record, DTLS supports fragmentation and subsequent reconstruction of record, DTLS supports fragmentation and subsequent reconstruction of
handshake messages across records. The receiver must reassemble handshake messages across records. The receiver must reassemble
records before processing. records before processing.
DTLS relies on unique UDP 4-tuples to identify connections. Since DTLS relies on unique UDP 4-tuples to identify connections, or a
all application-layer data is encrypted, demultiplexing over the same 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 4-tuple requires the use of a connection identifier extension
[I-D.ietf-tls-dtls-connection-id] to permit identification of the [I-D.ietf-tls-dtls-connection-id] to permit identification of the
correct connection-specific cryptographic context without the use of correct connection-specific cryptographic context without the use of
trial decryption. (Note that this extension is only supported in trial decryption. (Note that this extension is only supported in
DTLS 1.2 and 1.3 {{I-D.ietf-tls-dtls13}.) DTLS 1.2 and 1.3 {{?I-D.ietf-tls-dtls13}.)
Since datagrams can be replayed, DTLS provides optional anti-replay Since datagrams can be replayed, DTLS provides optional anti-replay
detection based on a window of acceptable sequence numbers [RFC6347]. detection based on a window of acceptable sequence numbers [RFC6347].
4.2.2. Security Features 4.2.2. Security Features
o Record replay protection. o Record replay protection.
o Record (datagram) confidentiality and integrity. o Record (datagram) confidentiality and integrity.
o Out-of-order record receipt. o Out-of-order record receipt.
o DoS mitigation (cookie-based). o DoS mitigation (cookie-based).
See also the features from TLS. See also the features from TLS.
4.2.3. Protocol Dependencies 4.2.3. Protocol Dependencies
o DTLS relies on UDP. o DTLS relies on an unreliable datagram transport.
o The DTLS record protocol explicitly encodes record lengths, so o The DTLS record protocol explicitly encodes record lengths, so
although it runs over a datagram transport, it does not rely on although it runs over a datagram transport, it does not rely on
the transport protocol's framing beyond requiring transport-level the transport protocol's framing beyond requiring transport-level
reconstruction of datagrams fragmented over packets. (Note: DTLS reconstruction of datagrams fragmented over packets. (Note: DTLS
1.3 short header records omit the explicit length field.) 1.3 short header records omit the explicit length field.)
o UDP 4-tuple uniqueness, or the connection identifier extension, o Uniqueness of the session within the transport flow (only one DTLS
for demultiplexing. connection on a UDP 4-tuple, for example); or else support for the
connection identifier extension to enable demultiplexing.
o Path MTU discovery. o Path MTU discovery.
o For the handshake: Reliable, in-order transport. DTLS provides o For the handshake: Reliable, in-order transport. DTLS provides
its own reliability. its own reliability.
4.3. (IETF) QUIC with TLS 4.3. QUIC with TLS
QUIC (Quick UDP Internet Connections) is a new standards-track QUIC is a new standards-track transport protocol that runs over UDP,
transport protocol that runs over UDP, loosely based on Google's loosely based on Google's original proprietary gQUIC protocol
original proprietary gQUIC protocol [I-D.ietf-quic-transport]. (See [I-D.ietf-quic-transport] (See Section 4.3.4 for more details). The
Section 4.3.4 for more details.) The QUIC transport layer itself QUIC transport layer itself provides support for data confidentiality
provides support for data confidentiality and integrity. This and integrity. This requires keys to be derived with a separate
requires keys to be derived with a separate handshake protocol. A handshake protocol. A mapping for QUIC of TLS 1.3
mapping for QUIC over TLS 1.3 [I-D.ietf-quic-tls] has been specified [I-D.ietf-quic-tls] has been specified to provide this handshake.
to provide this handshake.
4.3.1. Protocol Description 4.3.1. Protocol Description
As QUIC relies on TLS to secure its transport functions, it creates As QUIC relies on TLS to secure its transport functions, it creates
specific integration points between its security and transport specific integration points between its security and transport
functions: functions:
o Starting the handshake to generate keys and provide authentication o Starting the handshake to generate keys and provide authentication
(and providing the transport for the handshake). (and providing the transport for the handshake).
o Client address validation. o Client address validation.
o Key ready events from TLS to notify the QUIC transport. o Key ready events from TLS to notify the QUIC transport.
o Exporting secrets from TLS to the QUIC transport. o Exporting secrets from TLS to the QUIC transport.
The QUIC transport layer support multiple streams over a single The QUIC transport layer support multiple streams over a single
connection. QUIC implements a record protocol for TLS handshake connection. QUIC implements a record protocol for TLS handshake
messages to establish a connection. These messages are sent in messages to establish a connection. These messages are sent in
special INITIAL and CRYPTO frames [I-D.ietf-quic-transport], types of CRYPTO frames [I-D.ietf-quic-transport] in Initial and Handshake
which are encrypted using different keys. INITIAL frames are packets. Initial packets are encrypted using fixed keys derived from
encrypted using "fixed" keys derived from the QUIC version and public the QUIC version and public packet information (Connection ID).
packet information (Connection ID). CRYPTO frames are encrypted Handshake packets are encrypted using TLS handshake secrets. Once
using TLS handshake secrets. Once TLS completes, QUIC uses the TLS completes, QUIC uses the resulting traffic secrets to for the
resultant traffic secrets to for the QUIC connection to protect the QUIC connection to protect the rest of the frames. QUIC supports
rest of the streams. QUIC supports 0-RTT (early) data using 0-RTT data using previously negotiated connection secrets Early data
previously negotiated connection secrets. Early data is sent in is sent in 0-RTT packets, which may be included in the same datagram
0-RTT packets, which may be included in the same datagram as the as the Initial and Handshake packets.
Initial and Handshake packets.
4.3.2. Security Features 4.3.2. Security Features
o DoS mitigation (cookie-based). o DoS mitigation (cookie-based).
See also the properties of TLS. See also the properties of TLS.
4.3.3. Protocol Dependencies 4.3.3. Protocol Dependencies
o QUIC transport relies on UDP. o QUIC transport relies on UDP.
skipping to change at page 12, line 35 skipping to change at page 12, line 45
4.4. IKEv2 with ESP 4.4. IKEv2 with ESP
IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec
protocol suite that encrypts and authenticates IP packets, either for protocol suite that encrypts and authenticates IP packets, either for
creating tunnels (tunnel-mode) or for direct transport connections creating tunnels (tunnel-mode) or for direct transport connections
(transport-mode). This suite of protocols separates out the key (transport-mode). This suite of protocols separates out the key
generation protocol (IKEv2) from the transport encryption protocol generation protocol (IKEv2) from the transport encryption protocol
(ESP). Each protocol can be used independently, but this document (ESP). Each protocol can be used independently, but this document
considers them together, since that is the most common pattern. considers them together, since that is the most common pattern.
4.4.1. Protocol descriptions 4.4.1. IKEv2 Protocol Description
4.4.1.1. IKEv2
IKEv2 is a control protocol that runs on UDP ports 500 or 4500 and 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 TCP port 4500. Its primary goal is to generate keys for Security
Associations (SAs). An SA contains shared (cryptographic) Associations (SAs). An SA contains shared (cryptographic)
information used for establishing other SAs or keying ESP; See information used for establishing other SAs or keying ESP; See
Section 4.4.1.2. IKEv2 first uses a Diffie-Hellman key exchange to 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 generate keys for the "IKE SA", which is a set of keys used to
encrypt further IKEv2 messages. IKE then performs a phase of encrypt further IKEv2 messages. IKE then performs a phase of
authentication in which both peers present blobs signed by a shared authentication in which both peers present blobs signed by a shared
secret or private key that authenticates the entire IKE exchange and secret or private key that authenticates the entire IKE exchange and
the IKE identities. IKE then derives further sets of keys on demand, the IKE identities. IKE then derives further sets of keys on demand,
which together with traffic policies are referred to as the "Child which together with traffic policies are referred to as the "Child
SA". These Child SA keys are used by ESP. SA". These Child SA keys are used by ESP.
IKEv2 negotiates which protocols are acceptable to each peer for both IKEv2 negotiates which protocols are acceptable to each peer for both
the IKE and Child SAs using "Proposals". Each proposal specifies an the IKE and Child SAs using "Proposals". Each proposal specifies an
skipping to change at page 13, line 31 skipping to change at page 13, line 38
There is an extension to IKEv2 that allows session resumption There is an extension to IKEv2 that allows session resumption
[RFC5723]. [RFC5723].
MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a
set of Security Associations to migrate over different outer IP set of Security Associations to migrate over different outer IP
addresses and interfaces [RFC4555]. addresses and interfaces [RFC4555].
When UDP is not available or well-supported on a network, IKEv2 may When UDP is not available or well-supported on a network, IKEv2 may
be encapsulated in TCP [RFC8229]. be encapsulated in TCP [RFC8229].
4.4.1.2. ESP 4.4.2. ESP Protocol Description
ESP is a protocol that encrypts and authenticates IPv4 and IPv6 ESP is a protocol that encrypts and authenticates IPv4 and IPv6
packets. The keys used for both encryption and authentication can be packets. The keys used for both encryption and authentication can be
derived from an IKEv2 exchange. ESP Security Associations come as derived from an IKEv2 exchange. ESP Security Associations come as
pairs, one for each direction between two peers. Each SA is pairs, one for each direction between two peers. Each SA is
identified by a Security Parameter Index (SPI), which is marked on identified by a Security Parameter Index (SPI), which is marked on
each encrypted ESP packet. each encrypted ESP packet.
ESP packets include the SPI, a sequence number, an optional ESP packets include the SPI, a sequence number, an optional
Initialization Vector (IV), payload data, padding, a length and next Initialization Vector (IV), payload data, padding, a length and next
skipping to change at page 14, line 10 skipping to change at page 14, line 19
Since ESP operates on IP packets, it is not directly tied to the Since ESP operates on IP packets, it is not directly tied to the
transport protocols it encrypts. This means it requires little or no transport protocols it encrypts. This means it requires little or no
change from transports in order to provide security. change from transports in order to provide security.
ESP packets may be sent directly over IP, but where network ESP packets may be sent directly over IP, but where network
conditions warrant (e.g., when a NAT is present or when a firewall 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 blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP
[RFC8229]. [RFC8229].
4.4.2. Security Features 4.4.3. IKEv2 Security Features
4.4.2.1. IKEv2
o Forward-secure session key establishment. o Forward-secure session key establishment.
o Cryptographic algorithm negotiation. o Cryptographic algorithm negotiation.
o Peer authentication (certificate, raw public key, pre-shared key, o Peer authentication (certificate, raw public key, pre-shared key,
and EAP). and EAP).
o Unilateral responder authentication. o Unilateral responder authentication.
o Mutual authentication. o Mutual authentication.
o Record (datagram) confidentiality and integrity. o Record (datagram) confidentiality and integrity.
o Session resumption. o Session resumption.
o Connection mobility. o Connection mobility.
o DoS mitigation (cookie-based). o DoS mitigation (cookie-based).
4.4.2.2. ESP 4.4.4. ESP Security Features
o Record confidentiality and integrity. o Record confidentiality and integrity.
o Record replay protection. o Record replay protection.
4.4.3. Protocol Dependencies 4.4.5. IKEv2 Protocol Dependencies
4.4.3.1. IKEv2
o Availability of UDP to negotiate, or implementation support for o Availability of UDP to negotiate, or implementation support for
TCP-encapsulation. TCP-encapsulation.
o Some EAP authentication types require accessing a hardware device, o Some EAP authentication types require accessing a hardware device,
such as a SIM card; or interacting with a user, such as password such as a SIM card; or interacting with a user, such as password
prompting. prompting.
4.4.3.2. ESP 4.4.6. ESP Protocol Dependencies
o Since ESP is below transport protocols, it does not have any o Since ESP is below transport protocols, it does not have any
dependencies on the transports themselves, other than on UDP or dependencies on the transports themselves, other than on UDP or
TCP where encapsulation is employed. TCP where encapsulation is employed.
4.5. Secure RTP (with DTLS) 4.5. Secure RTP (with DTLS)
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]. and RTP control protocol (RTCP) packets [RFC3711].
skipping to change at page 17, line 30 skipping to change at page 17, line 36
4.6. tcpcrypt 4.6. tcpcrypt
Tcpcrypt is a lightweight extension to the TCP protocol for Tcpcrypt 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 4.6.1. Protocol Description
Tcpcrypt extends TCP to enable opportunistic encryption between the Tcpcrypt extends TCP to enable opportunistic encryption between the
two ends of a TCP connection [I-D.ietf-tcpinc-tcpcrypt]. It is a two ends of a TCP connection [RFC8548]. It is a family of TCP
family of TCP encryption protocols (TEP), distinguished by key encryption protocols (TEP), distinguished by key exchange algorithm.
exchange algorithm. The use of a TEP is negotiated with a TCP option The use of a TEP is negotiated with a TCP option during the initial
during the initial TCP handshake via the mechanism described by TCP TCP handshake via the mechanism described by TCP Encryption
Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the Negotiation Option (ENO) [RFC8547]. In the case of initial session
case of initial session establishment, once a tcpcrypt TEP has been establishment, once a tcpcrypt TEP has been negotiated the key
negotiated the key exchange occurs within the data segments of the exchange occurs within the data segments of the first few packets
first few packets exchanged after the handshake completes. The exchanged after the handshake completes. The initiator of a
initiator of a connection sends a list of supported AEAD algorithms, connection sends a list of supported AEAD algorithms, a random nonce,
a random nonce, and an ephemeral public key share. The responder and an ephemeral public key share. The responder typically chooses a
typically chooses a mutually-supported AEAD algorithm and replies mutually-supported AEAD algorithm and replies with this choice, its
with this choice, its own nonce, and ephemeral key share. An initial own nonce, and ephemeral key share. An initial shared secret is
shared secret is derived from the ENO handshake, the tcpcrypt derived from the ENO handshake, the tcpcrypt handshake, and the
handshake, and the initial keying material resulting from the key initial keying material resulting from the key exchange. The traffic
exchange. The traffic encryption keys on the initial connection are encryption keys on the initial connection are derived from the shared
derived from the shared secret. Connections can be re-keyed before secret. Connections can be re-keyed before the natural AEAD limit
the natural AEAD limit for a single set of traffic encryption keys is for a single set of traffic encryption keys is reached.
reached.
Each tcpcrypt session is associated with a ladder of resumption IDs, Each tcpcrypt session is associated with a ladder of resumption IDs,
each derived from the respective entry in a ladder of shared secrets. each derived from the respective entry in a ladder of shared secrets.
These resumption IDs can be used to negotiate a stateful resumption These resumption IDs can be used to negotiate a stateful resumption
of the session in a subsequent connection, resulting in use of a new of the session in a subsequent connection, resulting in use of a new
shared secret and traffic encryption keys without requiring a new key shared secret and traffic encryption keys without requiring a new key
exchange. Willingness to resume a session is signaled via the ENO exchange. Willingness to resume a session is signaled via the ENO
option during the TCP handshake. Given the length constraints option during the TCP handshake. Given the length constraints
imposed by TCP options, unlike stateless resumption mechanisms (such imposed by TCP options, unlike stateless resumption mechanisms (such
as that provided by session tickets in TLS) resumption in tcpcrypt as that provided by session tickets in TLS) resumption in tcpcrypt
skipping to change at page 18, line 30 skipping to change at page 18, line 35
o Record (channel) confidentiality and integrity. o Record (channel) confidentiality and integrity.
o Stateful cross-connection session resumption. o Stateful cross-connection session resumption.
o Session caching and management. o Session caching and management.
o Application authentication delegation. o Application authentication delegation.
4.6.3. Protocol Dependencies 4.6.3. Protocol Dependencies
o TCP. o TCP for in-order, reliable transport.
o TCP Encryption Negotiation Option (ENO). o TCP Encryption Negotiation Option (ENO).
4.7. WireGuard 4.7. WireGuard
WireGuard is a layer 3 protocol designed as an alternative to IPsec WireGuard is a layer 3 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
skipping to change at page 24, line 46 skipping to change at page 25, line 15
4.10.3. Protocol Dependencies 4.10.3. Protocol Dependencies
o For control packets such as handshake and key exchange: Reliable, o For control packets such as handshake and key exchange: Reliable,
in-order transport. Reliability is provided either by TCP, or by in-order transport. Reliability is provided either by TCP, or by
OpenVPN's own reliability layer when using UDP. OpenVPN's own reliability layer when using UDP.
5. Security Features and Application Dependencies 5. Security Features and Application Dependencies
There exists a common set of features shared across the transport There exists a common set of features shared across the transport
protocols surveyed in this document. Mandatory features constitute a protocols surveyed in this document. Mandatory features constitute a
baseline of functionality that an application may assume for any TAPS baseline of functionality that an application may assume for any
implementation. They were selected on the basis that they are either Transport Services implementation. They were selected on the basis
(a) required for any secure transport protocol or (b) nearly that they are either (a) required for any secure transport protocol
ubiquitous amongst common secure transport protocols. or (b) nearly ubiquitous amongst common secure transport protocols.
Optional features by contrast may vary from implementation to Optional features by contrast may vary from implementation to
implementation, and so an application cannot simply assume they are implementation, and so an application cannot simply assume they are
available. Applications learn of and use optional features by available. Applications learn of and use optional features by
querying for their presence and support. Optional features may not querying for their presence and support. Optional features may not
be implemented, or may be disabled if their presence impacts be implemented, or may be disabled if their presence impacts
transport services or if a necessary transport service or application transport services or if a necessary transport service or application
dependency is unavailable. dependency is unavailable.
In this context, an application dependency is an aspect of the In this context, an application dependency is an aspect of the
skipping to change at page 28, line 16 skipping to change at page 28, line 16
| Pro | P | A | A | M | D | C | S | A | CX | SC | LH | ED | RP | OO | | 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 | | | | | toc | S | N | D | A | M | M | V | F | | | P | | | |
| ol | K | | | | | | | N | | | | | | | | ol | K | | | | | | | N | | | | | | |
+-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+ +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+
| TLS | S | S | S | S | S | U | M | S | S | S | S | S | U | U | | 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 | | DTL | S | S | S | S | S | S | M | S | S | S | S | U | M | M |
| S | | | | | | | | | | | | | | | | S | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| IET | S | S | S | S | S | S | M | S | S | S | S | S | M | M | | QUI | S | S | S | S | S | S | M | S | S | S | S | S | M | M |
| F Q | | | | | | | | | | | | | | | | C | | | | | | | | | | | | | | |
| UIC | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| IKE | S | S | S | M | S | S | M | S | S | S | S | U | M | M | | IKE | S | S | S | M | S | S | M | S | S | S | S | U | M | M |
| v2+ | | | | | | | | | | | | | | | | v2+ | | | | | | | | | | | | | | |
| ESP | | | | | | | | | | | | | | | | ESP | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| SRT | S | S | S | S | S | U | M | S | S | S | U | U | M | M | | SRT | S | S | S | S | S | U | M | S | S | S | U | U | M | M |
| P+D | | | | | | | | | | | | | | | | P+D | | | | | | | | | | | | | | |
| TLS | | | | | | | | | | | | | | | | TLS | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| tcp | U | S | M | U | U | U | M | U | U | S | U | U | U | U | | tcp | U | S | M | U | U | U | M | U | U | S | U | U | U | U |
skipping to change at page 31, line 23 skipping to change at page 31, line 23
This document has no request to IANA. This document has no request to IANA.
8. Security Considerations 8. 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 9. 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 10. Acknowledgments
The authors would like to thank Bob Bradley, Theresa Enghardt, The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja
Frederic Jacobs, Mirja Kuehlewind, Yannick Sierra, and Brian Trammell Kuehlewind, Yannick Sierra, and Brian Trammell for their input and
for their input and feedback on earlier versions of this draft. feedback on earlier versions of this draft.
11. Normative References 11. Informative References
[ALTS] "Application Layer Transport Security", n.d.. [ALTS] "Application Layer Transport Security", n.d..
[BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d.. [BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d..
[Curve25519] [Curve25519]
"Curve25519 - new Diffie-Hellman speed records", n.d.. "Curve25519 - new Diffie-Hellman speed records", n.d..
[CurveCP] "CurveCP -- Usable security for the Internet", n.d.. [CurveCP] "CurveCP -- Usable security for the Internet", n.d..
[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-18 (work in progress), January 2019. draft-ietf-quic-tls-22 (work in progress), July 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-18 (work and Secure Transport", draft-ietf-quic-transport-22 (work
in progress), January 2019. in progress), July 2019.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-18 (work in progress), February 2019. 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-02 (work in Transport Services", draft-ietf-taps-arch-04 (work in
progress), October 2018. 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., and C. Wood, "An Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T.
Abstract Application Layer Interface to Transport Pauly, "An Abstract Application Layer Interface to
Services", draft-ietf-taps-interface-02 (work in Transport Services", draft-ietf-taps-interface-04 (work in
progress), October 2018. progress), July 2019.
[I-D.ietf-tcpinc-tcpcrypt]
Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
Q., and E. Smith, "Cryptographic protection of TCP Streams
(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-15 (work in
progress), December 2018.
[I-D.ietf-tcpinc-tcpeno]
Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.
Smith, "TCP-ENO: Encryption Negotiation Option", draft-
ietf-tcpinc-tcpeno-19 (work in progress), June 2018.
[I-D.ietf-tls-dtls-connection-id] [I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., and T. Fossati, "Connection Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
id-04 (work in progress), March 2019. 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-30 (work in progress),
November 2018.
[I-D.ietf-tls-record-limit]
Thomson, M., "Record Size Limit Extension for Transport
Layer Security (TLS)", draft-ietf-tls-record-limit-03
(work in progress), May 2018.
[I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018.
[MinimalT] [MinimalT]
"MinimaLT -- Minimal-latency Networking Through Better "MinimaLT -- Minimal-latency Networking Through Better
Security", n.d.. Security", n.d..
[Noise] "The Noise Protocol Framework", n.d.. [Noise] "The Noise Protocol Framework", n.d..
[OpenVPN] "OpenVPN cryptographic layer", n.d.. [OpenVPN] "OpenVPN cryptographic layer", n.d..
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
skipping to change at page 36, line 19 skipping to change at page 35, line 39
<https://www.rfc-editor.org/info/rfc8095>. <https://www.rfc-editor.org/info/rfc8095>.
[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>.
[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.
Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547,
DOI 10.17487/RFC8547, May 2019,
<https://www.rfc-editor.org/info/rfc8547>.
[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
Q., and E. Smith, "Cryptographic Protection of TCP Streams
(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
<https://www.rfc-editor.org/info/rfc8548>.
[SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated [SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated
Diffie-Hellman and Its Use in the IKE-Protocols", n.d.. Diffie-Hellman and Its Use in the IKE-Protocols", n.d..
[WireGuard] [WireGuard]
"WireGuard -- Next Generation Kernel Network Tunnel", "WireGuard -- Next Generation Kernel Network Tunnel",
n.d.. n.d..
Authors' Addresses Authors' Addresses
Christopher A. Wood (editor) Christopher A. Wood (editor)
 End of changes. 71 change blocks. 
232 lines changed or deleted 207 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/