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