Original text:
TLS within QUIC relies on a reliable stream abstraction for its handshake. <del> 3.4. </del>  <del> gQUIC is a UDP-based multiplexed streaming protocol designed and deployed by Google following experience from deploying SPDY, the proprietary predecessor to HTTP/2.  gQUIC was originally known as "QUIC": this document uses gQUIC to unambiguously distinguish it from the standards-track IETF QUIC.  The proprietary technical forebear of IETF QUIC, gQUIC was originally designed with tightly-integrated security and application data transport protocols. </del>  <del> 3.4.1. </del>  ((TODO: write me)) <del> 3.4.2. </del>  ((TODO: write me)) <del> 3.5. MinimalT is a UDP-based transport security protocol designed to offer confidentiality, mutual authentication, DoS prevention, and connection mobility MinimalT.  One major goal of the protocol is to leverage existing protocols to obtain server-side configuration information used to more quickly bootstrap a connection.  MinimalT uses a variant of TCP's congestion control algorithm. 3.5.1. MinimalT is a secure transport protocol built on top of a widespread directory service.  Clients and servers interact with local directory services to (a) resolve server information and (b) public ephemeral state information, respectively.  Clients connect to a local resolver once at boot time.  Through this resolver they recover the IP address(es) and public key(s) of each server to which they want to connect. Connections are instances of user-authenticated, mobile sessions between two endpoints.  Connections run within tunnels between hosts. A tunnel is a server-authenticated container that multiplexes multiple connections between the same hosts.  All connections in a tunnel share the same transport state machine and encryption.  Each tunnel has a dedicated control connection used to configure and manage the tunnel over time.  Moreover, since tunnels are independent of the network address information, they may be reused as both ends of the tunnel move about the network.  This does however imply that the connection establishment and packet encryption mechanisms are coupled. Before a client connects to a remote service, it must first establish a tunnel to the host providing or offering the service.  Tunnels are established in 1-RTT using an ephemeral key obtained from the directory service.  Tunnel initiators provide their own ephemeral key and, optionally, a DoS puzzle solution such that the recipient (server) can verify the authenticity of the request and derive a shared secret.  Within a tunnel, new connections to services may be established. 3.5.2. 0-RTT forward secrecy for new connections. DoS prevention by client-side puzzles. Tunnel-based mobility. (Transport Feature) Connection multiplexing between hosts across shared tunnels. (Transport Feature) Congestion control state is shared across connections between the same host pairs. 3.5.3. A DNS-like resolution service to obtain location information (an IP address) and ephemeral keys. A PKI trust store for certificate validation. 3.6. CurveCP CurveCP is a UDP-based transport security protocol from Daniel J.  Bernstein.  Unlike other transport security protocols, it is based entirely upon highly efficient public key algorithms.  This removes many pitfalls associated with nonce reuse and key synchronization. 3.6.1. CurveCP is a UDP-based transport security protocol.  It is built on three principal features: exclusive use of public key authenticated encryption of packets, server-chosen cookies to prohibit memory and computation DoS at the server, and connection mobility with a client- chosen ephemeral identifier. There are two rounds in CurveCP.  In the first round, the client sends its first initialization packet to the server, carrying its (possibly fresh) ephemeral public key C', with zero-padding encrypted under the server's long-term public key.  The server replies with a cookie and its own ephemeral key S' and a cookie that is to be used by the client.  Upon receipt, the client then generates its second initialization packet carrying: the ephemeral key C', cookie, and an encryption of C', the server's domain name, and, optionally, some message data.  The server verifies the cookie and the encrypted payload and, if valid, proceeds to send data in return.  At this point, the connection is established and the two parties can communicate. The use of only public-key encryption and authentication, or "boxing", is done to simplify problems that come with symmetric key management and synchronization.  For example, it allows the sender of a message to be in complete control of each message's nonce.  It does not require either end to share secret keying material.  Furthermore, it allows connections (or sessions) to be associated with unique ephemeral public keys as a mechanism for enabling forward secrecy given the risk of long-term private key compromise. The client and server do not perform a standard key exchange. Instead, in the initial exchange of packets, each party provides its own ephemeral key to the other end.  The client can choose a new ephemeral key for every new connection.  However, the server must rotate these keys on a slower basis.  Otherwise, it would be trivial for an attacker to force the server to create and store ephemeral keys with a fake client initialization packet. Unlike TCP, the server employs cookies to enable source validation. After receiving the client's initial packet, encrypted under the server's long-term public key, the server generates and returns a stateless cookie that must be echoed back in the client's following message.  This cookie is encrypted under the client's ephemeral public key.  This stateless technique prevents attackers from hijacking client initialization packets to obtain cookie values to flood clients.  (A client would detect the duplicate cookies and reject the flooded packets.)  Similarly, replaying the client's second packet, carrying the cookie, will be detected by the server. CurveCP supports a weak form of client authentication.  Clients are permitted to send their long-term public keys in the second initialization packet.  A server can verify this public key and, if untrusted, drop the connection and subsequent data. Unlike some other protocols, CurveCP data packets leave only the ephemeral public key, the connection ID, and the per-message nonce in the clear.  Everything else is encrypted. 3.6.2. Forward-secure data encryption and authentication. Per-packet public-key encryption. 1-RTT session bootstrapping. Connection mobility based on a client-chosen ephemeral identifier. Connection establishment message padding to prevent traffic amplification. Sender-chosen explicit nonces, e.g., based on a sequence number. 3.6.3. An unreliable transport protocol such as UDP. 3.7. Tcpcrypt is a lightweight extension to the TCP protocol to enable opportunistic encryption with hooks available to the application layer for implementation of endpoint authentication. 3.7.1. Tcpcrypt extends TCP to enable opportunistic encryption between the two ends of a TCP connection I-D.ietf-tcpinc-tcpcrypt.  It is a family of TCP encryption protocols (TEP), distinguished by key exchange algorithm.  The use of a TEP is negotiated with a TCP option during the initial TCP handshake via the mechanism described by TCP Encryption Negotiation Option (ENO) I-D.ietf-tcpinc-tcpeno.  In the case of initial session establishment, once a tcpcrypt TEP has been negotiated the key exchange occurs within the data segments of the first few packets exchanged after the handshake completes.  The initiator of a connection sends a list of supported AEAD algorithms, a random nonce, and an ephemeral public key share.  The responder typically chooses a mutually-supported AEAD algorithm and replies with this choice, its own nonce, and ephemeral key share.  An initial shared secret is derived from the ENO handshake, the tcpcrypt handshake, and the initial keying material resulting from the key exchange.  The traffic encryption keys on the initial connection are derived from the shared secret.  Connections can be re-keyed before the natural AEAD limit for a single set of traffic encryption keys is reached. Each tcpcrypt session is associated with a ladder of resumption IDs, each derived from the respective entry in a ladder of shared secrets. These resumption IDs can be used to negotiate a stateful resumption of the session in a subsequent connection, resulting in use of a new shared secret and traffic encryption keys without requiring a new key exchange.  Willingness to resume a session is signaled via the ENO option during the TCP handshake.  Given the length constraints imposed by TCP options, unlike stateless resumption mechanisms (such as that provided by session tickets in TLS) resumption in tcpcrypt requires the maintenance of state on the server, and so successful resumption across a pool of servers implies shared state. Owing to middlebox ossification issues, tcpcrypt only protects the payload portion of a TCP packet.  It does not encrypt any header information, such as the TCP sequence number. Tcpcrypt exposes a universally-unique connection-specific session ID to the application, suitable for application-level endpoint authentication either in-band or out-of-band. 3.7.2. Forward-secure TCP payload encryption and integrity protection. Session caching and address-agnostic resumption. Connection re-keying. Application-level authentication primitive. 3.7.3. TCP TCP Encryption Negotiation Option (ENO) 3.8. </del>  IKEv2 RFC7296 and ESP RFC4303 together form the modern IPsec protocol suite that encrypts and authenticates IP packets, either as for (ESP).  Each protocol can be used independently, but this document considers them together, since that is the most common pattern. <del> 3.8.1. </del>  <del> 3.8.1.1. </del>  IKEv2 is a control protocol that runs on UDP port 500.  Its primary goal is to generate keys for Security Associations (SAs).  It first When UDP is not available or well-supported on a network, IKEv2 may be encapsulated in TCP RFC8229. <del> 3.8.1.2. </del>  ESP is a protocol that encrypts and authenticates IPv4 and IPv6 packets.  The keys used for both encryption and authentication can be blocks such packets) they may be encapsulated in UDP RFC3948 or TCP RFC8229. <del> 3.8.2. </del>  <del> 3.8.2.1. </del>  Encryption and authentication of handshake packets. Peer authentication extensibility based on shared secret, certificates, digital signatures, or EAP methods. <del> 3.8.2.2. </del>  Data confidentiality and authentication. Limited flow confidentiality. <del> 3.8.3. </del>  <del> 3.8.3.1. </del>  Availability of UDP to negotiate, or implementation support for TCP-encapsulation. such as a SIM card; or interacting with a user, such as password prompting. <del> 3.8.3.2. </del>  Since ESP is below transport protocols, it does not have any dependencies on the transports themselves, other than on UDP or TCP where encapsulation is employed. <del> 3.9. </del>  <del> WireGuard is a layer 3 protocol designed to complement or replace IPsec WireGuard.  Unlike most transport security protocols, which rely on PKI for peer authentication, WireGuard authenticates peers using pre-shared public keys delivered out-of-band, each of which is bound to one or more IP addresses.  Moreover, as a protocol suited for VPNs, WireGuard offers no extensibility, negotiation, or cryptographic agility. </del>  <del> 3.9.1. </del>  <del> WireGuard is a simple VPN protocol that binds a pre-shared public key to one or more IP addresses.  Users configure WireGuard by associating peer public keys with IP addresses.  These mappings are stored in a CryptoKey Routing Table.  (See Section 2 of WireGuard for more details and sample configurations.)  These keys are used upon WireGuard packet transmission and reception.  For example, upon receipt of a Handshake Initiation message, receivers use the static public key in their CryptoKey routing table to perform necessary cryptographic computations. </del>  WireGuard builds on Noise Noise for 1-RTT key exchange with identity hiding.  The handshake hides peer identities as per the SIGMA This cookie only proves IP address ownership.  Any rate limiting scheme can be applied to packets coming from non-spoofed addresses. <del> 3.9.2. </del>  Optional PSK-based session creation. Cookie-based DoS mitigation similar to DTLS and IKEv2. <del> 3.9.3. </del>  Datagram transport. Out-of-band key distribution and management.  3.10. <del> SRTP - Secure RTP - is a profile for RTP that provides confidentiality, message authentication, and replay protection for data and control packets RFC3711.  SRTP packets are encrypted using a session key, which is derived from a separate master key.  Master keys are derived and managed externally, e.g., via DTLS, as specified in RFC 5763 RFC5763, under the control of a signaling protocol such as SIP RFC3261 or WebRTC I-D.ietf-rtcweb-security-arch. </del>  3.10.1. <del> SRTP adds confidentiality and optional integrity protection to RTP data packets, and adds confidentially and mandatory integrity protection to RTP control (RTCP) packets.  For RTP data packets, this is done by encrypting the payload section of the packet and optionally appending an authentication tag (MAC) as a packet trailer, with the RTP header authenticated but not encrypted.  The RTP header itself is left unencrypted to enable RTP header compression RFC3545. For RTCP packets, the first packet in the compound RTCP packet is partially encrypted, leaving the first eight octets of the header as cleartext to allow identification of the packet as RTCP, while the remainder of the compound packet is fully encrypted.  The entire RTCP packet is then authenticated by appending a MAC as packet trailer. </del>  <del> Packets are encrypted using session keys, which are ultimately derived from a master key and some additional master salt and session salt.  SRTP packets carry a 2-byte sequence number to partially identify the unique packet index.  SRTP peers maintain a separate rollover counter (ROC) for RTP data packets that is incremented whenever the sequence number wraps.  The sequence number and ROC together determine the packet index.  RTCP packets have a similar, yet differently named, field called the RTCP index which serves the same purpose. </del>  <del> Numerous encryption modes are supported.  For popular modes of operation, e.g., AES-CTR, the (unique) initialization vector (IV) used for each encryption mode is a function of the RTP SSRC (synchronization source), packet index, and session "salting key". </del>  <del> SRTP offers replay detection by keeping a replay list of already seen and processed packet indices.  If a packet arrives with an index that matches one in the replay list, it is silently discarded. </del>  <del> DTLS RFC5764 is commonly used as a way to perform mutual authentication and key agreement for SRTP RFC5763.  (Here, certificates marshal public keys between endpoints.  Thus, self- signed certificates may be used if peers do not mutually trust one another, as is common on the Internet.)  When DTLS is used, certificate fingerprints are transmitted out-of-band using SIP. Peers typically verify that DTLS-offered certificates match that which are offered over SIP.  This prevents active attacks on RTP, but not on the signaling (SIP or WebRTC) channel. </del>  3.10.2. <del> Optional replay protection with tunable replay windows. </del>  <del> Out-of-order packet receipt. </del>  <del> (RFC5763) Mandatory mutually authenticated key exchange. </del>  <del> Partial encryption, protecting media payloads and control packets but not data packet headers. </del>  <del> Optional authentication of data packets; mandatory authentication of control packets. </del>  <del> 3.10.3. </del>  <del> External key derivation and management mechanism or protocol, e.g., DTLS RFC5763. </del>  <del> External signaling protocol to manage RTP parameters and locate and identify peers, e.g., SIP RFC3261 or WebRTC I-D.ietf-rtcweb- security-arch. </del>  4.

Reviewer comments:
Sort the protocols we describe based on perceived importance, popularity, etc. Basically, put non-standard ones at the end, and all else towards the front.
Correct!
I'm assuming the content itself hasn't changed, just moved around? It's not obvious from the diff, so LMK if not and I'll un-approve.

Revised text:
TLS within QUIC relies on a reliable stream abstraction for its handshake.  <ins> 3.3.4. </ins>  <ins> Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol designed and deployed by Google following experience from deploying SPDY, the proprietary predecessor to HTTP/2.  gQUIC was originally known as "QUIC": this document uses gQUIC to unambiguously distinguish it from the standards-track IETF QUIC.  The proprietary technical forebear of IETF QUIC, gQUIC was originally designed with tightly-integrated security and application data transport protocols. </ins>  <ins> 3.3.5. </ins> ((TODO: write me))  <ins> 3.3.6. </ins> ((TODO: write me))  <ins> 3.4. </ins> IKEv2 RFC7296 and ESP RFC4303 together form the modern IPsec protocol suite that encrypts and authenticates IP packets, either as for (ESP).  Each protocol can be used independently, but this document considers them together, since that is the most common pattern.  <ins> 3.4.1. </ins>  <ins> 3.4.1.1. </ins> IKEv2 is a control protocol that runs on UDP port 500.  Its primary goal is to generate keys for Security Associations (SAs).  It first When UDP is not available or well-supported on a network, IKEv2 may be encapsulated in TCP RFC8229.  <ins> 3.4.1.2. </ins> ESP is a protocol that encrypts and authenticates IPv4 and IPv6 packets.  The keys used for both encryption and authentication can be blocks such packets) they may be encapsulated in UDP RFC3948 or TCP RFC8229.  <ins> 3.4.2. </ins>  <ins> 3.4.2.1. </ins> Encryption and authentication of handshake packets. Peer authentication extensibility based on shared secret, certificates, digital signatures, or EAP methods.  <ins> 3.4.2.2. </ins> Data confidentiality and authentication. Limited flow confidentiality.  <ins> 3.4.3. </ins>  <ins> 3.4.3.1. </ins> Availability of UDP to negotiate, or implementation support for TCP-encapsulation. such as a SIM card; or interacting with a user, such as password prompting.  <ins> 3.4.3.2. </ins> Since ESP is below transport protocols, it does not have any dependencies on the transports themselves, other than on UDP or TCP where encapsulation is employed.  <ins> 3.5. </ins>  <ins> SRTP - Secure RTP - is a profile for RTP that provides confidentiality, message authentication, and replay protection for data and control packets RFC3711.  SRTP packets are encrypted using a session key, which is derived from a separate master key.  Master keys are derived and managed externally, e.g., via DTLS, as specified in RFC 5763 RFC5763, under the control of a signaling protocol such as SIP RFC3261 or WebRTC I-D.ietf-rtcweb-security-arch. </ins>  <ins> 3.5.1. </ins>  <ins> SRTP adds confidentiality and optional integrity protection to RTP data packets, and adds confidentially and mandatory integrity protection to RTP control (RTCP) packets.  For RTP data packets, this is done by encrypting the payload section of the packet and optionally appending an authentication tag (MAC) as a packet trailer, with the RTP header authenticated but not encrypted.  The RTP header itself is left unencrypted to enable RTP header compression RFC3545. For RTCP packets, the first packet in the compound RTCP packet is partially encrypted, leaving the first eight octets of the header as cleartext to allow identification of the packet as RTCP, while the remainder of the compound packet is fully encrypted.  The entire RTCP packet is then authenticated by appending a MAC as packet trailer. Packets are encrypted using session keys, which are ultimately derived from a master key and some additional master salt and session salt.  SRTP packets carry a 2-byte sequence number to partially identify the unique packet index.  SRTP peers maintain a separate rollover counter (ROC) for RTP data packets that is incremented whenever the sequence number wraps.  The sequence number and ROC together determine the packet index.  RTCP packets have a similar, yet differently named, field called the RTCP index which serves the same purpose. Numerous encryption modes are supported.  For popular modes of operation, e.g., AES-CTR, the (unique) initialization vector (IV) used for each encryption mode is a function of the RTP SSRC (synchronization source), packet index, and session "salting key". SRTP offers replay detection by keeping a replay list of already seen and processed packet indices.  If a packet arrives with an index that matches one in the replay list, it is silently discarded. DTLS RFC5764 is commonly used as a way to perform mutual authentication and key agreement for SRTP RFC5763.  (Here, certificates marshal public keys between endpoints.  Thus, self- signed certificates may be used if peers do not mutually trust one another, as is common on the Internet.)  When DTLS is used, certificate fingerprints are transmitted out-of-band using SIP. Peers typically verify that DTLS-offered certificates match that which are offered over SIP.  This prevents active attacks on RTP, but not on the signaling (SIP or WebRTC) channel. 3.5.2. Optional replay protection with tunable replay windows. Out-of-order packet receipt. (RFC5763) Mandatory mutually authenticated key exchange. Partial encryption, protecting media payloads and control packets but not data packet headers. Optional authentication of data packets; mandatory authentication of control packets. 3.5.3. External key derivation and management mechanism or protocol, e.g., DTLS RFC5763. External signaling protocol to manage RTP parameters and locate and identify peers, e.g., SIP RFC3261 or WebRTC I-D.ietf-rtcweb- security-arch. 3.6. ((TODO: write me)) 3.7. Tcpcrypt is a lightweight extension to the TCP protocol to enable opportunistic encryption with hooks available to the application layer for implementation of endpoint authentication. 3.7.1. Tcpcrypt extends TCP to enable opportunistic encryption between the two ends of a TCP connection I-D.ietf-tcpinc-tcpcrypt.  It is a family of TCP encryption protocols (TEP), distinguished by key exchange algorithm.  The use of a TEP is negotiated with a TCP option during the initial TCP handshake via the mechanism described by TCP Encryption Negotiation Option (ENO) I-D.ietf-tcpinc-tcpeno.  In the case of initial session establishment, once a tcpcrypt TEP has been negotiated the key exchange occurs within the data segments of the first few packets exchanged after the handshake completes.  The initiator of a connection sends a list of supported AEAD algorithms, a random nonce, and an ephemeral public key share.  The responder typically chooses a mutually-supported AEAD algorithm and replies with this choice, its own nonce, and ephemeral key share.  An initial shared secret is derived from the ENO handshake, the tcpcrypt handshake, and the initial keying material resulting from the key exchange.  The traffic encryption keys on the initial connection are derived from the shared secret.  Connections can be re-keyed before the natural AEAD limit for a single set of traffic encryption keys is reached. Each tcpcrypt session is associated with a ladder of resumption IDs, each derived from the respective entry in a ladder of shared secrets. These resumption IDs can be used to negotiate a stateful resumption of the session in a subsequent connection, resulting in use of a new shared secret and traffic encryption keys without requiring a new key exchange.  Willingness to resume a session is signaled via the ENO option during the TCP handshake.  Given the length constraints imposed by TCP options, unlike stateless resumption mechanisms (such as that provided by session tickets in TLS) resumption in tcpcrypt requires the maintenance of state on the server, and so successful resumption across a pool of servers implies shared state. Owing to middlebox ossification issues, tcpcrypt only protects the payload portion of a TCP packet.  It does not encrypt any header information, such as the TCP sequence number. Tcpcrypt exposes a universally-unique connection-specific session ID to the application, suitable for application-level endpoint authentication either in-band or out-of-band. 3.7.2. Forward-secure TCP payload encryption and integrity protection. Session caching and address-agnostic resumption. Connection re-keying. Application-level authentication primitive. 3.7.3. TCP TCP Encryption Negotiation Option (ENO) 3.8. WireGuard is a layer 3 protocol designed to complement or replace IPsec WireGuard.  Unlike most transport security protocols, which rely on PKI for peer authentication, WireGuard authenticates peers using pre-shared public keys delivered out-of-band, each of which is bound to one or more IP addresses.  Moreover, as a protocol suited for VPNs, WireGuard offers no extensibility, negotiation, or cryptographic agility. 3.8.1. WireGuard is a simple VPN protocol that binds a pre-shared public key to one or more IP addresses.  Users configure WireGuard by associating peer public keys with IP addresses.  These mappings are stored in a CryptoKey Routing Table.  (See Section 2 of WireGuard for more details and sample configurations.)  These keys are used upon WireGuard packet transmission and reception.  For example, upon receipt of a Handshake Initiation message, receivers use the static public key in their CryptoKey routing table to perform necessary cryptographic computations. </ins> WireGuard builds on Noise Noise for 1-RTT key exchange with identity hiding.  The handshake hides peer identities as per the SIGMA This cookie only proves IP address ownership.  Any rate limiting scheme can be applied to packets coming from non-spoofed addresses.  <ins> 3.8.2. </ins> Optional PSK-based session creation. Cookie-based DoS mitigation similar to DTLS and IKEv2.  <ins> 3.8.3. </ins> Datagram transport. Out-of-band key distribution and management. <ins> 3.9. MinimalT is a UDP-based transport security protocol designed to offer confidentiality, mutual authentication, DoS prevention, and connection mobility MinimalT.  One major goal of the protocol is to leverage existing protocols to obtain server-side configuration information used to more quickly bootstrap a connection.  MinimalT uses a variant of TCP's congestion control algorithm. 3.9.1. MinimalT is a secure transport protocol built on top of a widespread directory service.  Clients and servers interact with local directory services to (a) resolve server information and (b) public ephemeral state information, respectively.  Clients connect to a local resolver once at boot time.  Through this resolver they recover the IP address(es) and public key(s) of each server to which they want to connect. Connections are instances of user-authenticated, mobile sessions between two endpoints.  Connections run within tunnels between hosts. A tunnel is a server-authenticated container that multiplexes multiple connections between the same hosts.  All connections in a tunnel share the same transport state machine and encryption.  Each tunnel has a dedicated control connection used to configure and manage the tunnel over time.  Moreover, since tunnels are independent of the network address information, they may be reused as both ends of the tunnel move about the network.  This does however imply that the connection establishment and packet encryption mechanisms are coupled. Before a client connects to a remote service, it must first establish a tunnel to the host providing or offering the service.  Tunnels are established in 1-RTT using an ephemeral key obtained from the directory service.  Tunnel initiators provide their own ephemeral key and, optionally, a DoS puzzle solution such that the recipient (server) can verify the authenticity of the request and derive a shared secret.  Within a tunnel, new connections to services may be established. 3.9.2. 0-RTT forward secrecy for new connections. DoS prevention by client-side puzzles. Tunnel-based mobility. (Transport Feature) Connection multiplexing between hosts across shared tunnels. (Transport Feature) Congestion control state is shared across connections between the same host pairs. 3.9.3. A DNS-like resolution service to obtain location information (an IP address) and ephemeral keys. A PKI trust store for certificate validation. </ins> 3.10.  <ins> CurveCP CurveCP is a UDP-based transport security protocol from Daniel J.  Bernstein.  Unlike other transport security protocols, it is based entirely upon highly efficient public key algorithms.  This removes many pitfalls associated with nonce reuse and key synchronization. </ins> 3.10.1.  <ins> CurveCP is a UDP-based transport security protocol.  It is built on three principal features: exclusive use of public key authenticated encryption of packets, server-chosen cookies to prohibit memory and computation DoS at the server, and connection mobility with a client- chosen ephemeral identifier. </ins>  <ins> There are two rounds in CurveCP.  In the first round, the client sends its first initialization packet to the server, carrying its (possibly fresh) ephemeral public key C', with zero-padding encrypted under the server's long-term public key.  The server replies with a cookie and its own ephemeral key S' and a cookie that is to be used by the client.  Upon receipt, the client then generates its second initialization packet carrying: the ephemeral key C', cookie, and an encryption of C', the server's domain name, and, optionally, some message data.  The server verifies the cookie and the encrypted payload and, if valid, proceeds to send data in return.  At this point, the connection is established and the two parties can communicate. </ins>  <ins> The use of only public-key encryption and authentication, or "boxing", is done to simplify problems that come with symmetric key management and synchronization.  For example, it allows the sender of a message to be in complete control of each message's nonce.  It does not require either end to share secret keying material.  Furthermore, it allows connections (or sessions) to be associated with unique ephemeral public keys as a mechanism for enabling forward secrecy given the risk of long-term private key compromise. </ins>  <ins> The client and server do not perform a standard key exchange. Instead, in the initial exchange of packets, each party provides its own ephemeral key to the other end.  The client can choose a new ephemeral key for every new connection.  However, the server must rotate these keys on a slower basis.  Otherwise, it would be trivial for an attacker to force the server to create and store ephemeral keys with a fake client initialization packet. </ins>  <ins> Unlike TCP, the server employs cookies to enable source validation. After receiving the client's initial packet, encrypted under the server's long-term public key, the server generates and returns a stateless cookie that must be echoed back in the client's following message.  This cookie is encrypted under the client's ephemeral public key.  This stateless technique prevents attackers from hijacking client initialization packets to obtain cookie values to flood clients.  (A client would detect the duplicate cookies and reject the flooded packets.)  Similarly, replaying the client's second packet, carrying the cookie, will be detected by the server. CurveCP supports a weak form of client authentication.  Clients are permitted to send their long-term public keys in the second initialization packet.  A server can verify this public key and, if untrusted, drop the connection and subsequent data. Unlike some other protocols, CurveCP data packets leave only the ephemeral public key, the connection ID, and the per-message nonce in the clear.  Everything else is encrypted. </ins> 3.10.2.  <ins> Forward-secure data encryption and authentication. </ins>  <ins> Per-packet public-key encryption. </ins>  <ins> 1-RTT session bootstrapping. </ins>  <ins> Connection mobility based on a client-chosen ephemeral identifier. </ins>  <ins> Connection establishment message padding to prevent traffic amplification. </ins>  <ins> Sender-chosen explicit nonces, e.g., based on a sequence number. </ins>  <ins> 3.10.3. </ins>  <ins> An unreliable transport protocol such as UDP. </ins> 4.