idnits 2.17.1 draft-pauly-taps-transport-security-02.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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 05, 2018) is 2215 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-quic-transport' is defined on line 1176, but no explicit reference was found in the text == Outdated reference: A later version (-34) exists of draft-ietf-quic-tls-10 == Outdated reference: A later version (-34) exists of draft-ietf-quic-transport-10 == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-13 == Outdated reference: A later version (-15) exists of draft-ietf-tcpinc-tcpcrypt-11 == Outdated reference: A later version (-19) exists of draft-ietf-tcpinc-tcpeno-18 == Outdated reference: A later version (-13) exists of draft-ietf-tls-dtls-connection-id-00 == Outdated reference: A later version (-43) exists of draft-ietf-tls-dtls13-26 == Outdated reference: A later version (-28) exists of draft-ietf-tls-tls13-26 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** 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: 6 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: September 6, 2018 University of Glasgow 6 K. Rose 7 Akamai Technologies, Inc. 8 C. Wood 9 Apple Inc. 10 March 05, 2018 12 A Survey of Transport Security Protocols 13 draft-pauly-taps-transport-security-02 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. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 6, 2018. 46 Copyright Notice 48 Copyright (c) 2018 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Transport Security Protocol Descriptions . . . . . . . . . . 5 66 3.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1.1. Protocol Description . . . . . . . . . . . . . . . . 6 68 3.1.2. Protocol Features . . . . . . . . . . . . . . . . . . 7 69 3.1.3. Protocol Dependencies . . . . . . . . . . . . . . . . 7 70 3.2. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3.2.1. Protocol Description . . . . . . . . . . . . . . . . 7 72 3.2.2. Protocol Features . . . . . . . . . . . . . . . . . . 8 73 3.2.3. Protocol Dependencies . . . . . . . . . . . . . . . . 8 74 3.3. (IETF) QUIC with TLS . . . . . . . . . . . . . . . . . . 9 75 3.3.1. Protocol Description . . . . . . . . . . . . . . . . 9 76 3.3.2. Protocol Features . . . . . . . . . . . . . . . . . . 9 77 3.3.3. Protocol Dependencies . . . . . . . . . . . . . . . . 10 78 3.4. gQUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 3.4.1. Protocol Description . . . . . . . . . . . . . . . . 10 80 3.4.2. Protocol Dependencies . . . . . . . . . . . . . . . . 10 81 3.5. MinimalT . . . . . . . . . . . . . . . . . . . . . . . . 10 82 3.5.1. Protocol Description . . . . . . . . . . . . . . . . 10 83 3.5.2. Protocol Features . . . . . . . . . . . . . . . . . . 11 84 3.5.3. Protocol Dependencies . . . . . . . . . . . . . . . . 11 85 3.6. CurveCP . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 3.6.1. Protocol Description . . . . . . . . . . . . . . . . 12 87 3.6.2. Protocol Features . . . . . . . . . . . . . . . . . . 13 88 3.6.3. Protocol Dependencies . . . . . . . . . . . . . . . . 13 89 3.7. tcpcrypt . . . . . . . . . . . . . . . . . . . . . . . . 13 90 3.7.1. Protocol Description . . . . . . . . . . . . . . . . 13 91 3.7.2. Protocol Features . . . . . . . . . . . . . . . . . . 14 92 3.7.3. Protocol Dependencies . . . . . . . . . . . . . . . . 15 93 3.8. IKEv2 with ESP . . . . . . . . . . . . . . . . . . . . . 15 94 3.8.1. Protocol descriptions . . . . . . . . . . . . . . . . 15 95 3.8.2. Protocol features . . . . . . . . . . . . . . . . . . 16 96 3.8.3. Protocol dependencies . . . . . . . . . . . . . . . . 17 97 3.9. WireGuard . . . . . . . . . . . . . . . . . . . . . . . . 17 98 3.9.1. Protocol description . . . . . . . . . . . . . . . . 17 99 3.9.2. Protocol features . . . . . . . . . . . . . . . . . . 18 100 3.9.3. Protocol dependencies . . . . . . . . . . . . . . . . 18 101 3.10. SRTP (with DTLS) . . . . . . . . . . . . . . . . . . . . 18 102 3.10.1. Protocol descriptions . . . . . . . . . . . . . . . 19 103 3.10.2. Protocol features . . . . . . . . . . . . . . . . . 20 104 3.10.3. Protocol dependencies . . . . . . . . . . . . . . . 20 105 4. Common Transport Security Features . . . . . . . . . . . . . 20 106 4.1. Mandatory Features . . . . . . . . . . . . . . . . . . . 20 107 4.1.1. Handshake . . . . . . . . . . . . . . . . . . . . . . 20 108 4.1.2. Record . . . . . . . . . . . . . . . . . . . . . . . 21 109 4.2. Optional Features . . . . . . . . . . . . . . . . . . . . 21 110 4.2.1. Handshake . . . . . . . . . . . . . . . . . . . . . . 21 111 4.2.2. Record . . . . . . . . . . . . . . . . . . . . . . . 21 112 5. Transport Security Protocol Interfaces . . . . . . . . . . . 21 113 5.1. Configuration Interfaces . . . . . . . . . . . . . . . . 22 114 5.2. Handshake Interfaces . . . . . . . . . . . . . . . . . . 22 115 5.3. Record Interfaces . . . . . . . . . . . . . . . . . . . . 23 116 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 117 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 118 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 119 9. Normative References . . . . . . . . . . . . . . . . . . . . 25 120 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 122 1. Introduction 124 This document provides a survey of commonly used or notable network 125 security protocols, with a focus on how they interact and integrate 126 with applications and transport protocols. Its goal is to supplement 127 efforts to define and catalog transport services [RFC8095] by 128 describing the interfaces required to add security protocols. It 129 examines Transport Layer Security (TLS), Datagram Transport Layer 130 Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + 131 TLS), MinimalT, CurveCP, tcpcrypt, Internet Key Exchange with 132 Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), and 133 WireGuard. This survey is not limited to protocols developed within 134 the scope or context of the IETF. 136 For each protocol, this document provides a brief description, the 137 security features it provides, and the dependencies it has on the 138 underlying transport. This is followed by defining the set of 139 transport security features shared by these protocols. Finally, we 140 distill the application and transport interfaces provided by the 141 transport security protocols. 143 Authentication-only protocols such as TCP-AO [RFC5925] and IPsec AH 144 [RFC4302] are excluded from this survey. TCP-AO adds authenticity 145 protections to long-lived TCP connections, e.g., replay protection 146 with per-packet Message Authentication Codes. (This protocol 147 obsoletes TCP MD5 "signature" options specified in [RFC2385].) One 148 prime use case of TCP-AO is for protecting BGP connections. 149 Similarly, AH adds per-datagram authenticity and adds similar replay 150 protection. Despite these improvements, neither protocol sees 151 general use and both lack critical properties important for emergent 152 transport security protocols: confidentiality, privacy protections, 153 and agility. Thus, we omit these and related protocols from our 154 survey. 156 2. Terminology 158 The following terms are used throughout this document to describe the 159 roles and interactions of transport security protocols: 161 o Transport Feature: a specific end-to-end feature that the 162 transport layer provides to an application. Examples include 163 confidentiality, reliable delivery, ordered delivery, message- 164 versus-stream orientation, etc. 166 o Transport Service: a set of Transport Features, without an 167 association to any given framing protocol, which provides 168 functionality to an application. 170 o Transport Protocol: an implementation that provides one or more 171 different transport services using a specific framing and header 172 format on the wire. A Transport Protocol services an application. 174 o Application: an entity that uses a transport protocol for end-to- 175 end delivery of data across the network. This may also be an 176 upper layer protocol or tunnel encapsulation. 178 o Security Feature: a specific feature that a network security layer 179 provides to applications. Examples include authentication, 180 encryption, key generation, session resumption, and privacy. A 181 feature may be considered to be Mandatory or Optional to an 182 application's implementation. 184 o Security Protocol: a defined network protocol that implements one 185 or more security features. Security protocols may be used 186 alongside transport protocols, and in combination with other 187 security protocols when appropriate. 189 o Handshake Protocol: a protocol that enables peers to validate each 190 other and to securely establish shared cryptographic context. 192 o Record Protocol: a security protocol that allows data to be 193 divided into manageable blocks and protected using a shared 194 cryptographic context. 196 o Session: an ephemeral security association between applications. 198 o Cryptographic context: a set of cryptographic parameters, 199 including but not necessarily limited to keys for encryption, 200 authentication, and session resumption, enabling authorized 201 parties to a session to communicate securely. 203 o Connection: the shared state of two or more endpoints that 204 persists across messages that are transmitted between these 205 endpoints. A connection is a transient participant of a session, 206 and a session generally lasts between connection instances. 208 o Connection Mobility: a property of a connection that allows it to 209 be multihomed or resilient across network interface or address 210 changes. 212 o Peer: an endpoint application party to a session. 214 o Client: the peer responsible for initiating a session. 216 o Server: the peer responsible for responding to a session 217 initiation. 219 3. Transport Security Protocol Descriptions 221 This section contains descriptions of security protocols that 222 currently used to protect data being sent over a network. 224 For each protocol, we describe the features it provides and its 225 dependencies on other protocols. 227 3.1. TLS 229 TLS (Transport Layer Security) [RFC5246] is a common protocol used to 230 establish a secure session between two endpoints. Communication over 231 this session "prevents eavesdropping, tampering, and message 232 forgery." TLS consists of a tightly coupled handshake and record 233 protocol. The handshake protocol is used to authenticate peers, 234 negotiate protocol options, such as cryptographic algorithms, and 235 derive session-specific keying material. The record protocol is used 236 to marshal (possibly encrypted) data from one peer to the other. 237 This data may contain handshake messages or raw application data. 239 3.1.1. Protocol Description 241 TLS is the composition of a handshake and record protocol 242 [I-D.ietf-tls-tls13]. The record protocol is designed to marshal an 243 arbitrary, in-order stream of bytes from one endpoint to the other. 244 It handles segmenting, compressing (when enabled), and encrypting 245 data into discrete records. When configured to use an AEAD 246 algorithm, it also handles nonce generation and encoding for each 247 record. The record protocol is hidden from the client behind a byte 248 stream-oriented API. 250 The handshake protocol serves several purposes, including: peer 251 authentication, protocol option (key exchange algorithm and 252 ciphersuite) negotiation, and key derivation. Peer authentication 253 may be mutual; however, commonly, only the server is authenticated. 254 X.509 certificates are commonly used in this authentication step, 255 though other mechanisms, such as raw public keys [RFC7250], exist. 256 The client is not authenticated unless explicitly requested by the 257 server with a CertificateRequest handshake message. Assuming strong 258 cryptography, an infrastructure for trust establishment, correctly- 259 functioning endpoints, and communication patterns free from side 260 channels, server authentication is sufficient to establish a channel 261 resistant to eavesdroppers. 263 The handshake protocol is also extensible. It allows for a variety 264 of extensions to be included by either the client or server. These 265 extensions are used to specify client preferences, e.g., the 266 application-layer protocol to be driven with the TLS connection 267 [RFC7301], or signals to the server to aid operation, e.g., Server 268 Name Indication (SNI) [RFC6066]. Various extensions also exist to 269 tune the parameters of the record protocol, e.g., the maximum 270 fragment length [RFC6066]. 272 Alerts are used to convey errors and other atypical events to the 273 endpoints. There are two classes of alerts: closure and error 274 alerts. A closure alert is used to signal to the other peer that the 275 sender wishes to terminate the connection. The sender typically 276 follows a close alert with a TCP FIN segment to close the connection. 277 Error alerts are used to indicate problems with the handshake or 278 individual records. Most errors are fatal and are followed by 279 connection termination. However, warning alerts may be handled at 280 the discretion of the implementation. 282 Once a session is disconnected all session keying material must be 283 destroyed, with the exception of secrets previously established 284 expressly for purposes of session resumption. TLS supports stateful 285 and stateless resumption. (Here, "state" refers to bookkeeping on a 286 per-session basis by the server. It is assumed that the client must 287 always store some state information in order to resume a session.) 289 3.1.2. Protocol Features 291 o Key exchange and ciphersuite algorithm negotiation. 293 o Stateful and stateless session resumption. 295 o Certificate- and raw public key-based authentication. 297 o Mutual client and server authentication. 299 o Byte stream confidentiality and integrity. 301 o Extensibility via well-defined extensions. 303 o 0-RTT data support (starting with TLS 1.3). 305 o Application-layer protocol negotiation. 307 o Transparent data segmentation. 309 3.1.3. Protocol Dependencies 311 o TCP for in-order, reliable transport. 313 o (Optionally) A PKI trust store for certificate validation. 315 3.2. DTLS 317 DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, 318 but differs in that it is designed to run over UDP instead of TCP. 319 Since UDP does not guarantee datagram ordering or reliability, DTLS 320 modifies the protocol to make sure it can still provide the same 321 security guarantees as TLS. DTLS was designed to be as close to TLS 322 as possible, so this document will assume that all properties from 323 TLS are carried over except where specified. 325 3.2.1. Protocol Description 327 DTLS is modified from TLS to account for packet loss, reordering, and 328 duplication that may occur when operating over UDP. To enable out- 329 of-order delivery of application data, the DTLS record protocol 330 itself has no inter-record dependencies. However, as the handshake 331 requires reliability, each handshake message is assigned an explicit 332 sequence number to enable retransmissions of lost packets and in- 333 order processing by the receiver. Handshake message loss is remedied 334 by sender retransmission after a configurable period in which the 335 expected response has not yet been received. 337 As the DTLS handshake protocol runs atop the record protocol, to 338 account for long handshake messages that cannot fit within a single 339 record, DTLS supports fragmentation and subsequent reconstruction of 340 handshake messages across records. The receiver must reassemble 341 records before processing. 343 DTLS relies on unique UDP 4-tuples to allow peers with multiple DTLS 344 connections between them to demultiplex connections, constraining 345 protocol design slightly more than UDP: application-layer 346 demultiplexing over the same 4-tuple is not possible without trial 347 decryption as all application-layer data is encrypted to a 348 connection-specific cryptographic context. Starting with DTLS 1.3 349 [I-D.ietf-tls-dtls13], a connection identifier extension to permit 350 multiplexing of independent connections over the same 4-tuple is 351 available [I-D.ietf-tls-dtls-connection-id]. 353 Since datagrams may be replayed, DTLS provides optional anti-replay 354 detection based on a window of acceptable sequence numbers [RFC6347]. 356 3.2.2. Protocol Features 358 o Anti-replay protection between datagrams. 360 o Basic reliability for handshake messages. 362 o See also the features from TLS. 364 3.2.3. Protocol Dependencies 366 o Since DTLS runs over an unreliable, unordered datagram transport, 367 it does not require any reliability features. 369 o The DTLS record protocol explicitly encodes record lengths, so 370 although it runs over a datagram transport, it does not rely on 371 the transport protocol's framing beyond requiring transport-level 372 reconstruction of datagrams fragmented over packets. 374 o UDP 4-tuple uniqueness, or the connection identifier extension, 375 for demultiplexing. 377 o Path MTU discovery. 379 3.3. (IETF) QUIC with TLS 381 QUIC (Quick UDP Internet Connections) is a new standards-track 382 transport protocol that runs over UDP, loosely based on Google's 383 original proprietary gQUIC protocol. (See Section 3.4 for more 384 details.) The QUIC transport layer itself provides support for data 385 confidentiality and integrity. This requires keys to be derived with 386 a separate handshake protocol. A mapping for QUIC over TLS 1.3 387 [I-D.ietf-quic-tls] has been specified to provide this handshake. 389 3.3.1. Protocol Description 391 As QUIC relies on TLS to secure its transport functions, it creates 392 specific integration points between its security and transport 393 functions: 395 o Starting the handshake to generate keys and provide authentication 396 (and providing the transport for the handshake). 398 o Client address validation. 400 o Key ready events from TLS to notify the QUIC transport. 402 o Exporting secrets from TLS to the QUIC transport. 404 The QUIC transport layer support multiple streams over a single 405 connection. The first stream is reserved specifically for a TLS 406 connection. The TLS handshake, along with further records, are sent 407 over this stream. This TLS connection follows the TLS standards and 408 inherits the security properties of TLS. The handshake generates 409 keys, which are then exported to the rest of the QUIC connection, and 410 are used to protect the rest of the streams. 412 Initial QUIC messages (packets) are encrypted using "fixed" keys 413 derived from the QUIC version and public packet information 414 (Connection ID). Packets are later encrypted using keys derived from 415 the TLS traffic secret upon handshake completion. The TLS 1.3 416 handshake for QUIC is used in either a single-RTT mode or a fast-open 417 zero-RTT mode. When zero-RTT handshakes are possible, the encryption 418 first transitions to use the zero-RTT keys before using single-RTT 419 handshake keys after the next TLS flight. 421 3.3.2. Protocol Features 423 o Handshake properties of TLS. 425 o Multiple encrypted streams over a single connection without head- 426 of-line blocking. 428 o Packet payload encryption and complete packet authentication (with 429 the exception of the Public Reset packet, which is not 430 authenticated). 432 3.3.3. Protocol Dependencies 434 o QUIC transport relies on UDP. 436 o QUIC transport relies on TLS 1.3 for authentication and initial 437 key derivation. 439 o TLS within QUIC relies on a reliable stream abstraction for its 440 handshake. 442 3.4. gQUIC 444 gQUIC is a UDP-based multiplexed streaming protocol designed and 445 deployed by Google following experience from deploying SPDY, the 446 proprietary predecessor to HTTP/2. gQUIC was originally known as 447 "QUIC": this document uses gQUIC to unambiguously distinguish it from 448 the standards-track IETF QUIC. The proprietary technical forebear of 449 IETF QUIC, gQUIC was originally designed with tightly-integrated 450 security and application data transport protocols. 452 3.4.1. Protocol Description 454 ((TODO: write me)) 456 3.4.2. Protocol Dependencies 458 ((TODO: write me)) 460 3.5. MinimalT 462 MinimalT is a UDP-based transport security protocol designed to offer 463 confidentiality, mutual authentication, DoS prevention, and 464 connection mobility [MinimalT]. One major goal of the protocol is to 465 leverage existing protocols to obtain server-side configuration 466 information used to more quickly bootstrap a connection. MinimalT 467 uses a variant of TCP's congestion control algorithm. 469 3.5.1. Protocol Description 471 MinimalT is a secure transport protocol built on top of a widespread 472 directory service. Clients and servers interact with local directory 473 services to (a) resolve server information and (b) public ephemeral 474 state information, respectively. Clients connect to a local resolver 475 once at boot time. Through this resolver they recover the IP 476 address(es) and public key(s) of each server to which they want to 477 connect. 479 Connections are instances of user-authenticated, mobile sessions 480 between two endpoints. Connections run within tunnels between hosts. 481 A tunnel is a server-authenticated container that multiplexes 482 multiple connections between the same hosts. All connections in a 483 tunnel share the same transport state machine and encryption. Each 484 tunnel has a dedicated control connection used to configure and 485 manage the tunnel over time. Moreover, since tunnels are independent 486 of the network address information, they may be reused as both ends 487 of the tunnel move about the network. This does however imply that 488 the connection establishment and packet encryption mechanisms are 489 coupled. 491 Before a client connects to a remote service, it must first establish 492 a tunnel to the host providing or offering the service. Tunnels are 493 established in 1-RTT using an ephemeral key obtained from the 494 directory service. Tunnel initiators provide their own ephemeral key 495 and, optionally, a DoS puzzle solution such that the recipient 496 (server) can verify the authenticity of the request and derive a 497 shared secret. Within a tunnel, new connections to services may be 498 established. 500 3.5.2. Protocol Features 502 o 0-RTT forward secrecy for new connections. 504 o DoS prevention by client-side puzzles. 506 o Tunnel-based mobility. 508 o (Transport Feature) Connection multiplexing between hosts across 509 shared tunnels. 511 o (Transport Feature) Congestion control state is shared across 512 connections between the same host pairs. 514 3.5.3. Protocol Dependencies 516 o A DNS-like resolution service to obtain location information (an 517 IP address) and ephemeral keys. 519 o A PKI trust store for certificate validation. 521 3.6. CurveCP 523 CurveCP [CurveCP] is a UDP-based transport security protocol from 524 Daniel J. Bernstein. Unlike other transport security protocols, it 525 is based entirely upon highly efficient public key algorithms. This 526 removes many pitfalls associated with nonce reuse and key 527 synchronization. 529 3.6.1. Protocol Description 531 CurveCP is a UDP-based transport security protocol. It is built on 532 three principal features: exclusive use of public key authenticated 533 encryption of packets, server-chosen cookies to prohibit memory and 534 computation DoS at the server, and connection mobility with a client- 535 chosen ephemeral identifier. 537 There are two rounds in CurveCP. In the first round, the client 538 sends its first initialization packet to the server, carrying its 539 (possibly fresh) ephemeral public key C', with zero-padding encrypted 540 under the server's long-term public key. The server replies with a 541 cookie and its own ephemeral key S' and a cookie that is to be used 542 by the client. Upon receipt, the client then generates its second 543 initialization packet carrying: the ephemeral key C', cookie, and an 544 encryption of C', the server's domain name, and, optionally, some 545 message data. The server verifies the cookie and the encrypted 546 payload and, if valid, proceeds to send data in return. At this 547 point, the connection is established and the two parties can 548 communicate. 550 The use of only public-key encryption and authentication, or 551 "boxing", is done to simplify problems that come with symmetric key 552 management and synchronization. For example, it allows the sender of 553 a message to be in complete control of each message's nonce. It does 554 not require either end to share secret keying material. Furthermore, 555 it allows connections (or sessions) to be associated with unique 556 ephemeral public keys as a mechanism for enabling forward secrecy 557 given the risk of long-term private key compromise. 559 The client and server do not perform a standard key exchange. 560 Instead, in the initial exchange of packets, each party provides its 561 own ephemeral key to the other end. The client can choose a new 562 ephemeral key for every new connection. However, the server must 563 rotate these keys on a slower basis. Otherwise, it would be trivial 564 for an attacker to force the server to create and store ephemeral 565 keys with a fake client initialization packet. 567 Unlike TCP, the server employs cookies to enable source validation. 568 After receiving the client's initial packet, encrypted under the 569 server's long-term public key, the server generates and returns a 570 stateless cookie that must be echoed back in the client's following 571 message. This cookie is encrypted under the client's ephemeral 572 public key. This stateless technique prevents attackers from 573 hijacking client initialization packets to obtain cookie values to 574 flood clients. (A client would detect the duplicate cookies and 575 reject the flooded packets.) Similarly, replaying the client's 576 second packet, carrying the cookie, will be detected by the server. 578 CurveCP supports a weak form of client authentication. Clients are 579 permitted to send their long-term public keys in the second 580 initialization packet. A server can verify this public key and, if 581 untrusted, drop the connection and subsequent data. 583 Unlike some other protocols, CurveCP data packets leave only the 584 ephemeral public key, the connection ID, and the per-message nonce in 585 the clear. Everything else is encrypted. 587 3.6.2. Protocol Features 589 o Forward-secure data encryption and authentication. 591 o Per-packet public-key encryption. 593 o 1-RTT session bootstrapping. 595 o Connection mobility based on a client-chosen ephemeral identifier. 597 o Connection establishment message padding to prevent traffic 598 amplification. 600 o Sender-chosen explicit nonces, e.g., based on a sequence number. 602 3.6.3. Protocol Dependencies 604 o An unreliable transport protocol such as UDP. 606 3.7. tcpcrypt 608 Tcpcrypt is a lightweight extension to the TCP protocol to enable 609 opportunistic encryption with hooks available to the application 610 layer for implementation of endpoint authentication. 612 3.7.1. Protocol Description 614 Tcpcrypt extends TCP to enable opportunistic encryption between the 615 two ends of a TCP connection [I-D.ietf-tcpinc-tcpcrypt]. It is a 616 family of TCP encryption protocols (TEP), distinguished by key 617 exchange algorithm. The use of a TEP is negotiated with a TCP option 618 during the initial TCP handshake via the mechanism described by TCP 619 Encryption Negotiation Option (ENO) [I-D.ietf-tcpinc-tcpeno]. In the 620 case of initial session establishment, once a tcpcrypt TEP has been 621 negotiated the key exchange occurs within the data segments of the 622 first few packets exchanged after the handshake completes. The 623 initiator of a connection sends a list of supported AEAD algorithms, 624 a random nonce, and an ephemeral public key share. The responder 625 typically chooses a mutually-supported AEAD algorithm and replies 626 with this choice, its own nonce, and ephemeral key share. An initial 627 shared secret is derived from the ENO handshake, the tcpcrypt 628 handshake, and the initial keying material resulting from the key 629 exchange. The traffic encryption keys on the initial connection are 630 derived from the shared secret. Connections can be re-keyed before 631 the natural AEAD limit for a single set of traffic encryption keys is 632 reached. 634 Each tcpcrypt session is associated with a ladder of resumption IDs, 635 each derived from the respective entry in a ladder of shared secrets. 636 These resumption IDs can be used to negotiate a stateful resumption 637 of the session in a subsequent connection, resulting in use of a new 638 shared secret and traffic encryption keys without requiring a new key 639 exchange. Willingness to resume a session is signaled via the ENO 640 option during the TCP handshake. Given the length constraints 641 imposed by TCP options, unlike stateless resumption mechanisms (such 642 as that provided by session tickets in TLS) resumption in tcpcrypt 643 requires the maintenance of state on the server, and so successful 644 resumption across a pool of servers implies shared state. 646 Owing to middlebox ossification issues, tcpcrypt only protects the 647 payload portion of a TCP packet. It does not encrypt any header 648 information, such as the TCP sequence number. 650 Tcpcrypt exposes a universally-unique connection-specific session ID 651 to the application, suitable for application-level endpoint 652 authentication either in-band or out-of-band. 654 3.7.2. Protocol Features 656 o Forward-secure TCP payload encryption and integrity protection. 658 o Session caching and address-agnostic resumption. 660 o Connection re-keying. 662 o Application-level authentication primitive. 664 3.7.3. Protocol Dependencies 666 o TCP 668 o TCP Encryption Negotiation Option (ENO) 670 3.8. IKEv2 with ESP 672 IKEv2 [RFC7296] and ESP [RFC4303] together form the modern IPsec 673 protocol suite that encrypts and authenticates IP packets, either as 674 for creating tunnels (tunnel-mode) or for direct transport 675 connections (transport-mode). This suite of protocols separates out 676 the key generation protocol (IKEv2) from the transport encryption 677 protocol (ESP). Each protocol can be used independently, but this 678 document considers them together, since that is the most common 679 pattern. 681 3.8.1. Protocol descriptions 683 3.8.1.1. IKEv2 685 IKEv2 is a control protocol that runs on UDP port 500. Its primary 686 goal is to generate keys for Security Associations (SAs). It first 687 uses a Diffie-Hellman key exchange to generate keys for the "IKE SA", 688 which is a set of keys used to encrypt further IKEv2 messages. It 689 then goes through a phase of authentication in which both peers 690 present blobs signed by a shared secret or private key, after which 691 another set of keys is derived, referred to as the "Child SA". These 692 Child SA keys are used by ESP. 694 IKEv2 negotiates which protocols are acceptable to each peer for both 695 the IKE and Child SAs using "Proposals". Each proposal may contain 696 an encryption algorithm, an authentication algorithm, a Diffie- 697 Hellman group, and (for IKE SAs only) a pseudorandom function 698 algorithm. Each peer may support multiple proposals, and the most 699 preferred mutually supported proposal is chosen during the handshake. 701 The authentication phase of IKEv2 may use Shared Secrets, 702 Certificates, Digital Signatures, or an EAP (Extensible 703 Authentication Protocol) method. At a minimum, IKEv2 takes two round 704 trips to set up both an IKE SA and a Child SA. If EAP is used, this 705 exchange may be expanded. 707 Any SA used by IKEv2 can be rekeyed upon expiration, which is usually 708 based either on time or number of bytes encrypted. 710 There is an extension to IKEv2 that allows session resumption 711 [RFC5723]. 713 MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a 714 set of Security Associations to migrate over different addresses and 715 interfaces [RFC4555]. 717 When UDP is not available or well-supported on a network, IKEv2 may 718 be encapsulated in TCP [RFC8229]. 720 3.8.1.2. ESP 722 ESP is a protocol that encrypts and authenticates IPv4 and IPv6 723 packets. The keys used for both encryption and authentication can be 724 derived from an IKEv2 exchange. ESP Security Associations come as 725 pairs, one for each direction between two peers. Each SA is 726 identified by a Security Parameter Index (SPI), which is marked on 727 each encrypted ESP packet. 729 ESP packets include the SPI, a sequence number, an optional 730 Initialization Vector (IV), payload data, padding, a length and next 731 header field, and an Integrity Check Value. 733 From [RFC4303], "ESP is used to provide confidentiality, data origin 734 authentication, connectionless integrity, an anti-replay service (a 735 form of partial sequence integrity), and limited traffic flow 736 confidentiality." 738 Since ESP operates on IP packets, it is not directly tied to the 739 transport protocols it encrypts. This means it requires little or no 740 change from transports in order to provide security. 742 ESP packets may be sent directly over IP, but where network 743 conditions warrant (e.g., when a NAT is present or when a firewall 744 blocks such packets) they may be encapsulated in UDP [RFC3948] or TCP 745 [RFC8229]. 747 3.8.2. Protocol features 749 3.8.2.1. IKEv2 751 o Encryption and authentication of handshake packets. 753 o Cryptographic algorithm negotiation. 755 o Session resumption. 757 o Mobility across addresses and interfaces. 759 o Peer authentication extensibility based on shared secret, 760 certificates, digital signatures, or EAP methods. 762 3.8.2.2. ESP 764 o Data confidentiality and authentication. 766 o Connectionless integrity. 768 o Anti-replay protection. 770 o Limited flow confidentiality. 772 3.8.3. Protocol dependencies 774 3.8.3.1. IKEv2 776 o Availability of UDP to negotiate, or implementation support for 777 TCP-encapsulation. 779 o Some EAP authentication types require accessing a hardware device, 780 such as a SIM card; or interacting with a user, such as password 781 prompting. 783 3.8.3.2. ESP 785 o Since ESP is below transport protocols, it does not have any 786 dependencies on the transports themselves, other than on UDP or 787 TCP where encapsulation is employed. 789 3.9. WireGuard 791 WireGuard is a layer 3 protocol designed to complement or replace 792 IPsec [WireGuard]. Unlike most transport security protocols, which 793 rely on PKI for peer authentication, WireGuard authenticates peers 794 using pre-shared public keys delivered out-of-band, each of which is 795 bound to one or more IP addresses. Moreover, as a protocol suited 796 for VPNs, WireGuard offers no extensibility, negotiation, or 797 cryptographic agility. 799 3.9.1. Protocol description 801 WireGuard is a simple VPN protocol that binds a pre-shared public key 802 to one or more IP addresses. Users configure WireGuard by 803 associating peer public keys with IP addresses. These mappings are 804 stored in a CryptoKey Routing Table. (See Section 2 of [WireGuard] 805 for more details and sample configurations.) These keys are used 806 upon WireGuard packet transmission and reception. For example, upon 807 receipt of a Handshake Initiation message, receivers use the static 808 public key in their CryptoKey routing table to perform necessary 809 cryptographic computations. 811 WireGuard builds on Noise [Noise] for 1-RTT key exchange with 812 identity hiding. The handshake hides peer identities as per the 813 SIGMA construction [SIGMA]. As a consequence of using Noise, 814 WireGuard comes with a fixed set of cryptographic algorithms: 816 o x25519 [Curve25519] and HKDF [RFC5869] for ECDH and key 817 derivation. 819 o ChaCha20+Poly1305 [RFC7539] for packet authenticated encryption. 821 o BLAKE2s [BLAKE2] for hashing. 823 There is no cryptographic agility. If weaknesses are found in any of 824 these algorithms, new message types using new algorithms must be 825 introduced. 827 WireGuard is designed to be entirely stateless, modulo the CryptoKey 828 routing table, which has size linear with the number of trusted 829 peers. If a WireGuard receiver is under heavy load and cannot 830 process a packet, e.g., cannot spare CPU cycles for point 831 multiplication, it can reply with a cookie similar to DTLS and IKEv2. 832 This cookie only proves IP address ownership. Any rate limiting 833 scheme can be applied to packets coming from non-spoofed addresses. 835 3.9.2. Protocol features 837 o Optional PSK-based session creation. 839 o Mutual client and server authentication. 841 o Stateful, timestamp-based replay prevention. 843 o Cookie-based DoS mitigation similar to DTLS and IKEv2. 845 3.9.3. Protocol dependencies 847 o Datagram transport. 849 o Out-of-band key distribution and management. 851 3.10. SRTP (with DTLS) 853 SRTP - Secure RTP - is a profile for RTP that provides 854 confidentiality, message authentication, and replay protection for 855 data and control packets [RFC3711]. SRTP packets are encrypted using 856 a session key, which is derived from a separate master key. Master 857 keys are derived and managed externally, e.g., via DTLS, as specified 858 in RFC 5763 [RFC5763], under the control of a signaling protocol such 859 as SIP [RFC3261] or WebRTC [I-D.ietf-rtcweb-security-arch]. 861 3.10.1. Protocol descriptions 863 SRTP adds confidentiality and optional integrity protection to RTP 864 data packets, and adds confidentially and mandatory integrity 865 protection to RTP control (RTCP) packets. For RTP data packets, this 866 is done by encrypting the payload section of the packet and 867 optionally appending an authentication tag (MAC) as a packet trailer, 868 with the RTP header authenticated but not encrypted. The RTP header 869 itself is left unencrypted to enable RTP header compression 870 [RFC2508][RFC3545]. For RTCP packets, the first packet in the 871 compound RTCP packet is partially encrypted, leaving the first eight 872 octets of the header as cleartext to allow identification of the 873 packet as RTCP, while the remainder of the compound packet is fully 874 encrypted. The entire RTCP packet is then authenticated by appending 875 a MAC as packet trailer. 877 Packets are encrypted using session keys, which are ultimately 878 derived from a master key and some additional master salt and session 879 salt. SRTP packets carry a 2-byte sequence number to partially 880 identify the unique packet index. SRTP peers maintain a separate 881 rollover counter (ROC) for RTP data packets that is incremented 882 whenever the sequence number wraps. The sequence number and ROC 883 together determine the packet index. RTCP packets have a similar, 884 yet differently named, field called the RTCP index which serves the 885 same purpose. 887 Numerous encryption modes are supported. For popular modes of 888 operation, e.g., AES-CTR, the (unique) initialization vector (IV) 889 used for each encryption mode is a function of the RTP SSRC 890 (synchronization source), packet index, and session "salting key". 892 SRTP offers replay detection by keeping a replay list of already seen 893 and processed packet indices. If a packet arrives with an index that 894 matches one in the replay list, it is silently discarded. 896 DTLS [RFC5764] is commonly used as a way to perform mutual 897 authentication and key agreement for SRTP [RFC5763]. (Here, 898 certificates marshal public keys between endpoints. Thus, self- 899 signed certificates may be used if peers do not mutually trust one 900 another, as is common on the Internet.) When DTLS is used, 901 certificate fingerprints are transmitted out-of-band using SIP. 902 Peers typically verify that DTLS-offered certificates match that 903 which are offered over SIP. This prevents active attacks on RTP, but 904 not on the signaling (SIP or WebRTC) channel. 906 3.10.2. Protocol features 908 o Optional replay protection with tunable replay windows. 910 o Out-of-order packet receipt. 912 o (RFC5763) Mandatory mutually authenticated key exchange. 914 o Partial encryption, protecting media payloads and control packets 915 but not data packet headers. 917 o Optional authentication of data packets; mandatory authentication 918 of control packets. 920 3.10.3. Protocol dependencies 922 o External key derivation and management mechanism or protocol, 923 e.g., DTLS [RFC5763]. 925 o External signaling protocol to manage RTP parameters and locate 926 and identify peers, e.g., SIP [RFC3261] or WebRTC 927 [I-D.ietf-rtcweb-security-arch]. 929 4. Common Transport Security Features 931 There exists a common set of features shared across the transport 932 protocols surveyed in this document. The mandatory features should 933 be provided by any transport security protocol, while the optional 934 features are extensions that a subset of the protocols provide. For 935 clarity, we also distinguish between handshake and record features. 937 4.1. Mandatory Features 939 4.1.1. Handshake 941 o Forward-secure segment encryption and authentication: Transit data 942 must be protected with an authenticated encryption algorithm. 944 o Private key interface or injection: Authentication based on public 945 key signatures is commonplace for many transport security 946 protocols. 948 o Endpoint authentication: The endpoint (receiver) of a new 949 connection must be authenticated before any data is sent to said 950 party. 952 o Source validation: Source validation must be provided to mitigate 953 server-targeted DoS attacks. This can be done with puzzles or 954 cookies. 956 4.1.2. Record 958 o Pre-shared key support: A record protocol must be able to use a 959 pre-shared key established out-of-band to encrypt individual 960 messages, packets, or datagrams. 962 4.2. Optional Features 964 4.2.1. Handshake 966 o Mutual authentication: Transport security protocols must allow 967 each endpoint to authenticate the other if required by the 968 application. 970 o Application-layer feature negotiation: The type of application 971 using a transport security protocol often requires features 972 configured at the connection establishment layer, e.g., ALPN 973 [RFC7301]. Moreover, application-layer features may often be used 974 to offload the session to another server which can better handle 975 the request. (The TLS SNI is one example of such a feature.) As 976 such, transport security protocols should provide a generic 977 mechanism to allow for such application-specific features and 978 options to be configured or otherwise negotiated. 980 o Configuration extensions: The protocol negotiation should be 981 extensible with addition of new configuration options. 983 o Session caching and management: Sessions should be cacheable to 984 enable reuse and amortize the cost of performing session 985 establishment handshakes. 987 4.2.2. Record 989 o Connection mobility: Sessions should not be bound to a network 990 connection (or 5-tuple). This allows cryptographic key material 991 and other state information to be reused in the event of a 992 connection change. Examples of this include a NAT rebinding that 993 occurs without a client's knowledge. 995 5. Transport Security Protocol Interfaces 997 This section describes the interface surface exposed by the security 998 protocols described above, with each interface. Note that not all 999 protocols support each interface. 1001 5.1. Configuration Interfaces 1003 Configuration interfaces are used to configure the security protocols 1004 before a handshake begins or the keys are negotiated. 1006 o Identity and Private Keys 1007 The application can provide its identities (certificates) and 1008 private keys, or mechanisms to access these, to the security 1009 protocol to use during handshakes. 1010 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, 1011 WireGuard, SRTP 1013 o Supported Algorithms (Key Exchange, Signatures, and Ciphersuites) 1014 The application can choose the algorithms that are supported for 1015 key exchange, signatures, and ciphersuites. 1016 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP 1018 o Session Cache 1019 The application provides the ability to save and retrieve session 1020 state (such as tickets, keying material, and server parameters) 1021 that may be used to resume the security session. 1022 Protocols: TLS, DTLS, QUIC + TLS, MinimalT 1024 o Authentication Delegation 1025 The application provides access to a separate module that will 1026 provide authentication, using EAP for example. 1027 Protocols: IKEv2, SRTP 1029 5.2. Handshake Interfaces 1031 Handshake interfaces are the points of interaction between a 1032 handshake protocol and the application, record protocol, and 1033 transport once the handshake is active. 1035 o Send Handshake Messages 1036 The handshake protocol needs to be able to send messages over a 1037 transport to the remote peer to establish trust and to negotiate 1038 keys. 1039 Protocols: All (TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, 1040 WireGuard, SRTP (DTLS)) 1042 o Receive Handshake Messages 1043 The handshake protocol needs to be able to receive messages from 1044 the remote peer over a transport to establish trust and to 1045 negotiate keys. 1046 Protocols: All (TLS, DTLS, QUIC + TLS, MinimalT, CurveCP, IKEv2, 1047 WireGuard, SRTP (DTLS)) 1049 o Identity Validation 1050 During a handshake, the security protocol will conduct identity 1051 validation of the peer. This can call into the application to 1052 offload validation. Protocols: All (TLS, DTLS, QUIC + TLS, 1053 MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) 1055 o Source Address Validation 1056 The handshake protocol may delegate validation of the remote peer 1057 that has sent data to the transport protocol or application. This 1058 involves sending a cookie exchange to avoid DoS attacks. 1059 Protocols: QUIC + TLS, DTLS, WireGuard 1061 o Key Update 1062 The handshake protocol may be instructed to update its keying 1063 material, either by the application directly or by the record 1064 protocol sending a key expiration event. 1065 Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 1067 o Pre-Shared Key Export 1068 The handshake protocol will generate one or more keys to be used 1069 for record encryption/decryption and authentication. These may be 1070 explicitly exportable to the application, traditionally limited to 1071 direct export to the record protocol, or inherently non-exportable 1072 because the keys must be used directly in conjunction with the 1073 record protocol. 1075 * Explict export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for 1076 SRTP) 1078 * Direct export: TLS, DTLS, MinimalT 1080 * Non-exportable: CurveCP 1082 5.3. Record Interfaces 1084 Record interfaces are the points of interaction between a record 1085 protocol and the application, handshake protocol, and transport once 1086 in use. 1088 o Pre-Shared Key Import 1089 Either the handshake protocol or the application directly can 1090 supply pre-shared keys for the record protocol use for encryption/ 1091 decryption and authentication. If the application can supply keys 1092 directly, this is considered explicit import; if the handshake 1093 protocol traditionally provides the keys directly, it is 1094 considered direct import; if the keys can only be shared by the 1095 handshake, they are considered non-importable. 1097 * Explict import: QUIC, ESP 1099 * Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard 1101 * Non-importable: CurveCP 1103 o Encrypt application data 1104 The application can send data to the record protocol to encrypt it 1105 into a format that can be sent on the underlying transport. The 1106 encryption step may require that the application data is treated 1107 as a stream or as datagrams, and that the transport to send the 1108 encrypted records present a stream or datagram interface. 1110 * Stream-to-Stream Protocols: TLS, tcpcrypt 1112 * Datagram-to-Datagram Protocols: DTLS, ESP, SRTP, WireGuard 1114 * Stream-to-Datagram Protocols: QUIC ((Editor's Note: This 1115 depends on the interface QUIC exposes to applications.)) 1117 o Decrypt application data 1118 The application can receive data from its transport to be 1119 decrypted using record protocol. The decryption step may require 1120 that the incoming transport data is presented as a stream or as 1121 datagrams, and that the resulting application data is a stream or 1122 datagrams. 1124 * Stream-to-Stream Protocols: TLS, tcpcrypt 1126 * Datagram-to-Datagram Protocols: DTLS, ESP, SRTP, WireGuard 1128 * Datagram-to-Stream Protocols: QUIC ((Editor's Note: This 1129 depends on the interface QUIC exposes to applications.)) 1131 o Key Expiration 1132 The record protocol can signal that its keys are expiring due to 1133 reaching a time-based deadline, or a use-based deadline (number of 1134 bytes that have been encrypted with the key). This interaction is 1135 often limited to signaling between the record layer and the 1136 handshake layer. 1137 Protocols: ESP ((Editor's note: One may consider TLS/DTLS to also 1138 have this interface)) 1140 o Transport mobility 1141 The record protocol can be signaled that it is being migrated to 1142 another transport or interface due to connection mobility, which 1143 may reset address and state validation. 1144 Protocols: QUIC, MinimalT, CurveCP, ESP, WireGuard (roaming) 1146 6. IANA Considerations 1148 This document has no request to IANA. 1150 7. Security Considerations 1152 This document summarizes existing transport security protocols and 1153 their interfaces. It does not propose changes to or recommend usage 1154 of reference protocols. 1156 8. Acknowledgments 1158 The authors would like to thank Mirja Kuehlewind, Brian Trammell, 1159 Yannick Sierra, Frederic Jacobs, and Bob Bradley for their input and 1160 feedback on earlier versions of this draft. 1162 9. Normative References 1164 [BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d.. 1166 [Curve25519] 1167 "Curve25519 - new Diffie-Hellman speed records", n.d.. 1169 [CurveCP] "CurveCP -- Usable security for the Internet", n.d.. 1171 [I-D.ietf-quic-tls] 1172 Thomson, M. and S. Turner, "Using Transport Layer Security 1173 (TLS) to Secure QUIC", draft-ietf-quic-tls-10 (work in 1174 progress), March 2018. 1176 [I-D.ietf-quic-transport] 1177 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 1178 and Secure Transport", draft-ietf-quic-transport-10 (work 1179 in progress), March 2018. 1181 [I-D.ietf-rtcweb-security-arch] 1182 Rescorla, E., "WebRTC Security Architecture", draft-ietf- 1183 rtcweb-security-arch-13 (work in progress), October 2017. 1185 [I-D.ietf-tcpinc-tcpcrypt] 1186 Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, 1187 Q., and E. Smith, "Cryptographic protection of TCP Streams 1188 (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-11 (work in 1189 progress), November 2017. 1191 [I-D.ietf-tcpinc-tcpeno] 1192 Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. 1193 Smith, "TCP-ENO: Encryption Negotiation Option", draft- 1194 ietf-tcpinc-tcpeno-18 (work in progress), November 2017. 1196 [I-D.ietf-tls-dtls-connection-id] 1197 Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, 1198 "The Datagram Transport Layer Security (DTLS) Connection 1199 Identifier", draft-ietf-tls-dtls-connection-id-00 (work in 1200 progress), December 2017. 1202 [I-D.ietf-tls-dtls13] 1203 Rescorla, E., Tschofenig, H., and N. Modadugu, "The 1204 Datagram Transport Layer Security (DTLS) Protocol Version 1205 1.3", draft-ietf-tls-dtls13-26 (work in progress), March 1206 2018. 1208 [I-D.ietf-tls-tls13] 1209 Rescorla, E., "The Transport Layer Security (TLS) Protocol 1210 Version 1.3", draft-ietf-tls-tls13-26 (work in progress), 1211 March 2018. 1213 [MinimalT] 1214 "MinimaLT -- Minimal-latency Networking Through Better 1215 Security", n.d.. 1217 [Noise] "The Noise Protocol Framework", n.d.. 1219 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 1220 Signature Option", RFC 2385, DOI 10.17487/RFC2385, August 1221 1998, . 1223 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 1224 Headers for Low-Speed Serial Links", RFC 2508, 1225 DOI 10.17487/RFC2508, February 1999, 1226 . 1228 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1229 A., Peterson, J., Sparks, R., Handley, M., and E. 1230 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1231 DOI 10.17487/RFC3261, June 2002, 1232 . 1234 [RFC3545] Koren, T., Casner, S., Geevarghese, J., Thompson, B., and 1235 P. Ruddy, "Enhanced Compressed RTP (CRTP) for Links with 1236 High Delay, Packet Loss and Reordering", RFC 3545, 1237 DOI 10.17487/RFC3545, July 2003, 1238 . 1240 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1241 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1242 RFC 3711, DOI 10.17487/RFC3711, March 2004, 1243 . 1245 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1246 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1247 RFC 3948, DOI 10.17487/RFC3948, January 2005, 1248 . 1250 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 1251 DOI 10.17487/RFC4302, December 2005, 1252 . 1254 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1255 RFC 4303, DOI 10.17487/RFC4303, December 2005, 1256 . 1258 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1259 (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, 1260 . 1262 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1263 (TLS) Protocol Version 1.2", RFC 5246, 1264 DOI 10.17487/RFC5246, August 2008, 1265 . 1267 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 1268 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 1269 DOI 10.17487/RFC5723, January 2010, 1270 . 1272 [RFC5763] Fischl, J., Tschofenig, H., and E. Rescorla, "Framework 1273 for Establishing a Secure Real-time Transport Protocol 1274 (SRTP) Security Context Using Datagram Transport Layer 1275 Security (DTLS)", RFC 5763, DOI 10.17487/RFC5763, May 1276 2010, . 1278 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 1279 Security (DTLS) Extension to Establish Keys for the Secure 1280 Real-time Transport Protocol (SRTP)", RFC 5764, 1281 DOI 10.17487/RFC5764, May 2010, 1282 . 1284 [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand 1285 Key Derivation Function (HKDF)", RFC 5869, 1286 DOI 10.17487/RFC5869, May 2010, 1287 . 1289 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1290 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 1291 June 2010, . 1293 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1294 Extensions: Extension Definitions", RFC 6066, 1295 DOI 10.17487/RFC6066, January 2011, 1296 . 1298 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 1299 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 1300 January 2012, . 1302 [RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., 1303 Weiler, S., and T. Kivinen, "Using Raw Public Keys in 1304 Transport Layer Security (TLS) and Datagram Transport 1305 Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, 1306 June 2014, . 1308 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 1309 Kivinen, "Internet Key Exchange Protocol Version 2 1310 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 1311 2014, . 1313 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 1314 "Transport Layer Security (TLS) Application-Layer Protocol 1315 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 1316 July 2014, . 1318 [RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF 1319 Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015, 1320 . 1322 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 1323 Ed., "Services Provided by IETF Transport Protocols and 1324 Congestion Control Mechanisms", RFC 8095, 1325 DOI 10.17487/RFC8095, March 2017, 1326 . 1328 [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation 1329 of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, 1330 August 2017, . 1332 [SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated 1333 Diffie-Hellman and Its Use in the IKE-Protocols", n.d.. 1335 [WireGuard] 1336 "WireGuard -- Next Generation Kernel Network Tunnel", 1337 n.d.. 1339 Authors' Addresses 1341 Tommy Pauly 1342 Apple Inc. 1343 1 Infinite Loop 1344 Cupertino, California 95014 1345 United States of America 1347 Email: tpauly@apple.com 1349 Colin Perkins 1350 University of Glasgow 1351 School of Computing Science 1352 Glasgow G12 8QQ 1353 United Kingdom 1355 Email: csp@csperkins.org 1357 Kyle Rose 1358 Akamai Technologies, Inc. 1359 150 Broadway 1360 Cambridge, MA 02144 1361 United States of America 1363 Email: krose@krose.org 1365 Christopher A. Wood 1366 Apple Inc. 1367 1 Infinite Loop 1368 Cupertino, California 95014 1369 United States of America 1371 Email: cawood@apple.com