Draft: draft-pauly-taps-transport-security

Commentary: There are more changes I want to make , but many of them will require a lot more discussion prior to editing . Please review the proposed changes prior to merging : some of them are nits , but many are substantive rewording and restructuring , so I 'm happy to migrate any that are too invasive or controversial to a different branch that we can haggle over after the draft deadline . 
 Looks good ! I only have two comments : one for including a forward pointer in IETF QUIC to gQUIC , and another for filling out some empty subsections . 
 I 'll just merge and address in a followup commit !
Paragraph (version A):
Authentication-only protocols such as TCP-AO RFC5925 and IPsec AH
RFC4302 are excluded from this survey.  TCP-AO adds authenticity
protections to long-lived TCP connections, e.g., replay protection
with per-packet Message Authentication Codes.  (This protocol
obsoletes TCP MD5 "signature" options specified in RFC2385.)  One
prime use case of TCP-AO is for protecting BGP connections.
Similarly, AH adds per-datagram authenticity and adds similar replay
protection.  Despite these improvements, neither protocol see general
use and lack critical properties important for emergent transport
security protocols: confidentiality, privacy protections, and
agility.  Thus, we omit these and related protocols from our survey.
Paragraph (version B):
Authentication-only protocols such as TCP-AO RFC5925 and IPsec AH
RFC4302 are excluded from this survey.  TCP-AO adds authenticity
protections to long-lived TCP connections, e.g., replay protection
with per-packet Message Authentication Codes.  (This protocol
obsoletes TCP MD5 "signature" options specified in RFC2385.)  One
prime use case of TCP-AO is for protecting BGP connections.
Similarly, AH adds per-datagram authenticity and adds similar replay
protection.  Despite these improvements, neither protocol sees
general use and both lack critical properties important for emergent
transport security protocols: confidentiality, privacy protections,
and agility.  Thus, we omit these and related protocols from our
survey.
Paragraph (version A):
Transport Service: a set of Transport Features, without an
association to any given framing protocol, which provides a
functionality to an application.
Paragraph (version B):
Transport Service: a set of Transport Features, without an
association to any given framing protocol, which provides
functionality to an application.
Paragraph (version A):
Application: an entity that uses a transport protocol for end-to-
end delivery of data across the network (this may also be an upper
layer protocol or tunnel encapsulation).
Paragraph (version B):
Application: an entity that uses a transport protocol for end-to-
end delivery of data across the network.  This may also be an
upper layer protocol or tunnel encapsulation.
Paragraph (version A):
Security Protocol: a defined network protocol that implements one
or more security features.  Security protocols may be used
alongside transport protocols, and in combination with one another
when appropriate.
Paragraph (version A):
Handshake Protocol: a security protocol that performs a handshake
to validate peers and establish a shared cryptographic key.
Paragraph (version A):
Record Protocol: a security protocol that allows data to be
encrypted in records or datagrams based on a shared cryptographic
key.
Paragraph (version B):
Security Protocol: a defined network protocol that implements one
or more security features.  Security protocols may be used
alongside transport protocols, and in combination with other
security protocols when appropriate.
Paragraph (version B):
Handshake Protocol: a protocol that enables peers to validate each
other and to securely establish shared cryptographic context.
Paragraph (version B):
Record Protocol: a security protocol that allows data to be
divided into manageable blocks and protected using a shared
cryptographic context.
Paragraph (version B):
Cryptographic context: a set of cryptographic parameters,
including but not necessarily limited to keys for encryption,
authentication, and session resumption, enabling authorized
parties to a session to communicate securely.
Paragraph (version A):
The handshake protocol serves several purposes, including: peer
authentication, protocol option (key exchange algorithm and
ciphersuite) negotiation, and key derivation.  Peer authentication
may be mutual.  However, commonly, only the server is authenticated.
X.509 certificates are commonly used in this authentication step,
though other mechanisms, such as raw public keys RFC7250, exist.  The
client is not authenticated unless explicitly requested by the server
with a CertificateRequest handshake message.
Paragraph (version A):
The handshake protocol is also extensible.  It allows for a variety
of extensions to be included by either the client or server.  These
extensions are used to specify client preferences, e.g., the
application-layer protocol to be driven with the TLS connection
RFC7301, or signals to the server to aid operation, e.g., the server
name RFC6066.  Various extensions also exist to tune the parameters
of the record protocol, e.g., the maximum fragment length RFC6066.
Paragraph (version B):
The handshake protocol serves several purposes, including: peer
authentication, protocol option (key exchange algorithm and
ciphersuite) negotiation, and key derivation.  Peer authentication
may be mutual; however, commonly, only the server is authenticated.
X.509 certificates are commonly used in this authentication step,
though other mechanisms, such as raw public keys RFC7250, exist.  The
client is not authenticated unless explicitly requested by the server
with a CertificateRequest handshake message.  Assuming strong
cryptography, an infrastructure for trust establishment, correctly-
functioning endpoints, and communication patterns free from side
channels, server authentication is sufficient to establish a channel
resistant to eavesdroppers.
Paragraph (version B):
The handshake protocol is also extensible.  It allows for a variety
of extensions to be included by either the client or server.  These
extensions are used to specify client preferences, e.g., the
application-layer protocol to be driven with the TLS connection
RFC7301, or signals to the server to aid operation, e.g., Server Name
Indication (SNI) RFC6066.  Various extensions also exist to tune the
parameters of the record protocol, e.g., the maximum fragment length
RFC6066.
Paragraph (version A):
Alerts are used to convey errors and other atypical events to the
endpoints.  There are two classes of alerts: closure and error
alerts.  A closure alert is used to signal to the other peer that the
sender wishes to terminate the connection.  The sender typically
follows a close alert with a TCP FIN segment to close the connection.
Error alerts are used to indicate problems with the handshake or
individual records.  Most errors are fatal and are followed by
connection termination.  However, warning alerts may be handled at
the discretion of each respective implementation.
Paragraph (version B):
Alerts are used to convey errors and other atypical events to the
endpoints.  There are two classes of alerts: closure and error
alerts.  A closure alert is used to signal to the other peer that the
sender wishes to terminate the connection.  The sender typically
follows a close alert with a TCP FIN segment to close the connection.
Error alerts are used to indicate problems with the handshake or
individual records.  Most errors are fatal and are followed by
connection termination.  However, warning alerts may be handled at
the discretion of the implementation.
Paragraph (version A):
Certificate- and raw public-key-based authentication.
Paragraph (version B):
Certificate- and raw public key-based authentication.
Paragraph (version A):
0-RTT data support (in TLS 1.3 only).
Paragraph (version B):
0-RTT data support (starting with TLS 1.3).
Paragraph (version A):
DTLS is modified from TLS to account for packet loss and reordering
that occur when operating over a datagram-based transport, i.e., UDP.
Each message is assigned an explicit sequence number to be used to
reorder on the receiving end.  This removes the inter-record
dependency and allows each record to be decrypt in isolation of the
rest.  However, DTLS does not deviate from TLS in that in still
provides in-order delivery of data to the application.
Paragraph (version A):
With respect to packet loss, if one peer has sent a handshake message
and has not yet received its expected response, it will retransmit
the handshake message after a configurable timeout.
Paragraph (version A):
To account for long records that cannot fit within a single UDP
datagram, DTLS supports fragmentation of records across datagrams,
keeping track of fragment offsets and lengths in each datagram.  The
receiving peer must re-assemble records before decrypting.
Paragraph (version A):
DTLS relies on UDP's port numbers to allow peers with multiple DTLS
sessions between them to demultiplex 'streams' of encrypted packets
that share a single TLS session.
Paragraph (version A):
Since datagrams may be replayed, DTLS provides anti-replay detection
based on a window of acceptable sequence numbers RFC4303.
Paragraph (version B):
DTLS is modified from TLS to account for packet loss, reordering, and
duplication that may occur when operating over UDP.  To enable out-
of-order delivery of application data, the DTLS record protocol
itself has no inter-record dependencies.  However, as the handshake
requires reliability, each handshake message is assigned an explicit
sequence number to enable retransmissions of lost packets and in-
order processing by the receiver.  Handshake message loss is remedied
by sender retransmission after a configurable period in which the
expected response has not yet been received.
Paragraph (version B):
As the DTLS handshake protocol runs atop the record protocol, to
account for long handshake messages that cannot fit within a single
record, DTLS supports fragmentation and subsequent reconstruction of
handshake messages across records.  The receiver must reassemble
records before processing.
Paragraph (version B):
DTLS relies on unique UDP 4-tuples to allow peers with multiple DTLS
connections between them to demultiplex connections, constraining
protocol design slightly more than UDP: application-layer
demultiplexing over the same 4-tuple is not possible without trial
decryption as all application-layer data is encrypted to a
connection-specific cryptographic context.  Starting with DTLS 1.3 I-
D.ietf-tls-dtls13, a connection identifier extension to permit
multiplexing of independent connections over the same 4-tuple is
available I-D.ietf-tls-dtls-connection-id.
Paragraph (version B):
Since datagrams may be replayed, DTLS provides optional anti-replay
detection based on a window of acceptable sequence numbers RFC6347.
Paragraph (version A):
DTLS contains its own length, so although it runs over a datagram
transport, it does not rely on the transport protocol supporting
framing.
Paragraph (version A):
UDP for port numbers used for demultiplexing.
Paragraph (version A):
QUIC (Quick UDP Internet Connections) is a new transport protocol
that runs over UDP, and was originally designed with a tight
integration with its security protocol and application protocol
mappings.  The QUIC transport layer itself provides support for data
confidentiality and integrity.  This requires keys to be derived with
a separate handshake protocol.  A mapping for QUIC over TLS 1.3 I-
D.ietf-quic-tls has been specified to provide this handshake.
Paragraph (version B):
The DTLS record protocol explicitly encodes record lengths, so
although it runs over a datagram transport, it does not rely on
the transport protocol's framing beyond requiring transport-level
reconstruction of datagrams fragmented over packets.
Paragraph (version B):
UDP 4-tuple uniqueness, or the connection identifier extension,
for demultiplexing.
Paragraph (version B):
QUIC (Quick UDP Internet Connections) is a new standards-track
transport protocol that runs over UDP, loosely based on Google's
original proprietary gQUIC protocol.  The QUIC transport layer itself
provides support for data confidentiality and integrity.  This
requires keys to be derived with a separate handshake protocol.  A
mapping for QUIC over TLS 1.3 I-D.ietf-quic-tls has been specified to
provide this handshake.
Paragraph (version B):
gQUIC is a UDP-based multiplexed streaming protocol designed and
deployed by Google following experience from deploying SPDY, the
proprietary predecessor to HTTP/2.  gQUIC was originally known as
"QUIC": this document uses gQUIC to unambiguously distinguish it from
the standards-track IETF QUIC.  The proprietary technical forebear of
IETF QUIC, gQUIC was originally designed with tightly-integrated
security and application data transport protocols.
Paragraph (version A):
The use of only public-key encryption and authentication, or
"boxing", is done to simplify problems that come with symmetric key
management and synchronization.  For example, it allows the sender of
a message to be in complete control of each message's nonce.  It does
not require either end to share secret keying material.  And it
allows ephemeral public keys to be associated with connections (or
sessions).
Paragraph (version A):
The client and server do not perform a standard key exchange.
Instead, in the initial exchange of packets, the each party provides
its own ephemeral key to the other end.  The client can choose a new
ephemeral key for every new connection.  However, the server must
rotate these keys on a slower basis.  Otherwise, it would be trivial
for an attacker to force the server to create and store ephemeral
keys with a fake client initialization packet.
Paragraph (version B):
The use of only public-key encryption and authentication, or
"boxing", is done to simplify problems that come with symmetric key
management and synchronization.  For example, it allows the sender of
a message to be in complete control of each message's nonce.  It does
not require either end to share secret keying material.  Furthermore,
it allows connections (or sessions) to be associated with unique
ephemeral public keys as a mechanism for enabling forward secrecy
given the risk of long-term private key compromise.
Paragraph (version B):
The client and server do not perform a standard key exchange.
Instead, in the initial exchange of packets, each party provides its
own ephemeral key to the other end.  The client can choose a new
ephemeral key for every new connection.  However, the server must
rotate these keys on a slower basis.  Otherwise, it would be trivial
for an attacker to force the server to create and store ephemeral
keys with a fake client initialization packet.
Paragraph (version A):
Unlike some other protocols, CurveCP data packets only leave the
ephemeral public key, i.e., the connection ID, and the per-message
nonce in the clear.  Everything else is encrypted.
Paragraph (version B):
Unlike some other protocols, CurveCP data packets leave only the
ephemeral public key, the connection ID, and the per-message nonce in
the clear.  Everything else is encrypted.
Paragraph (version A):
ESP is a protocol that encrypts and authenticates IP and IPv6
packets.  The keys used for both encryption and authentication can be
derived from an IKEv2 exchange.  ESP Security Associations come as
pairs, one for each direction between two peers.  Each SA is
identified by a Security Parameter Index (SPI), which is marked on
each encrypted ESP packet.
Paragraph (version B):
ESP is a protocol that encrypts and authenticates IPv4 and IPv6
packets.  The keys used for both encryption and authentication can be
derived from an IKEv2 exchange.  ESP Security Associations come as
pairs, one for each direction between two peers.  Each SA is
identified by a Security Parameter Index (SPI), which is marked on
each encrypted ESP packet.
Paragraph (version A):
ESP packets are sent directly over IP, except when a NAT is present,
in which case they are sent on UDP port 4500, or via TCP
encapsulation RFC8229.
Paragraph (version B):
ESP packets may be sent directly over IP, but where network
conditions warrant (e.g., when a NAT is present or when a firewall
blocks such packets) they may be encapsulated in UDP RFC3948 or TCP
RFC8229.
Paragraph (version A):
Since ESP is below transport protocols, it does not have any
dependencies on the transports themselves, other than on UDP or
TCP for NAT traversal.
Paragraph (version B):
Since ESP is below transport protocols, it does not have any
dependencies on the transports themselves, other than on UDP or
TCP where encapsulation is employed.
Paragraph (version A):
DTLS RFC5764 is commonly used as a way to perform mutually
authentication key establishment for SRTP RFC5763.  (Here,
certificates marshall public keys between endpoints.  Thus, self-
signed certificates may be used if peers do not mutually trust one
another, as is common on the Internet.)  When DTLS is used,
certificate fingerprints are transmitted out-of-band using SIP.
Peers typically verify that DTLS-offered certificates match that
which are offered over SIP.  This prevents active attacks on RTP, but
not on the signaling (SIP or WebRTC) channel.
Paragraph (version B):
DTLS RFC5764 is commonly used as a way to perform mutual
authentication and key agreement for SRTP RFC5763.  (Here,
certificates marshal public keys between endpoints.  Thus, self-
signed certificates may be used if peers do not mutually trust one
another, as is common on the Internet.)  When DTLS is used,
certificate fingerprints are transmitted out-of-band using SIP.
Peers typically verify that DTLS-offered certificates match that
which are offered over SIP.  This prevents active attacks on RTP, but
not on the signaling (SIP or WebRTC) channel.
Paragraph (version A):
Mutual authentication: Transport security protocols should allow
both endpoints to authenticate one another if needed.
Paragraph (version B):
Mutual authentication: Transport security protocols must allow
each endpoint to authenticate the other if required by the
application.
Paragraph (version A):
Connection mobility: Sessions should not be bound to a network
connection (or 5 tuple).  This allows cryptographic key material
and other state information to be reused in the event of a
connection change.  Examples of this include a NAT rebinding that
occurs without a client's knowledge.
Paragraph (version B):
Connection mobility: Sessions should not be bound to a network
connection (or 5-tuple).  This allows cryptographic key material
and other state information to be reused in the event of a
connection change.  Examples of this include a NAT rebinding that
occurs without a client's knowledge.
Paragraph (version A):
This document has on request to IANA.
Paragraph (version B):
This document has no request to IANA.