idnits 2.17.1 draft-ietf-taps-transport-security-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 07, 2019) is 1695 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-22 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-22 == Outdated reference: A later version (-19) exists of draft-ietf-taps-arch-04 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-04 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-06 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) -- Obsolete informational reference (is this intentional?): RFC 7539 (Obsoleted by RFC 8439) -- Obsolete informational reference (is this intentional?): RFC 8229 (Obsoleted by RFC 9329) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Wood, Ed. 3 Internet-Draft Apple Inc. 4 Intended status: Informational T. Enghardt 5 Expires: February 8, 2020 TU Berlin 6 T. Pauly 7 Apple Inc. 8 C. Perkins 9 University of Glasgow 10 K. Rose 11 Akamai Technologies, Inc. 12 August 07, 2019 14 A Survey of Transport Security Protocols 15 draft-ietf-taps-transport-security-08 17 Abstract 19 This document provides a survey of commonly used or notable network 20 security protocols, with a focus on how they interact and integrate 21 with applications and transport protocols. Its goal is to supplement 22 efforts to define and catalog transport services by describing the 23 interfaces required to add security protocols. This survey is not 24 limited to protocols developed within the scope or context of the 25 IETF, and those included represent a superset of features a Transport 26 Services system may need to support. Moreover, this document defines 27 a minimal set of security features that a secure transport system 28 should provide. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on February 8, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 6 67 4. Transport Security Protocol Descriptions . . . . . . . . . . 7 68 4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1.1. Protocol Description . . . . . . . . . . . . . . . . 8 70 4.1.2. Security Features . . . . . . . . . . . . . . . . . . 9 71 4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9 72 4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.2.1. Protocol Description . . . . . . . . . . . . . . . . 10 74 4.2.2. Security Features . . . . . . . . . . . . . . . . . . 10 75 4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 76 4.3. QUIC with TLS . . . . . . . . . . . . . . . . . . . . . . 11 77 4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11 78 4.3.2. Security Features . . . . . . . . . . . . . . . . . . 12 79 4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12 80 4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 12 81 4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12 82 4.4.1. IKEv2 Protocol Description . . . . . . . . . . . . . 12 83 4.4.2. ESP Protocol Description . . . . . . . . . . . . . . 13 84 4.4.3. IKEv2 Security Features . . . . . . . . . . . . . . . 14 85 4.4.4. ESP Security Features . . . . . . . . . . . . . . . . 14 86 4.4.5. IKEv2 Protocol Dependencies . . . . . . . . . . . . . 14 87 4.4.6. ESP Protocol Dependencies . . . . . . . . . . . . . . 15 88 4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15 89 4.5.1. Protocol description . . . . . . . . . . . . . . . . 15 90 4.5.2. Security Features . . . . . . . . . . . . . . . . . . 16 91 4.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16 92 4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 17 93 4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 17 94 4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17 95 4.6.2. Security Features . . . . . . . . . . . . . . . . . . 18 96 4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18 97 4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18 98 4.7.1. Protocol description . . . . . . . . . . . . . . . . 19 99 4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19 100 4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20 101 4.8. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20 102 4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20 103 4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 21 104 4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21 105 4.9. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 22 106 4.9.1. Protocol Description . . . . . . . . . . . . . . . . 22 107 4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 23 108 4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 23 109 4.10. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . 23 110 4.10.1. Protocol Description . . . . . . . . . . . . . . . . 23 111 4.10.2. Protocol Features . . . . . . . . . . . . . . . . . 24 112 4.10.3. Protocol Dependencies . . . . . . . . . . . . . . . 25 113 5. Security Features and Application Dependencies . . . . . . . 25 114 5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 25 115 5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 26 116 5.3. Optional Feature Availability . . . . . . . . . . . . . . 27 117 6. Transport Security Protocol Interfaces . . . . . . . . . . . 29 118 6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 29 119 6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 30 120 6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 30 121 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 122 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 123 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 124 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 125 11. Informative References . . . . . . . . . . . . . . . . . . . 31 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 128 1. Introduction 130 Services and features provided by transport protocols have been 131 cataloged in [RFC8095]. This document supplements that work by 132 surveying commonly used and notable network security protocols, and 133 identifying the services and features a Transport Services system (a 134 system that provides a transport API) needs to provide in order to 135 add transport security. It examines Transport Layer Security (TLS), 136 Datagram Transport Layer Security (DTLS), QUIC + TLS, tcpcrypt, 137 Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + 138 ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimalT. For each 139 protocol, this document provides a brief description, the security 140 features it provides, and the dependencies it has on the underlying 141 transport. This is followed by defining the set of transport 142 security features shared by these protocols. The document groups 143 these security features into a minimal set of features, which every 144 secure transport system should provide in addition to the transport 145 features described in [I-D.ietf-taps-minset], and additional optional 146 features, which may not be available in every secure transport 147 system. Finally, the document distills the application and transport 148 interfaces provided by the transport security protocols. 150 Selected protocols represent a superset of functionality and features 151 a Transport Services system may need to support, both internally and 152 externally (via an API) for applications [I-D.ietf-taps-arch]. 153 Ubiquitous IETF protocols such as (D)TLS, as well as non-standard 154 protocols such as Google QUIC, are both included despite overlapping 155 features. As such, this survey is not limited to protocols developed 156 within the scope or context of the IETF. Outside of this candidate 157 set, protocols that do not offer new features are omitted. For 158 example, newer protocols such as WireGuard make unique design choices 159 that have important implications on applications, such as how to best 160 configure peer public keys and to delegate algorithm selection to the 161 system. In contrast, protocols such as ALTS [ALTS] are omitted since 162 they do not represent features deemed unique. 164 Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH 165 [RFC4302] are excluded from this survey. TCP-AO adds authenticity 166 protections to long-lived TCP connections, e.g., replay protection 167 with per-packet Message Authentication Codes. (This protocol 168 obsoletes TCP MD5 "signature" options specified in [RFC2385].) One 169 prime use case of TCP-AO is for protecting BGP connections. 170 Similarly, AH adds per-datagram authenticity and adds similar replay 171 protection. Despite these improvements, neither protocol sees 172 general use and both lack critical properties important for emergent 173 transport security protocols: confidentiality, privacy protections, 174 and agility. Such protocols are thus omitted from this survey. 176 2. Terminology 178 The following terms are used throughout this document to describe the 179 roles and interactions of transport security protocols: 181 o Transport Feature: a specific end-to-end feature that the 182 transport layer provides to an application. Examples include 183 confidentiality, reliable delivery, ordered delivery, message- 184 versus-stream orientation, etc. 186 o Transport Service: a set of Transport Features, without an 187 association to any given framing protocol, which provides 188 functionality to an application. 190 o Transport Protocol: an implementation that provides one or more 191 different transport services using a specific framing and header 192 format on the wire. A Transport Protocol services an application. 194 o Application: an entity that uses a transport protocol for end-to- 195 end delivery of data across the network. This may also be an 196 upper layer protocol or tunnel encapsulation. 198 o Security Feature: a feature that a network security layer provides 199 to applications. Examples include authentication, encryption, key 200 generation, session resumption, and privacy. Features may be 201 Mandatory or Optional for an application's implementation. 202 Security Features extend the set of Transport Features described 203 in [RFC8095] and provided by Transport Services implementations. 205 o Security Protocol: a defined network protocol that implements one 206 or more security features. Security protocols may be used 207 alongside transport protocols, and in combination with other 208 security protocols when appropriate. 210 o Handshake Protocol: a protocol that enables peers to validate each 211 other and to securely establish shared cryptographic context. 213 o Record: Framed protocol messages. 215 o Record Protocol: a security protocol that allows data to be 216 divided into manageable blocks and protected using shared 217 cryptographic context. 219 o Session: an ephemeral security association between applications. 221 o Cryptographic context: a set of cryptographic parameters, 222 including but not necessarily limited to keys for encryption, 223 authentication, and session resumption, enabling authorized 224 parties to a session to communicate securely. 226 o Connection: the shared state of two or more endpoints that 227 persists across messages that are transmitted between these 228 endpoints. A connection is a transient participant of a session, 229 and a session generally lasts between connection instances. 231 o Peer: an endpoint application party to a session. 233 o Client: the peer responsible for initiating a session. 235 o Server: the peer responsible for responding to a session 236 initiation. 238 3. Security Features 240 In this section, we enumerate Security Features exposed by protocols 241 discussed in the remainder of this document. Protocol security (and 242 privacy) properties that are unrelated to the API surface exposed by 243 such protocols, such as client or server identity hiding, are not 244 listed here as features. 246 o Forward-secure session key establishment: Establishing 247 cryptographic keys with forward-secure properties. 249 o Cryptographic algorithm negotiation: Negotiating support of 250 protocol algorithms, including algorithms for encryption, hashing, 251 MAC (PRF), and digital signatures. 253 o Session caching and management: Managing session state caches used 254 for subsequent connections, with the aim of amortizing connection 255 establishment costs. 257 o Peer authentication: Authenticating peers using generic or 258 protocol-specific mechanisms, such as certificates, raw public 259 keys, pre-shared keys, or EAP methods. 261 o Unilateral responder authentication: Requiring authentication for 262 the responder of a connection. 264 o Mutual authentication: Establishing connections in which both 265 endpoints are authenticated. 267 o Application authentication delegation: Delegating to applications 268 out-of-band to perform peer authentication. 270 o Record (channel or datagram) confidentiality and integrity: 271 Encrypting and authenticating application plaintext bytes sent 272 between peers over a channel or in individual datagrams. 274 o Partial record confidentiality: Encrypting some portion of 275 records. 277 o Optional record integrity: Optionally authenticating certain 278 records. 280 o Record replay prevention: Detecting and defending against record 281 replays, which can be due to in-network retransmissions. 283 o Early data support: Transmitting application data prior to secure 284 connection establishment via a handshake. For TLS, this support 285 begins with TLS 1.3. 287 o Connection mobility: Allowing a connection to be multihomed or 288 resilient across network interface or address changes, such as NAT 289 rebindings that occur without an endpoint's knowledge. Mobility 290 allows cryptographic key material and other state information to 291 be reused in the event of a connection change. 293 o Application-layer feature negotiation: Securely negotiating 294 application-specific functionality. Such features may be 295 necessary for further application processing, such as the TLS 296 parent connection protocol type via ALPN [RFC7301] or desired 297 application identity via SNI [RFC6066]. 299 o Configuration extensions: Adding protocol features via extensions 300 or configuration options. TLS extensions are a primary example of 301 this feature. 303 o Out-of-order record receipt: Processing of records received out- 304 of-order. 306 o Source validation (cookie or puzzle based): Validating peers and 307 mitigating denial-of-service (DoS) attacks via explicit proof of 308 origin (cookies) or work mechanisms (puzzles). 310 o Length-hiding padding: Adding padding to records in order to hide 311 plaintext message length and mitigate amplification attack 312 vectors. 314 4. Transport Security Protocol Descriptions 316 This section contains descriptions of security protocols currently 317 used to protect data being sent over a network. 319 For each protocol, we describe its provided features and dependencies 320 on other protocols. 322 4.1. TLS 324 TLS (Transport Layer Security) [RFC5246] is a common protocol used to 325 establish a secure session between two endpoints. Communication over 326 this session "prevents eavesdropping, tampering, and message 327 forgery." TLS consists of a tightly coupled handshake and record 328 protocol. The handshake protocol is used to authenticate peers, 329 negotiate protocol options, such as cryptographic algorithms, and 330 derive session-specific keying material. The record protocol is used 331 to marshal (possibly encrypted) data from one peer to the other. 332 This data may contain handshake messages or raw application data. 334 4.1.1. Protocol Description 336 TLS is the composition of a handshake and record protocol [RFC8446]. 337 The record protocol is designed to marshal an arbitrary, in-order 338 stream of bytes from one endpoint to the other. It handles 339 segmenting, compressing (when enabled), and encrypting data into 340 discrete records. When configured to use an authenticated encryption 341 with associated data (AEAD) algorithm, it also handles nonce 342 generation and encoding for each record. The record protocol is 343 hidden from the client behind a bytestream-oriented API. 345 The handshake protocol serves several purposes, including: peer 346 authentication, protocol option (key exchange algorithm and 347 ciphersuite) negotiation, and key derivation. Peer authentication 348 may be mutual; however, commonly, only the server is authenticated. 349 X.509 certificates are commonly used in this authentication step, 350 though other mechanisms, such as raw public keys [RFC7250], exist. 351 The client is not authenticated unless explicitly requested by the 352 server. 354 The handshake protocol is also extensible. It allows for a variety 355 of extensions to be included by either the client or server. These 356 extensions are used to specify client preferences, e.g., the 357 application-layer protocol to be driven with the TLS connection 358 [RFC7301], or signals to the server to aid operation, e.g., Server 359 Name Indication (SNI) [RFC6066]. Various extensions also exist to 360 tune the parameters of the record protocol, e.g., the maximum 361 fragment length [RFC6066] and record size limit [RFC8449]. 363 Alerts are used to convey errors and other atypical events to the 364 endpoints. There are two classes of alerts: closure and error 365 alerts. A closure alert is used to signal to the other peer that the 366 sender wishes to terminate the connection. The sender typically 367 follows a close alert with a TCP FIN segment to close the connection. 368 Error alerts are used to indicate problems with the handshake or 369 individual records. Most errors are fatal and are followed by 370 connection termination. However, warning alerts may be handled at 371 the discretion of the implementation. 373 Once a session is disconnected all session keying material must be 374 destroyed, with the exception of secrets previously established 375 expressly for purposes of session resumption. TLS supports stateful 376 and stateless resumption. (Here, "state" refers to bookkeeping on a 377 per-session basis by the server. It is assumed that the client must 378 always store some state information in order to resume a session.) 380 4.1.2. Security Features 382 o Forward-secure session key establishment. 384 o Cryptographic algorithm negotiation. 386 o Stateful and stateless cross-connection session resumption. 388 o Session caching and management. 390 o Peer authentication (Certificate, raw public key, and pre-shared 391 key). 393 o Unilateral responder authentication. 395 o Mutual authentication. 397 o Application authentication delegation. 399 o Record (channel) confidentiality and integrity. 401 o Record replay prevention. 403 o Application-layer feature negotiation. 405 o Configuration extensions. 407 o Early data support (starting with TLS 1.3). 409 o Optional record-layer padding (starting with TLS 1.3). 411 4.1.3. Protocol Dependencies 413 o In-order, reliable bytestream transport. 415 o (Optionally) A PKI trust store for certificate validation. 417 4.2. DTLS 419 DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, 420 but differs in that it is designed to run over unrelaible datagram 421 protocols like UDP instead of TCP. DTLS modifies the protocol to 422 make sure it can still provide the same security guarantees as TLS 423 even without reliability from the transport. DTLS was designed to be 424 as similar to TLS as possible, so this document assumes that all 425 properties from TLS are carried over except where specified. 427 4.2.1. Protocol Description 429 DTLS is modified from TLS to operate with the possibility of packet 430 loss, reordering, and duplication that may occur when operating over 431 UDP. To enable out-of-order delivery of application data, the DTLS 432 record protocol itself has no inter-record dependencies. However, as 433 the handshake requires reliability, each handshake message is 434 assigned an explicit sequence number to enable retransmissions of 435 lost packets and in-order processing by the receiver. Handshake 436 message loss is remedied by sender retransmission after a 437 configurable period in which the expected response has not yet been 438 received. 440 As the DTLS handshake protocol runs atop the record protocol, to 441 account for long handshake messages that cannot fit within a single 442 record, DTLS supports fragmentation and subsequent reconstruction of 443 handshake messages across records. The receiver must reassemble 444 records before processing. 446 DTLS relies on unique UDP 4-tuples to identify connections, or a 447 similar mechanism in other datagram transports. Since all 448 application-layer data is encrypted, demultiplexing over the same 449 4-tuple requires the use of a connection identifier extension 450 [I-D.ietf-tls-dtls-connection-id] to permit identification of the 451 correct connection-specific cryptographic context without the use of 452 trial decryption. (Note that this extension is only supported in 453 DTLS 1.2 and 1.3 {{?I-D.ietf-tls-dtls13}.) 455 Since datagrams can be replayed, DTLS provides optional anti-replay 456 detection based on a window of acceptable sequence numbers [RFC6347]. 458 4.2.2. Security Features 460 o Record replay protection. 462 o Record (datagram) confidentiality and integrity. 464 o Out-of-order record receipt. 466 o DoS mitigation (cookie-based). 468 See also the features from TLS. 470 4.2.3. Protocol Dependencies 472 o DTLS relies on an unreliable datagram transport. 474 o The DTLS record protocol explicitly encodes record lengths, so 475 although it runs over a datagram transport, it does not rely on 476 the transport protocol's framing beyond requiring transport-level 477 reconstruction of datagrams fragmented over packets. (Note: DTLS 478 1.3 short header records omit the explicit length field.) 480 o Uniqueness of the session within the transport flow (only one DTLS 481 connection on a UDP 4-tuple, for example); or else support for the 482 connection identifier extension to enable demultiplexing. 484 o Path MTU discovery. 486 o For the handshake: Reliable, in-order transport. DTLS provides 487 its own reliability. 489 4.3. QUIC with TLS 491 QUIC is a new standards-track transport protocol that runs over UDP, 492 loosely based on Google's original proprietary gQUIC protocol 493 [I-D.ietf-quic-transport] (See Section 4.3.4 for more details). The 494 QUIC transport layer itself provides support for data confidentiality 495 and integrity. This requires keys to be derived with a separate 496 handshake protocol. A mapping for QUIC of TLS 1.3 497 [I-D.ietf-quic-tls] has been specified to provide this handshake. 499 4.3.1. Protocol Description 501 As QUIC relies on TLS to secure its transport functions, it creates 502 specific integration points between its security and transport 503 functions: 505 o Starting the handshake to generate keys and provide authentication 506 (and providing the transport for the handshake). 508 o Client address validation. 510 o Key ready events from TLS to notify the QUIC transport. 512 o Exporting secrets from TLS to the QUIC transport. 514 The QUIC transport layer support multiple streams over a single 515 connection. QUIC implements a record protocol for TLS handshake 516 messages to establish a connection. These messages are sent in 517 CRYPTO frames [I-D.ietf-quic-transport] in Initial and Handshake 518 packets. Initial packets are encrypted using fixed keys derived from 519 the QUIC version and public packet information (Connection ID). 520 Handshake packets are encrypted using TLS handshake secrets. Once 521 TLS completes, QUIC uses the resulting traffic secrets to for the 522 QUIC connection to protect the rest of the frames. QUIC supports 523 0-RTT data using previously negotiated connection secrets Early data 524 is sent in 0-RTT packets, which may be included in the same datagram 525 as the Initial and Handshake packets. 527 4.3.2. Security Features 529 o DoS mitigation (cookie-based). 531 See also the properties of TLS. 533 4.3.3. Protocol Dependencies 535 o QUIC transport relies on UDP. 537 o QUIC transport relies on TLS 1.3 for key exchange, peer 538 authentication, and shared secret derivation. 540 o For the handshake: Reliable, in-order transport. QUIC provides 541 its own reliability. 543 4.3.4. Variant: Google QUIC 545 Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol 546 designed and deployed by Google following experience from deploying 547 SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally 548 known as "QUIC": this document uses gQUIC to unambiguously 549 distinguish it from the standards-track IETF QUIC. The proprietary 550 technical forebear of IETF QUIC, gQUIC was originally designed with 551 tightly-integrated security and application data transport protocols. 553 4.4. IKEv2 with ESP 555 IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec 556 protocol suite that encrypts and authenticates IP packets, either for 557 creating tunnels (tunnel-mode) or for direct transport connections 558 (transport-mode). This suite of protocols separates out the key 559 generation protocol (IKEv2) from the transport encryption protocol 560 (ESP). Each protocol can be used independently, but this document 561 considers them together, since that is the most common pattern. 563 4.4.1. IKEv2 Protocol Description 565 IKEv2 is a control protocol that runs on UDP ports 500 or 4500 and 566 TCP port 4500. Its primary goal is to generate keys for Security 567 Associations (SAs). An SA contains shared (cryptographic) 568 information used for establishing other SAs or keying ESP; See 569 Section 4.4.2. IKEv2 first uses a Diffie-Hellman key exchange to 570 generate keys for the "IKE SA", which is a set of keys used to 571 encrypt further IKEv2 messages. IKE then performs a phase of 572 authentication in which both peers present blobs signed by a shared 573 secret or private key that authenticates the entire IKE exchange and 574 the IKE identities. IKE then derives further sets of keys on demand, 575 which together with traffic policies are referred to as the "Child 576 SA". These Child SA keys are used by ESP. 578 IKEv2 negotiates which protocols are acceptable to each peer for both 579 the IKE and Child SAs using "Proposals". Each proposal specifies an 580 encryption and authentication algorithm, or an AEAD algorithm, a 581 Diffie-Hellman group, and (for IKE SAs only) a pseudorandom function 582 algorithm. Each peer may support multiple proposals, and the most 583 preferred mutually supported proposal is chosen during the handshake. 585 The authentication phase of IKEv2 may use Shared Secrets, 586 Certificates, Digital Signatures, or an EAP (Extensible 587 Authentication Protocol) method. At a minimum, IKEv2 takes two round 588 trips to set up both an IKE SA and a Child SA. If EAP is used, this 589 exchange may be expanded. 591 Any SA used by IKEv2 can be rekeyed before expiration, which is 592 usually based either on time or number of bytes encrypted. 594 There is an extension to IKEv2 that allows session resumption 595 [RFC5723]. 597 MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a 598 set of Security Associations to migrate over different outer IP 599 addresses and interfaces [RFC4555]. 601 When UDP is not available or well-supported on a network, IKEv2 may 602 be encapsulated in TCP [RFC8229]. 604 4.4.2. ESP Protocol Description 606 ESP is a protocol that encrypts and authenticates IPv4 and IPv6 607 packets. The keys used for both encryption and authentication can be 608 derived from an IKEv2 exchange. ESP Security Associations come as 609 pairs, one for each direction between two peers. Each SA is 610 identified by a Security Parameter Index (SPI), which is marked on 611 each encrypted ESP packet. 613 ESP packets include the SPI, a sequence number, an optional 614 Initialization Vector (IV), payload data, padding, a length and next 615 header field, and an Integrity Check Value. 617 From [RFC4303], "ESP is used to provide confidentiality, data origin 618 authentication, connectionless integrity, an anti-replay service (a 619 form of partial sequence integrity), and limited traffic flow 620 confidentiality." 622 Since ESP operates on IP packets, it is not directly tied to the 623 transport protocols it encrypts. This means it requires little or no 624 change from transports in order to provide security. 626 ESP packets may be sent directly over IP, but where network 627 conditions warrant (e.g., when a NAT is present or when a firewall 628 blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP 629 [RFC8229]. 631 4.4.3. IKEv2 Security Features 633 o Forward-secure session key establishment. 635 o Cryptographic algorithm negotiation. 637 o Peer authentication (certificate, raw public key, pre-shared key, 638 and EAP). 640 o Unilateral responder authentication. 642 o Mutual authentication. 644 o Record (datagram) confidentiality and integrity. 646 o Session resumption. 648 o Connection mobility. 650 o DoS mitigation (cookie-based). 652 4.4.4. ESP Security Features 654 o Record confidentiality and integrity. 656 o Record replay protection. 658 4.4.5. IKEv2 Protocol Dependencies 660 o Availability of UDP to negotiate, or implementation support for 661 TCP-encapsulation. 663 o Some EAP authentication types require accessing a hardware device, 664 such as a SIM card; or interacting with a user, such as password 665 prompting. 667 4.4.6. ESP Protocol Dependencies 669 o Since ESP is below transport protocols, it does not have any 670 dependencies on the transports themselves, other than on UDP or 671 TCP where encapsulation is employed. 673 4.5. Secure RTP (with DTLS) 675 Secure RTP (SRTP) is a profile for RTP that provides confidentiality, 676 message authentication, and replay protection for RTP data packets 677 and RTP control protocol (RTCP) packets [RFC3711]. 679 4.5.1. Protocol description 681 SRTP adds confidentiality and optional integrity protection to RTP 682 data packets, and adds confidentially and mandatory integrity 683 protection to RTCP packets. For RTP data packets, this is done by 684 encrypting the payload section of the packet and optionally appending 685 an authentication tag (MAC) as a packet trailer, with the RTP header 686 authenticated but not encrypted (the RTP header was left unencrypted 687 to enable RTP header compression [RFC2508] [RFC3545]). For RTCP 688 packets, the first packet in the compound RTCP packet is partially 689 encrypted, leaving the first eight octets of the header as clear-text 690 to allow identification of the packet as RTCP, while the remainder of 691 the compound packet is fully encrypted. The entire RTCP packet is 692 then authenticated by appending a MAC as packet trailer. 694 Packets are encrypted using session keys, which are ultimately 695 derived from a master key and an additional master salt and session 696 salt. SRTP packets carry a 2-byte sequence number to partially 697 identify the unique packet index. SRTP peers maintain a separate 698 roll-over counter (ROC) for RTP data packets that is incremented 699 whenever the sequence number wraps. The sequence number and ROC 700 together determine the packet index. RTCP packets have a similar, 701 yet differently named, field called the RTCP index which serves the 702 same purpose. 704 Numerous encryption modes are supported. For popular modes of 705 operation, e.g., AES-CTR, the (unique) initialization vector (IV) 706 used for each encryption mode is a function of the RTP SSRC 707 (synchronization source), packet index, and session "salting key". 709 SRTP offers replay detection by keeping a replay list of already seen 710 and processed packet indices. If a packet arrives with an index that 711 matches one in the replay list, it is silently discarded. 713 DTLS [RFC5764] is commonly used to perform mutual authentication and 714 key agreement for SRTP [RFC5763]. Peers use DTLS to perform mutual 715 certificate-based authentication on the media path, and to generate 716 the SRTP master key. Peer certificates can be issued and signed by a 717 certificate authority. Alternatively, certificates used in the DTLS 718 exchange can be self-signed. If they are self-signed, certificate 719 fingerprints are included in the signalling exchange (e.g., in SIP or 720 WebRTC), and used to bind the DTLS key exchange in the media plane to 721 the signaling plane. The combination of a mutually authenticated 722 DTLS key exchange on the media path and a fingerprint sent in the 723 signalling channel protects against active attacks on the media, 724 provided the signalling can be trusted. Signalling needs to be 725 protected as described in, for example, SIP [RFC3261] Authenticated 726 Identity Management [RFC4474] or the WebRTC security architecture 727 [I-D.ietf-rtcweb-security-arch], to provide complete system security. 729 4.5.2. Security Features 731 o Forward-secure session key establishment. 733 o Cryptographic algorithm negotiation. 735 o Mutual authentication. 737 o Partial datagram confidentiality. (Packet headers are not 738 encrypted.) 740 o Optional authentication of data packets. 742 o Mandatory authentication of control packets. 744 o Out-of-order record receipt. 746 4.5.3. Protocol Dependencies 748 o Secure RTP can run over UDP or TCP. 750 o External key derivation and management protocol, e.g., DTLS 751 [RFC5763]. 753 o External identity management protocol, e.g., SIP Authenticated 754 Identity Management [RFC4474], WebRTC Security Architecture 755 [I-D.ietf-rtcweb-security-arch]. 757 4.5.4. Variant: ZRTP for Media Path Key Agreement 759 ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It 760 uses standard SRTP to protect RTP data packets and RTCP packets, but 761 provides alternative key agreement and identity management protocols. 763 Key agreement is performed using a Diffie-Hellman key exchange that 764 runs on the media path. This generates a shared secret that is then 765 used to generate the master key and salt for SRTP. 767 ZRTP does not rely on a PKI or external identity management system. 768 Rather, it uses an ephemeral Diffie-Hellman key exchange with hash 769 commitment to allow detection of man-in-the-middle attacks. This 770 requires endpoints to display a short authentication string that the 771 users must read and verbally compare to validate the hashes and 772 ensure security. Endpoints cache some key material after the first 773 call to use in subsequent calls; this is mixed in with the Diffie- 774 Hellman shared secret, so the short authentication string need only 775 be checked once for a given user. This gives key continuity 776 properties analogous to the secure shell (ssh) [RFC4253]. 778 4.6. tcpcrypt 780 Tcpcrypt is a lightweight extension to the TCP protocol for 781 opportunistic encryption. Applications may use tcpcrypt's unique 782 session ID for further application-level authentication. Absent this 783 authentication, tcpcrypt is vulnerable to active attacks. 785 4.6.1. Protocol Description 787 Tcpcrypt extends TCP to enable opportunistic encryption between the 788 two ends of a TCP connection [RFC8548]. It is a family of TCP 789 encryption protocols (TEP), distinguished by key exchange algorithm. 790 The use of a TEP is negotiated with a TCP option during the initial 791 TCP handshake via the mechanism described by TCP Encryption 792 Negotiation Option (ENO) [RFC8547]. In the case of initial session 793 establishment, once a tcpcrypt TEP has been negotiated the key 794 exchange occurs within the data segments of the first few packets 795 exchanged after the handshake completes. The initiator of a 796 connection sends a list of supported AEAD algorithms, a random nonce, 797 and an ephemeral public key share. The responder typically chooses a 798 mutually-supported AEAD algorithm and replies with this choice, its 799 own nonce, and ephemeral key share. An initial shared secret is 800 derived from the ENO handshake, the tcpcrypt handshake, and the 801 initial keying material resulting from the key exchange. The traffic 802 encryption keys on the initial connection are derived from the shared 803 secret. Connections can be re-keyed before the natural AEAD limit 804 for a single set of traffic encryption keys is reached. 806 Each tcpcrypt session is associated with a ladder of resumption IDs, 807 each derived from the respective entry in a ladder of shared secrets. 808 These resumption IDs can be used to negotiate a stateful resumption 809 of the session in a subsequent connection, resulting in use of a new 810 shared secret and traffic encryption keys without requiring a new key 811 exchange. Willingness to resume a session is signaled via the ENO 812 option during the TCP handshake. Given the length constraints 813 imposed by TCP options, unlike stateless resumption mechanisms (such 814 as that provided by session tickets in TLS) resumption in tcpcrypt 815 requires the maintenance of state on the server, and so successful 816 resumption across a pool of servers implies shared state. 818 Owing to middlebox ossification issues, tcpcrypt only protects the 819 payload portion of a TCP packet. It does not encrypt any header 820 information, such as the TCP sequence number. 822 4.6.2. Security Features 824 o Forward-secure session key establishment. 826 o Record (channel) confidentiality and integrity. 828 o Stateful cross-connection session resumption. 830 o Session caching and management. 832 o Application authentication delegation. 834 4.6.3. Protocol Dependencies 836 o TCP for in-order, reliable transport. 838 o TCP Encryption Negotiation Option (ENO). 840 4.7. WireGuard 842 WireGuard is a layer 3 protocol designed as an alternative to IPsec 843 [WireGuard] for certain use cases. It uses UDP to encapsulate IP 844 datagrams between peers. Unlike most transport security protocols, 845 which rely on PKI for peer authentication, WireGuard authenticates 846 peers using pre-shared public keys delivered out-of-band, each of 847 which is bound to one or more IP addresses. Moreover, as a protocol 848 suited for VPNs, WireGuard offers no extensibility, negotiation, or 849 cryptographic agility. 851 4.7.1. Protocol description 853 WireGuard is a simple VPN protocol that binds a pre-shared public key 854 to one or more IP addresses. Users configure WireGuard by 855 associating peer public keys with IP addresses. These mappings are 856 stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard] 857 for more details and sample configurations.) These keys are used 858 upon WireGuard packet transmission and reception. For example, upon 859 receipt of a Handshake Initiation message, receivers use the static 860 public key in their CryptoKey routing table to perform necessary 861 cryptographic computations. 863 WireGuard builds on Noise [Noise] for 1-RTT key exchange with 864 identity hiding. The handshake hides peer identities as per the 865 SIGMA construction [SIGMA]. As a consequence of using Noise, 866 WireGuard comes with a fixed set of cryptographic algorithms: 868 o x25519 [Curve25519] and HKDF [RFC5869] for ECDH and key 869 derivation. 871 o ChaCha20+Poly1305 [RFC7539] for packet authenticated encryption. 873 o BLAKE2s [BLAKE2] for hashing. 875 There is no cryptographic agility. If weaknesses are found in any of 876 these algorithms, new message types using new algorithms must be 877 introduced. 879 If a WireGuard receiver is under heavy load and cannot process a 880 packet, e.g., cannot spare CPU cycles for expensive public key 881 cryptographic operations, it can reply with a cookie similar to DTLS 882 and IKEv2. This cookie only proves IP address ownership. Any rate 883 limiting scheme can be applied to packets coming from non-spoofed 884 addresses. 886 4.7.2. Security Features 888 o Forward-secure session key establishment. 890 o Peer authentication (public-key and PSK). 892 o Mutual authentication. 894 o Record replay prevention (Stateful, timestamp-based). 896 o Connection mobility. 898 o DoS mitigation (cookie-based). 900 4.7.3. Protocol Dependencies 902 o Datagram transport. 904 o Out-of-band key distribution and management. 906 4.8. CurveCP 908 CurveCP [CurveCP] is a UDP-based transport security protocol from 909 Daniel J. Bernstein. Unlike other transport security protocols, it 910 is based entirely upon highly efficient public key algorithms. This 911 removes many pitfalls associated with nonce reuse and key 912 synchronization. 914 4.8.1. Protocol Description 916 CurveCP is a UDP-based transport security protocol. It is built on 917 three principal features: exclusive use of public key authenticated 918 encryption of packets, server-chosen cookies to prohibit memory and 919 computation DoS at the server, and connection mobility with a client- 920 chosen ephemeral identifier. 922 There are two rounds in CurveCP. In the first round, the client 923 sends its first initialization packet to the server, carrying its 924 (possibly fresh) ephemeral public key C', with zero-padding encrypted 925 under the server's long-term public key. The server replies with a 926 cookie and its own ephemeral key S' and a cookie that is to be used 927 by the client. Upon receipt, the client then generates its second 928 initialization packet carrying: the ephemeral key C', cookie, and an 929 encryption of C', the server's domain name, and, optionally, some 930 message data. The server verifies the cookie and the encrypted 931 payload and, if valid, proceeds to send data in return. At this 932 point, the connection is established and the two parties can 933 communicate. 935 The use of public-key encryption and authentication, or "boxing", 936 simplifies problems that come with symmetric key management and nonce 937 synchronization. For example, it allows the sender of a message to 938 be in complete control of each message's nonce. It does not require 939 either end to share secret keying material. Furthermore, it allows 940 connections (or sessions) to be associated with unique ephemeral 941 public keys as a mechanism for enabling forward secrecy given the 942 risk of long-term private key compromise. 944 The client and server do not perform a standard key exchange. 945 Instead, in the initial exchange of packets, each party provides its 946 own ephemeral key to the other end. The client can choose a new 947 ephemeral key for every new connection. However, the server must 948 rotate these keys on a slower basis. Otherwise, it would be trivial 949 for an attacker to force the server to create and store ephemeral 950 keys with a fake client initialization packet. 952 Servers use cookies for source validation. After receiving a 953 client's initial packet, encrypted under the server's long-term 954 public key, a server generates and returns a stateless cookie that 955 must be echoed back in the client's following message. This cookie 956 is encrypted under the client's ephemeral public key. This stateless 957 technique prevents attackers from hijacking client initialization 958 packets to obtain cookie values to flood clients. (A client would 959 detect the duplicate cookies and reject the flooded packets.) 960 Similarly, replaying the client's second packet, carrying the cookie, 961 will be detected by the server. 963 CurveCP supports client authentication by allowing clients to send 964 their long-term public keys in the second initialization packet. A 965 server can verify this public key and, if untrusted, drop the 966 connection and subsequent data. 968 Unlike some other protocols, CurveCP data packets leave only the 969 ephemeral public key, connection ID, and per-message nonce in the 970 clear. All other data is encrypted. 972 4.8.2. Protocol Features 974 o Datagram confidentiality and integrity (via public key 975 encryption). 977 o Peer authentication (public-key). 979 o Unilateral responder authentication. 981 o Mutual authentication. 983 o Connection mobility (based on a client-chosen ephemeral 984 identifier). 986 o Optional length-hiding and anti-amplification padding. 988 o Source validation (cookie-based) 990 4.8.3. Protocol Dependencies 992 o An unreliable transport protocol such as UDP. 994 4.9. MinimalT 996 MinimalT is a UDP-based transport security protocol designed to offer 997 confidentiality, mutual authentication, DoS prevention, and 998 connection mobility [MinimalT]. One major goal of the protocol is to 999 leverage existing protocols to obtain server-side configuration 1000 information used to more quickly bootstrap a connection. MinimalT 1001 uses a variant of TCP's congestion control algorithm. 1003 4.9.1. Protocol Description 1005 MinimalT is a secure transport protocol built on top of a widespread 1006 directory service. Clients and servers interact with local directory 1007 services to (a) resolve server information and (b) publish ephemeral 1008 state information, respectively. Clients connect to a local resolver 1009 once at boot time. Through this resolver they recover the IP 1010 address(es) and public key(s) of each server to which they want to 1011 connect. 1013 Connections are instances of user-authenticated, mobile sessions 1014 between two endpoints. Connections run within tunnels between hosts. 1015 A tunnel is a server-authenticated container that multiplexes 1016 multiple connections between the same hosts. All connections in a 1017 tunnel share the same transport state machine and encryption. Each 1018 tunnel has a dedicated control connection used to configure and 1019 manage the tunnel over time. Moreover, since tunnels are independent 1020 of the network address information, they may be reused as both ends 1021 of the tunnel move about the network. This does however imply that 1022 connection establishment and packet encryption mechanisms are 1023 coupled. 1025 Before a client connects to a remote service, it must first establish 1026 a tunnel to the host providing or offering the service. Tunnels are 1027 established in 1-RTT using an ephemeral key obtained from the 1028 directory service. Tunnel initiators provide their own ephemeral key 1029 and, optionally, a DoS puzzle solution such that the recipient 1030 (server) can verify the authenticity of the request and derive a 1031 shared secret. Within a tunnel, new connections to services may be 1032 established. 1034 Additional (orthogonal) transport features include: connection 1035 multiplexing between hosts across shared tunnels, and congestion 1036 control state is shared across connections between the same host 1037 pairs. 1039 4.9.2. Protocol Features 1041 o Record or datagram confidentiality and integrity. 1043 o Forward-secure session key establishment. 1045 o Peer authentication (public-key). 1047 o Unilateral responder authentication. 1049 o DoS mitigation (puzzle-based). 1051 o Out-of-order receipt record. 1053 o Connection mobility (based on tunnel identifiers). 1055 4.9.3. Protocol Dependencies 1057 o An unreliable transport protocol such as UDP. 1059 o A DNS-like resolution service to obtain location information (an 1060 IP address) and ephemeral keys. 1062 o A PKI trust store for certificate validation. 1064 4.10. OpenVPN 1066 OpenVPN [OpenVPN] is a commonly used protocol designed as an 1067 alternative to IPsec. A major goal of this protocol is to provide a 1068 VPN that is simple to configure and works over a variety of 1069 transports. OpenVPN encapsulates either IP packets or Ethernet 1070 frames within a secure tunnel and can run over UDP or TCP. 1072 4.10.1. Protocol Description 1074 OpenVPN facilitates authentication using either a pre-shared static 1075 key or using X.509 certificates and TLS. In pre-shared key mode, 1076 OpenVPN derives keys for encryption and authentication directly from 1077 one or multiple symmetric keys. In TLS mode, OpenVPN encapsulates a 1078 TLS handshake, in which both peers must present a certificate for 1079 authentication. After the handshake, both sides contribute random 1080 source material to derive keys for encryption and authentication 1081 using the TLS pseudo random function (PRF). OpenVPN provides the 1082 possibility to authenticate and encrypt the TLS handshake itself 1083 using a pre-shared key or passphrase. Furthermore, it supports 1084 rekeying using TLS. 1086 After authentication and key exchange, OpenVPN encrypts payload data, 1087 i.e., IP packets or Ethernet frames, and authenticates the payload 1088 using HMAC. Applications can select an arbitrary encryption 1089 algorithm (cipher) and key size, as well hash function for HMAC. The 1090 default cipher and hash functions are AES-GCM and SHA1, respectively. 1091 Recent versions of the protocol support cipher negotiation. 1093 OpenVPN can run over TCP or UDP. When running over UDP, OpenVPN 1094 provides a simple reliability layer for control packets such as the 1095 TLS handshake and key exchange. It assigns sequence numbers to 1096 packets, acknowledges packets it receives, and retransmits packets it 1097 deems lost. Similar to DTLS, this reliability layer is not used for 1098 data packets, which prevents the problem of two reliability 1099 mechanisms being encapsulated within each other. When running over 1100 TCP, OpenVPN includes the packet length in the header, which allows 1101 the peer to deframe the TCP stream into messages. 1103 For replay protection, OpenVPN assigns an identifier to each outgoing 1104 packet, which is unique for the packet and the currently used key. 1105 In pre-shared key mode or with a CFB or OFB mode cipher, OpenVPN 1106 combines a timestamp with an incrementing sequence number into a 1107 64-bit identifier. In TLS mode with CBC cipher mode, OpenVPN omits 1108 the timestamp, so identifiers are only 32-bit. This is sufficient 1109 since OpenVPN can guarantee the uniqueness of this identifier for 1110 each key, as it can trigger rekeying if needed. 1112 OpenVPN supports connection mobility by allowing a peer to change its 1113 IP address during an ongoing session. When configured accordingly, a 1114 host will accept authenticated packets for a session from any IP 1115 address. 1117 4.10.2. Protocol Features 1119 o Peer authentication using certificates or pre-shared key. 1121 o Mandatory mutual authentication. 1123 o Connection mobility. 1125 o Out-of-order record receipt. 1127 o Length-hiding padding. 1129 See also the properties of TLS. 1131 4.10.3. Protocol Dependencies 1133 o For control packets such as handshake and key exchange: Reliable, 1134 in-order transport. Reliability is provided either by TCP, or by 1135 OpenVPN's own reliability layer when using UDP. 1137 5. Security Features and Application Dependencies 1139 There exists a common set of features shared across the transport 1140 protocols surveyed in this document. Mandatory features constitute a 1141 baseline of functionality that an application may assume for any 1142 Transport Services implementation. They were selected on the basis 1143 that they are either (a) required for any secure transport protocol 1144 or (b) nearly ubiquitous amongst common secure transport protocols. 1146 Optional features by contrast may vary from implementation to 1147 implementation, and so an application cannot simply assume they are 1148 available. Applications learn of and use optional features by 1149 querying for their presence and support. Optional features may not 1150 be implemented, or may be disabled if their presence impacts 1151 transport services or if a necessary transport service or application 1152 dependency is unavailable. 1154 In this context, an application dependency is an aspect of the 1155 security feature which can be exposed to the application. An 1156 application dependency may be required for the security feature to 1157 function, or it may provide additional information and control to the 1158 application. For example, an application may need to provide 1159 information such as keying material or authentication credentials, or 1160 it may want to restrict which cryptographic algorithms to allow for 1161 negotiation. 1163 5.1. Mandatory Features 1165 Mandatory features must be supported regardless of transport and 1166 application services available. Note that not all mandatory features 1167 are provided by each surveyed protocol above. For example, tcpcrypt 1168 does not provide responder authentication and CurveCP does not 1169 provide forward-secure session key establishment. 1171 o Record or datagram confidentiality and integrity. 1173 * Application dependency: None. 1175 o Forward-secure session key establishment. 1177 * Application dependency: None. 1179 o Unilateral responder authentication. 1181 * (Optional) Application dependency: Application-provided trust 1182 information. System trust stores may also be used to 1183 authenticate responders. 1185 5.2. Optional Features 1187 In this section we list optional features along with their necessary 1188 application dependencies, if any. 1190 o Pre-shared key support (PSK): 1192 * Application dependency: Application provisioning and 1193 distribution of pre-shared keys. 1195 o Mutual authentication (MA): 1197 * Application dependency: Mutual authentication credentials 1198 required. 1200 o Cryptographic algorithm negotiation (AN): 1202 * Application dependency: Application awareness of supported or 1203 desired algorithms. 1205 o Application authentication delegation (AD): 1207 * Application dependency: Application opt-in and policy for 1208 endpoint authentication. 1210 o DoS mitigation (DM): 1212 * Application dependency: None. 1214 o Connection mobility (CM): 1216 * Application dependency: None. 1218 o Source validation (SV): 1220 * Application dependency: None. 1222 o Application-layer feature negotiation (AFN): 1224 * Application dependency: Specification of application-layer 1225 features or functionality. 1227 o Configuration extensions (CX): 1229 * Application dependency: Specification of application-specific 1230 extensions. 1232 o Session caching and management (SC): 1234 * Application dependency: None. 1236 o Length-hiding padding (LHP): (Optional) Application dependency: 1237 Knowledge of desired padding policies. Some protocols, such as 1238 IKE, can negotiate application-agnostic padding policies. 1240 o Early data support (ED): 1242 * Application dependency: Anti-replay protections or hints of 1243 data idempotency. 1245 o Record replay prevention (RP): 1247 * Application dependency: None. 1249 o Out-of-order receipt record (OO): 1251 * Application dependency: None. 1253 5.3. Optional Feature Availability 1255 The following table lists the availability of the above-listed 1256 optional features in each of the analyzed protocols. "Mandatory" 1257 indicates that the feature is intrinsic to the protocol and cannot be 1258 disabled. "Supported" indicates that the feature is optionally 1259 provided natively or through a (standardized, where applicable) 1260 extension. 1262 +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+ 1263 | Pro | P | A | A | M | D | C | S | A | CX | SC | LH | ED | RP | OO | 1264 | toc | S | N | D | A | M | M | V | F | | | P | | | | 1265 | ol | K | | | | | | | N | | | | | | | 1266 +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+ 1267 | TLS | S | S | S | S | S | U | M | S | S | S | S | S | U | U | 1268 | | | | | | | * | | | | | | | | | 1269 | | | | | | | | | | | | | | | | 1270 | DTL | S | S | S | S | S | S | M | S | S | S | S | U | M | M | 1271 | S | | | | | | | | | | | | | | | 1272 | | | | | | | | | | | | | | | | 1273 | QUI | S | S | S | S | S | S | M | S | S | S | S | S | M | M | 1274 | C | | | | | | | | | | | | | | | 1275 | | | | | | | | | | | | | | | | 1276 | IKE | S | S | S | M | S | S | M | S | S | S | S | U | M | M | 1277 | v2+ | | | | | | | | | | | | | | | 1278 | ESP | | | | | | | | | | | | | | | 1279 | | | | | | | | | | | | | | | | 1280 | SRT | S | S | S | S | S | U | M | S | S | S | U | U | M | M | 1281 | P+D | | | | | | | | | | | | | | | 1282 | TLS | | | | | | | | | | | | | | | 1283 | | | | | | | | | | | | | | | | 1284 | tcp | U | S | M | U | U | U | M | U | U | S | U | U | U | U | 1285 | cry | | | | | * | * | | | | | | | | | 1286 | pt | | | | | * | | | | | | | | | | 1287 | | | | | | | | | | | | | | | | 1288 | Wir | S | U | S | M | S | U | M | U | U | U | S+ | U | M | M | 1289 | eGu | | | | | | | | | | | | | | | 1290 | ard | | | | | | | | | | | | | | | 1291 | | | | | | | | | | | | | | | | 1292 | Min | U | U | U | M | S | M | M | U | U | U | S | U | U | U | 1293 | ima | | | | | | | | | | | | | | | 1294 | lT | | | | | | | | | | | | | | | 1295 | | | | | | | | | | | | | | | | 1296 | Cur | U | U | U | S | S | M | M | U | U | U | S | U | M | M | 1297 | veC | | | | | | | | | | | | | | | 1298 | P | | | | | | | | | | | | | | | 1299 +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+ 1301 M=Mandatory S=Supported but not required U=Unsupported *=On TCP; 1302 MPTCP would provide this ability **=TCP provides SYN cookies 1303 natively, but these are not cryptographically strong +=For transport 1304 packets only 1306 6. Transport Security Protocol Interfaces 1308 This section describes the interface surface exposed by the security 1309 protocols described above. Note that not all protocols support each 1310 interface. We partition these interfaces into pre-connection 1311 (configuration), connection, and post-connection interfaces, 1312 following conventions in [I-D.ietf-taps-interface] and 1313 [I-D.ietf-taps-arch]. 1315 6.1. Pre-Connection Interfaces 1317 Configuration interfaces are used to configure the security protocols 1318 before a handshake begins or the keys are negotiated. 1320 o Identities and Private Keys The application can provide its 1321 identities (certificates) and private keys, or mechanisms to 1322 access these, to the security protocol to use during handshakes. 1323 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, 1324 WireGuard, SRTP 1326 o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) 1327 The application can choose the algorithms that are supported for 1328 key exchange, signatures, and ciphersuites. Protocols: TLS, DTLS, 1329 QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP 1331 o Extensions (Application-Layer Protocol Negotiation): The 1332 application enables or configures extensions that are to be 1333 negotiated by the security protocol, such as ALPN [RFC7301]. 1334 Protocols: TLS, DTLS, QUIC + TLS 1336 o Session Cache Management The application provides the ability to 1337 save and retrieve session state (such as tickets, keying material, 1338 and server parameters) that may be used to resume the security 1339 session. Protocols: TLS, DTLS, QUIC + TLS, MinimalT 1341 o Authentication Delegation The application provides access to a 1342 separate module that will provide authentication, using EAP for 1343 example. Protocols: IKEv2, SRTP 1345 o Pre-Shared Key Import Either the handshake protocol or the 1346 application directly can supply pre-shared keys for the record 1347 protocol use for encryption/decryption and authentication. If the 1348 application can supply keys directly, this is considered explicit 1349 import; if the handshake protocol traditionally provides the keys 1350 directly, it is considered direct import; if the keys can only be 1351 shared by the handshake, they are considered non-importable. 1353 * Explict import: QUIC, ESP 1354 * Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard 1356 * Non-importable: CurveCP 1358 6.2. Connection Interfaces 1360 o Identity Validation During a handshake, the security protocol will 1361 conduct identity validation of the peer. This can call into the 1362 application to offload validation. Protocols: All (TLS, DTLS, 1363 QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) 1365 o Source Address Validation The handshake protocol may delegate 1366 validation of the remote peer that has sent data to the transport 1367 protocol or application. This involves sending a cookie exchange 1368 to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard 1370 6.3. Post-Connection Interfaces 1372 o Connection Termination The security protocol may be instructed to 1373 tear down its connection and session information. This is needed 1374 by some protocols to prevent application data truncation attacks. 1375 Protocols: TLS, DTLS, QUIC, tcpcrypt, IKEv2, MinimalT 1377 o Key Update The handshake protocol may be instructed to update its 1378 keying material, either by the application directly or by the 1379 record protocol sending a key expiration event. Protocols: TLS, 1380 DTLS, QUIC, tcpcrypt, IKEv2, MinimalT 1382 o Pre-Shared Key Export The handshake protocol will generate one or 1383 more keys to be used for record encryption/decryption and 1384 authentication. These may be explicitly exportable to the 1385 application, traditionally limited to direct export to the record 1386 protocol, or inherently non-exportable because the keys must be 1387 used directly in conjunction with the record protocol. 1389 * Explicit export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for 1390 SRTP) 1392 * Direct export: TLS, DTLS, MinimalT 1394 * Non-exportable: CurveCP 1396 o Key Expiration The record protocol can signal that its keys are 1397 expiring due to reaching a time-based deadline, or a use-based 1398 deadline (number of bytes that have been encrypted with the key). 1399 This interaction is often limited to signaling between the record 1400 layer and the handshake layer. Protocols: ESP ((Editor's note: 1401 One may consider TLS/DTLS to also have this interface)) 1403 o Mobility Events The record protocol can be signaled that it is 1404 being migrated to another transport or interface due to connection 1405 mobility, which may reset address and state validation and induce 1406 state changes such as use of a new Connection Identifier (CID). 1407 Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming) 1409 7. IANA Considerations 1411 This document has no request to IANA. 1413 8. Security Considerations 1415 This document summarizes existing transport security protocols and 1416 their interfaces. It does not propose changes to or recommend usage 1417 of reference protocols. Moreover, no claims of security and privacy 1418 properties beyond those guaranteed by the protocols discussed are 1419 made. For example, metadata leakage via timing side channels and 1420 traffic analysis may compromise any protocol discussed in this 1421 survey. Applications using Security Interfaces should take such 1422 limitations into consideration when using a particular protocol 1423 implementation. 1425 9. Privacy Considerations 1427 Analysis of how features improve or degrade privacy is intentionally 1428 omitted from this survey. All security protocols surveyed generally 1429 improve privacy by reducing information leakage via encryption. 1430 However, varying amounts of metadata remain in the clear across each 1431 protocol. For example, client and server certificates are sent in 1432 cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3 1433 [RFC8446]. A survey of privacy features, or lack thereof, for 1434 various security protocols could be addressed in a separate document. 1436 10. Acknowledgments 1438 The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja 1439 Kuehlewind, Yannick Sierra, and Brian Trammell for their input and 1440 feedback on earlier versions of this draft. 1442 11. Informative References 1444 [ALTS] "Application Layer Transport Security", n.d.. 1446 [BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d.. 1448 [Curve25519] 1449 "Curve25519 - new Diffie-Hellman speed records", n.d.. 1451 [CurveCP] "CurveCP -- Usable security for the Internet", n.d.. 1453 [I-D.ietf-quic-tls] 1454 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 1455 draft-ietf-quic-tls-22 (work in progress), July 2019. 1457 [I-D.ietf-quic-transport] 1458 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1459 and Secure Transport", draft-ietf-quic-transport-22 (work 1460 in progress), July 2019. 1462 [I-D.ietf-rtcweb-security-arch] 1463 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 1464 rtcweb-security-arch-20 (work in progress), July 2019. 1466 [I-D.ietf-taps-arch] 1467 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 1468 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for 1469 Transport Services", draft-ietf-taps-arch-04 (work in 1470 progress), July 2019. 1472 [I-D.ietf-taps-interface] 1473 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 1474 Kuehlewind, M., Perkins, C., Tiesel, P., Wood, C., and T. 1475 Pauly, "An Abstract Application Layer Interface to 1476 Transport Services", draft-ietf-taps-interface-04 (work in 1477 progress), July 2019. 1479 [I-D.ietf-taps-minset] 1480 Welzl, M. and S. Gjessing, "A Minimal Set of Transport 1481 Services for End Systems", draft-ietf-taps-minset-11 (work 1482 in progress), September 2018. 1484 [I-D.ietf-tls-dtls-connection-id] 1485 Rescorla, E., Tschofenig, H., and T. Fossati, "Connection 1486 Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- 1487 id-06 (work in progress), July 2019. 1489 [MinimalT] 1490 "MinimaLT -- Minimal-latency Networking Through Better 1491 Security", n.d.. 1493 [Noise] "The Noise Protocol Framework", n.d.. 1495 [OpenVPN] "OpenVPN cryptographic layer", n.d.. 1497 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1498 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1499 1998, . 1501 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 1502 Headers for Low-Speed Serial Links", RFC 2508, 1503 DOI 10.17487/RFC2508, February 1999, 1504 . 1506 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1507 A., Peterson, J., Sparks, R., Handley, M., and E. 1508 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1509 DOI 10.17487/RFC3261, June 2002, 1510 . 1512 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 1513 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 1514 High Delay, Packet Loss and Reordering", RFC 3545, 1515 DOI 10.17487/RFC3545, July 2003, 1516 . 1518 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1519 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1520 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1521 . 1523 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1524 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1525 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1526 . 1528 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1529 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 1530 January 2006, . 1532 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1533 DOI 10.17487/RFC4302, December 2005, 1534 . 1536 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1537 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1538 . 1540 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1541 Authenticated Identity Management in the Session 1542 Initiation Protocol (SIP)", RFC 4474, 1543 DOI 10.17487/RFC4474, August 2006, 1544 . 1546 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1547 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 1548 . 1550 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1551 (TLS) Protocol Version 1.2", RFC 5246, 1552 DOI 10.17487/RFC5246, August 2008, 1553 . 1555 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 1556 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 1557 DOI 10.17487/RFC5723, January 2010, 1558 . 1560 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1561 for Establishing a Secure Real-time Transport Protocol 1562 (SRTP) Security Context Using Datagram Transport Layer 1563 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1564 2010, . 1566 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1567 Security (DTLS) Extension to Establish Keys for the Secure 1568 Real-time Transport Protocol (SRTP)", RFC 5764, 1569 DOI 10.17487/RFC5764, May 2010, 1570 . 1572 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1573 Key Derivation Function (HKDF)", RFC 5869, 1574 DOI 10.17487/RFC5869, May 2010, 1575 . 1577 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1578 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1579 June 2010, . 1581 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1582 Extensions: Extension Definitions", RFC 6066, 1583 DOI 10.17487/RFC6066, January 2011, 1584 . 1586 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 1587 Media Path Key Agreement for Unicast Secure RTP", 1588 RFC 6189, DOI 10.17487/RFC6189, April 2011, 1589 . 1591 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1592 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1593 January 2012, . 1595 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1596 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1597 Transport Layer Security (TLS) and Datagram Transport 1598 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1599 June 2014, . 1601 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1602 Kivinen, "Internet Key Exchange Protocol Version 2 1603 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1604 2014, . 1606 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1607 "Transport Layer Security (TLS) Application-Layer Protocol 1608 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1609 July 2014, . 1611 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1612 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 1613 . 1615 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 1616 Ed., "Services Provided by IETF Transport Protocols and 1617 Congestion Control Mechanisms", RFC 8095, 1618 DOI 10.17487/RFC8095, March 2017, 1619 . 1621 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 1622 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 1623 August 2017, . 1625 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1626 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1627 . 1629 [RFC8449] Thomson, M., "Record Size Limit Extension for TLS", 1630 RFC 8449, DOI 10.17487/RFC8449, August 2018, 1631 . 1633 [RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. 1634 Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547, 1635 DOI 10.17487/RFC8547, May 2019, 1636 . 1638 [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 1639 Q., and E. Smith, "Cryptographic Protection of TCP Streams 1640 (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, 1641 . 1643 [SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated 1644 Diffie-Hellman and Its Use in the IKE-Protocols", n.d.. 1646 [WireGuard] 1647 "WireGuard -- Next Generation Kernel Network Tunnel", 1648 n.d.. 1650 Authors' Addresses 1652 Christopher A. Wood (editor) 1653 Apple Inc. 1654 One Apple Park Way 1655 Cupertino, California 95014 1656 United States of America 1658 Email: cawood@apple.com 1660 Theresa Enghardt 1661 TU Berlin 1662 Marchstr. 23 1663 10587 Berlin 1664 Germany 1666 Email: theresa@inet.tu-berlin.de 1668 Tommy Pauly 1669 Apple Inc. 1670 One Apple Park Way 1671 Cupertino, California 95014 1672 United States of America 1674 Email: tpauly@apple.com 1676 Colin Perkins 1677 University of Glasgow 1678 School of Computing Science 1679 Glasgow G12 8QQ 1680 United Kingdom 1682 Email: csp@csperkins.org 1683 Kyle Rose 1684 Akamai Technologies, Inc. 1685 150 Broadway 1686 Cambridge, MA 02144 1687 United States of America 1689 Email: krose@krose.org