draft-ietf-taps-transport-security-08.txt   draft-ietf-taps-transport-security-09.txt 
Network Working Group C. Wood, Ed. Network Working Group C. Wood, Ed.
Internet-Draft Apple Inc. Internet-Draft Apple Inc.
Intended status: Informational T. Enghardt Intended status: Informational T. Enghardt
Expires: February 8, 2020 TU Berlin Expires: March 31, 2020 TU Berlin
T. Pauly T. Pauly
Apple Inc. Apple Inc.
C. Perkins C. Perkins
University of Glasgow University of Glasgow
K. Rose K. Rose
Akamai Technologies, Inc. Akamai Technologies, Inc.
August 07, 2019 September 28, 2019
A Survey of Transport Security Protocols A Survey of Transport Security Protocols
draft-ietf-taps-transport-security-08 draft-ietf-taps-transport-security-09
Abstract Abstract
This document provides a survey of commonly used or notable network This document provides a survey of commonly used or notable network
security protocols, with a focus on how they interact and integrate security protocols, with a focus on how they interact and integrate
with applications and transport protocols. Its goal is to supplement with applications and transport protocols. Its goal is to supplement
efforts to define and catalog transport services by describing the efforts to define and catalog transport services by describing the
interfaces required to add security protocols. This survey is not interfaces required to add security protocols. This survey is not
limited to protocols developed within the scope or context of the limited to protocols developed within the scope or context of the
IETF, and those included represent a superset of features a Transport IETF, and those included represent a superset of features a Transport
skipping to change at page 1, line 46 skipping to change at page 1, line 46
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 8, 2020. This Internet-Draft will expire on March 31, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 7, line 42 skipping to change at page 7, line 42
4. Transport Security Protocol Descriptions 4. Transport Security Protocol Descriptions
This section contains descriptions of security protocols currently This section contains descriptions of security protocols currently
used to protect data being sent over a network. used to protect data being sent over a network.
For each protocol, we describe its provided features and dependencies For each protocol, we describe its provided features and dependencies
on other protocols. on other protocols.
4.1. TLS 4.1. TLS
TLS (Transport Layer Security) [RFC5246] is a common protocol used to TLS (Transport Layer Security) [RFC8446] is a common protocol used to
establish a secure session between two endpoints. Communication over establish a secure session between two endpoints. Communication over
this session "prevents eavesdropping, tampering, and message this session "prevents eavesdropping, tampering, and message
forgery." TLS consists of a tightly coupled handshake and record forgery." TLS consists of a tightly coupled handshake and record
protocol. The handshake protocol is used to authenticate peers, protocol. The handshake protocol is used to authenticate peers,
negotiate protocol options, such as cryptographic algorithms, and negotiate protocol options, such as cryptographic algorithms, and
derive session-specific keying material. The record protocol is used derive session-specific keying material. The record protocol is used
to marshal (possibly encrypted) data from one peer to the other. to marshal (possibly encrypted) data from one peer to the other.
This data may contain handshake messages or raw application data. This data may contain handshake messages or raw application data.
4.1.1. Protocol Description 4.1.1. Protocol Description
skipping to change at page 9, line 45 skipping to change at page 9, line 45
4.1.3. Protocol Dependencies 4.1.3. Protocol Dependencies
o In-order, reliable bytestream transport. o In-order, reliable bytestream transport.
o (Optionally) A PKI trust store for certificate validation. o (Optionally) A PKI trust store for certificate validation.
4.2. DTLS 4.2. DTLS
DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS, DTLS (Datagram Transport Layer Security) [RFC6347] is based on TLS,
but differs in that it is designed to run over unrelaible datagram but differs in that it is designed to run over unreliable datagram
protocols like UDP instead of TCP. DTLS modifies the protocol to protocols like UDP instead of TCP. DTLS modifies the protocol to
make sure it can still provide the same security guarantees as TLS make sure it can still provide the same security guarantees as TLS
even without reliability from the transport. DTLS was designed to be even without reliability from the transport. DTLS was designed to be
as similar to TLS as possible, so this document assumes that all as similar to TLS as possible, so this document assumes that all
properties from TLS are carried over except where specified. properties from TLS are carried over except where specified.
4.2.1. Protocol Description 4.2.1. Protocol Description
DTLS is modified from TLS to operate with the possibility of packet DTLS is modified from TLS to operate with the possibility of packet
loss, reordering, and duplication that may occur when operating over loss, reordering, and duplication that may occur when operating over
skipping to change at page 10, line 31 skipping to change at page 10, line 31
handshake messages across records. The receiver must reassemble handshake messages across records. The receiver must reassemble
records before processing. records before processing.
DTLS relies on unique UDP 4-tuples to identify connections, or a DTLS relies on unique UDP 4-tuples to identify connections, or a
similar mechanism in other datagram transports. Since all similar mechanism in other datagram transports. Since all
application-layer data is encrypted, demultiplexing over the same application-layer data is encrypted, demultiplexing over the same
4-tuple requires the use of a connection identifier extension 4-tuple requires the use of a connection identifier extension
[I-D.ietf-tls-dtls-connection-id] to permit identification of the [I-D.ietf-tls-dtls-connection-id] to permit identification of the
correct connection-specific cryptographic context without the use of correct connection-specific cryptographic context without the use of
trial decryption. (Note that this extension is only supported in trial decryption. (Note that this extension is only supported in
DTLS 1.2 and 1.3 {{?I-D.ietf-tls-dtls13}.) DTLS 1.2 and 1.3 [I-D.ietf-tls-dtls13].)
Since datagrams can be replayed, DTLS provides optional anti-replay Since datagrams can be replayed, DTLS provides optional anti-replay
detection based on a window of acceptable sequence numbers [RFC6347]. detection based on a window of acceptable sequence numbers [RFC6347].
4.2.2. Security Features 4.2.2. Security Features
o Record replay protection. o Record replay protection.
o Record (datagram) confidentiality and integrity. o Record (datagram) confidentiality and integrity.
skipping to change at page 12, line 17 skipping to change at page 12, line 17
as the Initial and Handshake packets. as the Initial and Handshake packets.
4.3.2. Security Features 4.3.2. Security Features
o DoS mitigation (cookie-based). o DoS mitigation (cookie-based).
See also the properties of TLS. See also the properties of TLS.
4.3.3. Protocol Dependencies 4.3.3. Protocol Dependencies
o QUIC transport relies on UDP. o QUIC transport assumes an unreliable transport, e.g., UDP.
o QUIC transport relies on TLS 1.3 for key exchange, peer o QUIC transport relies on TLS 1.3 for key exchange, peer
authentication, and shared secret derivation. authentication, and shared secret derivation.
o For the handshake: Reliable, in-order transport. QUIC provides o For the handshake: Reliable, in-order transport. QUIC provides
its own reliability. its own reliability.
4.3.4. Variant: Google QUIC 4.3.4. Variant: Google QUIC
Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol
skipping to change at page 13, line 25 skipping to change at page 13, line 25
Diffie-Hellman group, and (for IKE SAs only) a pseudorandom function Diffie-Hellman group, and (for IKE SAs only) a pseudorandom function
algorithm. Each peer may support multiple proposals, and the most algorithm. Each peer may support multiple proposals, and the most
preferred mutually supported proposal is chosen during the handshake. preferred mutually supported proposal is chosen during the handshake.
The authentication phase of IKEv2 may use Shared Secrets, The authentication phase of IKEv2 may use Shared Secrets,
Certificates, Digital Signatures, or an EAP (Extensible Certificates, Digital Signatures, or an EAP (Extensible
Authentication Protocol) method. At a minimum, IKEv2 takes two round Authentication Protocol) method. At a minimum, IKEv2 takes two round
trips to set up both an IKE SA and a Child SA. If EAP is used, this trips to set up both an IKE SA and a Child SA. If EAP is used, this
exchange may be expanded. exchange may be expanded.
Any SA used by IKEv2 can be rekeyed before expiration, which is Any SA used by IKEv2 can be re-keyed before expiration, which is
usually based either on time or number of bytes encrypted. usually based either on time or number of bytes encrypted.
There is an extension to IKEv2 that allows session resumption There is an extension to IKEv2 that allows session resumption
[RFC5723]. [RFC5723].
MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a MOBIKE is a Mobility and Multihoming extension to IKEv2 that allows a
set of Security Associations to migrate over different outer IP set of Security Associations to migrate over different outer IP
addresses and interfaces [RFC4555]. addresses and interfaces [RFC4555].
When UDP is not available or well-supported on a network, IKEv2 may When UDP is not available or well-supported on a network, IKEv2 may
skipping to change at page 16, line 15 skipping to change at page 16, line 15
SRTP offers replay detection by keeping a replay list of already seen SRTP offers replay detection by keeping a replay list of already seen
and processed packet indices. If a packet arrives with an index that and processed packet indices. If a packet arrives with an index that
matches one in the replay list, it is silently discarded. matches one in the replay list, it is silently discarded.
DTLS [RFC5764] is commonly used to perform mutual authentication and DTLS [RFC5764] is commonly used to perform mutual authentication and
key agreement for SRTP [RFC5763]. Peers use DTLS to perform mutual key agreement for SRTP [RFC5763]. Peers use DTLS to perform mutual
certificate-based authentication on the media path, and to generate certificate-based authentication on the media path, and to generate
the SRTP master key. Peer certificates can be issued and signed by a the SRTP master key. Peer certificates can be issued and signed by a
certificate authority. Alternatively, certificates used in the DTLS certificate authority. Alternatively, certificates used in the DTLS
exchange can be self-signed. If they are self-signed, certificate exchange can be self-signed. If they are self-signed, certificate
fingerprints are included in the signalling exchange (e.g., in SIP or fingerprints are included in the signaling exchange (e.g., in SIP or
WebRTC), and used to bind the DTLS key exchange in the media plane to WebRTC), and used to bind the DTLS key exchange in the media plane to
the signaling plane. The combination of a mutually authenticated the signaling plane. The combination of a mutually authenticated
DTLS key exchange on the media path and a fingerprint sent in the DTLS key exchange on the media path and a fingerprint sent in the
signalling channel protects against active attacks on the media, signaling channel protects against active attacks on the media,
provided the signalling can be trusted. Signalling needs to be provided the signaling can be trusted. Signaling needs to be
protected as described in, for example, SIP [RFC3261] Authenticated protected as described in, for example, SIP [RFC3261] Authenticated
Identity Management [RFC4474] or the WebRTC security architecture Identity Management [RFC8224] or the WebRTC security architecture
[I-D.ietf-rtcweb-security-arch], to provide complete system security. [I-D.ietf-rtcweb-security-arch], to provide complete system security.
4.5.2. Security Features 4.5.2. Security Features
o Forward-secure session key establishment. o Forward-secure session key establishment.
o Cryptographic algorithm negotiation. o Cryptographic algorithm negotiation.
o Mutual authentication. o Mutual authentication.
skipping to change at page 16, line 50 skipping to change at page 16, line 50
o Out-of-order record receipt. o Out-of-order record receipt.
4.5.3. Protocol Dependencies 4.5.3. Protocol Dependencies
o Secure RTP can run over UDP or TCP. o Secure RTP can run over UDP or TCP.
o External key derivation and management protocol, e.g., DTLS o External key derivation and management protocol, e.g., DTLS
[RFC5763]. [RFC5763].
o External identity management protocol, e.g., SIP Authenticated o External identity management protocol, e.g., SIP Authenticated
Identity Management [RFC4474], WebRTC Security Architecture Identity Management [RFC8224], WebRTC Security Architecture
[I-D.ietf-rtcweb-security-arch]. [I-D.ietf-rtcweb-security-arch].
4.5.4. Variant: ZRTP for Media Path Key Agreement 4.5.4. Variant: ZRTP for Media Path Key Agreement
ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It ZRTP [RFC6189] is an alternative key agreement protocol for SRTP. It
uses standard SRTP to protect RTP data packets and RTCP packets, but uses standard SRTP to protect RTP data packets and RTCP packets, but
provides alternative key agreement and identity management protocols. provides alternative key agreement and identity management protocols.
Key agreement is performed using a Diffie-Hellman key exchange that Key agreement is performed using a Diffie-Hellman key exchange that
runs on the media path. This generates a shared secret that is then runs on the media path. This generates a shared secret that is then
skipping to change at page 17, line 28 skipping to change at page 17, line 28
requires endpoints to display a short authentication string that the requires endpoints to display a short authentication string that the
users must read and verbally compare to validate the hashes and users must read and verbally compare to validate the hashes and
ensure security. Endpoints cache some key material after the first ensure security. Endpoints cache some key material after the first
call to use in subsequent calls; this is mixed in with the Diffie- call to use in subsequent calls; this is mixed in with the Diffie-
Hellman shared secret, so the short authentication string need only Hellman shared secret, so the short authentication string need only
be checked once for a given user. This gives key continuity be checked once for a given user. This gives key continuity
properties analogous to the secure shell (ssh) [RFC4253]. properties analogous to the secure shell (ssh) [RFC4253].
4.6. tcpcrypt 4.6. tcpcrypt
Tcpcrypt is a lightweight extension to the TCP protocol for Tcpcrypt [RFC8548] is a lightweight extension to the TCP protocol for
opportunistic encryption. Applications may use tcpcrypt's unique opportunistic encryption. Applications may use tcpcrypt's unique
session ID for further application-level authentication. Absent this session ID for further application-level authentication. Absent this
authentication, tcpcrypt is vulnerable to active attacks. authentication, tcpcrypt is vulnerable to active attacks.
4.6.1. Protocol Description 4.6.1. Protocol Description
Tcpcrypt extends TCP to enable opportunistic encryption between the Tcpcrypt extends TCP to enable opportunistic encryption between the
two ends of a TCP connection [RFC8548]. It is a family of TCP two ends of a TCP connection [RFC8548]. It is a family of TCP
encryption protocols (TEP), distinguished by key exchange algorithm. encryption protocols (TEP), distinguished by key exchange algorithm.
The use of a TEP is negotiated with a TCP option during the initial The use of a TEP is negotiated with a TCP option during the initial
skipping to change at page 19, line 25 skipping to change at page 19, line 25
cryptographic computations. cryptographic computations.
WireGuard builds on Noise [Noise] for 1-RTT key exchange with WireGuard builds on Noise [Noise] for 1-RTT key exchange with
identity hiding. The handshake hides peer identities as per the identity hiding. The handshake hides peer identities as per the
SIGMA construction [SIGMA]. As a consequence of using Noise, SIGMA construction [SIGMA]. As a consequence of using Noise,
WireGuard comes with a fixed set of cryptographic algorithms: WireGuard comes with a fixed set of cryptographic algorithms:
o x25519 [Curve25519] and HKDF [RFC5869] for ECDH and key o x25519 [Curve25519] and HKDF [RFC5869] for ECDH and key
derivation. derivation.
o ChaCha20+Poly1305 [RFC7539] for packet authenticated encryption. o ChaCha20+Poly1305 [RFC8439] for packet authenticated encryption.
o BLAKE2s [BLAKE2] for hashing. o BLAKE2s [BLAKE2] for hashing.
There is no cryptographic agility. If weaknesses are found in any of There is no cryptographic agility. If weaknesses are found in any of
these algorithms, new message types using new algorithms must be these algorithms, new message types using new algorithms must be
introduced. introduced.
If a WireGuard receiver is under heavy load and cannot process a If a WireGuard receiver is under heavy load and cannot process a
packet, e.g., cannot spare CPU cycles for expensive public key packet, e.g., cannot spare CPU cycles for expensive public key
cryptographic operations, it can reply with a cookie similar to DTLS cryptographic operations, it can reply with a cookie similar to DTLS
skipping to change at page 23, line 49 skipping to change at page 23, line 49
OpenVPN facilitates authentication using either a pre-shared static OpenVPN facilitates authentication using either a pre-shared static
key or using X.509 certificates and TLS. In pre-shared key mode, key or using X.509 certificates and TLS. In pre-shared key mode,
OpenVPN derives keys for encryption and authentication directly from OpenVPN derives keys for encryption and authentication directly from
one or multiple symmetric keys. In TLS mode, OpenVPN encapsulates a one or multiple symmetric keys. In TLS mode, OpenVPN encapsulates a
TLS handshake, in which both peers must present a certificate for TLS handshake, in which both peers must present a certificate for
authentication. After the handshake, both sides contribute random authentication. After the handshake, both sides contribute random
source material to derive keys for encryption and authentication source material to derive keys for encryption and authentication
using the TLS pseudo random function (PRF). OpenVPN provides the using the TLS pseudo random function (PRF). OpenVPN provides the
possibility to authenticate and encrypt the TLS handshake itself possibility to authenticate and encrypt the TLS handshake itself
using a pre-shared key or passphrase. Furthermore, it supports using a pre-shared key or passphrase. Furthermore, it supports re-
rekeying using TLS. keying using TLS.
After authentication and key exchange, OpenVPN encrypts payload data, After authentication and key exchange, OpenVPN encrypts payload data,
i.e., IP packets or Ethernet frames, and authenticates the payload i.e., IP packets or Ethernet frames, and authenticates the payload
using HMAC. Applications can select an arbitrary encryption using HMAC. Applications can select an arbitrary encryption
algorithm (cipher) and key size, as well hash function for HMAC. The algorithm (cipher) and key size, as well hash function for HMAC. The
default cipher and hash functions are AES-GCM and SHA1, respectively. default cipher and hash functions are AES-GCM and SHA1, respectively.
Recent versions of the protocol support cipher negotiation. Recent versions of the protocol support cipher negotiation.
OpenVPN can run over TCP or UDP. When running over UDP, OpenVPN OpenVPN can run over TCP or UDP. When running over UDP, OpenVPN
provides a simple reliability layer for control packets such as the provides a simple reliability layer for control packets such as the
skipping to change at page 24, line 29 skipping to change at page 24, line 29
TCP, OpenVPN includes the packet length in the header, which allows TCP, OpenVPN includes the packet length in the header, which allows
the peer to deframe the TCP stream into messages. the peer to deframe the TCP stream into messages.
For replay protection, OpenVPN assigns an identifier to each outgoing For replay protection, OpenVPN assigns an identifier to each outgoing
packet, which is unique for the packet and the currently used key. packet, which is unique for the packet and the currently used key.
In pre-shared key mode or with a CFB or OFB mode cipher, OpenVPN In pre-shared key mode or with a CFB or OFB mode cipher, OpenVPN
combines a timestamp with an incrementing sequence number into a combines a timestamp with an incrementing sequence number into a
64-bit identifier. In TLS mode with CBC cipher mode, OpenVPN omits 64-bit identifier. In TLS mode with CBC cipher mode, OpenVPN omits
the timestamp, so identifiers are only 32-bit. This is sufficient the timestamp, so identifiers are only 32-bit. This is sufficient
since OpenVPN can guarantee the uniqueness of this identifier for since OpenVPN can guarantee the uniqueness of this identifier for
each key, as it can trigger rekeying if needed. each key, as it can trigger re-keying if needed.
OpenVPN supports connection mobility by allowing a peer to change its OpenVPN supports connection mobility by allowing a peer to change its
IP address during an ongoing session. When configured accordingly, a IP address during an ongoing session. When configured accordingly, a
host will accept authenticated packets for a session from any IP host will accept authenticated packets for a session from any IP
address. address.
4.10.2. Protocol Features 4.10.2. Protocol Features
o Peer authentication using certificates or pre-shared key. o Peer authentication using certificates or pre-shared key.
skipping to change at page 29, line 52 skipping to change at page 29, line 52
example. Protocols: IKEv2, SRTP example. Protocols: IKEv2, SRTP
o Pre-Shared Key Import Either the handshake protocol or the o Pre-Shared Key Import Either the handshake protocol or the
application directly can supply pre-shared keys for the record application directly can supply pre-shared keys for the record
protocol use for encryption/decryption and authentication. If the protocol use for encryption/decryption and authentication. If the
application can supply keys directly, this is considered explicit application can supply keys directly, this is considered explicit
import; if the handshake protocol traditionally provides the keys import; if the handshake protocol traditionally provides the keys
directly, it is considered direct import; if the keys can only be directly, it is considered direct import; if the keys can only be
shared by the handshake, they are considered non-importable. shared by the handshake, they are considered non-importable.
* Explict import: QUIC, ESP * Explicit import: QUIC, ESP
* Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard * Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard
* Non-importable: CurveCP * Non-importable: CurveCP
6.2. Connection Interfaces 6.2. Connection Interfaces
o Identity Validation During a handshake, the security protocol will o Identity Validation During a handshake, the security protocol will
conduct identity validation of the peer. This can call into the conduct identity validation of the peer. This can call into the
application to offload validation. Protocols: All (TLS, DTLS, application to offload validation. Protocols: All (TLS, DTLS,
QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS)) QUIC + TLS, MinimalT, CurveCP, IKEv2, WireGuard, SRTP (DTLS))
skipping to change at page 31, line 41 skipping to change at page 31, line 41
improve privacy by reducing information leakage via encryption. improve privacy by reducing information leakage via encryption.
However, varying amounts of metadata remain in the clear across each However, varying amounts of metadata remain in the clear across each
protocol. For example, client and server certificates are sent in protocol. For example, client and server certificates are sent in
cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3 cleartext in TLS 1.2 [RFC5246], whereas they are encrypted in TLS 1.3
[RFC8446]. A survey of privacy features, or lack thereof, for [RFC8446]. A survey of privacy features, or lack thereof, for
various security protocols could be addressed in a separate document. various security protocols could be addressed in a separate document.
10. Acknowledgments 10. Acknowledgments
The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja The authors would like to thank Bob Bradley, Frederic Jacobs, Mirja
Kuehlewind, Yannick Sierra, and Brian Trammell for their input and Kuehlewind, Yannick Sierra, Brian Trammell, and Magnus Westerlund for
feedback on earlier versions of this draft. their input and feedback on this draft.
11. Informative References 11. Informative References
[ALTS] "Application Layer Transport Security", n.d.. [ALTS] Ghali, C., Stubblefield, A., Knapp, E., Li, J., Schmidt,
B., and J. Boeuf, "Application Layer Transport Security",
<https://cloud.google.com/security/encryption-in-transit/
application-layer-transport-security/>.
[BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d.. [BLAKE2] Aumasson, J., Neves, S., Wilcox-O'Hearn, Z., and C.
Winnerlein, "BLAKE2 -- simpler, smaller, fast as MD5",
<https://blake2.net/blake2.pdf>.
[Curve25519] [Curve25519]
"Curve25519 - new Diffie-Hellman speed records", n.d.. Bernstein, D., "Curve25519 - new Diffie-Hellman speed
records", <https://cr.yp.to/ecdh/curve25519-20060209.pdf>.
[CurveCP] "CurveCP -- Usable security for the Internet", n.d.. [CurveCP] Bernstein, D., "CurveCP -- Usable security for the
Internet", <http://curvecp.org>.
[I-D.ietf-quic-tls] [I-D.ietf-quic-tls]
Thomson, M. and S. Turner, "Using TLS to Secure QUIC", Thomson, M. and S. Turner, "Using TLS to Secure QUIC",
draft-ietf-quic-tls-22 (work in progress), July 2019. draft-ietf-quic-tls-23 (work in progress), September 2019.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", draft-ietf-quic-transport-22 (work and Secure Transport", draft-ietf-quic-transport-23 (work
in progress), July 2019. in progress), September 2019.
[I-D.ietf-rtcweb-security-arch] [I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf- Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-20 (work in progress), July 2019. rtcweb-security-arch-20 (work in progress), July 2019.
[I-D.ietf-taps-arch] [I-D.ietf-taps-arch]
Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G., Pauly, T., Trammell, B., Brunstrom, A., Fairhurst, G.,
Perkins, C., Tiesel, P., and C. Wood, "An Architecture for Perkins, C., Tiesel, P., and C. Wood, "An Architecture for
Transport Services", draft-ietf-taps-arch-04 (work in Transport Services", draft-ietf-taps-arch-04 (work in
progress), July 2019. progress), July 2019.
skipping to change at page 32, line 43 skipping to change at page 33, line 5
[I-D.ietf-taps-minset] [I-D.ietf-taps-minset]
Welzl, M. and S. Gjessing, "A Minimal Set of Transport Welzl, M. and S. Gjessing, "A Minimal Set of Transport
Services for End Systems", draft-ietf-taps-minset-11 (work Services for End Systems", draft-ietf-taps-minset-11 (work
in progress), September 2018. in progress), September 2018.
[I-D.ietf-tls-dtls-connection-id] [I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., and T. Fossati, "Connection Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection- Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
id-06 (work in progress), July 2019. id-06 (work in progress), July 2019.
[I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-32 (work in progress), July
2019.
[MinimalT] [MinimalT]
"MinimaLT -- Minimal-latency Networking Through Better Petullo, W., Zhang, X., Solworth, J., Bernstein, D., and
Security", n.d.. T. Lange, "MinimaLT -- Minimal-latency Networking Through
Better Security",
<http://dl.acm.org/citation.cfm?id=2516737>.
[Noise] "The Noise Protocol Framework", n.d.. [Noise] Perrin, T., "The Noise Protocol Framework",
<http://noiseprotocol.org/noise.pdf>.
[OpenVPN] "OpenVPN cryptographic layer", n.d.. [OpenVPN] "OpenVPN cryptographic layer", <https://openvpn.net/
community-resources/openvpn-cryptographic-layer/>.
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
Signature Option", RFC 2385, DOI 10.17487/RFC2385, August Signature Option", RFC 2385, DOI 10.17487/RFC2385, August
1998, <https://www.rfc-editor.org/info/rfc2385>. 1998, <https://www.rfc-editor.org/info/rfc2385>.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, Headers for Low-Speed Serial Links", RFC 2508,
DOI 10.17487/RFC2508, February 1999, DOI 10.17487/RFC2508, February 1999,
<https://www.rfc-editor.org/info/rfc2508>. <https://www.rfc-editor.org/info/rfc2508>.
skipping to change at page 33, line 48 skipping to change at page 34, line 17
January 2006, <https://www.rfc-editor.org/info/rfc4253>. January 2006, <https://www.rfc-editor.org/info/rfc4253>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005, DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>. <https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005, RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>. <https://www.rfc-editor.org/info/rfc4303>.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006,
<https://www.rfc-editor.org/info/rfc4474>.
[RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol
(MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006, (MOBIKE)", RFC 4555, DOI 10.17487/RFC4555, June 2006,
<https://www.rfc-editor.org/info/rfc4555>. <https://www.rfc-editor.org/info/rfc4555>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange
skipping to change at page 35, line 21 skipping to change at page 35, line 35
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2 Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, <https://www.rfc-editor.org/info/rfc7296>. 2014, <https://www.rfc-editor.org/info/rfc7296>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7539] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 7539, DOI 10.17487/RFC7539, May 2015,
<https://www.rfc-editor.org/info/rfc7539>.
[RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind,
Ed., "Services Provided by IETF Transport Protocols and Ed., "Services Provided by IETF Transport Protocols and
Congestion Control Mechanisms", RFC 8095, Congestion Control Mechanisms", RFC 8095,
DOI 10.17487/RFC8095, March 2017, DOI 10.17487/RFC8095, March 2017,
<https://www.rfc-editor.org/info/rfc8095>. <https://www.rfc-editor.org/info/rfc8095>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>.
[RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation [RFC8229] Pauly, T., Touati, S., and R. Mantha, "TCP Encapsulation
of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229, of IKE and IPsec Packets", RFC 8229, DOI 10.17487/RFC8229,
August 2017, <https://www.rfc-editor.org/info/rfc8229>. August 2017, <https://www.rfc-editor.org/info/rfc8229>.
[RFC8439] Nir, Y. and A. Langley, "ChaCha20 and Poly1305 for IETF
Protocols", RFC 8439, DOI 10.17487/RFC8439, June 2018,
<https://www.rfc-editor.org/info/rfc8439>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8449] Thomson, M., "Record Size Limit Extension for TLS", [RFC8449] Thomson, M., "Record Size Limit Extension for TLS",
RFC 8449, DOI 10.17487/RFC8449, August 2018, RFC 8449, DOI 10.17487/RFC8449, August 2018,
<https://www.rfc-editor.org/info/rfc8449>. <https://www.rfc-editor.org/info/rfc8449>.
[RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. [RFC8547] Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.
Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547, Smith, "TCP-ENO: Encryption Negotiation Option", RFC 8547,
DOI 10.17487/RFC8547, May 2019, DOI 10.17487/RFC8547, May 2019,
<https://www.rfc-editor.org/info/rfc8547>. <https://www.rfc-editor.org/info/rfc8547>.
[RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack, [RFC8548] Bittau, A., Giffin, D., Handley, M., Mazieres, D., Slack,
Q., and E. Smith, "Cryptographic Protection of TCP Streams Q., and E. Smith, "Cryptographic Protection of TCP Streams
(tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019, (tcpcrypt)", RFC 8548, DOI 10.17487/RFC8548, May 2019,
<https://www.rfc-editor.org/info/rfc8548>. <https://www.rfc-editor.org/info/rfc8548>.
[SIGMA] "SIGMA -- The 'SIGn-and-MAc' Approach to Authenticated [SIGMA] Krawczyk, H., "SIGMA -- The 'SIGn-and-MAc' Approach to
Diffie-Hellman and Its Use in the IKE-Protocols", n.d.. Authenticated Diffie-Hellman and Its Use in the IKE-
Protocols", <http://www.iacr.org/cryptodb/archive/2003/
CRYPTO/1495/1495.pdf>.
[WireGuard] [WireGuard]
"WireGuard -- Next Generation Kernel Network Tunnel", Donenfeld, J., "WireGuard -- Next Generation Kernel
n.d.. Network Tunnel",
<https://www.wireguard.com/papers/wireguard.pdf>.
Authors' Addresses Authors' Addresses
Christopher A. Wood (editor) Christopher A. Wood (editor)
Apple Inc. Apple Inc.
One Apple Park Way One Apple Park Way
Cupertino, California 95014 Cupertino, California 95014
United States of America United States of America
Email: cawood@apple.com Email: cawood@apple.com
 End of changes. 35 change blocks. 
47 lines changed or deleted 67 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/