idnits 2.17.1 draft-ietf-taps-transport-security-04.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 1302: '...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 (November 05, 2018) is 1998 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-tls-dtls13' is defined on line 1377, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-16 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-16 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-16 == 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 (-15) exists of draft-ietf-tcpinc-tcpcrypt-14 == 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-29 ** 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 (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Pauly 3 Internet-Draft Apple Inc. 4 Intended status: Informational C. Perkins 5 Expires: May 9, 2019 University of Glasgow 6 K. Rose 7 Akamai Technologies, Inc. 8 C. Wood 9 Apple Inc. 10 November 05, 2018 12 A Survey of Transport Security Protocols 13 draft-ietf-taps-transport-security-04 15 Abstract 17 This document provides a survey of commonly used or notable network 18 security protocols, with a focus on how they interact and integrate 19 with applications and transport protocols. Its goal is to supplement 20 efforts to define and catalog transport services [RFC8095] by 21 describing the interfaces required to add security protocols. It 22 examines Transport Layer Security (TLS), Datagram Transport Layer 23 Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + 24 TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with 25 Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and 26 WireGuard. This survey is not limited to protocols developed within 27 the scope or context of the IETF, and those included represent a 28 superset of features a TAPS system may need to support. 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 http://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 May 9, 2019. 47 Copyright Notice 49 Copyright (c) 2018 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Transport Security Protocol Descriptions . . . . . . . . . . 7 68 4.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 4.1.1. Protocol Description . . . . . . . . . . . . . . . . 7 70 4.1.2. Security Features . . . . . . . . . . . . . . . . . . 8 71 4.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 9 72 4.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 4.2.1. Protocol Description . . . . . . . . . . . . . . . . 9 74 4.2.2. Security Features . . . . . . . . . . . . . . . . . . 10 75 4.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 76 4.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 10 77 4.3.1. Protocol Description . . . . . . . . . . . . . . . . 11 78 4.3.2. Security Features . . . . . . . . . . . . . . . . . . 11 79 4.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 11 80 4.3.4. Variant: Google QUIC . . . . . . . . . . . . . . . . 11 81 4.4. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 12 82 4.4.1. Protocol descriptions . . . . . . . . . . . . . . . . 12 83 4.4.2. Security Features . . . . . . . . . . . . . . . . . . 13 84 4.4.3. Protocol Dependencies . . . . . . . . . . . . . . . . 14 85 4.5. Secure RTP (with DTLS) . . . . . . . . . . . . . . . . . 14 86 4.5.1. Protocol description . . . . . . . . . . . . . . . . 14 87 4.5.2. Security Features . . . . . . . . . . . . . . . . . . 15 88 4.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 16 89 4.5.4. Variant: ZRTP for Media Path Key Agreement . . . . . 16 90 4.6. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 16 91 4.6.1. Protocol Description . . . . . . . . . . . . . . . . 16 92 4.6.2. Security Features . . . . . . . . . . . . . . . . . . 17 93 4.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 18 94 4.7. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 18 95 4.7.1. Protocol description . . . . . . . . . . . . . . . . 18 96 4.7.2. Security Features . . . . . . . . . . . . . . . . . . 19 97 4.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 19 98 4.8. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 19 99 4.8.1. Protocol Description . . . . . . . . . . . . . . . . 19 100 4.8.2. Protocol Features . . . . . . . . . . . . . . . . . . 20 101 4.8.3. Protocol Dependencies . . . . . . . . . . . . . . . . 20 102 4.9. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 20 103 4.9.1. Protocol Description . . . . . . . . . . . . . . . . 20 104 4.9.2. Protocol Features . . . . . . . . . . . . . . . . . . 22 105 4.9.3. Protocol Dependencies . . . . . . . . . . . . . . . . 22 106 5. Security Features and Transport Dependencies . . . . . . . . 22 107 5.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 22 108 5.2. Optional Features . . . . . . . . . . . . . . . . . . . . 23 109 5.3. Optional Feature Availability . . . . . . . . . . . . . . 24 110 6. Transport Security Protocol Interfaces . . . . . . . . . . . 26 111 6.1. Pre-Connection Interfaces . . . . . . . . . . . . . . . . 26 112 6.2. Connection Interfaces . . . . . . . . . . . . . . . . . . 27 113 6.3. Post-Connection Interfaces . . . . . . . . . . . . . . . 27 114 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 115 8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 116 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 28 117 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 118 11. Normative References . . . . . . . . . . . . . . . . . . . . 28 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33 121 1. Introduction 123 This document provides a survey of commonly used or notable network 124 security protocols, with a focus on how they interact and integrate 125 with applications and transport protocols. Its goal is to supplement 126 efforts to define and catalog transport services [RFC8095] by 127 describing the interfaces required to add security protocols. It 128 examines Transport Layer Security (TLS), Datagram Transport Layer 129 Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + 130 TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with 131 Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and 132 WireGuard. For each protocol, this document provides a brief 133 description, the security features it provides, and the dependencies 134 it has on the underlying transport. This is followed by defining the 135 set of transport security features shared by these protocols. 136 Finally, we distill the application and transport interfaces provided 137 by the transport security protocols. 139 Selected protocols represent a superset of functionality and features 140 a TAPS system may need to support, both internally and externally - 141 via an API - for applications [I-D.ietf-taps-arch]. Ubiquitous IETF 142 protocols such as (D)TLS, as well as non-standard protocols such as 143 Google QUIC, are both included despite overlapping features. As 144 such, this survey is not limited to protocols developed within the 145 scope or context of the IETF. Outside of this candidate set, 146 protocols that do not offer new features are omitted. For example, 147 newer protocols such as WireGuard make unique design choices that 148 have important implications on applications, such as how to best 149 configure peer public keys and to delegate algorithm selection to the 150 system. In contrast, protocols such as ALTS [ALTS] are omitted since 151 they do not represent features deemed unique. 153 Also, authentication-only protocols such as TCP-AO [RFC5925] and 154 IPsec AH [RFC4302] are excluded from this survey. TCP-AO adds 155 authenticity protections to long-lived TCP connections, e.g., replay 156 protection with per-packet Message Authentication Codes. (This 157 protocol obsoletes TCP MD5 "signature" options specified in 158 [RFC2385].) One prime use case of TCP-AO is for protecting BGP 159 connections. Similarly, AH adds per-datagram authenticity and adds 160 similar replay protection. Despite these improvements, neither 161 protocol sees general use and both lack critical properties important 162 for emergent transport security protocols: confidentiality, privacy 163 protections, and agility. Thus, we omit these and related protocols 164 from our survey. 166 2. Terminology 168 The following terms are used throughout this document to describe the 169 roles and interactions of transport security protocols: 171 o Transport Feature: a specific end-to-end feature that the 172 transport layer provides to an application. Examples include 173 confidentiality, reliable delivery, ordered delivery, message- 174 versus-stream orientation, etc. 176 o Transport Service: a set of Transport Features, without an 177 association to any given framing protocol, which provides 178 functionality to an application. 180 o Transport Protocol: an implementation that provides one or more 181 different transport services using a specific framing and header 182 format on the wire. A Transport Protocol services an application. 184 o Application: an entity that uses a transport protocol for end-to- 185 end delivery of data across the network. This may also be an 186 upper layer protocol or tunnel encapsulation. 188 o Security Feature: a feature that a network security layer provides 189 to applications. Examples include authentication, encryption, key 190 generation, session resumption, and privacy. Features may be 191 Mandatory or Optional for an application's implementation. 192 Security Features extend the set of Transport Features described 193 in [RFC8095] and provided by Transport Services implementations. 195 o Security Protocol: a defined network protocol that implements one 196 or more security features. Security protocols may be used 197 alongside transport protocols, and in combination with other 198 security protocols when appropriate. 200 o Handshake Protocol: a protocol that enables peers to validate each 201 other and to securely establish shared cryptographic context. 203 o Record: Framed protocol messages. 205 o Record Protocol: a security protocol that allows data to be 206 divided into manageable blocks and protected using shared 207 cryptographic context. 209 o Session: an ephemeral security association between applications. 211 o Cryptographic context: a set of cryptographic parameters, 212 including but not necessarily limited to keys for encryption, 213 authentication, and session resumption, enabling authorized 214 parties to a session to communicate securely. 216 o Connection: the shared state of two or more endpoints that 217 persists across messages that are transmitted between these 218 endpoints. A connection is a transient participant of a session, 219 and a session generally lasts between connection instances. 221 o Peer: an endpoint application party to a session. 223 o Client: the peer responsible for initiating a session. 225 o Server: the peer responsible for responding to a session 226 initiation. 228 3. Security Features 230 In this section, we enumerate Security Features exposed by protocols 231 discussed in the remainder of this document. Protocol security (and 232 privacy) properties that are unrelated to the API surface exposed by 233 such protocols, such as client or server identity hiding, are not 234 listed here as features. 236 o Forward-secure key establishment: Cryptographic key establishment 237 with forward secure properties. 239 o Cryptographic algorithm negotiation: Negotiate support of protocol 240 algorithms, including: encryption, hash, MAC (PRF), and digital 241 signature algorithms. 243 o Session caching and management: Manage session state cache used 244 for subsequent connections aimed towards amortizing connection 245 establishment costs. 247 o Peer authentication (certificate, raw public key, pre-shared key, 248 or EAP-based): Peer authentication using select or protocol- 249 specific mechanisms. 251 o Mutual authentication: Connection establishment wherein both 252 endpoints are authenticated. 254 o Application-layer authentication delegation: Out-of-band peer 255 authentication performed by applications outside of the connection 256 establishment. 258 o Record (channel or datagram) confidentiality and integrity: 259 Encryption and authentication of application plaintext bytes sent 260 between peers over a channel or in individual datagrams. 262 o Partial record confidentiality: Encryption of some portion of 263 records. 265 o Optional record integrity: Optional authentication of certain 266 records. 268 o Record replay prevention: Protocol detection and defense against 269 record replays, e.g., due to in-network retransmissions. 271 o Early data support (starting with TLS 1.3): Transmission of 272 application data prior to connection (handshake) establishment. 274 o Connection mobility: a property of a connection that allows it to 275 be multihomed or resilient across network interface or address 276 changes, e.g., NAT rebindings that occur without an endpoint's 277 knowledge. Mobility allows cryptographic key material and other 278 state information to be reused in the event of a connection 279 change. 281 o Application-layer feature negotiation: Securely negotiate 282 application-specific functionality, including those necessary for 283 connection handling and management, e.g., the TLS parent 284 connection protocol type via ALPN [RFC7301] or desired application 285 identity via SNI [RFC6066]. 287 o Configuration extensions: Add protocol features via extensions or 288 configuration options. TLS extensions are a primary example of 289 this feature. 291 o Out-of-order record receipt: Processing of records received out- 292 of-order. 294 o Source validation (cookie or puzzle based): Peer source validation 295 and DoS mitigation via explicit proof of origin (cookie) or work 296 mechanisms (puzzles). 298 o Length-hiding padding: Protocol-drive record padding aimed at 299 hiding plaintext message length and mitigating amplification 300 attack vectors. 302 4. Transport Security Protocol Descriptions 304 This section contains descriptions of security protocols currently 305 used to protect data being sent over a network. 307 For each protocol, we describe its provided features and dependencies 308 on other protocols. 310 4.1. TLS 312 TLS (Transport Layer Security) [RFC5246] is a common protocol used to 313 establish a secure session between two endpoints. Communication over 314 this session "prevents eavesdropping, tampering, and message 315 forgery." TLS consists of a tightly coupled handshake and record 316 protocol. The handshake protocol is used to authenticate peers, 317 negotiate protocol options, such as cryptographic algorithms, and 318 derive session-specific keying material. The record protocol is used 319 to marshal (possibly encrypted) data from one peer to the other. 320 This data may contain handshake messages or raw application data. 322 4.1.1. Protocol Description 324 TLS is the composition of a handshake and record protocol 325 [I-D.ietf-tls-tls13]. The record protocol is designed to marshal an 326 arbitrary, in-order stream of bytes from one endpoint to the other. 327 It handles segmenting, compressing (when enabled), and encrypting 328 data into discrete records. When configured to use an authenticated 329 encryption with associated data (AEAD) algorithm, it also handles 330 nonce generation and encoding for each record. The record protocol 331 is hidden from the client behind a bytestream-oriented API. 333 The handshake protocol serves several purposes, including: peer 334 authentication, protocol option (key exchange algorithm and 335 ciphersuite) negotiation, and key derivation. Peer authentication 336 may be mutual; however, commonly, only the server is authenticated. 337 X.509 certificates are commonly used in this authentication step, 338 though other mechanisms, such as raw public keys [RFC7250], exist. 339 The client is not authenticated unless explicitly requested by the 340 server. 342 The handshake protocol is also extensible. It allows for a variety 343 of extensions to be included by either the client or server. These 344 extensions are used to specify client preferences, e.g., the 345 application-layer protocol to be driven with the TLS connection 346 [RFC7301], or signals to the server to aid operation, e.g., Server 347 Name Indication (SNI) [RFC6066]. Various extensions also exist to 348 tune the parameters of the record protocol, e.g., the maximum 349 fragment length [RFC6066] and record size limit 350 [I-D.ietf-tls-record-limit]. 352 Alerts are used to convey errors and other atypical events to the 353 endpoints. There are two classes of alerts: closure and error 354 alerts. A closure alert is used to signal to the other peer that the 355 sender wishes to terminate the connection. The sender typically 356 follows a close alert with a TCP FIN segment to close the connection. 357 Error alerts are used to indicate problems with the handshake or 358 individual records. Most errors are fatal and are followed by 359 connection termination. However, warning alerts may be handled at 360 the discretion of the implementation. 362 Once a session is disconnected all session keying material must be 363 destroyed, with the exception of secrets previously established 364 expressly for purposes of session resumption. TLS supports stateful 365 and stateless resumption. (Here, "state" refers to bookkeeping on a 366 per-session basis by the server. It is assumed that the client must 367 always store some state information in order to resume a session.) 369 4.1.2. Security Features 371 o Forward-secure key establishment. 373 o Cryptographic algorithm negotiation. 375 o Stateful and stateless cross-connection session resumption. 377 o Session caching and management. 379 o Peer authentication (Certificate, raw public key, and pre-shared 380 key). 382 o Mandatory server authentication, optional client authentication. 384 o Application authentication delegation. 386 o Record (channel) confidentiality and integrity. 388 o Record replay prevention. 390 o Application-layer feature negotiation. 392 o Configuration extensions. 394 o Early data support (starting with TLS 1.3). 396 o Optional record-layer padding (starting with TLS 1.3). 398 4.1.3. Protocol Dependencies 400 o TCP for in-order, reliable transport. 402 o (Optionally) A PKI trust store for certificate validation. 404 4.2. DTLS 406 DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, 407 but differs in that it is designed to run over UDP instead of TCP. 408 Since UDP does not guarantee datagram ordering or reliability, DTLS 409 modifies the protocol to make sure it can still provide the same 410 security guarantees as TLS. DTLS was designed to be as close to TLS 411 as possible, so this document will assume that all properties from 412 TLS are carried over except where specified. 414 4.2.1. Protocol Description 416 DTLS is modified from TLS to operate with the possibility of packet 417 loss, reordering, and duplication that may occur when operating over 418 UDP. To enable out-of-order delivery of application data, the DTLS 419 record protocol itself has no inter-record dependencies. However, as 420 the handshake requires reliability, each handshake message is 421 assigned an explicit sequence number to enable retransmissions of 422 lost packets and in-order processing by the receiver. Handshake 423 message loss is remedied by sender retransmission after a 424 configurable period in which the expected response has not yet been 425 received. 427 As the DTLS handshake protocol runs atop the record protocol, to 428 account for long handshake messages that cannot fit within a single 429 record, DTLS supports fragmentation and subsequent reconstruction of 430 handshake messages across records. The receiver must reassemble 431 records before processing. 433 DTLS relies on unique UDP 4-tuples to identify connections. Since 434 all application-layer data is encrypted, demultiplexing over the same 435 4-tuple requires the use of a connection identifier extension 436 [I-D.ietf-tls-dtls-connection-id] to permit identification of the 437 correct connection-specific cryptographic context without the use of 438 trial decryption. (Note that this extension is only supported in 439 DTLS 1.2 and 1.3 {{I-D.ietf-tls-dtls13}.) 441 Since datagrams can be replayed, DTLS provides optional anti-replay 442 detection based on a window of acceptable sequence numbers [RFC6347]. 444 4.2.2. Security Features 446 o Record replay protection. 448 o Record (datagram) confidentiality and integrity. 450 o Out-of-order record receipt. 452 o DoS mitigation (cookie-based). 454 See also the features from TLS. 456 4.2.3. Protocol Dependencies 458 o The DTLS record protocol explicitly encodes record lengths, so 459 although it runs over a datagram transport, it does not rely on 460 the transport protocol's framing beyond requiring transport-level 461 reconstruction of datagrams fragmented over packets. (Note: DTLS 462 1.3 short header records omit the explicit length field.) 464 o UDP 4-tuple uniqueness, or the connection identifier extension, 465 for demultiplexing. 467 o Path MTU discovery. 469 4.3. (IETF) QUIC with TLS 471 QUIC (Quick UDP Internet Connections) is a new standards-track 472 transport protocol that runs over UDP, loosely based on Google's 473 original proprietary gQUIC protocol [I-D.ietf-quic-transport]. (See 474 Section 4.3.4 for more details.) The QUIC transport layer itself 475 provides support for data confidentiality and integrity. This 476 requires keys to be derived with a separate handshake protocol. A 477 mapping for QUIC over TLS 1.3 [I-D.ietf-quic-tls] has been specified 478 to provide this handshake. 480 4.3.1. Protocol Description 482 As QUIC relies on TLS to secure its transport functions, it creates 483 specific integration points between its security and transport 484 functions: 486 o Starting the handshake to generate keys and provide authentication 487 (and providing the transport for the handshake). 489 o Client address validation. 491 o Key ready events from TLS to notify the QUIC transport. 493 o Exporting secrets from TLS to the QUIC transport. 495 The QUIC transport layer support multiple streams over a single 496 connection. QUIC implements a record protocol for TLS handshake 497 messages to establish a connection. These messages are sent in 498 special INITIAL and CRYPTO frames [I-D.ietf-quic-transport], types of 499 which are encrypted using different keys. INITIAL frames are 500 encrypted using "fixed" keys derived from the QUIC version and public 501 packet information (Connection ID). CRYPTO frames are encrypted 502 using TLS handshake secrets. Once TLS completes, QUIC uses the 503 resultant traffic secrets to for the QUIC connection to protect the 504 rest of the streams. QUIC supports 0-RTT (early) data using 505 previously negotiated connection secrets. Early data is sent in 506 0-RTT packets, which may be included in the same datagram as the 507 Initial and Handshake packets. 509 4.3.2. Security Features 511 o DoS mitigation (cookie-based). 513 See also the properties of TLS. 515 4.3.3. Protocol Dependencies 517 o QUIC transport relies on UDP. 519 o QUIC transport relies on TLS 1.3 for key exchange, peer 520 authentication, and shared secret derivation. 522 4.3.4. Variant: Google QUIC 524 Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol 525 designed and deployed by Google following experience from deploying 526 SPDY, the proprietary predecessor to HTTP/2. gQUIC was originally 527 known as "QUIC": this document uses gQUIC to unambiguously 528 distinguish it from the standards-track IETF QUIC. The proprietary 529 technical forebear of IETF QUIC, gQUIC was originally designed with 530 tightly-integrated security and application data transport protocols. 532 4.4. IKEv2 with ESP 534 IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec 535 protocol suite that encrypts and authenticates IP packets, either for 536 creating tunnels (tunnel-mode) or for direct transport connections 537 (transport-mode). This suite of protocols separates out the key 538 generation protocol (IKEv2) from the transport encryption protocol 539 (ESP). Each protocol can be used independently, but this document 540 considers them together, since that is the most common pattern. 542 4.4.1. Protocol descriptions 544 4.4.1.1. IKEv2 546 IKEv2 is a control protocol that runs on UDP port 500. Its primary 547 goal is to generate keys for Security Associations (SAs). An SA 548 contains shared (cryptographic) information used for establishing 549 other SAs or keying ESP; See Section 4.4.1.2. IKEv2 first uses a 550 Diffie-Hellman key exchange to generate keys for the "IKE SA", which 551 is a set of keys used to encrypt further IKEv2 messages. It then 552 goes through a phase of authentication in which both peers present 553 blobs signed by a shared secret or private key, after which another 554 set of keys is derived, referred to as the "Child SA". These Child 555 SA keys are used by ESP. 557 IKEv2 negotiates which protocols are acceptable to each peer for both 558 the IKE and Child SAs using "Proposals". Each proposal may contain 559 an encryption algorithm, an authentication algorithm, a Diffie- 560 Hellman group, and (for IKE SAs only) a pseudorandom function 561 algorithm. Each peer may support multiple proposals, and the most 562 preferred mutually supported proposal is chosen during the handshake. 564 The authentication phase of IKEv2 may use Shared Secrets, 565 Certificates, Digital Signatures, or an EAP (Extensible 566 Authentication Protocol) method. At a minimum, IKEv2 takes two round 567 trips to set up both an IKE SA and a Child SA. If EAP is used, this 568 exchange may be expanded. 570 Any SA used by IKEv2 can be rekeyed upon expiration, which is usually 571 based either on time or number of bytes encrypted. 573 There is an extension to IKEv2 that allows session resumption 574 [RFC5723]. 576 MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a 577 set of Security Associations to migrate over different addresses and 578 interfaces [RFC4555]. 580 When UDP is not available or well-supported on a network, IKEv2 may 581 be encapsulated in TCP [RFC8229]. 583 4.4.1.2. ESP 585 ESP is a protocol that encrypts and authenticates IPv4 and IPv6 586 packets. The keys used for both encryption and authentication can be 587 derived from an IKEv2 exchange. ESP Security Associations come as 588 pairs, one for each direction between two peers. Each SA is 589 identified by a Security Parameter Index (SPI), which is marked on 590 each encrypted ESP packet. 592 ESP packets include the SPI, a sequence number, an optional 593 Initialization Vector (IV), payload data, padding, a length and next 594 header field, and an Integrity Check Value. 596 From [RFC4303], "ESP is used to provide confidentiality, data origin 597 authentication, connectionless integrity, an anti-replay service (a 598 form of partial sequence integrity), and limited traffic flow 599 confidentiality." 601 Since ESP operates on IP packets, it is not directly tied to the 602 transport protocols it encrypts. This means it requires little or no 603 change from transports in order to provide security. 605 ESP packets may be sent directly over IP, but where network 606 conditions warrant (e.g., when a NAT is present or when a firewall 607 blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP 608 [RFC8229]. 610 4.4.2. Security Features 612 4.4.2.1. IKEv2 614 o Forward-secure key establishment. 616 o Cryptographic algorithm negotiation. 618 o Peer authentication (Certificate, raw public key, pre-shared key, 619 and EAP). 621 o Mutual authentication. 623 o Record (datagram) confidentiality and integrity. 625 o Session resumption. 627 o Connection mobility. 629 o DoS mitigation (cookie-based). 631 4.4.2.2. ESP 633 o Record confidentiality and integrity. 635 o Record replay protection. 637 4.4.3. Protocol Dependencies 639 4.4.3.1. IKEv2 641 o Availability of UDP to negotiate, or implementation support for 642 TCP-encapsulation. 644 o Some EAP authentication types require accessing a hardware device, 645 such as a SIM card; or interacting with a user, such as password 646 prompting. 648 4.4.3.2. ESP 650 o Since ESP is below transport protocols, it does not have any 651 dependencies on the transports themselves, other than on UDP or 652 TCP where encapsulation is employed. 654 4.5. Secure RTP (with DTLS) 656 Secure RTP (SRTP) is a profile for RTP that provides confidentiality, 657 message authentication, and replay protection for RTP data packets 658 and RTP control protocol (RTCP) packets [RFC3711]. 660 4.5.1. Protocol description 662 SRTP adds confidentiality and optional integrity protection to RTP 663 data packets, and adds confidentially and mandatory integrity 664 protection to RTCP packets. For RTP data packets, this is done by 665 encrypting the payload section of the packet and optionally appending 666 an authentication tag (MAC) as a packet trailer, with the RTP header 667 authenticated but not encrypted (the RTP header was left unencrypted 668 to enable RTP header compression [RFC2508] [RFC3545]). For RTCP 669 packets, the first packet in the compound RTCP packet is partially 670 encrypted, leaving the first eight octets of the header as clear-text 671 to allow identification of the packet as RTCP, while the remainder of 672 the compound packet is fully encrypted. The entire RTCP packet is 673 then authenticated by appending a MAC as packet trailer. 675 Packets are encrypted using session keys, which are ultimately 676 derived from a master key and an additional master salt and session 677 salt. SRTP packets carry a 2-byte sequence number to partially 678 identify the unique packet index. SRTP peers maintain a separate 679 roll-over counter (ROC) for RTP data packets that is incremented 680 whenever the sequence number wraps. The sequence number and ROC 681 together determine the packet index. RTCP packets have a similar, 682 yet differently named, field called the RTCP index which serves the 683 same purpose. 685 Numerous encryption modes are supported. For popular modes of 686 operation, e.g., AES-CTR, the (unique) initialization vector (IV) 687 used for each encryption mode is a function of the RTP SSRC 688 (synchronization source), packet index, and session "salting key". 690 SRTP offers replay detection by keeping a replay list of already seen 691 and processed packet indices. If a packet arrives with an index that 692 matches one in the replay list, it is silently discarded. 694 DTLS [RFC5764] is commonly used to perform mutual authentication and 695 key agreement for SRTP [RFC5763]. Peers use DTLS to perform mutual 696 certificate-based authentication on the media path, and to generate 697 the SRTP master key. Peer certificates can be issued and signed by a 698 certificate authority. Alternatively, certificates used in the DTLS 699 exchange can be self-signed. If they are self-signed, certificate 700 fingerprints are included in the signalling exchange (e.g., in SIP or 701 WebRTC), and used to bind the DTLS key exchange in the media plane to 702 the signaling plane. The combination of a mutually authenticated 703 DTLS key exchange on the media path and a fingerprint sent in the 704 signalling channel protects against active attacks on the media, 705 provided the signalling can be trusted. Signalling needs to be 706 protected as described in, for example, SIP [RFC3261] Authenticated 707 Identity Management [RFC4474] or the WebRTC security architecture 708 [I-D.ietf-rtcweb-security-arch], to provide complete system security. 710 4.5.2. Security Features 712 o Forward-secure key establishment. 714 o Cryptographic algorithm negotiation. 716 o Mutual authentication. 718 o Partial datagram confidentiality. (Packet headers are not 719 encrypted.) 721 o Optional authentication of data packets. 723 o Mandatory authentication of control packets. 725 o Out-of-order record receipt. 727 4.5.3. Protocol Dependencies 729 o External key derivation and management protocol, e.g., DTLS 730 [RFC5763]. 732 o External identity management protocol, e.g., SIP Authenticated 733 Identity Management [RFC4474], WebRTC Security Architecture 734 [I-D.ietf-rtcweb-security-arch]. 736 4.5.4. Variant: ZRTP for Media Path Key Agreement 738 ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It 739 uses standard SRTP to protect RTP data packets and RTCP packets, but 740 provides alternative key agreement and identity management protocols. 742 Key agreement is performed using a Diffie-Hellman key exchange that 743 runs on the media path. This generates a shared secret that is then 744 used to generate the master key and salt for SRTP. 746 ZRTP does not rely on a PKI or external identity management system. 747 Rather, it uses an ephemeral Diffie-Hellman key exchange with hash 748 commitment to allow detection of man-in-the-middle attacks. This 749 requires endpoints to display a short authentication string that the 750 users must read and verbally compare to validate the hashes and 751 ensure security. Endpoints cache some key material after the first 752 call to use in subsequent calls; this is mixed in with the Diffie- 753 Hellman shared secret, so the short authentication string need only 754 be checked once for a given user. This gives key continuity 755 properties analogous to the secure shell (ssh) [RFC4253]. 757 4.6. tcpcrypt 759 Tcpcrypt is a lightweight extension to the TCP protocol to enable 760 opportunistic encryption with hooks available to the application 761 layer for implementation of endpoint authentication. 763 4.6.1. Protocol Description 765 Tcpcrypt extends TCP to enable opportunistic encryption between the 766 two ends of a TCP connection [I-D.ietf-tcpinc-tcpcrypt]. It is a 767 family of TCP encryption protocols (TEP), distinguished by key 768 exchange algorithm. The use of a TEP is negotiated with a TCP option 769 during the initial TCP handshake via the mechanism described by TCP 770 Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the 771 case of initial session establishment, once a tcpcrypt TEP has been 772 negotiated the key exchange occurs within the data segments of the 773 first few packets exchanged after the handshake completes. The 774 initiator of a connection sends a list of supported AEAD algorithms, 775 a random nonce, and an ephemeral public key share. The responder 776 typically chooses a mutually-supported AEAD algorithm and replies 777 with this choice, its own nonce, and ephemeral key share. An initial 778 shared secret is derived from the ENO handshake, the tcpcrypt 779 handshake, and the initial keying material resulting from the key 780 exchange. The traffic encryption keys on the initial connection are 781 derived from the shared secret. Connections can be re-keyed before 782 the natural AEAD limit for a single set of traffic encryption keys is 783 reached. 785 Each tcpcrypt session is associated with a ladder of resumption IDs, 786 each derived from the respective entry in a ladder of shared secrets. 787 These resumption IDs can be used to negotiate a stateful resumption 788 of the session in a subsequent connection, resulting in use of a new 789 shared secret and traffic encryption keys without requiring a new key 790 exchange. Willingness to resume a session is signaled via the ENO 791 option during the TCP handshake. Given the length constraints 792 imposed by TCP options, unlike stateless resumption mechanisms (such 793 as that provided by session tickets in TLS) resumption in tcpcrypt 794 requires the maintenance of state on the server, and so successful 795 resumption across a pool of servers implies shared state. 797 Owing to middlebox ossification issues, tcpcrypt only protects the 798 payload portion of a TCP packet. It does not encrypt any header 799 information, such as the TCP sequence number. 801 Tcpcrypt exposes a universally-unique connection-specific session ID 802 to the application, suitable for application-level endpoint 803 authentication either in-band or out-of-band. 805 4.6.2. Security Features 807 o Forward-secure key establishment. 809 o Record (channel) confidentiality and integrity. 811 o Stateful cross-connection session resumption. 813 o Session caching and management. 815 o Application authentication delegation. 817 4.6.3. Protocol Dependencies 819 o TCP. 821 o TCP Encryption Negotiation Option (ENO). 823 4.7. WireGuard 825 WireGuard is a layer 3 protocol designed to complement or replace 826 IPsec [WireGuard] for certain use cases. It uses UDP to encapsulate 827 IP datagrams between peers. Unlike most transport security 828 protocols, which rely on PKI for peer authentication, WireGuard 829 authenticates peers using pre-shared public keys delivered out-of- 830 band, each of which is bound to one or more IP addresses. Moreover, 831 as a protocol suited for VPNs, WireGuard offers no extensibility, 832 negotiation, or cryptographic agility. 834 4.7.1. Protocol description 836 WireGuard is a simple VPN protocol that binds a pre-shared public key 837 to one or more IP addresses. Users configure WireGuard by 838 associating peer public keys with IP addresses. These mappings are 839 stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard] 840 for more details and sample configurations.) These keys are used 841 upon WireGuard packet transmission and reception. For example, upon 842 receipt of a Handshake Initiation message, receivers use the static 843 public key in their CryptoKey routing table to perform necessary 844 cryptographic computations. 846 WireGuard builds on Noise [Noise] for 1-RTT key exchange with 847 identity hiding. The handshake hides peer identities as per the 848 SIGMA construction [SIGMA]. As a consequence of using Noise, 849 WireGuard comes with a fixed set of cryptographic algorithms: 851 o x25519 [Curve25519] and HKDF [RFC5869] for ECDH and key 852 derivation. 854 o ChaCha20+Poly1305 [RFC7539] for packet authenticated encryption. 856 o BLAKE2s [BLAKE2] for hashing. 858 There is no cryptographic agility. If weaknesses are found in any of 859 these algorithms, new message types using new algorithms must be 860 introduced. 862 WireGuard is designed to be entirely stateless, modulo the CryptoKey 863 routing table, which has size linear with the number of trusted 864 peers. If a WireGuard receiver is under heavy load and cannot 865 process a packet, e.g., cannot spare CPU cycles for point 866 multiplication, it can reply with a cookie similar to DTLS and IKEv2. 867 This cookie only proves IP address ownership. Any rate limiting 868 scheme can be applied to packets coming from non-spoofed addresses. 870 4.7.2. Security Features 872 o Forward-secure key establishment. 874 o Peer authentication (Public-key and PSK). 876 o Mutual authentication. 878 o Record replay prevention (Stateful, timestamp-based). 880 o DoS mitigation (cookie-based). 882 4.7.3. Protocol Dependencies 884 o Datagram transport. 886 o Out-of-band key distribution and management. 888 4.8. MinimalT 890 MinimalT is a UDP-based transport security protocol designed to offer 891 confidentiality, mutual authentication, DoS prevention, and 892 connection mobility [MinimalT]. One major goal of the protocol is to 893 leverage existing protocols to obtain server-side configuration 894 information used to more quickly bootstrap a connection. MinimalT 895 uses a variant of TCP's congestion control algorithm. 897 4.8.1. Protocol Description 899 MinimalT is a secure transport protocol built on top of a widespread 900 directory service. Clients and servers interact with local directory 901 services to (a) resolve server information and (b) public ephemeral 902 state information, respectively. Clients connect to a local resolver 903 once at boot time. Through this resolver they recover the IP 904 address(es) and public key(s) of each server to which they want to 905 connect. 907 Connections are instances of user-authenticated, mobile sessions 908 between two endpoints. Connections run within tunnels between hosts. 909 A tunnel is a server-authenticated container that multiplexes 910 multiple connections between the same hosts. All connections in a 911 tunnel share the same transport state machine and encryption. Each 912 tunnel has a dedicated control connection used to configure and 913 manage the tunnel over time. Moreover, since tunnels are independent 914 of the network address information, they may be reused as both ends 915 of the tunnel move about the network. This does however imply that 916 connection establishment and packet encryption mechanisms are 917 coupled. 919 Before a client connects to a remote service, it must first establish 920 a tunnel to the host providing or offering the service. Tunnels are 921 established in 1-RTT using an ephemeral key obtained from the 922 directory service. Tunnel initiators provide their own ephemeral key 923 and, optionally, a DoS puzzle solution such that the recipient 924 (server) can verify the authenticity of the request and derive a 925 shared secret. Within a tunnel, new connections to services may be 926 established. 928 4.8.2. Protocol Features 930 o Forward-secure key establishment. 932 o DoS mitigation (puzzle-based). 934 o Connection mobility (based on tunnel identifiers). 936 Additional (orthogonal) transport features include: connection 937 multiplexing between hosts across shared tunnels, and congestion 938 control state is shared across connections between the same host 939 pairs. 941 4.8.3. Protocol Dependencies 943 o A DNS-like resolution service to obtain location information (an 944 IP address) and ephemeral keys. 946 o A PKI trust store for certificate validation. 948 4.9. CurveCP 950 CurveCP [CurveCP] is a UDP-based transport security protocol from 951 Daniel J. Bernstein. Unlike other transport security protocols, it 952 is based entirely upon highly efficient public key algorithms. This 953 removes many pitfalls associated with nonce reuse and key 954 synchronization. 956 4.9.1. Protocol Description 958 CurveCP is a UDP-based transport security protocol. It is built on 959 three principal features: exclusive use of public key authenticated 960 encryption of packets, server-chosen cookies to prohibit memory and 961 computation DoS at the server, and connection mobility with a client- 962 chosen ephemeral identifier. 964 There are two rounds in CurveCP. In the first round, the client 965 sends its first initialization packet to the server, carrying its 966 (possibly fresh) ephemeral public key C', with zero-padding encrypted 967 under the server's long-term public key. The server replies with a 968 cookie and its own ephemeral key S' and a cookie that is to be used 969 by the client. Upon receipt, the client then generates its second 970 initialization packet carrying: the ephemeral key C', cookie, and an 971 encryption of C', the server's domain name, and, optionally, some 972 message data. The server verifies the cookie and the encrypted 973 payload and, if valid, proceeds to send data in return. At this 974 point, the connection is established and the two parties can 975 communicate. 977 The use of public-key encryption and authentication, or "boxing", is 978 done to simplify problems that come with symmetric key management and 979 synchronization. For example, it allows the sender of a message to 980 be in complete control of each message's nonce. It does not require 981 either end to share secret keying material. Furthermore, it allows 982 connections (or sessions) to be associated with unique ephemeral 983 public keys as a mechanism for enabling forward secrecy given the 984 risk of long-term private key compromise. 986 The client and server do not perform a standard key exchange. 987 Instead, in the initial exchange of packets, each party provides its 988 own ephemeral key to the other end. The client can choose a new 989 ephemeral key for every new connection. However, the server must 990 rotate these keys on a slower basis. Otherwise, it would be trivial 991 for an attacker to force the server to create and store ephemeral 992 keys with a fake client initialization packet. 994 Servers use cookies for source validation. After receiving a 995 client's initial packet, encrypted under the server's long-term 996 public key, a server generates and returns a stateless cookie that 997 must be echoed back in the client's following message. This cookie 998 is encrypted under the client's ephemeral public key. This stateless 999 technique prevents attackers from hijacking client initialization 1000 packets to obtain cookie values to flood clients. (A client would 1001 detect the duplicate cookies and reject the flooded packets.) 1002 Similarly, replaying the client's second packet, carrying the cookie, 1003 will be detected by the server. 1005 CurveCP supports a weak form of client authentication. Clients are 1006 permitted to send their long-term public keys in the second 1007 initialization packet. A server can verify this public key and, if 1008 untrusted, drop the connection and subsequent data. 1010 Unlike some other protocols, CurveCP data packets leave only the 1011 ephemeral public key, the connection ID, and the per-message nonce in 1012 the clear. Everything else is encrypted. 1014 4.9.2. Protocol Features 1016 o Datagram confidentiality and integrity (via public key 1017 encryption). 1019 o Connection mobility (based on a client-chosen ephemeral 1020 identifier). 1022 o Optional length-hiding and anti-amplification padding. 1024 4.9.3. Protocol Dependencies 1026 o An unreliable transport protocol such as UDP. 1028 5. Security Features and Transport Dependencies 1030 There exists a common set of features shared across the transport 1031 protocols surveyed in this document. Mandatory features constitute a 1032 baseline of functionality that an application may assume for any TAPS 1033 implementation. They were selected on the basis that they are either 1034 (a) required for any secure transport protocol or (b) nearly 1035 ubiquitous amongst common secure transport protocols. 1037 Optional features by contrast may vary from implementation to 1038 implementation, and so an application cannot simply assume they are 1039 available. Applications learn of and use optional features by 1040 querying for their presence and support. Optional features may not 1041 be implemented, or may be disabled if their presence impacts 1042 transport services or if a necessary transport service or application 1043 dependency is unavailable. In this context, an application 1044 dependency is one required from an application in order to function. 1046 5.1. Mandatory Features 1048 Mandatory features must be supported regardless of transport and 1049 application services available. 1051 o Record or datagram confidentiality and integrity. 1053 o Forward-secure key establishment. 1055 o Public-key certificate based authentication. 1057 o Unilateral responder authentication. 1059 Note that most systems provide defailt trust stores used to 1060 authenticate peers based on certificates. In such systems, 1061 applications need not provide any trust information. Applications 1062 running on systems without such a feature must necessary depend on 1063 applications for this information so as to authenticate peers. 1065 5.2. Optional Features 1067 In this section we list optional features along with their necessary 1068 application dependencies, if any. 1070 o Pre-shared key support (PSK): 1072 * Application dependency: Application provisioning and 1073 distribution of pre-shared keys. 1075 o Cryptographic algorithm negotiation (AN): 1077 * Application dependency: Application awareness of supported or 1078 desired algorithms. 1080 o Application authentication delegation (AD): 1082 * Application dependency: Application opt-in and policy for 1083 endpoint authentication. 1085 o Mutual authentication (MA): 1087 * Application dependency: Mutual authentication credentials 1088 required for application support. 1090 o DoS mitigation (DM): 1092 * Application dependency: None. 1094 o Connection mobility (CM): 1096 * Application dependency: None. 1098 o Source validation (SV): 1100 * Application dependency: None. 1102 o Application-layer feature negotiation (AFN): 1104 * Application dependency: Specification of application-layer 1105 features or functionality. 1107 o Configuration extensions (CX): 1109 * Application dependency: Specification of application-specific 1110 extensions. 1112 o Session caching and management (SC): 1114 * Application dependency: None. 1116 o Length-hiding padding (LHP): 1118 * Application dependency: Knowledge of desired padding policies. 1120 o Early data support (ED): 1122 * Application dependency: Anti-replay protections or hints of 1123 data idempotency. 1125 o Record replay prevention (RP): 1127 * Application dependency: None. 1129 o Out-of-order receipt record (OO): 1131 * Application dependency: None. 1133 5.3. Optional Feature Availability 1135 The following table lists the availability of the above-listed 1136 optional features in each of the analyzed protocols. "Mandatory" 1137 indicates that the feature is intrinsic to the protocol and cannot be 1138 disabled. "Supported" indicates that the feature is optionally 1139 provided natively or through a (standardized, where applicable) 1140 extension. 1142 +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+ 1143 | Pro | P | A | A | M | D | C | S | A | CX | SC | LH | ED | RP | OO | 1144 | toc | S | N | D | A | M | M | V | F | | | P | | | | 1145 | ol | K | | | | | | | N | | | | | | | 1146 +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+ 1147 | TLS | S | S | S | S | S | U | M | S | S | S | S | S | U | U | 1148 | | | | | | | * | | | | | | | | | 1149 | | | | | | | | | | | | | | | | 1150 | DTL | S | S | S | S | S | S | M | S | S | S | S | U | M | M | 1151 | S | | | | | | | | | | | | | | | 1152 | | | | | | | | | | | | | | | | 1153 | IET | S | S | S | S | S | S | M | S | S | S | S | S | M | M | 1154 | F Q | | | | | | | | | | | | | | | 1155 | UIC | | | | | | | | | | | | | | | 1156 | | | | | | | | | | | | | | | | 1157 | IKE | S | S | S | M | S | S | M | S | S | S | S | U | M | M | 1158 | v2+ | | | | | | | | | | | | | | | 1159 | ESP | | | | | | | | | | | | | | | 1160 | | | | | | | | | | | | | | | | 1161 | SRT | S | S | S | S | S | U | M | S | S | S | U | U | M | M | 1162 | P+D | | | | | | | | | | | | | | | 1163 | TLS | | | | | | | | | | | | | | | 1164 | | | | | | | | | | | | | | | | 1165 | tcp | U | S | M | U | U | U | M | U | U | S | U | U | U | U | 1166 | cry | | | | | * | * | | | | | | | | | 1167 | pt | | | | | * | | | | | | | | | | 1168 | | | | | | | | | | | | | | | | 1169 | Wir | S | U | S | M | S | U | M | U | U | U | S+ | U | M | M | 1170 | eGu | | | | | | | | | | | | | | | 1171 | ard | | | | | | | | | | | | | | | 1172 | | | | | | | | | | | | | | | | 1173 | Min | U | U | U | M | S | M | M | U | U | U | S | U | U | U | 1174 | ima | | | | | | | | | | | | | | | 1175 | lT | | | | | | | | | | | | | | | 1176 | | | | | | | | | | | | | | | | 1177 | Cur | U | U | U | S | S | M | M | U | U | U | S | U | M | M | 1178 | veC | | | | | | | | | | | | | | | 1179 | P | | | | | | | | | | | | | | | 1180 +-----+---+---+---+---+---+---+---+---+----+----+----+----+----+----+ 1182 M=Mandatory S=Supported but not required U=Unsupported *=On TCP; 1183 MPTCP would provide this ability **=TCP provides SYN cookies 1184 natively, but these are not cryptographically strong +=For transport 1185 packets only 1187 6. Transport Security Protocol Interfaces 1189 This section describes the interface surface exposed by the security 1190 protocols described above. Note that not all protocols support each 1191 interface. We partition these interfaces into pre-connection 1192 (configuration), connection, and post-connection interfaces, 1193 following conventions in [I-D.ietf-taps-interface] and 1194 [I-D.ietf-taps-arch]. 1196 6.1. Pre-Connection Interfaces 1198 Configuration interfaces are used to configure the security protocols 1199 before a handshake begins or the keys are negotiated. 1201 o Identities and Private Keys The application can provide its 1202 identities (certificates) and private keys, or mechanisms to 1203 access these, to the security protocol to use during handshakes. 1204 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, 1205 WireGuard, SRTP 1207 o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) 1208 The application can choose the algorithms that are supported for 1209 key exchange, signatures, and ciphersuites. Protocols: TLS, DTLS, 1210 QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP 1212 o Extensions (Application-Layer Protocol Negotiation): The 1213 application enables or configures extensions that are to be 1214 negotiated by the security protocol, such as ALPN [RFC7301]. 1215 Protocols: TLS, DTLS, QUIC + TLS 1217 o Session Cache Management The application provides the ability to 1218 save and retrieve session state (such as tickets, keying material, 1219 and server parameters) that may be used to resume the security 1220 session. Protocols: TLS, DTLS, QUIC + TLS, MinimalT 1222 o Authentication Delegation The application provides access to a 1223 separate module that will provide authentication, using EAP for 1224 example. Protocols: IKEv2, SRTP 1226 o Pre-Shared Key Import Either the handshake protocol or the 1227 application directly can supply pre-shared keys for the record 1228 protocol use for encryption/decryption and authentication. If the 1229 application can supply keys directly, this is considered explicit 1230 import; if the handshake protocol traditionally provides the keys 1231 directly, it is considered direct import; if the keys can only be 1232 shared by the handshake, they are considered non-importable. 1234 * Explict import: QUIC, ESP 1235 * Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard 1237 * Non-importable: CurveCP 1239 6.2. Connection Interfaces 1241 o Identity Validation During a handshake, the security protocol will 1242 conduct identity validation of the peer. This can call into the 1243 application to offload validation. Protocols: All (TLS, DTLS, 1244 QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) 1246 o Source Address Validation The handshake protocol may delegate 1247 validation of the remote peer that has sent data to the transport 1248 protocol or application. This involves sending a cookie exchange 1249 to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard 1251 6.3. Post-Connection Interfaces 1253 o Connection Termination The security protocol may be instructed to 1254 tear down its connection and session information. This is needed 1255 by some protocols to prevent application data truncation attacks. 1256 Protocols: TLS, DTLS, QUIC, MinimalT, tcpcrypt, IKEv2 1258 o Key Update The handshake protocol may be instructed to update its 1259 keying material, either by the application directly or by the 1260 record protocol sending a key expiration event. Protocols: TLS, 1261 DTLS, QUIC, MinimalT, tcpcrypt, IKEv2 1263 o Pre-Shared Key Export The handshake protocol will generate one or 1264 more keys to be used for record encryption/decryption and 1265 authentication. These may be explicitly exportable to the 1266 application, traditionally limited to direct export to the record 1267 protocol, or inherently non-exportable because the keys must be 1268 used directly in conjunction with the record protocol. 1270 * Explicit export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for 1271 SRTP) 1273 * Direct export: TLS, DTLS, MinimalT 1275 * Non-exportable: CurveCP 1277 o Key Expiration The record protocol can signal that its keys are 1278 expiring due to reaching a time-based deadline, or a use-based 1279 deadline (number of bytes that have been encrypted with the key). 1280 This interaction is often limited to signaling between the record 1281 layer and the handshake layer. Protocols: ESP ((Editor's note: 1282 One may consider TLS/DTLS to also have this interface)) 1284 o Mobility Events The record protocol can be signaled that it is 1285 being migrated to another transport or interface due to connection 1286 mobility, which may reset address and state validation and induce 1287 state changes such as use of a new Connection Identifier (CID). 1288 Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming) 1290 7. IANA Considerations 1292 This document has no request to IANA. 1294 8. Security Considerations 1296 This document summarizes existing transport security protocols and 1297 their interfaces. It does not propose changes to or recommend usage 1298 of reference protocols. Moreover, no claims of security and privacy 1299 properties beyond those guaranteed by the protocols discussed are 1300 made. For example, metadata leakage via timing side channels and 1301 traffic analysis may compromise any protocol discussed in this 1302 survey. Applications using Security Interfaces SHOULD take such 1303 limitations into consideration when using a particular protocol 1304 implementation. 1306 9. Privacy Considerations 1308 Analysis of how features improve or degrade privacy is intentionally 1309 omitted from this survey. All security protocols surveyed generally 1310 improve privacy by reducing information leakage via encryption. 1311 However, varying amounts of metadata remain in the clear across each 1312 protocol. For example, client and server certificates are sent in 1313 cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3 1314 [RFC8446]. A survey of privacy features, or lack thereof, for 1315 various security protocols could be addressed in a separate document. 1317 10. Acknowledgments 1319 The authors would like to thank Bob Bradley, Theresa Enghardt, 1320 Frederic Jacobs, Mirja Kuehlewind, Yannick Sierra, and Brian Trammell 1321 for their input and feedback on earlier versions of this draft. 1323 11. Normative References 1325 [ALTS] "Application Layer Transport Security", n.d.. 1327 [BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d.. 1329 [Curve25519] 1330 "Curve25519 - new Diffie-Hellman speed records", n.d.. 1332 [CurveCP] "CurveCP -- Usable security for the Internet", n.d.. 1334 [I-D.ietf-quic-tls] 1335 Thomson, M. and S. Turner, "Using Transport Layer Security 1336 (TLS) to Secure QUIC", draft-ietf-quic-tls-16 (work in 1337 progress), October 2018. 1339 [I-D.ietf-quic-transport] 1340 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1341 and Secure Transport", draft-ietf-quic-transport-16 (work 1342 in progress), October 2018. 1344 [I-D.ietf-rtcweb-security-arch] 1345 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 1346 rtcweb-security-arch-16 (work in progress), October 2018. 1348 [I-D.ietf-taps-arch] 1349 Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., 1350 Perkins, C., Tiesel, P., and C. Wood, "An Architecture for 1351 Transport Services", draft-ietf-taps-arch-02 (work in 1352 progress), October 2018. 1354 [I-D.ietf-taps-interface] 1355 Trammell, B., Welzl, M., Enghardt, T., Fairhurst, G., 1356 Kuehlewind, M., Perkins, C., Tiesel, P., and C. Wood, "An 1357 Abstract Application Layer Interface to Transport 1358 Services", draft-ietf-taps-interface-02 (work in 1359 progress), October 2018. 1361 [I-D.ietf-tcpinc-tcpcrypt] 1362 Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 1363 Q., and E. Smith, "Cryptographic protection of TCP Streams 1364 (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-14 (work in 1365 progress), November 2018. 1367 [I-D.ietf-tcpinc-tcpeno] 1368 Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. 1369 Smith, "TCP-ENO: Encryption Negotiation Option", draft- 1370 ietf-tcpinc-tcpeno-19 (work in progress), June 2018. 1372 [I-D.ietf-tls-dtls-connection-id] 1373 Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, 1374 "Connection Identifiers for DTLS 1.2", draft-ietf-tls- 1375 dtls-connection-id-02 (work in progress), October 2018. 1377 [I-D.ietf-tls-dtls13] 1378 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1379 Datagram Transport Layer Security (DTLS) Protocol Version 1380 1.3", draft-ietf-tls-dtls13-29 (work in progress), October 1381 2018. 1383 [I-D.ietf-tls-record-limit] 1384 Thomson, M., "Record Size Limit Extension for Transport 1385 Layer Security (TLS)", draft-ietf-tls-record-limit-03 1386 (work in progress), May 2018. 1388 [I-D.ietf-tls-tls13] 1389 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1390 Version 1.3", draft-ietf-tls-tls13-28 (work in progress), 1391 March 2018. 1393 [MinimalT] 1394 "MinimaLT -- Minimal-latency Networking Through Better 1395 Security", n.d.. 1397 [Noise] "The Noise Protocol Framework", n.d.. 1399 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1400 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1401 1998, . 1403 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 1404 Headers for Low-Speed Serial Links", RFC 2508, 1405 DOI 10.17487/RFC2508, February 1999, . 1408 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1409 A., Peterson, J., Sparks, R., Handley, M., and E. 1410 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1411 DOI 10.17487/RFC3261, June 2002, . 1414 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 1415 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 1416 High Delay, Packet Loss and Reordering", RFC 3545, 1417 DOI 10.17487/RFC3545, July 2003, . 1420 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1421 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1422 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1423 . 1425 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1426 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1427 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1428 . 1430 [RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) 1431 Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, 1432 January 2006, . 1434 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1435 DOI 10.17487/RFC4302, December 2005, . 1438 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1439 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1440 . 1442 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1443 Authenticated Identity Management in the Session 1444 Initiation Protocol (SIP)", RFC 4474, 1445 DOI 10.17487/RFC4474, August 2006, . 1448 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1449 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 1450 . 1452 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1453 (TLS) Protocol Version 1.2", RFC 5246, 1454 DOI 10.17487/RFC5246, August 2008, . 1457 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 1458 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 1459 DOI 10.17487/RFC5723, January 2010, . 1462 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1463 for Establishing a Secure Real-time Transport Protocol 1464 (SRTP) Security Context Using Datagram Transport Layer 1465 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1466 2010, . 1468 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1469 Security (DTLS) Extension to Establish Keys for the Secure 1470 Real-time Transport Protocol (SRTP)", RFC 5764, 1471 DOI 10.17487/RFC5764, May 2010, . 1474 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1475 Key Derivation Function (HKDF)", RFC 5869, 1476 DOI 10.17487/RFC5869, May 2010, . 1479 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1480 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1481 June 2010, . 1483 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1484 Extensions: Extension Definitions", RFC 6066, 1485 DOI 10.17487/RFC6066, January 2011, . 1488 [RFC6189] Zimmermann, P., Johnston, A., Ed., and J. Callas, "ZRTP: 1489 Media Path Key Agreement for Unicast Secure RTP", 1490 RFC 6189, DOI 10.17487/RFC6189, April 2011, 1491 . 1493 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1494 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1495 January 2012, . 1497 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1498 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1499 Transport Layer Security (TLS) and Datagram Transport 1500 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1501 June 2014, . 1503 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1504 Kivinen, "Internet Key Exchange Protocol Version 2 1505 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1506 2014, . 1508 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1509 "Transport Layer Security (TLS) Application-Layer Protocol 1510 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1511 July 2014, . 1513 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1514 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 1515 . 1517 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 1518 Ed., "Services Provided by IETF Transport Protocols and 1519 Congestion Control Mechanisms", RFC 8095, 1520 DOI 10.17487/RFC8095, March 2017, . 1523 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 1524 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 1525 August 2017, . 1527 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1528 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1529 . 1531 [SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated 1532 Diffie-Hellman and Its Use in the IKE-Protocols", n.d.. 1534 [WireGuard] 1535 "WireGuard -- Next Generation Kernel Network Tunnel", 1536 n.d.. 1538 Authors' Addresses 1540 Tommy Pauly 1541 Apple Inc. 1542 One Apple Park Way 1543 Cupertino, California 95014 1544 United States of America 1546 Email: tpauly@apple.com 1548 Colin Perkins 1549 University of Glasgow 1550 School of Computing Science 1551 Glasgow G12 8QQ 1552 United Kingdom 1554 Email: csp@csperkins.org 1556 Kyle Rose 1557 Akamai Technologies, Inc. 1558 150 Broadway 1559 Cambridge, MA 02144 1560 United States of America 1562 Email: krose@krose.org 1563 Christopher A. Wood 1564 Apple Inc. 1565 One Apple Park Way 1566 Cupertino, California 95014 1567 United States of America 1569 Email: cawood@apple.com