draft-ietf-taps-transport-security-02.txt   draft-ietf-taps-transport-security-03.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: January 1, 2019 University of Glasgow Expires: April 25, 2019 University of Glasgow
K. Rose K. Rose
Akamai Technologies, Inc. Akamai Technologies, Inc.
C. Wood C. Wood
Apple Inc. Apple Inc.
June 30, 2018 October 22, 2018
A Survey of Transport Security Protocols A Survey of Transport Security Protocols
draft-ietf-taps-transport-security-02 draft-ietf-taps-transport-security-03
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 +
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 January 1, 2019. This Internet-Draft will expire on April 25, 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
skipping to change at page 2, line 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security Features . . . . . . . . . . . . . . . . . . . . . . 5 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 5
4. Transport Security Protocol Descriptions . . . . . . . . . . 7 4. Transport Security Protocol Descriptions . . . . . . . . . . 7
4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. Protocol Description . . . . . . . . . . . . . . . . 7 4.1.1. Protocol Description . . . . . . . . . . . . . . . . 7
4.1.2. Protocol Features . . . . . . . . . . . . . . . . . . 8 4.1.2. Security Features . . . . . . . . . . . . . . . . . . 8
4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9 4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9
4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Protocol Description . . . . . . . . . . . . . . . . 9 4.2.1. Protocol Description . . . . . . . . . . . . . . . . 9
4.2.2. Protocol Features . . . . . . . . . . . . . . . . . . 10 4.2.2. Security Features . . . . . . . . . . . . . . . . . . 10
4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10
4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 10 4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 11
4.3.1. Protocol Description . . . . . . . . . . . . . . . . 10 4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11
4.3.2. Protocol Features . . . . . . . . . . . . . . . . . . 11 4.3.2. Security Features . . . . . . . . . . . . . . . . . . 11
4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 11 4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12
4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 11 4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 12
4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12 4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12
4.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 12 4.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 12
4.4.2. Protocol features . . . . . . . . . . . . . . . . . . 13 4.4.2. Security Features . . . . . . . . . . . . . . . . . . 14
4.4.3. Protocol dependencies . . . . . . . . . . . . . . . . 14 4.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 14
4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 14 4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15
4.5.1. Protocol description . . . . . . . . . . . . . . . . 14 4.5.1. Protocol description . . . . . . . . . . . . . . . . 15
4.5.2. Protocol features . . . . . . . . . . . . . . . . . . 15 4.5.2. Security Features . . . . . . . . . . . . . . . . . . 16
4.5.3. Protocol dependencies . . . . . . . . . . . . . . . . 16 4.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16
4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 16 4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 16
4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 16 4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 17
4.6.1. Protocol Description . . . . . . . . . . . . . . . . 16 4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17
4.6.2. Protocol Features . . . . . . . . . . . . . . . . . . 17 4.6.2. Security Features . . . . . . . . . . . . . . . . . . 18
4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18 4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18
4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18 4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18
4.7.1. Protocol description . . . . . . . . . . . . . . . . 18 4.7.1. Protocol description . . . . . . . . . . . . . . . . 18
4.7.2. Protocol features . . . . . . . . . . . . . . . . . . 19 4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19
4.7.3. Protocol dependencies . . . . . . . . . . . . . . . . 19 4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19
4.8. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 19 4.8. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 20
4.8.1. Protocol Description . . . . . . . . . . . . . . . . 19 4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20
4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 20 4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 20
4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20 4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21
4.9. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.9. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.9.1. Protocol Description . . . . . . . . . . . . . . . . 20 4.9.1. Protocol Description . . . . . . . . . . . . . . . . 21
4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22 4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22
4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 22 4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 22
5. Security Features and Transport Dependencies . . . . . . . . 22 5. Security Features and Transport Dependencies . . . . . . . . 23
5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 22 5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 23
5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 23 5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 23
5.3. Optional Feature Availability . . . . . . . . . . . . . . 25 5.3. Optional Feature Availability . . . . . . . . . . . . . . 25
6. Transport Security Protocol Interfaces . . . . . . . . . . . 25 6. Transport Security Protocol Interfaces . . . . . . . . . . . 26
6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 26 6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 26
6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 27 6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 27
6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 27 6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
10. Normative References . . . . . . . . . . . . . . . . . . . . 28 10. Normative References . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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 +
skipping to change at page 5, line 13 skipping to change at page 5, line 13
Mandatory or Optional for an application's implementation. Mandatory or Optional for an 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: Framed protocol messages.
o Record Protocol: a security protocol that allows data to be o Record Protocol: a security protocol that allows data to be
divided into manageable blocks and protected using shared divided into manageable blocks and protected using shared
cryptographic context. cryptographic context.
o Session: an ephemeral security association between applications. o Session: an ephemeral security association between applications.
o Cryptographic context: a set of cryptographic parameters, 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
persists across messages that are transmitted between these persists across messages that are transmitted between these
endpoints. A connection is a transient participant of a session, endpoints. A connection is a transient participant of a session,
and a session generally lasts between connection instances. and a session generally lasts between connection instances.
o Connection Mobility: a property of a connection that allows it to o Connection Mobility: a property of a connection that allows it to
be multihomed or resilient across network interface or address be multihomed or resilient across network interface or address
changes. changes, e.g., NAT rebindings that occur without an endpoint's
knowledge. Mobility allows cryptographic key material and other
state information to be reused in the event of a connection
change.
o Peer: an endpoint application party to a session. o Peer: an endpoint application party to a session.
o Client: the peer responsible for initiating a session. o Client: the peer responsible for initiating a session.
o Server: the peer responsible for responding to a session o Server: the peer responsible for responding to a session
initiation. initiation.
3. Security Features 3. Security Features
In this section, we enumerate Security Features exposed by protocols In this section, we enumerate Security Features exposed by protocols
discussed in the remainder of this document. Protocol security discussed in the remainder of this document. Security Features
extend the set of Transport Features described in [RFC8095] and
provided by Transport Services implementations. Protocol security
properties that are unrelated to the API surface exposed by such properties that are unrelated to the API surface exposed by such
protocols, such as client or server identity hiding, are not listed protocols, such as client or server identity hiding, are not listed
here as features. here as features.
o Forward-secure key establishment: Cryptographic key establishment o Forward-secure key establishment: Cryptographic key establishment
with forward secure properties. with forward secure properties.
o Cryptographic algorithm negotiation: Negotiate support of protocol o Cryptographic algorithm negotiation: Negotiate support of protocol
algorithms, including: encryption, hash, MAC (PRF), and digital algorithms, including: encryption, hash, MAC (PRF), and digital
signature algorithms. signature algorithms.
o Stateful and stateless cross-connection session resumption: o Stateful and stateless cross-connection session resumption:
Connection establishment without needing to complete an entirely Connection establishment without needing to complete an entirely
new handshake. new handshake.
o Session caching and management: Manage session state cache used
for subsequent connections aimed towards amortizing connection
establishment costs.
o Peer authentication (certificate, raw public key, pre-shared key, o Peer authentication (certificate, raw public key, pre-shared key,
or EAP-based): Peer authentication using select or protocol- or EAP-based): Peer authentication using select or protocol-
specific mechanisms. specific mechanisms.
o Mutual authentication: Connection establishment wherein both o Mutual authentication: Connection establishment wherein both
endpoints are authenticated. endpoints are authenticated.
o Application-layer authentication delegation: Out-of-band peer
authentication performed by applications outside of the connection
establishment.
o Record (channel or datagram) confidentiality and integrity: o Record (channel or datagram) confidentiality and integrity:
Encryption and authentication of application plaintext bytes sent Encryption and authentication of application plaintext bytes sent
between peers over a channel or in individual datagrams. between peers over a channel or in individual datagrams.
o Partial record confidentiality: Encryption of some portion of o Partial record confidentiality: Encryption of some portion of
records. records.
o Optional record integrity: Optional authentication of certain o Optional record integrity: Optional authentication of certain
records. records.
o Record replay prevention: Protocol detection and defense against o Record replay prevention: Protocol detection and defense against
record replays, e.g., due to in-network retransmissions. 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 o Early data support (starting with TLS 1.3): Transmission of
application data prior to connection (handshake) establishment. application data prior to connection (handshake) establishment.
o Connection mobility: Connection continuation in the presence of o Connection mobility: Connection continuation in the presence of
5-tuple changes beneath the secure transport protocol, e.g., due 5-tuple changes beneath the secure transport protocol, e.g., due
to NAT rebindings. to NAT rebindings.
o Application-layer authentication delegation: Out-of-band peer o Application-layer feature negotiation: Securely negotiate
authentication performed by applications outside of the connection application-specific functionality, including those necessary for
establishment. connection handling and management, e.g., the TLS parent
connection protocol type via ALPN [RFC7301] or desired application
identity via SNI [RFC6066].
o Configuration extensions: Add protocol features via extensions or
configuration options. TLS extensions are a primary example of
this feature.
o Out-of-order record receipt: Processing of records received out- o Out-of-order record receipt: Processing of records received out-
of-order. of-order.
o DoS mitigation (cookie or puzzle based): Peer DoS mitigation via o Source validation (cookie or puzzle based): Peer source validation
explicit proof of origin (cookie) or work mechanisms (puzzles). and DoS mitigation via explicit proof of origin (cookie) or work
mechanisms (puzzles).
o Connection re-keying: In-band cryptographic handshake re-keying. o Connection re-keying: In-band cryptographic handshake re-keying.
o Optional length-hiding and anti-amplification padding: Protocol- o Length-hiding padding: Protocol-drive record padding aimed at
drive record padding aimed at hiding plaintext message length and hiding plaintext message length and mitigating amplification
mitigating amplification attack vectors. attack vectors.
4. Transport Security Protocol Descriptions 4. Transport Security Protocol Descriptions
This section contains descriptions of security protocols currently This section contains descriptions of security protocols currently
used to protect data being sent over a network. used to protect data being sent over a network.
For each protocol, we describe its provided features and dependencies For each protocol, we describe its provided features and dependencies
on other protocols. on other protocols.
4.1. TLS 4.1. TLS
skipping to change at page 7, line 49 skipping to change at page 8, line 18
nonce generation and encoding for each record. The record protocol nonce generation and encoding for each record. The record protocol
is hidden from the client behind a bytestream-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.
cryptography, an infrastructure for trust establishment, correctly-
functioning endpoints, and communication patterns free from side
channels, server authentication is sufficient to establish a channel
resistant to eavesdroppers.
The handshake protocol is also extensible. It allows for a variety The handshake protocol is also extensible. It allows for a variety
of extensions to be included by either the client or server. These of extensions to be included by either the client or server. These
extensions are used to specify client preferences, e.g., the extensions are used to specify client preferences, e.g., the
application-layer protocol to be driven with the TLS connection application-layer protocol to be driven with the TLS connection
[RFC7301], or signals to the server to aid operation, e.g., Server [RFC7301], or signals to the server to aid operation, e.g., Server
Name Indication (SNI) [RFC6066]. Various extensions also exist to Name Indication (SNI) [RFC6066]. Various extensions also exist to
tune the parameters of the record protocol, e.g., the maximum tune the parameters of the record protocol, e.g., the maximum
fragment length [RFC6066]. fragment length [RFC6066] and record size limit
[I-D.ietf-tls-record-limit].
Alerts are used to convey errors and other atypical events to the Alerts are used to convey errors and other atypical events to the
endpoints. There are two classes of alerts: closure and error endpoints. There are two classes of alerts: closure and error
alerts. A closure alert is used to signal to the other peer that the alerts. A closure alert is used to signal to the other peer that the
sender wishes to terminate the connection. The sender typically sender wishes to terminate the connection. The sender typically
follows a close alert with a TCP FIN segment to close the connection. follows a close alert with a TCP FIN segment to close the connection.
Error alerts are used to indicate problems with the handshake or Error alerts are used to indicate problems with the handshake or
individual records. Most errors are fatal and are followed by individual records. Most errors are fatal and are followed by
connection termination. However, warning alerts may be handled at connection termination. However, warning alerts may be handled at
the discretion of the implementation. the discretion of the implementation.
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.)
4.1.2. Protocol Features 4.1.2. Security Features
o Forward-secure key establishment. o Forward-secure key establishment.
o Cryptographic algorithm negotiation. o Cryptographic algorithm negotiation.
o Stateful and stateless cross-connection session resumption. o Stateful and stateless cross-connection session resumption.
o Session caching and management.
o Peer authentication (Certificate, raw public key, and pre-shared o Peer authentication (Certificate, raw public key, and pre-shared
key). key).
o Mandatory server authentication, optional client authentication. o Mandatory server authentication, optional client authentication.
o Application authentication delegation.
o Record (channel) confidentiality and integrity. o Record (channel) confidentiality and integrity.
o Record replay prevention. o Record replay prevention.
o Application-layer feature negotiation. o Application-layer feature negotiation.
o Configuration extensions.
o Early data support (starting with TLS 1.3). o Early data support (starting with TLS 1.3).
o Optional length-hiding padding (starting with TLS 1.3). o Optional record-layer padding (starting with TLS 1.3).
4.1.3. Protocol Dependencies 4.1.3. Protocol Dependencies
o TCP for in-order, reliable transport. o TCP for in-order, reliable transport.
o (Optionally) A PKI trust store for certificate validation. o (Optionally) A PKI trust store for certificate validation.
4.2. DTLS 4.2. DTLS
DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS,
skipping to change at page 10, line 4 skipping to change at page 10, line 21
handshake messages across records. The receiver must reassemble handshake messages across records. The receiver must reassemble
records before processing. records before processing.
DTLS relies on unique UDP 4-tuples to identify connections. Since DTLS relies on unique UDP 4-tuples to identify connections. Since
all application-layer data is encrypted, demultiplexing over the same all application-layer data is encrypted, demultiplexing over the same
4-tuple requires the use of a connection identifier extension 4-tuple requires the use of a connection identifier extension
[I-D.ietf-tls-dtls-connection-id] to permit identification of the [I-D.ietf-tls-dtls-connection-id] to permit identification of the
correct connection-specific cryptographic context without the use of correct connection-specific cryptographic context without the use of
trial decryption. (Note that this extension is only supported in trial decryption. (Note that this extension is only supported in
DTLS 1.2 and 1.3 {{I-D.ietf-tls-dtls13}.) DTLS 1.2 and 1.3 {{I-D.ietf-tls-dtls13}.)
Since datagrams can be replayed, DTLS provides optional anti-replay Since datagrams can be replayed, DTLS provides optional anti-replay
detection based on a window of acceptable sequence numbers [RFC6347]. detection based on a window of acceptable sequence numbers [RFC6347].
4.2.2. Protocol Features 4.2.2. Security Features
o Record replay protection. o Record replay protection.
o Record (datagram) confidentiality and integrity. o Record (datagram) confidentiality and integrity.
o Out-of-order record receipt. o Out-of-order record receipt.
o DoS mitigation (cookie-based). o DoS mitigation (cookie-based).
See also the features from TLS. See also the features from TLS.
4.2.3. Protocol Dependencies 4.2.3. Protocol Dependencies
o Since DTLS runs over an unreliable, unordered datagram transport,
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. (Note: DTLS reconstruction of datagrams fragmented over packets. (Note: DTLS
1.3 short header records omit the explicit length field.) 1.3 short header records omit the explicit length field.)
o UDP 4-tuple uniqueness, or the connection identifier extension, o UDP 4-tuple uniqueness, or the connection identifier extension,
for demultiplexing. for demultiplexing.
o Path MTU discovery. o Path MTU discovery.
skipping to change at page 11, line 15 skipping to change at page 11, line 32
o Starting the handshake to generate keys and provide authentication o Starting the handshake to generate keys and provide authentication
(and providing the transport for the handshake). (and providing the transport for the handshake).
o Client address validation. o Client address validation.
o Key ready events from TLS to notify the QUIC transport. o Key ready events from TLS to notify the QUIC transport.
o Exporting secrets from TLS to the QUIC transport. o Exporting secrets from TLS to the QUIC transport.
The QUIC transport layer support multiple streams over a single The QUIC transport layer support multiple streams over a single
connection. The first stream is reserved specifically for a TLS connection. QUIC implements a record protocol for TLS handshake
connection. The TLS handshake, along with further records, are sent messages to establish a connection. These messages are sent in
over this stream. This TLS connection follows the TLS standards and special INITIAL and CRYPTO frames [I-D.ietf-quic-transport], types of
inherits the security properties of TLS. The handshake generates which are encrypted using different keys. INITIAL frames are
keys, which are then exported to the rest of the QUIC connection, and encrypted using "fixed" keys derived from the QUIC version and public
are used to protect the rest of the streams. packet information (Connection ID). CRYPTO frames are encrypted
using TLS handshake secrets. Once TLS completes, QUIC uses the
Initial QUIC messages (packets) are encrypted using "fixed" keys resultant traffic secrets to for the QUIC connection to protect the
derived from the QUIC version and public packet information rest of the streams. QUIC supports 0-RTT (early) data using
(Connection ID). Packets are later encrypted using keys derived from previously negotiated connection secrets. Early data is sent in
the TLS traffic secret upon handshake completion. The TLS 1.3 0-RTT packets, which may be included in the same datagram as the
handshake for QUIC is used in either a single-RTT mode or a fast-open Initial and Handshake packets.
zero-RTT mode. When zero-RTT handshakes are possible, the encryption
first transitions to use the zero-RTT keys before using single-RTT
handshake keys after the next TLS flight.
4.3.2. Protocol Features 4.3.2. Security Features
o DoS mitigation (cookie-based). o DoS mitigation (cookie-based).
See also the properties of TLS. See also the properties of TLS.
4.3.3. Protocol Dependencies 4.3.3. Protocol Dependencies
o QUIC transport relies on UDP. o QUIC transport relies on UDP.
o QUIC transport relies on TLS 1.3 for peer authentication and o QUIC transport relies on TLS 1.3 for key exchange, peer
initial key derivation. authentication, and shared secret derivation.
o TLS within QUIC relies on QUIC for reliable handshake record
transmission and receipt.
4.3.4. Variant: 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.
4.4. IKEv2 with ESP 4.4. IKEv2 with ESP
IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec
protocol suite that encrypts and authenticates IP packets, either as protocol suite that encrypts and authenticates IP packets, either for
for creating tunnels (tunnel-mode) or for direct transport creating tunnels (tunnel-mode) or for direct transport connections
connections (transport-mode). This suite of protocols separates out (transport-mode). This suite of protocols separates out the key
the key generation protocol (IKEv2) from the transport encryption generation protocol (IKEv2) from the transport encryption protocol
protocol (ESP). Each protocol can be used independently, but this (ESP). Each protocol can be used independently, but this document
document considers them together, since that is the most common considers them together, since that is the most common pattern.
pattern.
4.4.1. Protocol descriptions 4.4.1. Protocol descriptions
4.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). An SA goal is to generate keys for Security Associations (SAs). An SA
contains shared (cryptographic) information used for establishing contains shared (cryptographic) information used for establishing
other SAs or keying ESP; See Section 4.4.1.2. IKEv2 first uses a other SAs or keying ESP; See Section 4.4.1.2. IKEv2 first uses a
Diffie-Hellman key exchange to generate keys for the "IKE SA", which Diffie-Hellman key exchange to generate keys for the "IKE SA", which
skipping to change at page 13, line 39 skipping to change at page 14, line 5
Since ESP operates on IP packets, it is not directly tied to the Since ESP operates on IP packets, it is not directly tied to the
transport protocols it encrypts. This means it requires little or no transport protocols it encrypts. This means it requires little or no
change from transports in order to provide security. change from transports in order to provide security.
ESP packets may be sent directly over IP, but where network ESP packets may be sent directly over IP, but where network
conditions warrant (e.g., when a NAT is present or when a firewall conditions warrant (e.g., when a NAT is present or when a firewall
blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP
[RFC8229]. [RFC8229].
4.4.2. Protocol features 4.4.2. Security Features
4.4.2.1. IKEv2 4.4.2.1. IKEv2
o Forward-secure key establishment. o Forward-secure key establishment.
o Cryptographic algorithm negotiation. o Cryptographic algorithm negotiation.
o Peer authentication (Certificate, raw public key, pre-shared key, o Peer authentication (Certificate, raw public key, pre-shared key,
and EAP). and EAP).
skipping to change at page 14, line 17 skipping to change at page 14, line 32
o Connection mobility. o Connection mobility.
o DoS mitigation (cookie-based). o DoS mitigation (cookie-based).
4.4.2.2. ESP 4.4.2.2. ESP
o Record confidentiality and integrity. o Record confidentiality and integrity.
o Record replay protection. o Record replay protection.
4.4.3. Protocol dependencies 4.4.3. Protocol Dependencies
4.4.3.1. IKEv2 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.
skipping to change at page 15, line 42 skipping to change at page 16, line 12
fingerprints are included in the signalling exchange (e.g., in SIP or fingerprints are included in the signalling exchange (e.g., in SIP or
WebRTC), and used to bind the DTLS key exchange in the media plane to WebRTC), and used to bind the DTLS key exchange in the media plane to
the signaling plane. The combination of a mutually authenticated the signaling plane. The combination of a mutually authenticated
DTLS key exchange on the media path and a fingerprint sent in the DTLS key exchange on the media path and a fingerprint sent in the
signalling channel protects against active attacks on the media, signalling channel protects against active attacks on the media,
provided the signalling can be trusted. Signalling needs to be provided the signalling can be trusted. Signalling needs to be
protected as described in, for example, SIP [RFC3261] Authenticated protected as described in, for example, SIP [RFC3261] Authenticated
Identity Management [RFC4474] or the WebRTC security architecture Identity Management [RFC4474] or the WebRTC security architecture
[I-D.ietf-rtcweb-security-arch], to provide complete system security. [I-D.ietf-rtcweb-security-arch], to provide complete system security.
4.5.2. Protocol features 4.5.2. Security Features
o Forward-secure key establishment. o Forward-secure key establishment.
o Cryptographic algorithm negotiation. o Cryptographic algorithm negotiation.
o Mutual authentication. o Mutual authentication.
o Partial datagram confidentiality. (Packet headers are not o Partial datagram confidentiality. (Packet headers are not
encrypted.) encrypted.)
o Optional authentication of data packets. o Optional authentication of data packets.
o Mandatory authentication of control packets. o Mandatory authentication of control packets.
o Out-of-order record receipt. o Out-of-order record receipt.
4.5.3. Protocol dependencies 4.5.3. Protocol Dependencies
o External key derivation and management protocol, e.g., DTLS o External key derivation and management protocol, e.g., DTLS
[RFC5763]. [RFC5763].
o External identity management protocol, e.g., SIP Authenticated o External identity management protocol, e.g., SIP Authenticated
Identity Management [RFC4474], WebRTC Security Architecture Identity Management [RFC4474], WebRTC Security Architecture
[I-D.ietf-rtcweb-security-arch]. [I-D.ietf-rtcweb-security-arch].
4.5.4. Variant: ZRTP for Media Path Key Agreement 4.5.4. Variant: ZRTP for Media Path Key Agreement
skipping to change at page 17, line 40 skipping to change at page 18, line 13
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.
4.6.2. Protocol Features 4.6.2. Security Features
o Forward-secure key establishment. o Forward-secure key establishment.
o Record (channel) confidentiality and integrity. o Record (channel) confidentiality and integrity.
o Stateful cross-connection session resumption. o Stateful cross-connection session resumption.
o Session caching and management.
o Connection re-keying. o Connection re-keying.
o Application authentication delegation. o Application authentication delegation.
4.6.3. Protocol Dependencies 4.6.3. Protocol Dependencies
o TCP o TCP.
o TCP Encryption Negotiation Option (ENO) o TCP Encryption Negotiation Option (ENO).
4.7. WireGuard 4.7. WireGuard
WireGuard is a layer 3 protocol designed 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] for certain use cases. It uses UDP to encapsulate
rely on PKI for peer authentication, WireGuard authenticates peers IP datagrams between peers. Unlike most transport security
using pre-shared public keys delivered out-of-band, each of which is protocols, which rely on PKI for peer authentication, WireGuard
bound to one or more IP addresses. Moreover, as a protocol suited authenticates peers using pre-shared public keys delivered out-of-
for VPNs, WireGuard offers no extensibility, negotiation, or band, each of which is bound to one or more IP addresses. Moreover,
cryptographic agility. as a protocol suited for VPNs, WireGuard offers no extensibility,
negotiation, or cryptographic agility.
4.7.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
skipping to change at page 19, line 8 skipping to change at page 19, line 31
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.
4.7.2. Protocol features 4.7.2. Security Features
o Forward-secure key establishment. o Forward-secure key establishment.
o Peer authentication (Public-key and PSK). o Peer authentication (Public-key and PSK).
o Mutual authentication. o Mutual authentication.
o Record replay prevention (Stateful, timestamp-based). o Record replay prevention (Stateful, timestamp-based).
o DoS mitigation (cookie-based). o DoS mitigation (cookie-based).
4.7.3. Protocol dependencies 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.
4.8. 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
skipping to change at page 20, line 24 skipping to change at page 20, line 51
(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.
4.8.2. Protocol Features 4.8.2. Protocol Features
o Forward-secure key establishment. o Forward-secure key establishment.
o DoS mitigation (puzzle-based). o DoS mitigation (puzzle-based).
o Connection mobility (tunnel-based). o Connection mobility (based on tunnel identifiers).
Additional (orthogonal) transport features include: connection Additional (orthogonal) transport features include: connection
multiplexing between hosts across shared tunnels, and congestion multiplexing between hosts across shared tunnels, and congestion
control state is shared across connections between the same host control state is shared across connections between the same host
pairs. pairs.
4.8.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.
skipping to change at page 21, line 37 skipping to change at page 22, line 15
given the risk of long-term private key compromise. given the risk of long-term private key compromise.
The client and server do not perform a standard key exchange. The client and server do not perform a standard key exchange.
Instead, in the initial exchange of packets, each party provides its Instead, in the initial exchange of packets, each party provides its
own ephemeral key to the other end. The client can choose a new own ephemeral key to the other end. The client can choose a new
ephemeral key for every new connection. However, the server must ephemeral key for every new connection. However, the server must
rotate these keys on a slower basis. Otherwise, it would be trivial rotate these keys on a slower basis. Otherwise, it would be trivial
for an attacker to force the server to create and store ephemeral for an attacker to force the server to create and store ephemeral
keys with a fake client initialization packet. keys with a fake client initialization packet.
Unlike TCP, the server employs cookies to enable source validation. Servers use cookies for source validation. After receiving a
After receiving the client's initial packet, encrypted under the client's initial packet, encrypted under the server's long-term
server's long-term public key, the server generates and returns a public key, a server generates and returns a stateless cookie that
stateless cookie that must be echoed back in the client's following must be echoed back in the client's following message. This cookie
message. This cookie is encrypted under the client's ephemeral is encrypted under the client's ephemeral public key. This stateless
public key. This stateless technique prevents attackers from technique prevents attackers from hijacking client initialization
hijacking client initialization packets to obtain cookie values to packets to obtain cookie values to flood clients. (A client would
flood clients. (A client would detect the duplicate cookies and detect the duplicate cookies and reject the flooded packets.)
reject the flooded packets.) Similarly, replaying the client's Similarly, replaying the client's second packet, carrying the cookie,
second packet, carrying the cookie, will be detected by the server. will be detected by the server.
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.
4.9.2. Protocol Features 4.9.2. Protocol Features
o Datagram confidentiality and integrity (via public key o Datagram confidentiality and integrity (via public key
encryption). encryption).
o 1-RTT session bootstrapping.
o Connection mobility (based on a client-chosen ephemeral o Connection mobility (based on a client-chosen ephemeral
identifier). identifier).
o Optional length-hiding and anti-amplification padding. o Optional length-hiding and anti-amplification padding.
4.9.3. Protocol Dependencies 4.9.3. Protocol Dependencies
o An unreliable transport protocol such as UDP. o An unreliable transport protocol such as UDP.
5. 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. They were selected on the basis that they are either
implementation to implementation, and so an application cannot simply (a) required for any secure transport protocol or (b) nearly
assume they are available. Applications learn of and use optional ubiquitous amongst common secure transport protocols. Optional
features by querying for their presence and support. Optional features by contrast may vary from implementation to implementation,
features may not be implemented, or may be disabled if their presence and so an application cannot simply assume they are available.
impacts transport services or if a necessary transport service is Applications learn of and use optional features by querying for their
unavailable. presence and support. Optional features may not be implemented, or
may be disabled if their presence impacts transport services or if a
necessary transport service is unavailable.
5.1. Mandatory Features 5.1. Mandatory Features
o Segment or datagram encryption and authentication: Transit data o Segment or datagram encryption and authentication: Protect transit
must be protected with an authenticated encryption algorithm. data with an authenticated encryption algorithm.
o Forward-secure key establishment: Negotiated keying material must o Forward-secure key establishment.
come from an authenticated, forward-secure key exchange protocol.
o Public-key (raw or certificate) based authentication: o Public-key (raw or certificate) based authentication.
Authentication based on public key signatures is commonplace for
many transport security protocols.
o Responder authentication: The endpoint (receiver) of a new o Unilateral responder authentication.
connection must be authenticated before any data is sent to said
party.
o Pre-shared key support: A security protocol must be able to use a o Pre-shared key support.
pre-shared key established out-of-band or from a prior session to
encrypt individual messages, packets, or datagrams.
5.2. Optional Features 5.2. Optional Features
o Cryptographic algorithm negotiation (AN): Transport security o Cryptographic algorithm negotiation (AN):
protocols should permit applications to configure supported or
enabled cryptographic algorithms.
* Transport dependency: None. * Transport dependency: None.
* Application dependency: Application awareness of supported or * Application dependency: Application awareness of supported or
desired algorithms. desired algorithms.
o Application authentication delegation (AD): Some protocols may o Application authentication delegation (AD):
completely defer endpoint authentication to applications, e.g., to
reduce online protocol complexity.
* Transport dependency: None. * Transport dependency: None.
* Application dependency: Application opt-in and policy for * Application dependency: Application opt-in and policy for
endpoint authentication endpoint authentication
o Mutual authentication (MA): Transport security protocols should o Mutual authentication (MA):
allow each endpoint to authenticate the other if required by the
application.
* Transport dependency: None. * Transport dependency: None.
* Application dependency: Mutual authentication required for * Application dependency: Mutual authentication required for
application support. application support.
o DoS mitigation (DM): Transport security protocols may need to o DoS mitigation (DM):
support volumetric DoS prevention via, e.g., cookies or initiator-
side puzzles.
* Transport dependency: None. * Transport dependency: None.
* Application dependency: None. * Application dependency: None.
o Connection mobility (CM): Sessions should not be bound to a o Connection mobility (CM):
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 (SV): Source validation must be provided to o Source validation (SV):
mitigate server-targeted DoS attacks. This can be done with
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 (AFN): The type of o Application-layer feature negotiation (AFN):
application using a transport security protocol often requires
features configured at the connection establishment layer, e.g.,
ALPN [RFC7301]. Moreover, application-layer features may often be
used to offload the session to another server which can better
handle the request. (The TLS SNI is one example of such a
feature.) As such, transport security protocols should provide a
generic mechanism to allow for such application-specific features
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 (CX): The protocol negotiation should be o Configuration extensions (CX):
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 (SC): Sessions should be cacheable o Session caching and management (SC):
to enable reuse and amortize the cost of performing session
establishment handshakes.
* Transport dependency: None. * Transport dependency: None.
* Application dependency: None. * Application dependency: None.
o Length-hiding padding (LHP): Applications may wish to defer o Early data support (ED):
traffic padding to the security protocol to deter traffic analysis
attacks. * Transport dependency: None.
* Application dependency: Anti-replay protections or hints of
data idempotency.
o Length-hiding padding (LHP):
* Transport dependency: None. * Transport dependency: None.
* Application dependency: Knowledge of desired padding policies. * Application dependency: Knowledge of desired padding policies.
5.3. Optional Feature Availability 5.3. Optional Feature Availability
The following table lists the availability of the above-listed The following table lists the availability of the above-listed
optional features in each of the analyzed protocols. "Mandatory" optional features in each of the analyzed protocols. "Mandatory"
indicates that the feature is intrinsic to the protocol and cannot be indicates that the feature is intrinsic to the protocol and cannot be
disabled. "Supported" indicates that the feature is optionally disabled. "Supported" indicates that the feature is optionally
provided natively or through a (standardized, where applicable) provided natively or through a (standardized, where applicable)
extension. extension.
+-----------+----+----+----+-----+----+----+-----+----+----+-----+ +----------+---+----+----+-----+----+----+-----+----+----+-----+----+
| Protocol | AN | AD | MA | DM | CM | SV | AFN | CX | SC | LHP | | Protocol | A | AD | MA | DM | CM | SV | AFN | CX | SC | LHP | ED |
+-----------+----+----+----+-----+----+----+-----+----+----+-----+ | | N | | | | | | | | | | |
| TLS | S | S | S | S | U* | M | S | S | S | S | +----------+---+----+----+-----+----+----+-----+----+----+-----+----+
| | | | | | | | | | | | | TLS | S | S | S | S | U* | M | S | S | S | S | S |
| DTLS | S | S | S | S | S | M | S | S | S | S | | | | | | | | | | | | | |
| | | | | | | | | | | | | DTLS | S | S | S | S | S | M | S | S | S | S | U |
| IETF QUIC | S | S | S | S | S | M | S | S | S | S | | | | | | | | | | | | | |
| | | | | | | | | | | | | IETF | S | S | S | S | S | M | S | S | S | S | S |
| IKEv2+ESP | S | S | M | S | S | M | S | S | S | S | | QUIC | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | |
| SRTP+DTLS | S | S | S | S | U | M | S | S | S | U | | IKEv2+ES | S | S | M | S | S | M | S | S | S | S | U |
| | | | | | | | | | | | | P | | | | | | | | | | | |
| tcpcrypt | S | M | U | U** | U* | M | U | U | S | U | | | | | | | | | | | | | |
| | | | | | | | | | | | | SRTP+DTL | S | S | S | S | U | M | S | S | S | U | U |
| WireGuard | U | S | M | S | U | M | U | U | U | S+ | | S | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | |
| MinimalT | U | U | M | S | M | M | U | U | U | S | | tcpcrypt | S | M | U | U** | U* | M | U | U | S | U | U |
| | | | | | | | | | | | | | | | | | | | | | | | |
| CurveCP | U | U | S | S | M | M | U | U | U | S | | WireGuar | U | S | M | S | U | M | U | U | U | S+ | U |
+-----------+----+----+----+-----+----+----+-----+----+----+-----+ | d | | | | | | | | | | | |
| | | | | | | | | | | | |
| MinimalT | U | U | M | S | M | M | U | U | U | S | U |
| | | | | | | | | | | | |
| CurveCP | U | U | S | S | M | M | U | U | U | S | U |
+----------+---+----+----+-----+----+----+-----+----+----+-----+----+
M=Mandatory M=Mandatory S=Supported but not required U=Unsupported *=On TCP;
S=Supported but not required MPTCP would provide this ability **=TCP provides SYN cookies
U=Unsupported natively, but these are not cryptographically strong +=For transport
*=On TCP; MPTCP would provide this ability packets only
**=TCP provides SYN cookies natively, but these are not
cryptographically strong
+=For transport packets only
6. Transport Security Protocol Interfaces 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,
following conventions in [I-D.ietf-taps-interface] and
[I-D.ietf-taps-arch].
6.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
The application can provide its identities (certificates) and identities (certificates) and private keys, or mechanisms to
private keys, or mechanisms to access these, to the security 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
o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites)
The application can choose the algorithms that are supported for The application can choose the algorithms that are supported for
key exchange, signatures, and ciphersuites. key exchange, signatures, and ciphersuites. Protocols: TLS, DTLS,
Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP
o Session Cache Management The application provides the ability to o Session Cache Management The application provides the ability to
save and retrieve session state (such as tickets, keying material, save and retrieve session state (such as tickets, keying material,
and server parameters) that may be used to resume the security and server parameters) that may be used to resume the security
session. session. Protocols: TLS, DTLS, QUIC + TLS, MinimalT
Protocols: TLS, DTLS, QUIC + TLS, MinimalT
o Authentication Delegation o Authentication Delegation The application provides access to a
The application provides access to a separate module that will separate module that will provide authentication, using EAP for
provide authentication, using EAP for example. example. Protocols: IKEv2, SRTP
Protocols: IKEv2, SRTP
o Pre-Shared Key Import o Pre-Shared Key Import Either the handshake protocol or the
Either the handshake protocol or the application directly can application directly can supply pre-shared keys for the record
supply pre-shared keys for the record protocol use for encryption/ protocol use for encryption/decryption and authentication. If the
decryption and authentication. If the application can supply keys application can supply keys directly, this is considered explicit
directly, this is considered explicit import; if the handshake import; if the handshake protocol traditionally provides the keys
protocol traditionally provides the keys directly, it is directly, it is considered direct import; if the keys can only be
considered direct import; if the keys can only be shared by the 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
6.2. Connection Interfaces 6.2. Connection Interfaces
o Identity Validation o Identity Validation During a handshake, the security protocol will
During a handshake, the security protocol will conduct identity conduct identity validation of the peer. This can call into the
validation of the peer. This can call into the application to application to offload validation. Protocols: All (TLS, DTLS,
offload validation. Protocols: All (TLS, DTLS, QUIC + TLS, 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
The handshake protocol may delegate validation of the remote peer validation of the remote peer that has sent data to the transport
that has sent data to the transport protocol or application. This protocol or application. This involves sending a cookie exchange
involves sending a cookie exchange to avoid DoS attacks. to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard
Protocols: QUIC + TLS, DTLS, WireGuard
6.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
The handshake protocol may be instructed to update its keying keying material, either by the application directly or by the
material, either by the application directly or by the record record protocol sending a key expiration event. Protocols: TLS,
protocol sending a key expiration event. 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.
* Explicit 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
The record protocol can signal that its keys are expiring due to expiring due to reaching a time-based deadline, or a use-based
reaching a time-based deadline, or a use-based deadline (number of deadline (number of bytes that have been encrypted with the key).
bytes that have been encrypted with the key). This interaction is This interaction is often limited to signaling between the record
often limited to signaling between the record layer and the layer and the handshake layer. Protocols: ESP ((Editor's note:
handshake layer. One may consider TLS/DTLS to also have this interface))
Protocols: ESP ((Editor's note: One may consider TLS/DTLS to also
have this interface))
o Connection mobility o Connection mobility The record protocol can be signaled that it is
The record protocol can be signaled that it is being migrated to being migrated to another transport or interface due to connection
another transport or interface due to connection mobility, which 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)
7. IANA Considerations 7. IANA Considerations
This document has no request to IANA. This document has no request to IANA.
8. Security Considerations 8. Security Considerations
This document summarizes existing transport security protocols and This document summarizes existing transport security protocols and
their interfaces. It does not propose changes to or recommend usage their interfaces. It does not propose changes to or recommend usage
skipping to change at page 28, line 49 skipping to change at page 28, line 45
[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-13 (work in (TLS) to Secure QUIC", draft-ietf-quic-tls-15 (work in
progress), June 2018. progress), October 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-13 (work and Secure Transport", draft-ietf-quic-transport-15 (work
in progress), June 2018. in progress), October 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-15 (work in progress), July 2018.
[I-D.ietf-taps-arch] [I-D.ietf-taps-arch]
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
Perkins, C., Tiesel, P., and C. Wood, "An Architecture for Perkins, C., Tiesel, P., and C. Wood, "An Architecture for
Transport Services", draft-ietf-taps-arch-00 (work in Transport Services", draft-ietf-taps-arch-02 (work in
progress), April 2018. progress), October 2018.
[I-D.ietf-taps-interface]
Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G.,
Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An
Abstract Application Layer Interface to Transport
Services", draft-ietf-taps-interface-02 (work in
progress), October 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-12 (work in (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-13 (work in
progress), June 2018. progress), September 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-19 (work in progress), June 2018. 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-01 (work in
progress), December 2017. progress), July 2018.
[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
1.3", draft-ietf-tls-dtls13-26 (work in progress), March 1.3", draft-ietf-tls-dtls13-28 (work in progress), July
2018. 2018.
[I-D.ietf-tls-record-limit]
Thomson, M., "Record Size Limit Extension for Transport
Layer Security (TLS)", draft-ietf-tls-record-limit-03
(work in progress), May 2018.
[I-D.ietf-tls-tls13] [I-D.ietf-tls-tls13]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", draft-ietf-tls-tls13-28 (work in progress), Version 1.3", draft-ietf-tls-tls13-28 (work in progress),
March 2018. March 2018.
[MinimalT] [MinimalT]
"MinimaLT -- Minimal-latency Networking Through Better "MinimaLT -- Minimal-latency Networking Through Better
Security", n.d.. Security", n.d..
[Noise] "The Noise Protocol Framework", n.d.. [Noise] "The Noise Protocol Framework", n.d..
 End of changes. 89 change blocks. 
259 lines changed or deleted 252 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/