draft-ietf-taps-transport-security-01.txt   draft-ietf-taps-transport-security-02.txt 
Network Working Group T. Pauly Network Working Group T. Pauly
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Informational C. Perkins Intended status: Informational C. Perkins
Expires: November 12, 2018 University of Glasgow Expires: January 1, 2019 University of Glasgow
K. Rose K. Rose
Akamai Technologies, Inc. Akamai Technologies, Inc.
C. Wood C. Wood
Apple Inc. Apple Inc.
May 11, 2018 June 30, 2018
A Survey of Transport Security Protocols A Survey of Transport Security Protocols
draft-ietf-taps-transport-security-01 draft-ietf-taps-transport-security-02
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 [RFC8095] by
describing the interfaces required to add security protocols. It describing the interfaces required to add security protocols. It
examines Transport Layer Security (TLS), Datagram Transport Layer examines Transport Layer Security (TLS), Datagram Transport Layer
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with
Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and
WireGuard. This survey is not limited to protocols developed within WireGuard. This survey is not limited to protocols developed within
the scope or context of the IETF. 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 November 12, 2018. This Internet-Draft will expire on January 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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. Transport Security Protocol Descriptions . . . . . . . . . . 5 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 5
3.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Transport Security Protocol Descriptions . . . . . . . . . . 7
3.1.1. Protocol Description . . . . . . . . . . . . . . . . 6 4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2. Protocol Features . . . . . . . . . . . . . . . . . . 7 4.1.1. Protocol Description . . . . . . . . . . . . . . . . 7
3.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 7 4.1.2. Protocol Features . . . . . . . . . . . . . . . . . . 8
3.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9
3.2.1. Protocol Description . . . . . . . . . . . . . . . . 7 4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Protocol Features . . . . . . . . . . . . . . . . . . 8 4.2.1. Protocol Description . . . . . . . . . . . . . . . . 9
3.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 8 4.2.2. Protocol Features . . . . . . . . . . . . . . . . . . 10
3.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 9 4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10
3.3.1. Protocol Description . . . . . . . . . . . . . . . . 9 4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 10
3.3.2. Protocol Features . . . . . . . . . . . . . . . . . . 9 4.3.1. Protocol Description . . . . . . . . . . . . . . . . 10
3.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 4.3.2. Protocol Features . . . . . . . . . . . . . . . . . . 11
3.3.4. Differences from Google QUIC . . . . . . . . . . . . 10 4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 11
3.3.5. Protocol Description . . . . . . . . . . . . . . . . 10 4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 11
3.3.6. Protocol Dependencies . . . . . . . . . . . . . . . . 10 4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12
3.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 10 4.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 12
3.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 10 4.4.2. Protocol features . . . . . . . . . . . . . . . . . . 13
3.4.2. Protocol features . . . . . . . . . . . . . . . . . . 12 4.4.3. Protocol dependencies . . . . . . . . . . . . . . . . 14
3.4.3. Protocol dependencies . . . . . . . . . . . . . . . . 12 4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 14
3.5. SRTP (with DTLS) . . . . . . . . . . . . . . . . . . . . 13 4.5.1. Protocol description . . . . . . . . . . . . . . . . 14
3.5.1. Protocol descriptions . . . . . . . . . . . . . . . . 13 4.5.2. Protocol features . . . . . . . . . . . . . . . . . . 15
3.5.2. Protocol features . . . . . . . . . . . . . . . . . . 14 4.5.3. Protocol dependencies . . . . . . . . . . . . . . . . 16
3.5.3. Protocol dependencies . . . . . . . . . . . . . . . . 14 4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 16
3.6. Differences from ZRTP . . . . . . . . . . . . . . . . . . 15 4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 16
3.7. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 15 4.6.1. Protocol Description . . . . . . . . . . . . . . . . 16
3.7.1. Protocol Description . . . . . . . . . . . . . . . . 15 4.6.2. Protocol Features . . . . . . . . . . . . . . . . . . 17
3.7.2. Protocol Features . . . . . . . . . . . . . . . . . . 16 4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18
3.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16 4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18
4.7.1. Protocol description . . . . . . . . . . . . . . . . 18
3.8. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 16 4.7.2. Protocol features . . . . . . . . . . . . . . . . . . 19
3.8.1. Protocol description . . . . . . . . . . . . . . . . 16 4.7.3. Protocol dependencies . . . . . . . . . . . . . . . . 19
3.8.2. Protocol features . . . . . . . . . . . . . . . . . . 17 4.8. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 19
3.8.3. Protocol dependencies . . . . . . . . . . . . . . . . 17 4.8.1. Protocol Description . . . . . . . . . . . . . . . . 19
3.9. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 17 4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 20
3.9.1. Protocol Description . . . . . . . . . . . . . . . . 18 4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20
3.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 18 4.9. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19 4.9.1. Protocol Description . . . . . . . . . . . . . . . . 20
3.10. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22
3.10.1. Protocol Description . . . . . . . . . . . . . . . . 19 4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 22
3.10.2. Protocol Features . . . . . . . . . . . . . . . . . 20 5. Security Features and Transport Dependencies . . . . . . . . 22
3.10.3. Protocol Dependencies . . . . . . . . . . . . . . . 20 5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 22
4. Security Features and Transport Dependencies . . . . . . . . 21 5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 23
4.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 21 5.3. Optional Feature Availability . . . . . . . . . . . . . . 25
4.2. Optional Features . . . . . . . . . . . . . . . . . . . . 21 6. Transport Security Protocol Interfaces . . . . . . . . . . . 25
5. Transport Security Protocol Interfaces . . . . . . . . . . . 23 6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 26
5.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 23 6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 27
5.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 24 6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 27
5.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 10. Normative References . . . . . . . . . . . . . . . . . . . . 28
9. Normative References . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
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 [RFC8095] by
describing the interfaces required to add security protocols. It describing the interfaces required to add security protocols. It
examines Transport Layer Security (TLS), Datagram Transport Layer examines Transport Layer Security (TLS), Datagram Transport Layer
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with
Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and
WireGuard. This survey is not limited to protocols developed within WireGuard. For each protocol, this document provides a brief
the scope or context of the IETF. description, the security features it provides, and the dependencies
it has on the underlying transport. This is followed by defining the
set of transport security features shared by these protocols.
Finally, we distill the application and transport interfaces provided
by the transport security protocols.
For each protocol, this document provides a brief description, the Selected protocols represent a superset of functionality and features
security features it provides, and the dependencies it has on the a TAPS system may need to support, both internally and externally -
underlying transport. This is followed by defining the set of via an API - for applications [I-D.ietf-taps-arch]. Ubiquitous IETF
transport security features shared by these protocols. Finally, we protocols such as (D)TLS, as well as non-standard protocols such as
distill the application and transport interfaces provided by the Google QUIC, are both included despite overlapping features. As
transport security protocols. such, this survey is not limited to protocols developed within the
scope or context of the IETF. Outside of this candidate set,
protocols that do not offer new features are omitted. For example,
newer protocols such as WireGuard make unique design choices that
have important implications on applications, such as how to best
configure peer public keys and to delegate algorithm selection to the
system. In contrast, protocols such as ALTS [ALTS] are omitted since
they do not represent features deemed unique.
Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH Also, authentication-only protocols such as TCP-AO [RFC5925] and
[RFC4302] are excluded from this survey. TCP-AO adds authenticity IPsec AH [RFC4302] are excluded from this survey. TCP-AO adds
protections to long-lived TCP connections, e.g., replay protection authenticity protections to long-lived TCP connections, e.g., replay
with per-packet Message Authentication Codes. (This protocol protection with per-packet Message Authentication Codes. (This
obsoletes TCP MD5 "signature" options specified in [RFC2385].) One protocol obsoletes TCP MD5 "signature" options specified in
prime use case of TCP-AO is for protecting BGP connections. [RFC2385].) One prime use case of TCP-AO is for protecting BGP
Similarly, AH adds per-datagram authenticity and adds similar replay connections. Similarly, AH adds per-datagram authenticity and adds
protection. Despite these improvements, neither protocol sees similar replay protection. Despite these improvements, neither
general use and both lack critical properties important for emergent protocol sees general use and both lack critical properties important
transport security protocols: confidentiality, privacy protections, for emergent transport security protocols: confidentiality, privacy
and agility. Thus, we omit these and related protocols from our protections, and agility. Thus, we omit these and related protocols
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 4, line 37 skipping to change at page 4, line 48
functionality to an application. functionality to an application.
o Transport Protocol: an implementation that provides one or more o Transport Protocol: an implementation that provides one or more
different transport services using a specific framing and header different transport services using a specific framing and header
format on the wire. A Transport Protocol services an application. format on the wire. A Transport Protocol services an application.
o Application: an entity that uses a transport protocol for end-to- o Application: an entity that uses a transport protocol for end-to-
end delivery of data across the network. This may also be an end delivery of data across the network. This may also be an
upper layer protocol or tunnel encapsulation. upper layer protocol or tunnel encapsulation.
o Security Feature: a specific feature that a network security layer o Security Feature: a feature that a network security layer provides
provides to applications. Examples include authentication, to applications. Examples include authentication, encryption, key
encryption, key generation, session resumption, and privacy. A generation, session resumption, and privacy. Features may be
feature may be considered to be Mandatory or Optional to an Mandatory or Optional for an application's implementation.
application's implementation.
o Security Protocol: a defined network protocol that implements one o Security Protocol: a defined network protocol that implements one
or more security features. Security protocols may be used or more security features. Security protocols may be used
alongside transport protocols, and in combination with other alongside transport protocols, and in combination with other
security protocols when appropriate. security protocols when appropriate.
o Handshake Protocol: a protocol that enables peers to validate each o Handshake Protocol: a protocol that enables peers to validate each
other and to securely establish shared cryptographic context. other and to securely establish shared cryptographic context.
o Record Protocol: a security protocol that allows data to be o Record Protocol: a security protocol that allows data to be
divided into manageable blocks and protected using a shared divided into manageable blocks and protected using shared
cryptographic context. cryptographic context.
o Session: an ephemeral security association between applications. o Session: an ephemeral security association between applications.
o Cryptographic context: a set of cryptographic parameters, o Cryptographic context: a set of cryptographic parameters,
including but not necessarily limited to keys for encryption, including but not necessarily limited to keys for encryption,
authentication, and session resumption, enabling authorized authentication, and session resumption, enabling authorized
parties to a session to communicate securely. parties to a session to communicate securely.
o Connection: the shared state of two or more endpoints that o Connection: the shared state of two or more endpoints that
skipping to change at page 5, line 32 skipping to change at page 5, line 40
be multihomed or resilient across network interface or address be multihomed or resilient across network interface or address
changes. changes.
o Peer: an endpoint application party to a session. o Peer: an endpoint application party to a session.
o Client: the peer responsible for initiating a session. o Client: the peer responsible for initiating a session.
o Server: the peer responsible for responding to a session o Server: the peer responsible for responding to a session
initiation. initiation.
3. Transport Security Protocol Descriptions 3. Security Features
This section contains descriptions of security protocols that In this section, we enumerate Security Features exposed by protocols
currently used to protect data being sent over a network. discussed in the remainder of this document. Protocol security
properties that are unrelated to the API surface exposed by such
protocols, such as client or server identity hiding, are not listed
here as features.
For each protocol, we describe the features it provides and its o Forward-secure key establishment: Cryptographic key establishment
dependencies on other protocols. with forward secure properties.
3.1. TLS o Cryptographic algorithm negotiation: Negotiate support of protocol
algorithms, including: encryption, hash, MAC (PRF), and digital
signature algorithms.
o Stateful and stateless cross-connection session resumption:
Connection establishment without needing to complete an entirely
new handshake.
o Peer authentication (certificate, raw public key, pre-shared key,
or EAP-based): Peer authentication using select or protocol-
specific mechanisms.
o Mutual authentication: Connection establishment wherein both
endpoints are authenticated.
o Record (channel or datagram) confidentiality and integrity:
Encryption and authentication of application plaintext bytes sent
between peers over a channel or in individual datagrams.
o Partial record confidentiality: Encryption of some portion of
records.
o Optional record integrity: Optional authentication of certain
records.
o Record replay prevention: Protocol detection and defense against
record replays, e.g., due to in-network retransmissions.
o Application-layer feature negotiation: Securely negotiate
application-specific functionality.
o Early data support (starting with TLS 1.3): Transmission of
application data prior to connection (handshake) establishment.
o Connection mobility: Connection continuation in the presence of
5-tuple changes beneath the secure transport protocol, e.g., due
to NAT rebindings.
o Application-layer authentication delegation: Out-of-band peer
authentication performed by applications outside of the connection
establishment.
o Out-of-order record receipt: Processing of records received out-
of-order.
o DoS mitigation (cookie or puzzle based): Peer DoS mitigation via
explicit proof of origin (cookie) or work mechanisms (puzzles).
o Connection re-keying: In-band cryptographic handshake re-keying.
o Optional length-hiding and anti-amplification padding: Protocol-
drive record padding aimed at hiding plaintext message length and
mitigating amplification attack vectors.
4. Transport Security Protocol Descriptions
This section contains descriptions of security protocols currently
used to protect data being sent over a network.
For each protocol, we describe its provided features and dependencies
on other protocols.
4.1. TLS
TLS (Transport Layer Security) [RFC5246] is a common protocol used to TLS (Transport Layer Security) [RFC5246] is a common protocol used to
establish a secure session between two endpoints. Communication over establish a secure session between two endpoints. Communication over
this session "prevents eavesdropping, tampering, and message this session "prevents eavesdropping, tampering, and message
forgery." TLS consists of a tightly coupled handshake and record forgery." TLS consists of a tightly coupled handshake and record
protocol. The handshake protocol is used to authenticate peers, protocol. The handshake protocol is used to authenticate peers,
negotiate protocol options, such as cryptographic algorithms, and negotiate protocol options, such as cryptographic algorithms, and
derive session-specific keying material. The record protocol is used derive session-specific keying material. The record protocol is used
to marshal (possibly encrypted) data from one peer to the other. to marshal (possibly encrypted) data from one peer to the other.
This data may contain handshake messages or raw application data. This data may contain handshake messages or raw application data.
3.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
[I-D.ietf-tls-tls13]. The record protocol is designed to marshal an [I-D.ietf-tls-tls13]. The record protocol is designed to marshal an
arbitrary, in-order stream of bytes from one endpoint to the other. arbitrary, in-order stream of bytes from one endpoint to the other.
It handles segmenting, compressing (when enabled), and encrypting It handles segmenting, compressing (when enabled), and encrypting
data into discrete records. When configured to use an AEAD data into discrete records. When configured to use an authenticated
algorithm, it also handles nonce generation and encoding for each encryption with associated data (AEAD) algorithm, it also handles
record. The record protocol is hidden from the client behind a byte nonce generation and encoding for each record. The record protocol
stream-oriented API. is 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 with a CertificateRequest handshake message. Assuming strong server with a CertificateRequest handshake message. Assuming strong
cryptography, an infrastructure for trust establishment, correctly- cryptography, an infrastructure for trust establishment, correctly-
skipping to change at page 7, line 7 skipping to change at page 8, line 33
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.
Once a session is disconnected all session keying material must be Once a session is disconnected all session keying material must be
destroyed, with the exception of secrets previously established destroyed, with the exception of secrets previously established
expressly for purposes of session resumption. TLS supports stateful expressly for purposes of session resumption. TLS supports stateful
and stateless resumption. (Here, "state" refers to bookkeeping on a and stateless resumption. (Here, "state" refers to bookkeeping on a
per-session basis by the server. It is assumed that the client must per-session basis by the server. It is assumed that the client must
always store some state information in order to resume a session.) always store some state information in order to resume a session.)
3.1.2. Protocol Features 4.1.2. Protocol Features
o Key exchange and ciphersuite algorithm negotiation. o Forward-secure key establishment.
o Stateful and stateless session resumption. o Cryptographic algorithm negotiation.
o Certificate- and raw public key-based authentication. o Stateful and stateless cross-connection session resumption.
o Mutual client and server authentication. o Peer authentication (Certificate, raw public key, and pre-shared
key).
o Byte stream confidentiality and integrity. o Mandatory server authentication, optional client authentication.
o Extensibility via well-defined extensions. o Record (channel) confidentiality and integrity.
o 0-RTT data support (starting with TLS 1.3). o Record replay prevention.
o Application-layer protocol negotiation. o Application-layer feature negotiation.
o Transparent data segmentation. o Early data support (starting with TLS 1.3).
3.1.3. Protocol Dependencies o Optional length-hiding padding (starting with TLS 1.3).
4.1.3. Protocol Dependencies
o TCP for in-order, reliable transport. o TCP for in-order, reliable transport.
o (Optionally) A PKI trust store for certificate validation. o (Optionally) A PKI trust store for certificate validation.
3.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 UDP instead of TCP.
Since UDP does not guarantee datagram ordering or reliability, DTLS Since UDP does not guarantee datagram ordering or reliability, DTLS
modifies the protocol to make sure it can still provide the same modifies the protocol to make sure it can still provide the same
security guarantees as TLS. DTLS was designed to be as close to TLS security guarantees as TLS. DTLS was designed to be as close to TLS
as possible, so this document will assume that all properties from as possible, so this document will assume that all properties from
TLS are carried over except where specified. TLS are carried over except where specified.
3.2.1. Protocol Description 4.2.1. Protocol Description
DTLS is modified from TLS to account for packet loss, reordering, and DTLS is modified from TLS to operate with the possibility of packet
duplication that may occur when operating over UDP. To enable out- loss, reordering, and duplication that may occur when operating over
of-order delivery of application data, the DTLS record protocol UDP. To enable out-of-order delivery of application data, the DTLS
itself has no inter-record dependencies. However, as the handshake record protocol itself has no inter-record dependencies. However, as
requires reliability, each handshake message is assigned an explicit the handshake requires reliability, each handshake message is
sequence number to enable retransmissions of lost packets and in- assigned an explicit sequence number to enable retransmissions of
order processing by the receiver. Handshake message loss is remedied lost packets and in-order processing by the receiver. Handshake
by sender retransmission after a configurable period in which the message loss is remedied by sender retransmission after a
expected response has not yet been received. configurable period in which the expected response has not yet been
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 allow peers with multiple DTLS DTLS relies on unique UDP 4-tuples to identify connections. Since
connections between them to demultiplex connections, constraining all application-layer data is encrypted, demultiplexing over the same
protocol design slightly more than UDP: application-layer 4-tuple requires the use of a connection identifier extension
demultiplexing over the same 4-tuple is not possible without trial [I-D.ietf-tls-dtls-connection-id] to permit identification of the
decryption as all application-layer data is encrypted to a correct connection-specific cryptographic context without the use of
connection-specific cryptographic context. Starting with DTLS 1.3 trial decryption. (Note that this extension is only supported in
[I-D.ietf-tls-dtls13], a connection identifier extension to permit DTLS 1.2 and 1.3 {{I-D.ietf-tls-dtls13}.)
multiplexing of independent connections over the same 4-tuple is Since datagrams can be replayed, DTLS provides optional anti-replay
available [I-D.ietf-tls-dtls-connection-id].
Since datagrams may 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].
3.2.2. Protocol Features 4.2.2. Protocol Features
o Anti-replay protection between datagrams. o Record replay protection.
o Basic reliability for handshake messages. o Record (datagram) confidentiality and integrity.
o See also the features from TLS. o Out-of-order record receipt.
3.2.3. Protocol Dependencies o DoS mitigation (cookie-based).
See also the features from TLS.
4.2.3. Protocol Dependencies
o Since DTLS runs over an unreliable, unordered datagram transport, o Since DTLS runs over an unreliable, unordered datagram transport,
it does not require any reliability features. it does not require any reliability features.
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. reconstruction of datagrams fragmented over packets. (Note: DTLS
1.3 short header records omit the explicit length field.)
o UDP 4-tuple uniqueness, or the connection identifier extension, o UDP 4-tuple uniqueness, or the connection identifier extension,
for demultiplexing. for demultiplexing.
o Path MTU discovery. o Path MTU discovery.
3.3. (IETF) QUIC with TLS 4.3. (IETF) QUIC with TLS
QUIC (Quick UDP Internet Connections) is a new standards-track QUIC (Quick UDP Internet Connections) is a new standards-track
transport protocol that runs over UDP, loosely based on Google's transport protocol that runs over UDP, loosely based on Google's
original proprietary gQUIC protocol. (See Section 3.3.4 for more original proprietary gQUIC protocol [I-D.ietf-quic-transport]. (See
details.) The QUIC transport layer itself provides support for data Section 4.3.4 for more details.) The QUIC transport layer itself
confidentiality and integrity. This requires keys to be derived with provides support for data confidentiality and integrity. This
a separate handshake protocol. A mapping for QUIC over TLS 1.3 requires keys to be derived with a separate handshake protocol. A
[I-D.ietf-quic-tls] has been specified to provide this handshake. mapping for QUIC over TLS 1.3 [I-D.ietf-quic-tls] has been specified
to provide this handshake.
3.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.
skipping to change at page 9, line 47 skipping to change at page 11, line 31
Initial QUIC messages (packets) are encrypted using "fixed" keys Initial QUIC messages (packets) are encrypted using "fixed" keys
derived from the QUIC version and public packet information derived from the QUIC version and public packet information
(Connection ID). Packets are later encrypted using keys derived from (Connection ID). Packets are later encrypted using keys derived from
the TLS traffic secret upon handshake completion. The TLS 1.3 the TLS traffic secret upon handshake completion. The TLS 1.3
handshake for QUIC is used in either a single-RTT mode or a fast-open handshake for QUIC is used in either a single-RTT mode or a fast-open
zero-RTT mode. When zero-RTT handshakes are possible, the encryption zero-RTT mode. When zero-RTT handshakes are possible, the encryption
first transitions to use the zero-RTT keys before using single-RTT first transitions to use the zero-RTT keys before using single-RTT
handshake keys after the next TLS flight. handshake keys after the next TLS flight.
3.3.2. Protocol Features 4.3.2. Protocol Features
o Handshake properties of TLS.
o Multiple encrypted streams over a single connection without head- o DoS mitigation (cookie-based).
of-line blocking.
o Packet payload encryption and complete packet authentication (with See also the properties of TLS.
the exception of the Public Reset packet, which is not
authenticated).
3.3.3. Protocol Dependencies 4.3.3. Protocol Dependencies
o QUIC transport relies on UDP. o QUIC transport relies on UDP.
o QUIC transport relies on TLS 1.3 for authentication and initial o QUIC transport relies on TLS 1.3 for peer authentication and
key derivation. initial key derivation.
o TLS within QUIC relies on a reliable stream abstraction for its o TLS within QUIC relies on QUIC for reliable handshake record
handshake. transmission and receipt.
3.3.4. Differences from Google QUIC 4.3.4. Variant: Google QUIC
Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol
designed and deployed by Google following experience from deploying designed and deployed by Google following experience from deploying
SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally
known as "QUIC": this document uses gQUIC to unambiguously known as "QUIC": this document uses gQUIC to unambiguously
distinguish it from the standards-track IETF QUIC. The proprietary distinguish it from the standards-track IETF QUIC. The proprietary
technical forebear of IETF QUIC, gQUIC was originally designed with technical forebear of IETF QUIC, gQUIC was originally designed with
tightly-integrated security and application data transport protocols. tightly-integrated security and application data transport protocols.
3.3.5. Protocol Description 4.4. IKEv2 with ESP
((TODO: write me))
3.3.6. Protocol Dependencies
((TODO: write me))
3.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 as protocol suite that encrypts and authenticates IP packets, either as
for creating tunnels (tunnel-mode) or for direct transport for creating tunnels (tunnel-mode) or for direct transport
connections (transport-mode). This suite of protocols separates out connections (transport-mode). This suite of protocols separates out
the key generation protocol (IKEv2) from the transport encryption the key generation protocol (IKEv2) from the transport encryption
protocol (ESP). Each protocol can be used independently, but this protocol (ESP). Each protocol can be used independently, but this
document considers them together, since that is the most common document considers them together, since that is the most common
pattern. pattern.
3.4.1. Protocol descriptions 4.4.1. Protocol descriptions
3.4.1.1. IKEv2
4.4.1.1. IKEv2
IKEv2 is a control protocol that runs on UDP port 500. Its primary IKEv2 is a control protocol that runs on UDP port 500. Its primary
goal is to generate keys for Security Associations (SAs). It first goal is to generate keys for Security Associations (SAs). An SA
uses a Diffie-Hellman key exchange to generate keys for the "IKE SA", contains shared (cryptographic) information used for establishing
which is a set of keys used to encrypt further IKEv2 messages. It other SAs or keying ESP; See Section 4.4.1.2. IKEv2 first uses a
then goes through a phase of authentication in which both peers Diffie-Hellman key exchange to generate keys for the "IKE SA", which
present blobs signed by a shared secret or private key, after which is a set of keys used to encrypt further IKEv2 messages. It then
another set of keys is derived, referred to as the "Child SA". These goes through a phase of authentication in which both peers present
Child SA keys are used by ESP. blobs signed by a shared secret or private key, after which another
set of keys is derived, referred to as the "Child SA". These Child
SA keys are used by ESP.
IKEv2 negotiates which protocols are acceptable to each peer for both IKEv2 negotiates which protocols are acceptable to each peer for both
the IKE and Child SAs using "Proposals". Each proposal may contain the IKE and Child SAs using "Proposals". Each proposal may contain
an encryption algorithm, an authentication algorithm, a Diffie- an encryption algorithm, an authentication algorithm, a Diffie-
Hellman group, and (for IKE SAs only) a pseudorandom function Hellman group, and (for IKE SAs only) a pseudorandom function
algorithm. Each peer may support multiple proposals, and the most algorithm. Each peer may support multiple proposals, and the most
preferred mutually supported proposal is chosen during the handshake. preferred mutually supported proposal is chosen during the handshake.
The authentication phase of IKEv2 may use Shared Secrets, The authentication phase of IKEv2 may use Shared Secrets,
Certificates, Digital Signatures, or an EAP (Extensible Certificates, Digital Signatures, or an EAP (Extensible
skipping to change at page 11, line 41 skipping to change at page 13, line 12
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 addresses and set of Security Associations to migrate over different addresses and
interfaces [RFC4555]. 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].
3.4.1.2. ESP 4.4.1.2. ESP
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 12, line 23 skipping to change at page 13, line 39
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].
3.4.2. Protocol features 4.4.2. Protocol features
3.4.2.1. IKEv2 4.4.2.1. IKEv2
o Encryption and authentication of handshake packets. o Forward-secure key establishment.
o Cryptographic algorithm negotiation. o Cryptographic algorithm negotiation.
o Session resumption. o Peer authentication (Certificate, raw public key, pre-shared key,
and EAP).
o Mobility across addresses and interfaces. o Mutual authentication.
o Peer authentication extensibility based on shared secret, o Record (datagram) confidentiality and integrity.
certificates, digital signatures, or EAP methods.
3.4.2.2. ESP o Session resumption.
o Data confidentiality and authentication. o Connection mobility.
o Connectionless integrity. o DoS mitigation (cookie-based).
o Anti-replay protection. 4.4.2.2. ESP
o Limited flow confidentiality. o Record confidentiality and integrity.
3.4.3. Protocol dependencies o Record replay protection.
3.4.3.1. IKEv2
4.4.3. 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.
3.4.3.2. ESP 4.4.3.2. ESP
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.
3.5. SRTP (with DTLS) 4.5. Secure RTP (with DTLS)
SRTP - Secure RTP - is a profile for RTP that provides Secure RTP (SRTP) is a profile for RTP that provides confidentiality,
confidentiality, message authentication, and replay protection for message authentication, and replay protection for RTP data packets
data and control packets [RFC3711]. SRTP packets are encrypted using and RTP control protocol (RTCP) packets [RFC3711].
a session key, which is derived from a separate master key. Master
keys are derived and managed externally, e.g., via DTLS, as specified
in RFC 5763 [RFC5763], under the control of a signaling protocol such
as SIP [RFC3261] or WebRTC [I-D.ietf-rtcweb-security-arch].
3.5.1. Protocol descriptions 4.5.1. Protocol description
SRTP adds confidentiality and optional integrity protection to RTP SRTP adds confidentiality and optional integrity protection to RTP
data packets, and adds confidentially and mandatory integrity data packets, and adds confidentially and mandatory integrity
protection to RTP control (RTCP) packets. For RTP data packets, this protection to RTCP packets. For RTP data packets, this is done by
is done by encrypting the payload section of the packet and encrypting the payload section of the packet and optionally appending
optionally appending an authentication tag (MAC) as a packet trailer, an authentication tag (MAC) as a packet trailer, with the RTP header
with the RTP header authenticated but not encrypted. The RTP header authenticated but not encrypted (the RTP header was left unencrypted
itself is left unencrypted to enable RTP header compression to enable RTP header compression [RFC2508] [RFC3545]). For RTCP
[RFC2508][RFC3545]. For RTCP packets, the first packet in the packets, the first packet in the compound RTCP packet is partially
compound RTCP packet is partially encrypted, leaving the first eight encrypted, leaving the first eight octets of the header as clear-text
octets of the header as cleartext to allow identification of the to allow identification of the packet as RTCP, while the remainder of
packet as RTCP, while the remainder of the compound packet is fully the compound packet is fully encrypted. The entire RTCP packet is
encrypted. The entire RTCP packet is then authenticated by appending then authenticated by appending a MAC as packet trailer.
a MAC as packet trailer.
Packets are encrypted using session keys, which are ultimately Packets are encrypted using session keys, which are ultimately
derived from a master key and some additional master salt and session derived from a master key and an additional master salt and session
salt. SRTP packets carry a 2-byte sequence number to partially salt. SRTP packets carry a 2-byte sequence number to partially
identify the unique packet index. SRTP peers maintain a separate identify the unique packet index. SRTP peers maintain a separate
rollover counter (ROC) for RTP data packets that is incremented roll-over counter (ROC) for RTP data packets that is incremented
whenever the sequence number wraps. The sequence number and ROC whenever the sequence number wraps. The sequence number and ROC
together determine the packet index. RTCP packets have a similar, together determine the packet index. RTCP packets have a similar,
yet differently named, field called the RTCP index which serves the yet differently named, field called the RTCP index which serves the
same purpose. same purpose.
Numerous encryption modes are supported. For popular modes of Numerous encryption modes are supported. For popular modes of
operation, e.g., AES-CTR, the (unique) initialization vector (IV) operation, e.g., AES-CTR, the (unique) initialization vector (IV)
used for each encryption mode is a function of the RTP SSRC used for each encryption mode is a function of the RTP SSRC
(synchronization source), packet index, and session "salting key". (synchronization source), packet index, and session "salting key".
SRTP offers replay detection by keeping a replay list of already seen SRTP offers replay detection by keeping a replay list of already seen
and processed packet indices. If a packet arrives with an index that and processed packet indices. If a packet arrives with an index that
matches one in the replay list, it is silently discarded. matches one in the replay list, it is silently discarded.
DTLS [RFC5764] is commonly used as a way to perform mutual DTLS [RFC5764] is commonly used to perform mutual authentication and
authentication and key agreement for SRTP [RFC5763]. (Here, key agreement for SRTP [RFC5763]. Peers use DTLS to perform mutual
certificates marshal public keys between endpoints. Thus, self- certificate-based authentication on the media path, and to generate
signed certificates may be used if peers do not mutually trust one the SRTP master key. Peer certificates can be issued and signed by a
another, as is common on the Internet.) When DTLS is used, certificate authority. Alternatively, certificates used in the DTLS
certificate fingerprints are transmitted out-of-band using SIP. exchange can be self-signed. If they are self-signed, certificate
Peers typically verify that DTLS-offered certificates match that fingerprints are included in the signalling exchange (e.g., in SIP or
which are offered over SIP. This prevents active attacks on RTP, but WebRTC), and used to bind the DTLS key exchange in the media plane to
not on the signaling (SIP or WebRTC) channel. the signaling plane. The combination of a mutually authenticated
DTLS key exchange on the media path and a fingerprint sent in the
signalling channel protects against active attacks on the media,
provided the signalling can be trusted. Signalling needs to be
protected as described in, for example, SIP [RFC3261] Authenticated
Identity Management [RFC4474] or the WebRTC security architecture
[I-D.ietf-rtcweb-security-arch], to provide complete system security.
3.5.2. Protocol features 4.5.2. Protocol features
o Optional replay protection with tunable replay windows. o Forward-secure key establishment.
o Out-of-order packet receipt. o Cryptographic algorithm negotiation.
o (RFC5763) Mandatory mutually authenticated key exchange. o Mutual authentication.
o Partial encryption, protecting media payloads and control packets o Partial datagram confidentiality. (Packet headers are not
but not data packet headers. encrypted.)
o Optional authentication of data packets; mandatory authentication o Optional authentication of data packets.
of control packets.
3.5.3. Protocol dependencies o Mandatory authentication of control packets.
o External key derivation and management mechanism or protocol, o Out-of-order record receipt.
e.g., DTLS [RFC5763].
o External signaling protocol to manage RTP parameters and locate 4.5.3. Protocol dependencies
and identify peers, e.g., SIP [RFC3261] or WebRTC
o External key derivation and management protocol, e.g., DTLS
[RFC5763].
o External identity management protocol, e.g., SIP Authenticated
Identity Management [RFC4474], WebRTC Security Architecture
[I-D.ietf-rtcweb-security-arch]. [I-D.ietf-rtcweb-security-arch].
3.6. Differences from ZRTP 4.5.4. Variant: ZRTP for Media Path Key Agreement
((TODO: write me)) ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It
uses standard SRTP to protect RTP data packets and RTCP packets, but
provides alternative key agreement and identity management protocols.
3.7. tcpcrypt Key agreement is performed using a Diffie-Hellman key exchange that
runs on the media path. This generates a shared secret that is then
used to generate the master key and salt for SRTP.
ZRTP does not rely on a PKI or external identity management system.
Rather, it uses an ephemeral Diffie-Hellman key exchange with hash
commitment to allow detection of man-in-the-middle attacks. This
requires endpoints to display a short authentication string that the
users must read and verbally compare to validate the hashes and
ensure security. Endpoints cache some key material after the first
call to use in subsequent calls; this is mixed in with the Diffie-
Hellman shared secret, so the short authentication string need only
be checked once for a given user. This gives key continuity
properties analogous to the secure shell (ssh) [RFC4253].
4.6. tcpcrypt
Tcpcrypt is a lightweight extension to the TCP protocol to enable Tcpcrypt is a lightweight extension to the TCP protocol to enable
opportunistic encryption with hooks available to the application opportunistic encryption with hooks available to the application
layer for implementation of endpoint authentication. layer for implementation of endpoint authentication.
3.7.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 [I-D.ietf-tcpinc-tcpcrypt]. It is a
family of TCP encryption protocols (TEP), distinguished by key family of TCP encryption protocols (TEP), distinguished by key
exchange algorithm. The use of a TEP is negotiated with a TCP option exchange algorithm. The use of a TEP is negotiated with a TCP option
during the initial TCP handshake via the mechanism described by TCP during the initial TCP handshake via the mechanism described by TCP
Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the
case of initial session establishment, once a tcpcrypt TEP has been case of initial session establishment, once a tcpcrypt TEP has been
negotiated the key exchange occurs within the data segments of the negotiated the key exchange occurs within the data segments of the
first few packets exchanged after the handshake completes. The first few packets exchanged after the handshake completes. The
skipping to change at page 16, line 9 skipping to change at page 17, line 40
resumption across a pool of servers implies shared state. resumption across a pool of servers implies shared state.
Owing to middlebox ossification issues, tcpcrypt only protects the Owing to middlebox ossification issues, tcpcrypt only protects the
payload portion of a TCP packet. It does not encrypt any header payload portion of a TCP packet. It does not encrypt any header
information, such as the TCP sequence number. information, such as the TCP sequence number.
Tcpcrypt exposes a universally-unique connection-specific session ID Tcpcrypt exposes a universally-unique connection-specific session ID
to the application, suitable for application-level endpoint to the application, suitable for application-level endpoint
authentication either in-band or out-of-band. authentication either in-band or out-of-band.
3.7.2. Protocol Features 4.6.2. Protocol Features
o Forward-secure TCP payload encryption and integrity protection. o Forward-secure key establishment.
o Session caching and address-agnostic resumption. o Record (channel) confidentiality and integrity.
o Stateful cross-connection session resumption.
o Connection re-keying. o Connection re-keying.
o Application-level authentication primitive. o Application authentication delegation.
3.7.3. Protocol Dependencies 4.6.3. Protocol Dependencies
o TCP o TCP
o TCP Encryption Negotiation Option (ENO) o TCP Encryption Negotiation Option (ENO)
3.8. WireGuard 4.7. WireGuard
WireGuard is a layer 3 protocol designed to complement or replace WireGuard is a layer 3 protocol designed to complement or replace
IPsec [WireGuard]. Unlike most transport security protocols, which IPsec [WireGuard]. Unlike most transport security protocols, which
rely on PKI for peer authentication, WireGuard authenticates peers rely on PKI for peer authentication, WireGuard authenticates peers
using pre-shared public keys delivered out-of-band, each of which is using pre-shared public keys delivered out-of-band, each of which is
bound to one or more IP addresses. Moreover, as a protocol suited bound to one or more IP addresses. Moreover, as a protocol suited
for VPNs, WireGuard offers no extensibility, negotiation, or for VPNs, WireGuard offers no extensibility, negotiation, or
cryptographic agility. cryptographic agility.
3.8.1. Protocol description 4.7.1. Protocol description
WireGuard is a simple VPN protocol that binds a pre-shared public key WireGuard is a simple VPN protocol that binds a pre-shared public key
to one or more IP addresses. Users configure WireGuard by to one or more IP addresses. Users configure WireGuard by
associating peer public keys with IP addresses. These mappings are associating peer public keys with IP addresses. These mappings are
stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard] stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard]
for more details and sample configurations.) These keys are used for more details and sample configurations.) These keys are used
upon WireGuard packet transmission and reception. For example, upon upon WireGuard packet transmission and reception. For example, upon
receipt of a Handshake Initiation message, receivers use the static receipt of a Handshake Initiation message, receivers use the static
public key in their CryptoKey routing table to perform necessary public key in their CryptoKey routing table to perform necessary
cryptographic computations. cryptographic computations.
skipping to change at page 17, line 24 skipping to change at page 19, line 8
introduced. introduced.
WireGuard is designed to be entirely stateless, modulo the CryptoKey WireGuard is designed to be entirely stateless, modulo the CryptoKey
routing table, which has size linear with the number of trusted routing table, which has size linear with the number of trusted
peers. If a WireGuard receiver is under heavy load and cannot peers. If a WireGuard receiver is under heavy load and cannot
process a packet, e.g., cannot spare CPU cycles for point process a packet, e.g., cannot spare CPU cycles for point
multiplication, it can reply with a cookie similar to DTLS and IKEv2. multiplication, it can reply with a cookie similar to DTLS and IKEv2.
This cookie only proves IP address ownership. Any rate limiting This cookie only proves IP address ownership. Any rate limiting
scheme can be applied to packets coming from non-spoofed addresses. scheme can be applied to packets coming from non-spoofed addresses.
3.8.2. Protocol features 4.7.2. Protocol features
o Optional PSK-based session creation. o Forward-secure key establishment.
o Mutual client and server authentication. o Peer authentication (Public-key and PSK).
o Stateful, timestamp-based replay prevention. o Mutual authentication.
o Cookie-based DoS mitigation similar to DTLS and IKEv2. o Record replay prevention (Stateful, timestamp-based).
3.8.3. Protocol dependencies o DoS mitigation (cookie-based).
4.7.3. Protocol dependencies
o Datagram transport. o Datagram transport.
o Out-of-band key distribution and management. o Out-of-band key distribution and management.
3.9. MinimalT 4.8. MinimalT
MinimalT is a UDP-based transport security protocol designed to offer MinimalT is a UDP-based transport security protocol designed to offer
confidentiality, mutual authentication, DoS prevention, and confidentiality, mutual authentication, DoS prevention, and
connection mobility [MinimalT]. One major goal of the protocol is to connection mobility [MinimalT]. One major goal of the protocol is to
leverage existing protocols to obtain server-side configuration leverage existing protocols to obtain server-side configuration
information used to more quickly bootstrap a connection. MinimalT information used to more quickly bootstrap a connection. MinimalT
uses a variant of TCP's congestion control algorithm. uses a variant of TCP's congestion control algorithm.
3.9.1. Protocol Description 4.8.1. Protocol Description
MinimalT is a secure transport protocol built on top of a widespread MinimalT is a secure transport protocol built on top of a widespread
directory service. Clients and servers interact with local directory directory service. Clients and servers interact with local directory
services to (a) resolve server information and (b) public ephemeral services to (a) resolve server information and (b) public ephemeral
state information, respectively. Clients connect to a local resolver state information, respectively. Clients connect to a local resolver
once at boot time. Through this resolver they recover the IP once at boot time. Through this resolver they recover the IP
address(es) and public key(s) of each server to which they want to address(es) and public key(s) of each server to which they want to
connect. connect.
Connections are instances of user-authenticated, mobile sessions Connections are instances of user-authenticated, mobile sessions
skipping to change at page 18, line 36 skipping to change at page 20, line 18
Before a client connects to a remote service, it must first establish Before a client connects to a remote service, it must first establish
a tunnel to the host providing or offering the service. Tunnels are a tunnel to the host providing or offering the service. Tunnels are
established in 1-RTT using an ephemeral key obtained from the established in 1-RTT using an ephemeral key obtained from the
directory service. Tunnel initiators provide their own ephemeral key directory service. Tunnel initiators provide their own ephemeral key
and, optionally, a DoS puzzle solution such that the recipient and, optionally, a DoS puzzle solution such that the recipient
(server) can verify the authenticity of the request and derive a (server) can verify the authenticity of the request and derive a
shared secret. Within a tunnel, new connections to services may be shared secret. Within a tunnel, new connections to services may be
established. established.
3.9.2. Protocol Features 4.8.2. Protocol Features
o 0-RTT forward secrecy for new connections.
o DoS prevention by client-side puzzles. o Forward-secure key establishment.
o Tunnel-based mobility. o DoS mitigation (puzzle-based).
o (Transport Feature) Connection multiplexing between hosts across o Connection mobility (tunnel-based).
shared tunnels.
o (Transport Feature) Congestion control state is shared across Additional (orthogonal) transport features include: connection
connections between the same host pairs. multiplexing between hosts across shared tunnels, and congestion
control state is shared across connections between the same host
pairs.
3.9.3. Protocol Dependencies 4.8.3. Protocol Dependencies
o A DNS-like resolution service to obtain location information (an o A DNS-like resolution service to obtain location information (an
IP address) and ephemeral keys. IP address) and ephemeral keys.
o A PKI trust store for certificate validation. o A PKI trust store for certificate validation.
3.10. CurveCP 4.9. CurveCP
CurveCP [CurveCP] is a UDP-based transport security protocol from CurveCP [CurveCP] is a UDP-based transport security protocol from
Daniel J. Bernstein. Unlike other transport security protocols, it Daniel J. Bernstein. Unlike other transport security protocols, it
is based entirely upon highly efficient public key algorithms. This is based entirely upon highly efficient public key algorithms. This
removes many pitfalls associated with nonce reuse and key removes many pitfalls associated with nonce reuse and key
synchronization. synchronization.
3.10.1. Protocol Description 4.9.1. Protocol Description
CurveCP is a UDP-based transport security protocol. It is built on CurveCP is a UDP-based transport security protocol. It is built on
three principal features: exclusive use of public key authenticated three principal features: exclusive use of public key authenticated
encryption of packets, server-chosen cookies to prohibit memory and encryption of packets, server-chosen cookies to prohibit memory and
computation DoS at the server, and connection mobility with a client- computation DoS at the server, and connection mobility with a client-
chosen ephemeral identifier. chosen ephemeral identifier.
There are two rounds in CurveCP. In the first round, the client There are two rounds in CurveCP. In the first round, the client
sends its first initialization packet to the server, carrying its sends its first initialization packet to the server, carrying its
(possibly fresh) ephemeral public key C', with zero-padding encrypted (possibly fresh) ephemeral public key C', with zero-padding encrypted
skipping to change at page 20, line 29 skipping to change at page 22, line 9
CurveCP supports a weak form of client authentication. Clients are CurveCP supports a weak form of client authentication. Clients are
permitted to send their long-term public keys in the second permitted to send their long-term public keys in the second
initialization packet. A server can verify this public key and, if initialization packet. A server can verify this public key and, if
untrusted, drop the connection and subsequent data. untrusted, drop the connection and subsequent data.
Unlike some other protocols, CurveCP data packets leave only the Unlike some other protocols, CurveCP data packets leave only the
ephemeral public key, the connection ID, and the per-message nonce in ephemeral public key, the connection ID, and the per-message nonce in
the clear. Everything else is encrypted. the clear. Everything else is encrypted.
3.10.2. Protocol Features 4.9.2. Protocol Features
o Forward-secure data encryption and authentication.
o Per-packet public-key encryption. o Datagram confidentiality and integrity (via public key
encryption).
o 1-RTT session bootstrapping. o 1-RTT session bootstrapping.
o Connection mobility based on a client-chosen ephemeral identifier. o Connection mobility (based on a client-chosen ephemeral
identifier).
o Connection establishment message padding to prevent traffic
amplification.
o Sender-chosen explicit nonces, e.g., based on a sequence number. o Optional length-hiding and anti-amplification padding.
3.10.3. Protocol Dependencies 4.9.3. Protocol Dependencies
o An unreliable transport protocol such as UDP. o An unreliable transport protocol such as UDP.
4. Security Features and Transport Dependencies 5. Security Features and Transport 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 TAPS
implementation. Optional features by contrast may vary from implementation. Optional features by contrast may vary from
implementation to implementation, and so an application cannot simply implementation to implementation, and so an application cannot simply
assume they are available. Applications learn of and use optional assume they are available. Applications learn of and use optional
features by querying for their presence and support. Optional features by querying for their presence and support. Optional
features may not be implemented, or may be disabled if their presence features may not be implemented, or may be disabled if their presence
impacts transport services or if a necessary transport service is impacts transport services or if a necessary transport service is
unavailable. unavailable.
4.1. Mandatory Features 5.1. Mandatory Features
o Segment encryption and authentication: Transit data must be o Segment or datagram encryption and authentication: Transit data
protected with an authenticated encryption algorithm. must be protected with an authenticated encryption algorithm.
o Forward-secure key establishment: Negotiated keying material must o Forward-secure key establishment: Negotiated keying material must
come from an authenticated, forward-secure key exchange protocol. come from an authenticated, forward-secure key exchange protocol.
o Private key interface or injection: Authentication based on public o Public-key (raw or certificate) based authentication:
key signatures is commonplace for many transport security Authentication based on public key signatures is commonplace for
protocols. many transport security protocols.
o Endpoint authentication: The endpoint (receiver) of a new o Responder authentication: The endpoint (receiver) of a new
connection must be authenticated before any data is sent to said connection must be authenticated before any data is sent to said
party. party.
o Pre-shared key support: A security protocol must be able to use a o Pre-shared key support: A security protocol must be able to use a
pre-shared key established out-of-band or from a prior session to pre-shared key established out-of-band or from a prior session to
encrypt individual messages, packets, or datagrams. encrypt individual messages, packets, or datagrams.
4.2. Optional Features 5.2. Optional Features
o Mutual authentication: Transport security protocols must allow o Cryptographic algorithm negotiation (AN): Transport security
each endpoint to authenticate the other if required by the protocols should permit applications to configure supported or
enabled cryptographic algorithms.
* Transport dependency: None.
* Application dependency: Application awareness of supported or
desired algorithms.
o Application authentication delegation (AD): Some protocols may
completely defer endpoint authentication to applications, e.g., to
reduce online protocol complexity.
* Transport dependency: None.
* Application dependency: Application opt-in and policy for
endpoint authentication
o Mutual authentication (MA): Transport security protocols should
allow each endpoint to authenticate the other if required by the
application. application.
* Transport dependency: None. * Transport dependency: None.
* Application dependency: Mutual authentication required for * Application dependency: Mutual authentication required for
application support. application support.
o Connection mobility: Sessions should not be bound to a network o DoS mitigation (DM): Transport security protocols may need to
connection (or 5-tuple). This allows cryptographic key material support volumetric DoS prevention via, e.g., cookies or initiator-
and other state information to be reused in the event of a side puzzles.
connection change. Examples of this include a NAT rebinding that
occurs without a client's knowledge. * Transport dependency: None.
* Application dependency: None.
o Connection mobility (CM): Sessions should not be bound to a
network connection (or 5-tuple). This allows cryptographic key
material and other state information to be reused in the event of
a connection change. Examples of this include a NAT rebinding
that occurs without a client's knowledge.
* Transport dependency: Connections are unreliable or can change * Transport dependency: Connections are unreliable or can change
due to unpredictable network events, e.g., NAT re-bindings. due to unpredictable network events, e.g., NAT re-bindings.
* Application dependency: None. * Application dependency: None.
o Source validation: Source validation must be provided to mitigate o Source validation (SV): Source validation must be provided to
server-targeted DoS attacks. This can be done with puzzles or mitigate server-targeted DoS attacks. This can be done with
cookies. puzzles or cookies.
* Transport dependency: Packets may arrive as datagrams instead * Transport dependency: Packets may arrive as datagrams instead
of streams from unauthenticated sources. of streams from unauthenticated sources.
* Application dependency: None. * Application dependency: None.
o Application-layer feature negotiation: The type of application o Application-layer feature negotiation (AFN): The type of
using a transport security protocol often requires features application using a transport security protocol often requires
configured at the connection establishment layer, e.g., ALPN features configured at the connection establishment layer, e.g.,
[RFC7301]. Moreover, application-layer features may often be used ALPN [RFC7301]. Moreover, application-layer features may often be
to offload the session to another server which can better handle used to offload the session to another server which can better
the request. (The TLS SNI is one example of such a feature.) As handle the request. (The TLS SNI is one example of such a
such, transport security protocols should provide a generic feature.) As such, transport security protocols should provide a
mechanism to allow for such application-specific features and generic mechanism to allow for such application-specific features
options to be configured or otherwise negotiated. and options to be configured or otherwise negotiated.
* Transport dependency: None. * Transport dependency: None.
* Application dependency: Specification of application-layer * Application dependency: Specification of application-layer
features or functionality. features or functionality.
o Configuration extensions: The protocol negotiation should be o Configuration extensions (CX): The protocol negotiation should be
extensible with addition of new configuration options. extensible with addition of new configuration options.
* Transport dependency: None. * Transport dependency: None.
* Application dependency: Specification of application-specific * Application dependency: Specification of application-specific
extensions. extensions.
o Session caching and management: Sessions should be cacheable to o Session caching and management (SC): Sessions should be cacheable
enable reuse and amortize the cost of performing session to enable reuse and amortize the cost of performing session
establishment handshakes. establishment handshakes.
* Transport dependency: None. * Transport dependency: None.
* Application dependency: None. * Application dependency: None.
5. Transport Security Protocol Interfaces o Length-hiding padding (LHP): Applications may wish to defer
traffic padding to the security protocol to deter traffic analysis
attacks.
* Transport dependency: None.
* Application dependency: Knowledge of desired padding policies.
5.3. Optional Feature Availability
The following table lists the availability of the above-listed
optional features in each of the analyzed protocols. "Mandatory"
indicates that the feature is intrinsic to the protocol and cannot be
disabled. "Supported" indicates that the feature is optionally
provided natively or through a (standardized, where applicable)
extension.
+-----------+----+----+----+-----+----+----+-----+----+----+-----+
| Protocol | AN | AD | MA | DM | CM | SV | AFN | CX | SC | LHP |
+-----------+----+----+----+-----+----+----+-----+----+----+-----+
| TLS | S | S | S | S | U* | M | S | S | S | S |
| | | | | | | | | | | |
| DTLS | S | S | S | S | S | M | S | S | S | S |
| | | | | | | | | | | |
| IETF QUIC | S | S | S | S | S | M | S | S | S | S |
| | | | | | | | | | | |
| IKEv2+ESP | S | S | M | S | S | M | S | S | S | S |
| | | | | | | | | | | |
| SRTP+DTLS | S | S | S | S | U | M | S | S | S | U |
| | | | | | | | | | | |
| tcpcrypt | S | M | U | U** | U* | M | U | U | S | U |
| | | | | | | | | | | |
| WireGuard | U | S | M | S | U | M | U | U | U | S+ |
| | | | | | | | | | | |
| MinimalT | U | U | M | S | M | M | U | U | U | S |
| | | | | | | | | | | |
| CurveCP | U | U | S | S | M | M | U | U | U | S |
+-----------+----+----+----+-----+----+----+-----+----+----+-----+
M=Mandatory
S=Supported but not required
U=Unsupported
*=On TCP; MPTCP would provide this ability
**=TCP provides SYN cookies natively, but these are not
cryptographically strong
+=For transport packets only
6. Transport Security Protocol Interfaces
This section describes the interface surface exposed by the security This section describes the interface surface exposed by the security
protocols described above. Note that not all protocols support each protocols described above. Note that not all protocols support each
interface. We partition these interfaces into pre-connection interface. We partition these interfaces into pre-connection
(configuration), connection, and post-connection interfaces. (configuration), connection, and post-connection interfaces.
5.1. Pre-Connection Interfaces 6.1. Pre-Connection Interfaces
Configuration interfaces are used to configure the security protocols Configuration interfaces are used to configure the security protocols
before a handshake begins or the keys are negotiated. before a handshake begins or the keys are negotiated.
o Identity and Private Keys o Identity and Private Keys
The application can provide its identities (certificates) and The application can provide its identities (certificates) and
private keys, or mechanisms to access these, to the security private keys, or mechanisms to access these, to the security
protocol to use during handshakes. protocol to use during handshakes.
Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2,
WireGuard, SRTP WireGuard, SRTP
skipping to change at page 24, line 4 skipping to change at page 26, line 47
supply pre-shared keys for the record protocol use for encryption/ supply pre-shared keys for the record protocol use for encryption/
decryption and authentication. If the application can supply keys decryption and authentication. If the application can supply keys
directly, this is considered explicit import; if the handshake directly, this is considered explicit import; if the handshake
protocol traditionally provides the keys directly, it is protocol traditionally provides the keys directly, it is
considered direct import; if the keys can only be shared by the considered direct import; if the keys can only be shared by the
handshake, they are considered non-importable. handshake, they are considered non-importable.
* Explict import: QUIC, ESP * Explict import: QUIC, ESP
* Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard * Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard
* Non-importable: CurveCP * Non-importable: CurveCP
5.2. Connection Interfaces 6.2. Connection Interfaces
o Identity Validation o Identity Validation
During a handshake, the security protocol will conduct identity During a handshake, the security protocol will conduct identity
validation of the peer. This can call into the application to validation of the peer. This can call into the application to
offload validation. Protocols: All (TLS, DTLS, QUIC + TLS, offload validation. Protocols: All (TLS, DTLS, QUIC + TLS,
MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS))
o Source Address Validation o Source Address Validation
The handshake protocol may delegate validation of the remote peer The handshake protocol may delegate validation of the remote peer
that has sent data to the transport protocol or application. This that has sent data to the transport protocol or application. This
involves sending a cookie exchange to avoid DoS attacks. involves sending a cookie exchange to avoid DoS attacks.
Protocols: QUIC + TLS, DTLS, WireGuard Protocols: QUIC + TLS, DTLS, WireGuard
5.3. Post-Connection Interfaces 6.3. Post-Connection Interfaces
o Connection Termination The security protocol may be instructed to o Connection Termination The security protocol may be instructed to
tear down its connection and session information. This is needed tear down its connection and session information. This is needed
by some protocols to prevent application data truncation attacks. by some protocols to prevent application data truncation attacks.
Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2
o Key Update o Key Update
The handshake protocol may be instructed to update its keying The handshake protocol may be instructed to update its keying
material, either by the application directly or by the record material, either by the application directly or by the record
protocol sending a key expiration event. protocol sending a key expiration event.
Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2
o Pre-Shared Key Export The handshake protocol will generate one or o Pre-Shared Key Export The handshake protocol will generate one or
more keys to be used for record encryption/decryption and more keys to be used for record encryption/decryption and
authentication. These may be explicitly exportable to the authentication. These may be explicitly exportable to the
application, traditionally limited to direct export to the record application, traditionally limited to direct export to the record
protocol, or inherently non-exportable because the keys must be protocol, or inherently non-exportable because the keys must be
used directly in conjunction with the record protocol. used directly in conjunction with the record protocol.
* Explict export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for * Explicit export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for
SRTP) SRTP)
* Direct export: TLS, DTLS, MinimalT * Direct export: TLS, DTLS, MinimalT
* Non-exportable: CurveCP * Non-exportable: CurveCP
o Key Expiration o Key Expiration
The record protocol can signal that its keys are expiring due to The record protocol can signal that its keys are expiring due to
reaching a time-based deadline, or a use-based deadline (number of reaching a time-based deadline, or a use-based deadline (number of
bytes that have been encrypted with the key). This interaction is bytes that have been encrypted with the key). This interaction is
skipping to change at page 25, line 6 skipping to change at page 28, line 4
* Direct export: TLS, DTLS, MinimalT * Direct export: TLS, DTLS, MinimalT
* Non-exportable: CurveCP * Non-exportable: CurveCP
o Key Expiration o Key Expiration
The record protocol can signal that its keys are expiring due to The record protocol can signal that its keys are expiring due to
reaching a time-based deadline, or a use-based deadline (number of reaching a time-based deadline, or a use-based deadline (number of
bytes that have been encrypted with the key). This interaction is bytes that have been encrypted with the key). This interaction is
often limited to signaling between the record layer and the often limited to signaling between the record layer and the
handshake layer. handshake layer.
Protocols: ESP ((Editor's note: One may consider TLS/DTLS to also Protocols: ESP ((Editor's note: One may consider TLS/DTLS to also
have this interface)) have this interface))
o Transport mobility o Connection mobility
The record protocol can be signaled that it is being migrated to The record protocol can be signaled that it is being migrated to
another transport or interface due to connection mobility, which another transport or interface due to connection mobility, which
may reset address and state validation. may reset address and state validation.
Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming) Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming)
6. IANA Considerations 7. IANA Considerations
This document has no request to IANA. This document has no request to IANA.
7. 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. of reference protocols. Moreover, no claims of security and privacy
properties beyond those guaranteed by the protocols discussed are
made. For example, metadata leakage via timing side channels and
traffic analysis may compromise any protocol discussed in this
survey. Applications using Security Interfaces SHOULD take such
limitations into consideration when using a particular protocol
implementation.
8. Acknowledgments 9. Acknowledgments
The authors would like to thank Mirja Kuehlewind, Brian Trammell, The authors would like to thank Mirja Kuehlewind, Brian Trammell,
Yannick Sierra, Frederic Jacobs, and Bob Bradley for their input and Yannick Sierra, Frederic Jacobs, and Bob Bradley for their input and
feedback on earlier versions of this draft. feedback on earlier versions of this draft.
9. Normative References 10. Normative References
[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 Transport Layer Security Thomson, M. and S. Turner, "Using Transport Layer Security
(TLS) to Secure QUIC", draft-ietf-quic-tls-11 (work in (TLS) to Secure QUIC", draft-ietf-quic-tls-13 (work in
progress), April 2018. progress), June 2018.
[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-11 (work and Secure Transport", draft-ietf-quic-transport-13 (work
in progress), April 2018. in progress), June 2018.
[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-14 (work in progress), March 2018. rtcweb-security-arch-14 (work in progress), March 2018.
[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", draft-ietf-taps-arch-00 (work in
progress), April 2018.
[I-D.ietf-tcpinc-tcpcrypt] [I-D.ietf-tcpinc-tcpcrypt]
Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 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)", draft-ietf-tcpinc-tcpcrypt-11 (work in (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-12 (work in
progress), November 2017. progress), June 2018.
[I-D.ietf-tcpinc-tcpeno] [I-D.ietf-tcpinc-tcpeno]
Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.
Smith, "TCP-ENO: Encryption Negotiation Option", draft- Smith, "TCP-ENO: Encryption Negotiation Option", draft-
ietf-tcpinc-tcpeno-18 (work in progress), November 2017. 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., Fossati, T., and T. Gondrom, Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom,
"The Datagram Transport Layer Security (DTLS) Connection "The Datagram Transport Layer Security (DTLS) Connection
Identifier", draft-ietf-tls-dtls-connection-id-00 (work in Identifier", draft-ietf-tls-dtls-connection-id-00 (work in
progress), December 2017. progress), December 2017.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
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
skipping to change at page 27, line 27 skipping to change at page 30, line 36
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", Norrman, "The Secure Real-time Transport Protocol (SRTP)",
RFC 3711, DOI 10.17487/RFC3711, March 2004, RFC 3711, DOI 10.17487/RFC3711, March 2004,
<https://www.rfc-editor.org/info/rfc3711>. <https://www.rfc-editor.org/info/rfc3711>.
[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", Stenberg, "UDP Encapsulation of IPsec ESP Packets",
RFC 3948, DOI 10.17487/RFC3948, January 2005, RFC 3948, DOI 10.17487/RFC3948, January 2005,
<https://www.rfc-editor.org/info/rfc3948>. <https://www.rfc-editor.org/info/rfc3948>.
[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253,
January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006,
<https://www.rfc-editor.org/info/rfc4474>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
<https://www.rfc-editor.org/info/rfc4555>. <https://www.rfc-editor.org/info/rfc4555>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
skipping to change at page 28, line 31 skipping to change at page 31, line 45
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, DOI 10.17487/RFC5925, Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
June 2010, <https://www.rfc-editor.org/info/rfc5925>. June 2010, <https://www.rfc-editor.org/info/rfc5925>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP:
Media Path Key Agreement for Unicast Secure RTP",
RFC 6189, DOI 10.17487/RFC6189, April 2011,
<https://www.rfc-editor.org/info/rfc6189>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <https://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J.,
Weiler, S., and T. Kivinen, "Using Raw Public Keys in Weiler, S., and T. Kivinen, "Using Raw Public Keys in
Transport Layer Security (TLS) and Datagram Transport Transport Layer Security (TLS) and Datagram Transport
Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250,
June 2014, <https://www.rfc-editor.org/info/rfc7250>. June 2014, <https://www.rfc-editor.org/info/rfc7250>.
 End of changes. 146 change blocks. 
324 lines changed or deleted 524 lines changed or added

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