idnits 2.17.1 draft-ietf-taps-transport-security-05.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8095]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 1428: '...g Security Interfaces SHOULD take such...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 26, 2019) is 1885 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-tls-dtls13' is defined on line 1505, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-18 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-18 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-18 == Outdated reference: A later version (-19) exists of draft-ietf-taps-arch-02 == Outdated reference: A later version (-26) exists of draft-ietf-taps-interface-02 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-02 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-30 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 4474 (Obsoleted by RFC 8224) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6347 (Obsoleted by RFC 9147) ** Obsolete normative reference: RFC 7539 (Obsoleted by RFC 8439) ** Obsolete normative reference: RFC 8229 (Obsoleted by RFC 9329) Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 1 comment (--). 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: August 30, 2019 TU Berlin 6 T. Pauly 7 Apple Inc. 8 C. Perkins 9 University of Glasgow 10 K. Rose 11 Akamai Technologies, Inc. 12 February 26, 2019 14 A Survey of Transport Security Protocols 15 draft-ietf-taps-transport-security-05 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 [RFC8095] by 23 describing the interfaces required to add security protocols. It 24 examines Transport Layer Security (TLS), Datagram Transport Layer 25 Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + 26 TLS), tcpcrypt, Internet Key Exchange with Encapsulating Security 27 Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, 28 MinimalT. This survey is not limited to protocols developed within 29 the scope or context of the IETF, and those included represent a 30 superset of features a TAPS system may need to support. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on August 30, 2019. 49 Copyright Notice 51 Copyright (c) 2019 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Security Features . . . . . . . . . . . . . . . . . . . . . . 5 69 4. Transport Security Protocol Descriptions . . . . . . . . . . 7 70 4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 4.1.1. Protocol Description . . . . . . . . . . . . . . . . 7 72 4.1.2. Security Features . . . . . . . . . . . . . . . . . . 8 73 4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9 74 4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.2.1. Protocol Description . . . . . . . . . . . . . . . . 9 76 4.2.2. Security Features . . . . . . . . . . . . . . . . . . 10 77 4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 78 4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 11 79 4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11 80 4.3.2. Security Features . . . . . . . . . . . . . . . . . . 11 81 4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 12 82 4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 12 83 4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12 84 4.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 12 85 4.4.2. Security Features . . . . . . . . . . . . . . . . . . 14 86 4.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 14 87 4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 15 88 4.5.1. Protocol description . . . . . . . . . . . . . . . . 15 89 4.5.2. Security Features . . . . . . . . . . . . . . . . . . 16 90 4.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16 91 4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 16 92 4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 17 93 4.6.1. Protocol Description . . . . . . . . . . . . . . . . 17 94 4.6.2. Security Features . . . . . . . . . . . . . . . . . . 18 95 4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18 96 4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18 97 4.7.1. Protocol description . . . . . . . . . . . . . . . . 18 98 4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19 99 4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19 100 4.8. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20 101 4.8.1. Protocol Description . . . . . . . . . . . . . . . . 20 102 4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 21 103 4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 21 104 4.9. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 21 105 4.9.1. Protocol Description . . . . . . . . . . . . . . . . 22 106 4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22 107 4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 23 108 4.10. OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . 23 109 4.10.1. Protocol Description . . . . . . . . . . . . . . . . 23 110 4.10.2. Protocol Features . . . . . . . . . . . . . . . . . 24 111 4.10.3. Protocol Dependencies . . . . . . . . . . . . . . . 24 112 5. Security Features and Application Dependencies . . . . . . . 24 113 5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 25 114 5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 25 115 5.3. Optional Feature Availability . . . . . . . . . . . . . . 27 116 6. Transport Security Protocol Interfaces . . . . . . . . . . . 29 117 6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 29 118 6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 30 119 6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 30 120 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 121 8. Security Considerations . . . . . . . . . . . . . . . . . . . 31 122 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31 123 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 31 124 11. Normative References . . . . . . . . . . . . . . . . . . . . 31 125 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 127 1. Introduction 129 This document provides a survey of commonly used or notable network 130 security protocols, with a focus on how they interact and integrate 131 with applications and transport protocols. Its goal is to supplement 132 efforts to define and catalog transport services [RFC8095] by 133 describing the interfaces required to add security protocols. It 134 examines Transport Layer Security (TLS), Datagram Transport Layer 135 Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + 136 TLS), tcpcrypt, Internet Key Exchange with Encapsulating Security 137 Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and 138 MinimalT. For each protocol, this document provides a brief 139 description, the security features it provides, and the dependencies 140 it has on the underlying transport. This is followed by defining the 141 set of transport security features shared by these protocols. 142 Finally, we distill the application and transport interfaces provided 143 by the transport security protocols. 145 Selected protocols represent a superset of functionality and features 146 a TAPS system may need to support, both internally and externally - 147 via an API - for applications [I-D.ietf-taps-arch]. Ubiquitous IETF 148 protocols such as (D)TLS, as well as non-standard protocols such as 149 Google QUIC, are both included despite overlapping features. As 150 such, this survey is not limited to protocols developed within the 151 scope or context of the IETF. Outside of this candidate set, 152 protocols that do not offer new features are omitted. For example, 153 newer protocols such as WireGuard make unique design choices that 154 have important implications on applications, such as how to best 155 configure peer public keys and to delegate algorithm selection to the 156 system. In contrast, protocols such as ALTS [ALTS] are omitted since 157 they do not represent features deemed unique. 159 Also, authentication-only protocols such as TCP-AO [RFC5925] and 160 IPsec AH [RFC4302] are excluded from this survey. TCP-AO adds 161 authenticity protections to long-lived TCP connections, e.g., replay 162 protection with per-packet Message Authentication Codes. (This 163 protocol obsoletes TCP MD5 "signature" options specified in 164 [RFC2385].) One prime use case of TCP-AO is for protecting BGP 165 connections. Similarly, AH adds per-datagram authenticity and adds 166 similar replay protection. Despite these improvements, neither 167 protocol sees general use and both lack critical properties important 168 for emergent transport security protocols: confidentiality, privacy 169 protections, and agility. Thus, we omit these and related protocols 170 from our survey. 172 2. Terminology 174 The following terms are used throughout this document to describe the 175 roles and interactions of transport security protocols: 177 o Transport Feature: a specific end-to-end feature that the 178 transport layer provides to an application. Examples include 179 confidentiality, reliable delivery, ordered delivery, message- 180 versus-stream orientation, etc. 182 o Transport Service: a set of Transport Features, without an 183 association to any given framing protocol, which provides 184 functionality to an application. 186 o Transport Protocol: an implementation that provides one or more 187 different transport services using a specific framing and header 188 format on the wire. A Transport Protocol services an application. 190 o Application: an entity that uses a transport protocol for end-to- 191 end delivery of data across the network. This may also be an 192 upper layer protocol or tunnel encapsulation. 194 o Security Feature: a feature that a network security layer provides 195 to applications. Examples include authentication, encryption, key 196 generation, session resumption, and privacy. Features may be 197 Mandatory or Optional for an application's implementation. 198 Security Features extend the set of Transport Features described 199 in [RFC8095] and provided by Transport Services implementations. 201 o Security Protocol: a defined network protocol that implements one 202 or more security features. Security protocols may be used 203 alongside transport protocols, and in combination with other 204 security protocols when appropriate. 206 o Handshake Protocol: a protocol that enables peers to validate each 207 other and to securely establish shared cryptographic context. 209 o Record: Framed protocol messages. 211 o Record Protocol: a security protocol that allows data to be 212 divided into manageable blocks and protected using shared 213 cryptographic context. 215 o Session: an ephemeral security association between applications. 217 o Cryptographic context: a set of cryptographic parameters, 218 including but not necessarily limited to keys for encryption, 219 authentication, and session resumption, enabling authorized 220 parties to a session to communicate securely. 222 o Connection: the shared state of two or more endpoints that 223 persists across messages that are transmitted between these 224 endpoints. A connection is a transient participant of a session, 225 and a session generally lasts between connection instances. 227 o Peer: an endpoint application party to a session. 229 o Client: the peer responsible for initiating a session. 231 o Server: the peer responsible for responding to a session 232 initiation. 234 3. Security Features 236 In this section, we enumerate Security Features exposed by protocols 237 discussed in the remainder of this document. Protocol security (and 238 privacy) properties that are unrelated to the API surface exposed by 239 such protocols, such as client or server identity hiding, are not 240 listed here as features. 242 o Forward-secure session key establishment: Cryptographic key 243 establishment with forward secure properties. 245 o Cryptographic algorithm negotiation: Negotiate support of protocol 246 algorithms, including: encryption, hash, MAC (PRF), and digital 247 signature algorithms. 249 o Session caching and management: Manage session state cache used 250 for subsequent connections aimed towards amortizing connection 251 establishment costs. 253 o Peer authentication (certificate, raw public key, pre-shared key, 254 or EAP-based): Peer authentication using select or protocol- 255 specific mechanisms. 257 o Unilateral responder authentication: Required authentication for 258 the responder of a connection. 260 o Mutual authentication: Connection establishment wherein both 261 endpoints are authenticated. 263 o Application authentication delegation: Out-of-band peer 264 authentication performed by applications outside of the connection 265 establishment. 267 o Record (channel or datagram) confidentiality and integrity: 268 Encryption and authentication of application plaintext bytes sent 269 between peers over a channel or in individual datagrams. 271 o Partial record confidentiality: Encryption of some portion of 272 records. 274 o Optional record integrity: Optional authentication of certain 275 records. 277 o Record replay prevention: Protocol detection and defense against 278 record replays, e.g., due to in-network retransmissions. 280 o Early data support (starting with TLS 1.3): Transmission of 281 application data prior to connection (handshake) establishment. 283 o Connection mobility: a property of a connection that allows it to 284 be multihomed or resilient across network interface or address 285 changes, e.g., NAT rebindings that occur without an endpoint's 286 knowledge. Mobility allows cryptographic key material and other 287 state information to be reused in the event of a connection 288 change. 290 o Application-layer feature negotiation: Securely negotiate 291 application-specific functionality, including those necessary for 292 connection handling and management, e.g., the TLS parent 293 connection protocol type via ALPN [RFC7301] or desired application 294 identity via SNI [RFC6066]. 296 o Configuration extensions: Add protocol features via extensions or 297 configuration options. TLS extensions are a primary example of 298 this feature. 300 o Out-of-order record receipt: Processing of records received out- 301 of-order. 303 o Source validation (cookie or puzzle based): Peer source validation 304 and DoS mitigation via explicit proof of origin (cookie) or work 305 mechanisms (puzzles). 307 o Length-hiding padding: Protocol-drive record padding aimed at 308 hiding plaintext message length and mitigating amplification 309 attack vectors. 311 4. Transport Security Protocol Descriptions 313 This section contains descriptions of security protocols currently 314 used to protect data being sent over a network. 316 For each protocol, we describe its provided features and dependencies 317 on other protocols. 319 4.1. TLS 321 TLS (Transport Layer Security) [RFC5246] is a common protocol used to 322 establish a secure session between two endpoints. Communication over 323 this session "prevents eavesdropping, tampering, and message 324 forgery." TLS consists of a tightly coupled handshake and record 325 protocol. The handshake protocol is used to authenticate peers, 326 negotiate protocol options, such as cryptographic algorithms, and 327 derive session-specific keying material. The record protocol is used 328 to marshal (possibly encrypted) data from one peer to the other. 329 This data may contain handshake messages or raw application data. 331 4.1.1. Protocol Description 333 TLS is the composition of a handshake and record protocol 334 [I-D.ietf-tls-tls13]. The record protocol is designed to marshal an 335 arbitrary, in-order stream of bytes from one endpoint to the other. 336 It handles segmenting, compressing (when enabled), and encrypting 337 data into discrete records. When configured to use an authenticated 338 encryption with associated data (AEAD) algorithm, it also handles 339 nonce generation and encoding for each record. The record protocol 340 is hidden from the client behind a bytestream-oriented API. 342 The handshake protocol serves several purposes, including: peer 343 authentication, protocol option (key exchange algorithm and 344 ciphersuite) negotiation, and key derivation. Peer authentication 345 may be mutual; however, commonly, only the server is authenticated. 346 X.509 certificates are commonly used in this authentication step, 347 though other mechanisms, such as raw public keys [RFC7250], exist. 348 The client is not authenticated unless explicitly requested by the 349 server. 351 The handshake protocol is also extensible. It allows for a variety 352 of extensions to be included by either the client or server. These 353 extensions are used to specify client preferences, e.g., the 354 application-layer protocol to be driven with the TLS connection 355 [RFC7301], or signals to the server to aid operation, e.g., Server 356 Name Indication (SNI) [RFC6066]. Various extensions also exist to 357 tune the parameters of the record protocol, e.g., the maximum 358 fragment length [RFC6066] and record size limit 359 [I-D.ietf-tls-record-limit]. 361 Alerts are used to convey errors and other atypical events to the 362 endpoints. There are two classes of alerts: closure and error 363 alerts. A closure alert is used to signal to the other peer that the 364 sender wishes to terminate the connection. The sender typically 365 follows a close alert with a TCP FIN segment to close the connection. 366 Error alerts are used to indicate problems with the handshake or 367 individual records. Most errors are fatal and are followed by 368 connection termination. However, warning alerts may be handled at 369 the discretion of the implementation. 371 Once a session is disconnected all session keying material must be 372 destroyed, with the exception of secrets previously established 373 expressly for purposes of session resumption. TLS supports stateful 374 and stateless resumption. (Here, "state" refers to bookkeeping on a 375 per-session basis by the server. It is assumed that the client must 376 always store some state information in order to resume a session.) 378 4.1.2. Security Features 380 o Forward-secure session key establishment. 382 o Cryptographic algorithm negotiation. 384 o Stateful and stateless cross-connection session resumption. 386 o Session caching and management. 388 o Peer authentication (Certificate, raw public key, and pre-shared 389 key). 391 o Unilateral responder authentication. 393 o Mutual authentication. 395 o Application authentication delegation. 397 o Record (channel) confidentiality and integrity. 399 o Record replay prevention. 401 o Application-layer feature negotiation. 403 o Configuration extensions. 405 o Early data support (starting with TLS 1.3). 407 o Optional record-layer padding (starting with TLS 1.3). 409 4.1.3. Protocol Dependencies 411 o TCP for in-order, reliable transport. 413 o (Optionally) A PKI trust store for certificate validation. 415 4.2. DTLS 417 DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, 418 but differs in that it is designed to run over UDP instead of TCP. 419 Since UDP does not guarantee datagram ordering or reliability, DTLS 420 modifies the protocol to make sure it can still provide the same 421 security guarantees as TLS. DTLS was designed to be as close to TLS 422 as possible, so this document will assume that all properties from 423 TLS are carried over except where specified. 425 4.2.1. Protocol Description 427 DTLS is modified from TLS to operate with the possibility of packet 428 loss, reordering, and duplication that may occur when operating over 429 UDP. To enable out-of-order delivery of application data, the DTLS 430 record protocol itself has no inter-record dependencies. However, as 431 the handshake requires reliability, each handshake message is 432 assigned an explicit sequence number to enable retransmissions of 433 lost packets and in-order processing by the receiver. Handshake 434 message loss is remedied by sender retransmission after a 435 configurable period in which the expected response has not yet been 436 received. 438 As the DTLS handshake protocol runs atop the record protocol, to 439 account for long handshake messages that cannot fit within a single 440 record, DTLS supports fragmentation and subsequent reconstruction of 441 handshake messages across records. The receiver must reassemble 442 records before processing. 444 DTLS relies on unique UDP 4-tuples to identify connections. Since 445 all application-layer data is encrypted, demultiplexing over the same 446 4-tuple requires the use of a connection identifier extension 447 [I-D.ietf-tls-dtls-connection-id] to permit identification of the 448 correct connection-specific cryptographic context without the use of 449 trial decryption. (Note that this extension is only supported in 450 DTLS 1.2 and 1.3 {{I-D.ietf-tls-dtls13}.) 452 Since datagrams can be replayed, DTLS provides optional anti-replay 453 detection based on a window of acceptable sequence numbers [RFC6347]. 455 4.2.2. Security Features 457 o Record replay protection. 459 o Record (datagram) confidentiality and integrity. 461 o Out-of-order record receipt. 463 o DoS mitigation (cookie-based). 465 See also the features from TLS. 467 4.2.3. Protocol Dependencies 469 o DTLS relies on UDP. 471 o The DTLS record protocol explicitly encodes record lengths, so 472 although it runs over a datagram transport, it does not rely on 473 the transport protocol's framing beyond requiring transport-level 474 reconstruction of datagrams fragmented over packets. (Note: DTLS 475 1.3 short header records omit the explicit length field.) 477 o UDP 4-tuple uniqueness, or the connection identifier extension, 478 for demultiplexing. 480 o Path MTU discovery. 482 o For the handshake: Reliable, in-order transport. DTLS provides 483 its own reliability. 485 4.3. (IETF) QUIC with TLS 487 QUIC (Quick UDP Internet Connections) is a new standards-track 488 transport protocol that runs over UDP, loosely based on Google's 489 original proprietary gQUIC protocol [I-D.ietf-quic-transport]. (See 490 Section 4.3.4 for more details.) The QUIC transport layer itself 491 provides support for data confidentiality and integrity. This 492 requires keys to be derived with a separate handshake protocol. A 493 mapping for QUIC over TLS 1.3 [I-D.ietf-quic-tls] has been specified 494 to provide this handshake. 496 4.3.1. Protocol Description 498 As QUIC relies on TLS to secure its transport functions, it creates 499 specific integration points between its security and transport 500 functions: 502 o Starting the handshake to generate keys and provide authentication 503 (and providing the transport for the handshake). 505 o Client address validation. 507 o Key ready events from TLS to notify the QUIC transport. 509 o Exporting secrets from TLS to the QUIC transport. 511 The QUIC transport layer support multiple streams over a single 512 connection. QUIC implements a record protocol for TLS handshake 513 messages to establish a connection. These messages are sent in 514 special INITIAL and CRYPTO frames [I-D.ietf-quic-transport], types of 515 which are encrypted using different keys. INITIAL frames are 516 encrypted using "fixed" keys derived from the QUIC version and public 517 packet information (Connection ID). CRYPTO frames are encrypted 518 using TLS handshake secrets. Once TLS completes, QUIC uses the 519 resultant traffic secrets to for the QUIC connection to protect the 520 rest of the streams. QUIC supports 0-RTT (early) data using 521 previously negotiated connection secrets. Early data is sent in 522 0-RTT packets, which may be included in the same datagram as the 523 Initial and Handshake packets. 525 4.3.2. Security Features 527 o DoS mitigation (cookie-based). 529 See also the properties of TLS. 531 4.3.3. Protocol Dependencies 533 o QUIC transport relies on UDP. 535 o QUIC transport relies on TLS 1.3 for key exchange, peer 536 authentication, and shared secret derivation. 538 o For the handshake: Reliable, in-order transport. QUIC provides 539 its own reliability. 541 4.3.4. Variant: Google QUIC 543 Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol 544 designed and deployed by Google following experience from deploying 545 SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally 546 known as "QUIC": this document uses gQUIC to unambiguously 547 distinguish it from the standards-track IETF QUIC. The proprietary 548 technical forebear of IETF QUIC, gQUIC was originally designed with 549 tightly-integrated security and application data transport protocols. 551 4.4. IKEv2 with ESP 553 IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec 554 protocol suite that encrypts and authenticates IP packets, either for 555 creating tunnels (tunnel-mode) or for direct transport connections 556 (transport-mode). This suite of protocols separates out the key 557 generation protocol (IKEv2) from the transport encryption protocol 558 (ESP). Each protocol can be used independently, but this document 559 considers them together, since that is the most common pattern. 561 4.4.1. Protocol descriptions 563 4.4.1.1. IKEv2 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.1.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.1.2. ESP 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.2. Security Features 633 4.4.2.1. IKEv2 635 o Forward-secure session key establishment. 637 o Cryptographic algorithm negotiation. 639 o Peer authentication (certificate, raw public key, pre-shared key, 640 and EAP). 642 o Unilateral responder authentication. 644 o Mutual authentication. 646 o Record (datagram) confidentiality and integrity. 648 o Session resumption. 650 o Connection mobility. 652 o DoS mitigation (cookie-based). 654 4.4.2.2. ESP 656 o Record confidentiality and integrity. 658 o Record replay protection. 660 4.4.3. Protocol Dependencies 662 4.4.3.1. IKEv2 664 o Availability of UDP to negotiate, or implementation support for 665 TCP-encapsulation. 667 o Some EAP authentication types require accessing a hardware device, 668 such as a SIM card; or interacting with a user, such as password 669 prompting. 671 4.4.3.2. ESP 673 o Since ESP is below transport protocols, it does not have any 674 dependencies on the transports themselves, other than on UDP or 675 TCP where encapsulation is employed. 677 4.5. Secure RTP (with DTLS) 679 Secure RTP (SRTP) is a profile for RTP that provides confidentiality, 680 message authentication, and replay protection for RTP data packets 681 and RTP control protocol (RTCP) packets [RFC3711]. 683 4.5.1. Protocol description 685 SRTP adds confidentiality and optional integrity protection to RTP 686 data packets, and adds confidentially and mandatory integrity 687 protection to RTCP packets. For RTP data packets, this is done by 688 encrypting the payload section of the packet and optionally appending 689 an authentication tag (MAC) as a packet trailer, with the RTP header 690 authenticated but not encrypted (the RTP header was left unencrypted 691 to enable RTP header compression [RFC2508] [RFC3545]). For RTCP 692 packets, the first packet in the compound RTCP packet is partially 693 encrypted, leaving the first eight octets of the header as clear-text 694 to allow identification of the packet as RTCP, while the remainder of 695 the compound packet is fully encrypted. The entire RTCP packet is 696 then authenticated by appending a MAC as packet trailer. 698 Packets are encrypted using session keys, which are ultimately 699 derived from a master key and an additional master salt and session 700 salt. SRTP packets carry a 2-byte sequence number to partially 701 identify the unique packet index. SRTP peers maintain a separate 702 roll-over counter (ROC) for RTP data packets that is incremented 703 whenever the sequence number wraps. The sequence number and ROC 704 together determine the packet index. RTCP packets have a similar, 705 yet differently named, field called the RTCP index which serves the 706 same purpose. 708 Numerous encryption modes are supported. For popular modes of 709 operation, e.g., AES-CTR, the (unique) initialization vector (IV) 710 used for each encryption mode is a function of the RTP SSRC 711 (synchronization source), packet index, and session "salting key". 713 SRTP offers replay detection by keeping a replay list of already seen 714 and processed packet indices. If a packet arrives with an index that 715 matches one in the replay list, it is silently discarded. 717 DTLS [RFC5764] is commonly used to perform mutual authentication and 718 key agreement for SRTP [RFC5763]. Peers use DTLS to perform mutual 719 certificate-based authentication on the media path, and to generate 720 the SRTP master key. Peer certificates can be issued and signed by a 721 certificate authority. Alternatively, certificates used in the DTLS 722 exchange can be self-signed. If they are self-signed, certificate 723 fingerprints are included in the signalling exchange (e.g., in SIP or 724 WebRTC), and used to bind the DTLS key exchange in the media plane to 725 the signaling plane. The combination of a mutually authenticated 726 DTLS key exchange on the media path and a fingerprint sent in the 727 signalling channel protects against active attacks on the media, 728 provided the signalling can be trusted. Signalling needs to be 729 protected as described in, for example, SIP [RFC3261] Authenticated 730 Identity Management [RFC4474] or the WebRTC security architecture 731 [I-D.ietf-rtcweb-security-arch], to provide complete system security. 733 4.5.2. Security Features 735 o Forward-secure session key establishment. 737 o Cryptographic algorithm negotiation. 739 o Mutual authentication. 741 o Partial datagram confidentiality. (Packet headers are not 742 encrypted.) 744 o Optional authentication of data packets. 746 o Mandatory authentication of control packets. 748 o Out-of-order record receipt. 750 4.5.3. Protocol Dependencies 752 o Secure RTP can run over UDP or TCP. 754 o External key derivation and management protocol, e.g., DTLS 755 [RFC5763]. 757 o External identity management protocol, e.g., SIP Authenticated 758 Identity Management [RFC4474], WebRTC Security Architecture 759 [I-D.ietf-rtcweb-security-arch]. 761 4.5.4. Variant: ZRTP for Media Path Key Agreement 763 ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It 764 uses standard SRTP to protect RTP data packets and RTCP packets, but 765 provides alternative key agreement and identity management protocols. 767 Key agreement is performed using a Diffie-Hellman key exchange that 768 runs on the media path. This generates a shared secret that is then 769 used to generate the master key and salt for SRTP. 771 ZRTP does not rely on a PKI or external identity management system. 772 Rather, it uses an ephemeral Diffie-Hellman key exchange with hash 773 commitment to allow detection of man-in-the-middle attacks. This 774 requires endpoints to display a short authentication string that the 775 users must read and verbally compare to validate the hashes and 776 ensure security. Endpoints cache some key material after the first 777 call to use in subsequent calls; this is mixed in with the Diffie- 778 Hellman shared secret, so the short authentication string need only 779 be checked once for a given user. This gives key continuity 780 properties analogous to the secure shell (ssh) [RFC4253]. 782 4.6. tcpcrypt 784 Tcpcrypt is a lightweight extension to the TCP protocol for 785 opportunistic encryption. Applications may use tcpcrypt's unique 786 session ID for further application-level authentication. Absent this 787 authentication, tcpcrypt is vulnerable to active attacks. 789 4.6.1. Protocol Description 791 Tcpcrypt extends TCP to enable opportunistic encryption between the 792 two ends of a TCP connection [I-D.ietf-tcpinc-tcpcrypt]. It is a 793 family of TCP encryption protocols (TEP), distinguished by key 794 exchange algorithm. The use of a TEP is negotiated with a TCP option 795 during the initial TCP handshake via the mechanism described by TCP 796 Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the 797 case of initial session establishment, once a tcpcrypt TEP has been 798 negotiated the key exchange occurs within the data segments of the 799 first few packets exchanged after the handshake completes. The 800 initiator of a connection sends a list of supported AEAD algorithms, 801 a random nonce, and an ephemeral public key share. The responder 802 typically chooses a mutually-supported AEAD algorithm and replies 803 with this choice, its own nonce, and ephemeral key share. An initial 804 shared secret is derived from the ENO handshake, the tcpcrypt 805 handshake, and the initial keying material resulting from the key 806 exchange. The traffic encryption keys on the initial connection are 807 derived from the shared secret. Connections can be re-keyed before 808 the natural AEAD limit for a single set of traffic encryption keys is 809 reached. 811 Each tcpcrypt session is associated with a ladder of resumption IDs, 812 each derived from the respective entry in a ladder of shared secrets. 813 These resumption IDs can be used to negotiate a stateful resumption 814 of the session in a subsequent connection, resulting in use of a new 815 shared secret and traffic encryption keys without requiring a new key 816 exchange. Willingness to resume a session is signaled via the ENO 817 option during the TCP handshake. Given the length constraints 818 imposed by TCP options, unlike stateless resumption mechanisms (such 819 as that provided by session tickets in TLS) resumption in tcpcrypt 820 requires the maintenance of state on the server, and so successful 821 resumption across a pool of servers implies shared state. 823 Owing to middlebox ossification issues, tcpcrypt only protects the 824 payload portion of a TCP packet. It does not encrypt any header 825 information, such as the TCP sequence number. 827 4.6.2. Security Features 829 o Forward-secure session key establishment. 831 o Record (channel) confidentiality and integrity. 833 o Stateful cross-connection session resumption. 835 o Session caching and management. 837 o Application authentication delegation. 839 4.6.3. Protocol Dependencies 841 o TCP. 843 o TCP Encryption Negotiation Option (ENO). 845 4.7. WireGuard 847 WireGuard is a layer 3 protocol designed as an alternative to IPsec 848 [WireGuard] for certain use cases. It uses UDP to encapsulate IP 849 datagrams between peers. Unlike most transport security protocols, 850 which rely on PKI for peer authentication, WireGuard authenticates 851 peers using pre-shared public keys delivered out-of-band, each of 852 which is bound to one or more IP addresses. Moreover, as a protocol 853 suited for VPNs, WireGuard offers no extensibility, negotiation, or 854 cryptographic agility. 856 4.7.1. Protocol description 858 WireGuard is a simple VPN protocol that binds a pre-shared public key 859 to one or more IP addresses. Users configure WireGuard by 860 associating peer public keys with IP addresses. These mappings are 861 stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard] 862 for more details and sample configurations.) These keys are used 863 upon WireGuard packet transmission and reception. For example, upon 864 receipt of a Handshake Initiation message, receivers use the static 865 public key in their CryptoKey routing table to perform necessary 866 cryptographic computations. 868 WireGuard builds on Noise [Noise] for 1-RTT key exchange with 869 identity hiding. The handshake hides peer identities as per the 870 SIGMA construction [SIGMA]. As a consequence of using Noise, 871 WireGuard comes with a fixed set of cryptographic algorithms: 873 o x25519 [Curve25519] and HKDF [RFC5869] for ECDH and key 874 derivation. 876 o ChaCha20+Poly1305 [RFC7539] for packet authenticated encryption. 878 o BLAKE2s [BLAKE2] for hashing. 880 There is no cryptographic agility. If weaknesses are found in any of 881 these algorithms, new message types using new algorithms must be 882 introduced. 884 WireGuard is designed to be entirely stateless, modulo the CryptoKey 885 routing table, which has size linear with the number of trusted 886 peers. If a WireGuard receiver is under heavy load and cannot 887 process a packet, e.g., cannot spare CPU cycles for point 888 multiplication, it can reply with a cookie similar to DTLS and IKEv2. 889 This cookie only proves IP address ownership. Any rate limiting 890 scheme can be applied to packets coming from non-spoofed addresses. 892 4.7.2. Security Features 894 o Forward-secure session key establishment. 896 o Peer authentication (public-key and PSK). 898 o Mutual authentication. 900 o Record replay prevention (Stateful, timestamp-based). 902 o DoS mitigation (cookie-based). 904 4.7.3. Protocol Dependencies 906 o Datagram transport. 908 o Out-of-band key distribution and management. 910 4.8. CurveCP 912 CurveCP [CurveCP] is a UDP-based transport security protocol from 913 Daniel J. Bernstein. Unlike other transport security protocols, it 914 is based entirely upon highly efficient public key algorithms. This 915 removes many pitfalls associated with nonce reuse and key 916 synchronization. 918 4.8.1. Protocol Description 920 CurveCP is a UDP-based transport security protocol. It is built on 921 three principal features: exclusive use of public key authenticated 922 encryption of packets, server-chosen cookies to prohibit memory and 923 computation DoS at the server, and connection mobility with a client- 924 chosen ephemeral identifier. 926 There are two rounds in CurveCP. In the first round, the client 927 sends its first initialization packet to the server, carrying its 928 (possibly fresh) ephemeral public key C', with zero-padding encrypted 929 under the server's long-term public key. The server replies with a 930 cookie and its own ephemeral key S' and a cookie that is to be used 931 by the client. Upon receipt, the client then generates its second 932 initialization packet carrying: the ephemeral key C', cookie, and an 933 encryption of C', the server's domain name, and, optionally, some 934 message data. The server verifies the cookie and the encrypted 935 payload and, if valid, proceeds to send data in return. At this 936 point, the connection is established and the two parties can 937 communicate. 939 The use of public-key encryption and authentication, or "boxing", 940 simplifies problems that come with symmetric key management and nonce 941 synchronization. For example, it allows the sender of a message to 942 be in complete control of each message's nonce. It does not require 943 either end to share secret keying material. Furthermore, it allows 944 connections (or sessions) to be associated with unique ephemeral 945 public keys as a mechanism for enabling forward secrecy given the 946 risk of long-term private key compromise. 948 The client and server do not perform a standard key exchange. 949 Instead, in the initial exchange of packets, each party provides its 950 own ephemeral key to the other end. The client can choose a new 951 ephemeral key for every new connection. However, the server must 952 rotate these keys on a slower basis. Otherwise, it would be trivial 953 for an attacker to force the server to create and store ephemeral 954 keys with a fake client initialization packet. 956 Servers use cookies for source validation. After receiving a 957 client's initial packet, encrypted under the server's long-term 958 public key, a server generates and returns a stateless cookie that 959 must be echoed back in the client's following message. This cookie 960 is encrypted under the client's ephemeral public key. This stateless 961 technique prevents attackers from hijacking client initialization 962 packets to obtain cookie values to flood clients. (A client would 963 detect the duplicate cookies and reject the flooded packets.) 964 Similarly, replaying the client's second packet, carrying the cookie, 965 will be detected by the server. 967 CurveCP supports client authentication by allowing clients to send 968 their long-term public keys in the second initialization packet. A 969 server can verify this public key and, if untrusted, drop the 970 connection and subsequent data. 972 Unlike some other protocols, CurveCP data packets leave only the 973 ephemeral public key, connection ID, and per-message nonce in the 974 clear. All other data is encrypted. 976 4.8.2. Protocol Features 978 o Datagram confidentiality and integrity (via public key 979 encryption). 981 o Peer authentication (public-key). 983 o Unilateral responder authentication. 985 o Mutual authentication. 987 o Connection mobility (based on a client-chosen ephemeral 988 identifier). 990 o Optional length-hiding and anti-amplification padding. 992 o Source validation (cookie-based) 994 4.8.3. Protocol Dependencies 996 o An unreliable transport protocol such as UDP. 998 4.9. MinimalT 1000 MinimalT is a UDP-based transport security protocol designed to offer 1001 confidentiality, mutual authentication, DoS prevention, and 1002 connection mobility [MinimalT]. One major goal of the protocol is to 1003 leverage existing protocols to obtain server-side configuration 1004 information used to more quickly bootstrap a connection. MinimalT 1005 uses a variant of TCP's congestion control algorithm. 1007 4.9.1. Protocol Description 1009 MinimalT is a secure transport protocol built on top of a widespread 1010 directory service. Clients and servers interact with local directory 1011 services to (a) resolve server information and (b) publish ephemeral 1012 state information, respectively. Clients connect to a local resolver 1013 once at boot time. Through this resolver they recover the IP 1014 address(es) and public key(s) of each server to which they want to 1015 connect. 1017 Connections are instances of user-authenticated, mobile sessions 1018 between two endpoints. Connections run within tunnels between hosts. 1019 A tunnel is a server-authenticated container that multiplexes 1020 multiple connections between the same hosts. All connections in a 1021 tunnel share the same transport state machine and encryption. Each 1022 tunnel has a dedicated control connection used to configure and 1023 manage the tunnel over time. Moreover, since tunnels are independent 1024 of the network address information, they may be reused as both ends 1025 of the tunnel move about the network. This does however imply that 1026 connection establishment and packet encryption mechanisms are 1027 coupled. 1029 Before a client connects to a remote service, it must first establish 1030 a tunnel to the host providing or offering the service. Tunnels are 1031 established in 1-RTT using an ephemeral key obtained from the 1032 directory service. Tunnel initiators provide their own ephemeral key 1033 and, optionally, a DoS puzzle solution such that the recipient 1034 (server) can verify the authenticity of the request and derive a 1035 shared secret. Within a tunnel, new connections to services may be 1036 established. 1038 Additional (orthogonal) transport features include: connection 1039 multiplexing between hosts across shared tunnels, and congestion 1040 control state is shared across connections between the same host 1041 pairs. 1043 4.9.2. Protocol Features 1045 o Record or datagram confidentiality and integrity. 1047 o Forward-secure session key establishment. 1049 o Peer authentication (public-key). 1051 o Unilateral responder authentication. 1053 o DoS mitigation (puzzle-based). 1055 o Out-of-order receipt record. 1057 o Connection mobility (based on tunnel identifiers). 1059 4.9.3. Protocol Dependencies 1061 o An unreliable transport protocol such as UDP. 1063 o A DNS-like resolution service to obtain location information (an 1064 IP address) and ephemeral keys. 1066 o A PKI trust store for certificate validation. 1068 4.10. OpenVPN 1070 OpenVPN [OpenVPN] is a commonly used protocol designed as an 1071 alternative to IPsec. A major goal of this protocol is to provide a 1072 VPN that is simple to configure and works over a variety of 1073 transports. OpenVPN encapsulates either IP packets or Ethernet 1074 frames within a secure tunnel and can run over UDP or TCP. 1076 4.10.1. Protocol Description 1078 OpenVPN facilitates authentication using either a pre-shared static 1079 key or using X.509 certificates and TLS. In pre-shared key mode, 1080 OpenVPN derives keys for encryption and authentication directly from 1081 one or multiple symmetric keys. In TLS mode, OpenVPN encapsulates a 1082 TLS handshake, in which both peers must present a certificate for 1083 authentication. After the handshake, both sides contribute random 1084 source material to derive keys for encryption and authentication 1085 using the TLS pseudo random function (PRF). OpenVPN provides the 1086 possibility to authenticate and encrypt the TLS handshake itself 1087 using a pre-shared key or passphrase. Furthermore, it supports 1088 rekeying using TLS. 1090 After authentication and key exchange, OpenVPN encrypts payload data, 1091 i.e., IP packets or Ethernet frames, and signs the payload using an 1092 HMAC function. The default cipher is BlowFish [BlowFish] and the 1093 default message digest algorithm is SHA1, but an application can 1094 select an arbitrary cipher, key size, and message digest algorithm 1095 for the HMAC. OpenVPN peers support cipher negotiation (NCP) since 1096 version 2.4, in which case they will upgrade the cipher to AES- 1097 256-GCM by default. 1099 OpenVPN can run over TCP or UDP. When running over UDP, OpenVPN 1100 provides a simple reliability layer for control packets such as the 1101 TLS handshake and key exchange. It assigns sequence numbers to 1102 packets, acknowledges packets it receives, and retransmits packets it 1103 deems lost. Similar to DTLS, this reliability layer is not used for 1104 data packets, which prevents the problem of two reliability 1105 mechanisms being encapsulated within each other. When running over 1106 TCP, OpenVPN includes the packet length in the header, which allows 1107 the peer to deframe the TCP stream into messages. 1109 For replay protection, OpenVPN assigns an identifier to each outgoing 1110 packet, which is unique for the packet and the currently used key. 1111 In pre-shared key mode or with a CFB or OFB mode cipher, OpenVPN 1112 combines a timestamp with an incrementing sequence number into a 1113 64-bit identifier. In TLS mode with CBC cipher mode, OpenVPN omits 1114 the timestamp, so identifiers are only 32-bit. This is sufficient 1115 since OpenVPN can guarantee the uniqueness of this identifier for 1116 each key, as it can trigger rekeying if needed. 1118 OpenVPN supports connection mobility by allowing a peer to change its 1119 IP address during an ongoing session. When configured accordingly, a 1120 host will accept authenticated packets for a session from any IP 1121 address. 1123 4.10.2. Protocol Features 1125 o Peer authentication using certificates or pre-shared key. 1127 o Mandatory mutual authentication. 1129 o Connection mobility. 1131 o Out-of-order record receipt. 1133 o Length-hiding padding. 1135 See also the properties of TLS. 1137 4.10.3. Protocol Dependencies 1139 o For control packets such as handshake and key exchange: Reliable, 1140 in-order transport. Reliability is provided either by TCP, or by 1141 OpenVPN's own reliability layer when using UDP. 1143 5. Security Features and Application Dependencies 1145 There exists a common set of features shared across the transport 1146 protocols surveyed in this document. Mandatory features constitute a 1147 baseline of functionality that an application may assume for any TAPS 1148 implementation. They were selected on the basis that they are either 1149 (a) required for any secure transport protocol or (b) nearly 1150 ubiquitous amongst common secure transport protocols. 1152 Optional features by contrast may vary from implementation to 1153 implementation, and so an application cannot simply assume they are 1154 available. Applications learn of and use optional features by 1155 querying for their presence and support. Optional features may not 1156 be implemented, or may be disabled if their presence impacts 1157 transport services or if a necessary transport service or application 1158 dependency is unavailable. 1160 In this context, an application dependency is an aspect of the 1161 security feature which can be exposed to the application. An 1162 application dependency may be required for the security feature to 1163 function, or it may provide additional information and control to the 1164 application. For example, an application may need to provide 1165 information such as keying material or authentication credentials, or 1166 it may want to restrict which cryptographic algorithms to allow for 1167 negotiation. 1169 5.1. Mandatory Features 1171 Mandatory features must be supported regardless of transport and 1172 application services available. Note that not all mandatory features 1173 are provided by each surveyed protocol above. For example, tcpcrypt 1174 does not provide responder authentication and CurveCP does not 1175 provide forward-secure session key establishment. 1177 o Record or datagram confidentiality and integrity. 1179 * Application dependency: None. 1181 o Forward-secure session key establishment. 1183 * Application dependency: None. 1185 o Unilateral responder authentication. 1187 * (Optional) Application dependency: Application-provided trust 1188 information. System trust stores may also be used to 1189 authenticate responders. 1191 5.2. Optional Features 1193 In this section we list optional features along with their necessary 1194 application dependencies, if any. 1196 o Pre-shared key support (PSK): 1198 * Application dependency: Application provisioning and 1199 distribution of pre-shared keys. 1201 o Mutual authentication (MA): 1203 * Application dependency: Mutual authentication credentials 1204 required. 1206 o Cryptographic algorithm negotiation (AN): 1208 * Application dependency: Application awareness of supported or 1209 desired algorithms. 1211 o Application authentication delegation (AD): 1213 * Application dependency: Application opt-in and policy for 1214 endpoint authentication. 1216 o DoS mitigation (DM): 1218 * Application dependency: None. 1220 o Connection mobility (CM): 1222 * Application dependency: None. 1224 o Source validation (SV): 1226 * Application dependency: None. 1228 o Application-layer feature negotiation (AFN): 1230 * Application dependency: Specification of application-layer 1231 features or functionality. 1233 o Configuration extensions (CX): 1235 * Application dependency: Specification of application-specific 1236 extensions. 1238 o Session caching and management (SC): 1240 * Application dependency: None. 1242 o Length-hiding padding (LHP): (Optional) Application dependency: 1243 Knowledge of desired padding policies. Some protocols, such as 1244 IKE, can negotiate application-agnostic padding policies. 1246 o Early data support (ED): 1248 * Application dependency: Anti-replay protections or hints of 1249 data idempotency. 1251 o Record replay prevention (RP): 1253 * Application dependency: None. 1255 o Out-of-order receipt record (OO): 1257 * Application dependency: None. 1259 5.3. Optional Feature Availability 1261 The following table lists the availability of the above-listed 1262 optional features in each of the analyzed protocols. "Mandatory" 1263 indicates that the feature is intrinsic to the protocol and cannot be 1264 disabled. "Supported" indicates that the feature is optionally 1265 provided natively or through a (standardized, where applicable) 1266 extension. 1268 +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+ 1269 | Pro | P | A | A | M | D | C | S | A | CX | SC | LH | ED | RP | OO | 1270 | toc | S | N | D | A | M | M | V | F | | | P | | | | 1271 | ol | K | | | | | | | N | | | | | | | 1272 +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+ 1273 | TLS | S | S | S | S | S | U | M | S | S | S | S | S | U | U | 1274 | | | | | | | * | | | | | | | | | 1275 | | | | | | | | | | | | | | | | 1276 | DTL | S | S | S | S | S | S | M | S | S | S | S | U | M | M | 1277 | S | | | | | | | | | | | | | | | 1278 | | | | | | | | | | | | | | | | 1279 | IET | S | S | S | S | S | S | M | S | S | S | S | S | M | M | 1280 | F Q | | | | | | | | | | | | | | | 1281 | UIC | | | | | | | | | | | | | | | 1282 | | | | | | | | | | | | | | | | 1283 | IKE | S | S | S | M | S | S | M | S | S | S | S | U | M | M | 1284 | v2+ | | | | | | | | | | | | | | | 1285 | ESP | | | | | | | | | | | | | | | 1286 | | | | | | | | | | | | | | | | 1287 | SRT | S | S | S | S | S | U | M | S | S | S | U | U | M | M | 1288 | P+D | | | | | | | | | | | | | | | 1289 | TLS | | | | | | | | | | | | | | | 1290 | | | | | | | | | | | | | | | | 1291 | tcp | U | S | M | U | U | U | M | U | U | S | U | U | U | U | 1292 | cry | | | | | * | * | | | | | | | | | 1293 | pt | | | | | * | | | | | | | | | | 1294 | | | | | | | | | | | | | | | | 1295 | Wir | S | U | S | M | S | U | M | U | U | U | S+ | U | M | M | 1296 | eGu | | | | | | | | | | | | | | | 1297 | ard | | | | | | | | | | | | | | | 1298 | | | | | | | | | | | | | | | | 1299 | Min | U | U | U | M | S | M | M | U | U | U | S | U | U | U | 1300 | ima | | | | | | | | | | | | | | | 1301 | lT | | | | | | | | | | | | | | | 1302 | | | | | | | | | | | | | | | | 1303 | Cur | U | U | U | S | S | M | M | U | U | U | S | U | M | M | 1304 | veC | | | | | | | | | | | | | | | 1305 | P | | | | | | | | | | | | | | | 1306 +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+ 1308 M=Mandatory S=Supported but not required U=Unsupported *=On TCP; 1309 MPTCP would provide this ability **=TCP provides SYN cookies 1310 natively, but these are not cryptographically strong +=For transport 1311 packets only 1313 6. Transport Security Protocol Interfaces 1315 This section describes the interface surface exposed by the security 1316 protocols described above. Note that not all protocols support each 1317 interface. We partition these interfaces into pre-connection 1318 (configuration), connection, and post-connection interfaces, 1319 following conventions in [I-D.ietf-taps-interface] and 1320 [I-D.ietf-taps-arch]. 1322 6.1. Pre-Connection Interfaces 1324 Configuration interfaces are used to configure the security protocols 1325 before a handshake begins or the keys are negotiated. 1327 o Identities and Private Keys The application can provide its 1328 identities (certificates) and private keys, or mechanisms to 1329 access these, to the security protocol to use during handshakes. 1330 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, 1331 WireGuard, SRTP 1333 o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) 1334 The application can choose the algorithms that are supported for 1335 key exchange, signatures, and ciphersuites. Protocols: TLS, DTLS, 1336 QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP 1338 o Extensions (Application-Layer Protocol Negotiation): The 1339 application enables or configures extensions that are to be 1340 negotiated by the security protocol, such as ALPN [RFC7301]. 1341 Protocols: TLS, DTLS, QUIC + TLS 1343 o Session Cache Management The application provides the ability to 1344 save and retrieve session state (such as tickets, keying material, 1345 and server parameters) that may be used to resume the security 1346 session. Protocols: TLS, DTLS, QUIC + TLS, MinimalT 1348 o Authentication Delegation The application provides access to a 1349 separate module that will provide authentication, using EAP for 1350 example. Protocols: IKEv2, SRTP 1352 o Pre-Shared Key Import Either the handshake protocol or the 1353 application directly can supply pre-shared keys for the record 1354 protocol use for encryption/decryption and authentication. If the 1355 application can supply keys directly, this is considered explicit 1356 import; if the handshake protocol traditionally provides the keys 1357 directly, it is considered direct import; if the keys can only be 1358 shared by the handshake, they are considered non-importable. 1360 * Explict import: QUIC, ESP 1361 * Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard 1363 * Non-importable: CurveCP 1365 6.2. Connection Interfaces 1367 o Identity Validation During a handshake, the security protocol will 1368 conduct identity validation of the peer. This can call into the 1369 application to offload validation. Protocols: All (TLS, DTLS, 1370 QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) 1372 o Source Address Validation The handshake protocol may delegate 1373 validation of the remote peer that has sent data to the transport 1374 protocol or application. This involves sending a cookie exchange 1375 to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard 1377 6.3. Post-Connection Interfaces 1379 o Connection Termination The security protocol may be instructed to 1380 tear down its connection and session information. This is needed 1381 by some protocols to prevent application data truncation attacks. 1382 Protocols: TLS, DTLS, QUIC, tcpcrypt, IKEv2, MinimalT 1384 o Key Update The handshake protocol may be instructed to update its 1385 keying material, either by the application directly or by the 1386 record protocol sending a key expiration event. Protocols: TLS, 1387 DTLS, QUIC, tcpcrypt, IKEv2, MinimalT 1389 o Pre-Shared Key Export The handshake protocol will generate one or 1390 more keys to be used for record encryption/decryption and 1391 authentication. These may be explicitly exportable to the 1392 application, traditionally limited to direct export to the record 1393 protocol, or inherently non-exportable because the keys must be 1394 used directly in conjunction with the record protocol. 1396 * Explicit export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for 1397 SRTP) 1399 * Direct export: TLS, DTLS, MinimalT 1401 * Non-exportable: CurveCP 1403 o Key Expiration The record protocol can signal that its keys are 1404 expiring due to reaching a time-based deadline, or a use-based 1405 deadline (number of bytes that have been encrypted with the key). 1406 This interaction is often limited to signaling between the record 1407 layer and the handshake layer. Protocols: ESP ((Editor's note: 1408 One may consider TLS/DTLS to also have this interface)) 1410 o Mobility Events The record protocol can be signaled that it is 1411 being migrated to another transport or interface due to connection 1412 mobility, which may reset address and state validation and induce 1413 state changes such as use of a new Connection Identifier (CID). 1414 Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming) 1416 7. IANA Considerations 1418 This document has no request to IANA. 1420 8. Security Considerations 1422 This document summarizes existing transport security protocols and 1423 their interfaces. It does not propose changes to or recommend usage 1424 of reference protocols. Moreover, no claims of security and privacy 1425 properties beyond those guaranteed by the protocols discussed are 1426 made. For example, metadata leakage via timing side channels and 1427 traffic analysis may compromise any protocol discussed in this 1428 survey. Applications using Security Interfaces SHOULD take such 1429 limitations into consideration when using a particular protocol 1430 implementation. 1432 9. Privacy Considerations 1434 Analysis of how features improve or degrade privacy is intentionally 1435 omitted from this survey. All security protocols surveyed generally 1436 improve privacy by reducing information leakage via encryption. 1437 However, varying amounts of metadata remain in the clear across each 1438 protocol. For example, client and server certificates are sent in 1439 cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3 1440 [RFC8446]. A survey of privacy features, or lack thereof, for 1441 various security protocols could be addressed in a separate document. 1443 10. Acknowledgments 1445 The authors would like to thank Bob Bradley, Theresa Enghardt, 1446 Frederic Jacobs, Mirja Kuehlewind, Yannick Sierra, and Brian Trammell 1447 for their input and feedback on earlier versions of this draft. 1449 11. Normative References 1451 [ALTS] "Application Layer Transport Security", n.d.. 1453 [BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d.. 1455 [BlowFish] 1456 "The Blowfish Encryption Algorithm", n.d.. 1458 [Curve25519] 1459 "Curve25519 - new Diffie-Hellman speed records", n.d.. 1461 [CurveCP] "CurveCP -- Usable security for the Internet", n.d.. 1463 [I-D.ietf-quic-tls] 1464 Thomson, M. and S. Turner, "Using TLS to Secure QUIC", 1465 draft-ietf-quic-tls-18 (work in progress), January 2019. 1467 [I-D.ietf-quic-transport] 1468 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1469 and Secure Transport", draft-ietf-quic-transport-18 (work 1470 in progress), January 2019. 1472 [I-D.ietf-rtcweb-security-arch] 1473 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 1474 rtcweb-security-arch-18 (work in progress), February 2019. 1476 [I-D.ietf-taps-arch] 1477 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 1478 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for 1479 Transport Services", draft-ietf-taps-arch-02 (work in 1480 progress), October 2018. 1482 [I-D.ietf-taps-interface] 1483 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 1484 Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An 1485 Abstract Application Layer Interface to Transport 1486 Services", draft-ietf-taps-interface-02 (work in 1487 progress), October 2018. 1489 [I-D.ietf-tcpinc-tcpcrypt] 1490 Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 1491 Q., and E. Smith, "Cryptographic protection of TCP Streams 1492 (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-15 (work in 1493 progress), December 2018. 1495 [I-D.ietf-tcpinc-tcpeno] 1496 Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. 1497 Smith, "TCP-ENO: Encryption Negotiation Option", draft- 1498 ietf-tcpinc-tcpeno-19 (work in progress), June 2018. 1500 [I-D.ietf-tls-dtls-connection-id] 1501 Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, 1502 "Connection Identifiers for DTLS 1.2", draft-ietf-tls- 1503 dtls-connection-id-02 (work in progress), October 2018. 1505 [I-D.ietf-tls-dtls13] 1506 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1507 Datagram Transport Layer Security (DTLS) Protocol Version 1508 1.3", draft-ietf-tls-dtls13-30 (work in progress), 1509 November 2018. 1511 [I-D.ietf-tls-record-limit] 1512 Thomson, M., "Record Size Limit Extension for Transport 1513 Layer Security (TLS)", draft-ietf-tls-record-limit-03 1514 (work in progress), May 2018. 1516 [I-D.ietf-tls-tls13] 1517 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1518 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 1519 March 2018. 1521 [MinimalT] 1522 "MinimaLT -- Minimal-latency Networking Through Better 1523 Security", n.d.. 1525 [Noise] "The Noise Protocol Framework", n.d.. 1527 [OpenVPN] "OpenVPN cryptographic layer", n.d.. 1529 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1530 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1531 1998, . 1533 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 1534 Headers for Low-Speed Serial Links", RFC 2508, 1535 DOI 10.17487/RFC2508, February 1999, 1536 . 1538 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1539 A., Peterson, J., Sparks, R., Handley, M., and E. 1540 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1541 DOI 10.17487/RFC3261, June 2002, 1542 . 1544 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 1545 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 1546 High Delay, Packet Loss and Reordering", RFC 3545, 1547 DOI 10.17487/RFC3545, July 2003, 1548 . 1550 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1551 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1552 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1553 . 1555 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1556 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1557 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1558 . 1560 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1561 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 1562 January 2006, . 1564 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1565 DOI 10.17487/RFC4302, December 2005, 1566 . 1568 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1569 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1570 . 1572 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1573 Authenticated Identity Management in the Session 1574 Initiation Protocol (SIP)", RFC 4474, 1575 DOI 10.17487/RFC4474, August 2006, 1576 . 1578 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1579 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 1580 . 1582 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1583 (TLS) Protocol Version 1.2", RFC 5246, 1584 DOI 10.17487/RFC5246, August 2008, 1585 . 1587 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 1588 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 1589 DOI 10.17487/RFC5723, January 2010, 1590 . 1592 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1593 for Establishing a Secure Real-time Transport Protocol 1594 (SRTP) Security Context Using Datagram Transport Layer 1595 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1596 2010, . 1598 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1599 Security (DTLS) Extension to Establish Keys for the Secure 1600 Real-time Transport Protocol (SRTP)", RFC 5764, 1601 DOI 10.17487/RFC5764, May 2010, 1602 . 1604 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1605 Key Derivation Function (HKDF)", RFC 5869, 1606 DOI 10.17487/RFC5869, May 2010, 1607 . 1609 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1610 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1611 June 2010, . 1613 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1614 Extensions: Extension Definitions", RFC 6066, 1615 DOI 10.17487/RFC6066, January 2011, 1616 . 1618 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 1619 Media Path Key Agreement for Unicast Secure RTP", 1620 RFC 6189, DOI 10.17487/RFC6189, April 2011, 1621 . 1623 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1624 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1625 January 2012, . 1627 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1628 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1629 Transport Layer Security (TLS) and Datagram Transport 1630 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1631 June 2014, . 1633 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1634 Kivinen, "Internet Key Exchange Protocol Version 2 1635 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1636 2014, . 1638 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1639 "Transport Layer Security (TLS) Application-Layer Protocol 1640 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1641 July 2014, . 1643 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1644 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 1645 . 1647 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 1648 Ed., "Services Provided by IETF Transport Protocols and 1649 Congestion Control Mechanisms", RFC 8095, 1650 DOI 10.17487/RFC8095, March 2017, 1651 . 1653 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 1654 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 1655 August 2017, . 1657 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1658 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1659 . 1661 [SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated 1662 Diffie-Hellman and Its Use in the IKE-Protocols", n.d.. 1664 [WireGuard] 1665 "WireGuard -- Next Generation Kernel Network Tunnel", 1666 n.d.. 1668 Authors' Addresses 1670 Christopher A. Wood (editor) 1671 Apple Inc. 1672 One Apple Park Way 1673 Cupertino, California 95014 1674 United States of America 1676 Email: cawood@apple.com 1678 Theresa Enghardt 1679 TU Berlin 1680 Marchstr. 23 1681 10587 Berlin 1682 Germany 1684 Email: theresa@inet.tu-berlin.de 1686 Tommy Pauly 1687 Apple Inc. 1688 One Apple Park Way 1689 Cupertino, California 95014 1690 United States of America 1692 Email: tpauly@apple.com 1693 Colin Perkins 1694 University of Glasgow 1695 School of Computing Science 1696 Glasgow G12 8QQ 1697 United Kingdom 1699 Email: csp@csperkins.org 1701 Kyle Rose 1702 Akamai Technologies, Inc. 1703 150 Broadway 1704 Cambridge, MA 02144 1705 United States of America 1707 Email: krose@krose.org