draft-ietf-taps-transport-security-05.txt   draft-ietf-taps-transport-security-06.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: August 30, 2019 TU Berlin Expires: September 12, 2019 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.
February 26, 2019 March 11, 2019
A Survey of Transport Security Protocols A Survey of Transport Security Protocols
draft-ietf-taps-transport-security-05 draft-ietf-taps-transport-security-06
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 [RFC8095] by efforts to define and catalog transport services [RFC8095] by
describing the interfaces required to add security protocols. It describing the interfaces required to add security protocols. It
examines Transport Layer Security (TLS), Datagram Transport Layer examines Transport Layer Security (TLS), Datagram Transport Layer
Security (DTLS), Quick UDP Internet Connections with TLS (QUIC + Security (DTLS), Quick UDP Internet Connections with TLS (QUIC +
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 August 30, 2019. This Internet-Draft will expire on September 12, 2019.
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 19, line 25 skipping to change at page 19, line 25
derivation. derivation.
o ChaCha20+Poly1305 [RFC7539] for packet authenticated encryption. o ChaCha20+Poly1305 [RFC7539] 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.
WireGuard is designed to be entirely stateless, modulo the CryptoKey If a WireGuard receiver is under heavy load and cannot process a
routing table, which has size linear with the number of trusted packet, e.g., cannot spare CPU cycles for expensive public key
peers. If a WireGuard receiver is under heavy load and cannot cryptographic operations, it can reply with a cookie similar to DTLS
process a packet, e.g., cannot spare CPU cycles for point and IKEv2. This cookie only proves IP address ownership. Any rate
multiplication, it can reply with a cookie similar to DTLS and IKEv2. limiting scheme can be applied to packets coming from non-spoofed
This cookie only proves IP address ownership. Any rate limiting addresses.
scheme can be applied to packets coming from non-spoofed addresses.
4.7.2. Security Features 4.7.2. Security Features
o Forward-secure session key establishment. o Forward-secure session key establishment.
o Peer authentication (public-key and PSK). o Peer authentication (public-key and PSK).
o Mutual authentication. o Mutual authentication.
o Record replay prevention (Stateful, timestamp-based). o Record replay prevention (Stateful, timestamp-based).
o Connection mobility.
o DoS mitigation (cookie-based). o DoS mitigation (cookie-based).
4.7.3. Protocol Dependencies 4.7.3. Protocol Dependencies
o Datagram transport. o Datagram transport.
o Out-of-band key distribution and management. o Out-of-band key distribution and management.
4.8. CurveCP 4.8. CurveCP
skipping to change at page 23, line 41 skipping to change at page 23, line 41
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
rekeying using TLS. rekeying 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 signs the payload using an i.e., IP packets or Ethernet frames, and authenticates the payload
HMAC function. The default cipher is BlowFish [BlowFish] and the using HMAC. Applications can select an arbitrary encryption
default message digest algorithm is SHA1, but an application can algorithm (cipher) and key size, as well hash function for HMAC. The
select an arbitrary cipher, key size, and message digest algorithm default cipher and hash functions are AES-GCM and SHA1, respectively.
for the HMAC. OpenVPN peers support cipher negotiation (NCP) since Recent versions of the protocol support cipher negotiation.
version 2.4, in which case they will upgrade the cipher to AES-
256-GCM by default.
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
TLS handshake and key exchange. It assigns sequence numbers to TLS handshake and key exchange. It assigns sequence numbers to
packets, acknowledges packets it receives, and retransmits packets it packets, acknowledges packets it receives, and retransmits packets it
deems lost. Similar to DTLS, this reliability layer is not used for deems lost. Similar to DTLS, this reliability layer is not used for
data packets, which prevents the problem of two reliability data packets, which prevents the problem of two reliability
mechanisms being encapsulated within each other. When running over mechanisms being encapsulated within each other. When running over
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.
skipping to change at page 31, line 50 skipping to change at page 31, line 50
The authors would like to thank Bob Bradley, Theresa Enghardt, The authors would like to thank Bob Bradley, Theresa Enghardt,
Frederic Jacobs, Mirja Kuehlewind, Yannick Sierra, and Brian Trammell Frederic Jacobs, Mirja Kuehlewind, Yannick Sierra, and Brian Trammell
for their input and feedback on earlier versions of this draft. for their input and feedback on earlier versions of this draft.
11. Normative References 11. Normative References
[ALTS] "Application Layer Transport Security", n.d.. [ALTS] "Application Layer Transport Security", n.d..
[BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d.. [BLAKE2] "BLAKE2 -- simpler, smaller, fast as MD5", n.d..
[BlowFish]
"The Blowfish Encryption Algorithm", n.d..
[Curve25519] [Curve25519]
"Curve25519 - new Diffie-Hellman speed records", n.d.. "Curve25519 - new Diffie-Hellman speed records", n.d..
[CurveCP] "CurveCP -- Usable security for the Internet", n.d.. [CurveCP] "CurveCP -- Usable security for the Internet", n.d..
[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-18 (work in progress), January 2019. draft-ietf-quic-tls-18 (work in progress), January 2019.
[I-D.ietf-quic-transport] [I-D.ietf-quic-transport]
skipping to change at page 32, line 48 skipping to change at page 32, line 45
Q., and E. Smith, "Cryptographic protection of TCP Streams Q., and E. Smith, "Cryptographic protection of TCP Streams
(tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-15 (work in (tcpcrypt)", draft-ietf-tcpinc-tcpcrypt-15 (work in
progress), December 2018. progress), December 2018.
[I-D.ietf-tcpinc-tcpeno] [I-D.ietf-tcpinc-tcpeno]
Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E. Bittau, A., Giffin, D., Handley, M., Mazieres, D., and E.
Smith, "TCP-ENO: Encryption Negotiation Option", draft- Smith, "TCP-ENO: Encryption Negotiation Option", draft-
ietf-tcpinc-tcpeno-19 (work in progress), June 2018. ietf-tcpinc-tcpeno-19 (work in progress), June 2018.
[I-D.ietf-tls-dtls-connection-id] [I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., Fossati, T., and T. Gondrom, Rescorla, E., Tschofenig, H., and T. Fossati, "Connection
"Connection Identifiers for DTLS 1.2", draft-ietf-tls- Identifiers for DTLS 1.2", draft-ietf-tls-dtls-connection-
dtls-connection-id-02 (work in progress), October 2018. id-04 (work in progress), March 2019.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", draft-ietf-tls-dtls13-30 (work in progress), 1.3", draft-ietf-tls-dtls13-30 (work in progress),
November 2018. November 2018.
[I-D.ietf-tls-record-limit] [I-D.ietf-tls-record-limit]
Thomson, M., "Record Size Limit Extension for Transport Thomson, M., "Record Size Limit Extension for Transport
Layer Security (TLS)", draft-ietf-tls-record-limit-03 Layer Security (TLS)", draft-ietf-tls-record-limit-03
 End of changes. 9 change blocks. 
24 lines changed or deleted 20 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/