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.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |