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.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |