Draft: draft-ietf-taps-transport-security

Commentary: Fix some typos and spelling errors , too ! 
 Looks good ! Thanks for making these fixes .
Paragraph (version A):
TLS (Transport Layer Security) RFC5246 is a common protocol used to
establish a secure session between two endpoints.  Communication over
this session "prevents eavesdropping, tampering, and message
forgery."  TLS consists of a tightly coupled handshake and record
protocol.  The handshake protocol is used to authenticate peers,
negotiate protocol options, such as cryptographic algorithms, and
derive session-specific keying material.  The record protocol is used
to marshal (possibly encrypted) data from one peer to the other.
This data may contain handshake messages or raw application data.
Paragraph (version B):
TLS (Transport Layer Security) RFC8446 is a common protocol used to
establish a secure session between two endpoints.  Communication over
this session "prevents eavesdropping, tampering, and message
forgery."  TLS consists of a tightly coupled handshake and record
protocol.  The handshake protocol is used to authenticate peers,
negotiate protocol options, such as cryptographic algorithms, and
derive session-specific keying material.  The record protocol is used
to marshal (possibly encrypted) data from one peer to the other.
This data may contain handshake messages or raw application data.
Paragraph (version A):
DTLS (Datagram Transport Layer Security) RFC6347 is based on TLS, but
differs in that it is designed to run over unrelaible datagram
protocols like UDP instead of TCP.  DTLS modifies the protocol to
make sure it can still provide the same security guarantees as TLS
even without reliability from the transport.  DTLS was designed to be
as similar to TLS as possible, so this document assumes that all
properties from TLS are carried over except where specified.
Paragraph (version B):
DTLS (Datagram Transport Layer Security) RFC6347 is based on TLS, but
differs in that it is designed to run over unreliable datagram
protocols like UDP instead of TCP.  DTLS modifies the protocol to
make sure it can still provide the same security guarantees as TLS
even without reliability from the transport.  DTLS was designed to be
as similar to TLS as possible, so this document assumes that all
properties from TLS are carried over except where specified.
Paragraph (version A):
QUIC transport relies on UDP.
Paragraph (version B):
QUIC transport assumes an unreliable transport, e.g., UDP.
Paragraph (version A):
Any SA used by IKEv2 can be rekeyed before expiration, which is
usually based either on time or number of bytes encrypted.
Paragraph (version B):
Any SA used by IKEv2 can be re-keyed before expiration, which is
usually based either on time or number of bytes encrypted.
Paragraph (version A):
DTLS RFC5764 is commonly used to perform mutual authentication and
key agreement for SRTP RFC5763.  Peers use DTLS to perform mutual
certificate-based authentication on the media path, and to generate
the SRTP master key.  Peer certificates can be issued and signed by a
certificate authority.  Alternatively, certificates used in the DTLS
exchange can be self-signed.  If they are self-signed, certificate
fingerprints are included in the signalling exchange (e.g., in SIP or
WebRTC), and used to bind the DTLS key exchange in the media plane to
the signaling plane.  The combination of a mutually authenticated
DTLS key exchange on the media path and a fingerprint sent in the
signalling channel protects against active attacks on the media,
provided the signalling can be trusted.  Signalling needs to be
protected as described in, for example, SIP RFC3261 Authenticated
Identity Management RFC8224 or the WebRTC security architecture I-
D.ietf-rtcweb-security-arch, to provide complete system security.
Paragraph (version B):
DTLS RFC5764 is commonly used to perform mutual authentication and
key agreement for SRTP RFC5763.  Peers use DTLS to perform mutual
certificate-based authentication on the media path, and to generate
the SRTP master key.  Peer certificates can be issued and signed by a
certificate authority.  Alternatively, certificates used in the DTLS
exchange can be self-signed.  If they are self-signed, certificate
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
the signaling plane.  The combination of a mutually authenticated
DTLS key exchange on the media path and a fingerprint sent in the
signaling channel protects against active attacks on the media,
provided the signaling can be trusted.  Signaling needs to be
protected as described in, for example, SIP RFC3261 Authenticated
Identity Management RFC8224 or the WebRTC security architecture I-
D.ietf-rtcweb-security-arch, to provide complete system security.
Paragraph (version A):
Tcpcrypt is a lightweight extension to the TCP protocol for
opportunistic encryption.  Applications may use tcpcrypt's unique
session ID for further application-level authentication.  Absent this
authentication, tcpcrypt is vulnerable to active attacks.
Paragraph (version B):
Tcpcrypt RFC8548 is a lightweight extension to the TCP protocol for
opportunistic encryption.  Applications may use tcpcrypt's unique
session ID for further application-level authentication.  Absent this
authentication, tcpcrypt is vulnerable to active attacks.
Paragraph (version A):
OpenVPN facilitates authentication using either a pre-shared static
key or using X.509 certificates and TLS.  In pre-shared key mode,
OpenVPN derives keys for encryption and authentication directly from
one or multiple symmetric keys.  In TLS mode, OpenVPN encapsulates a
TLS handshake, in which both peers must present a certificate for
authentication.  After the handshake, both sides contribute random
source material to derive keys for encryption and authentication
using the TLS pseudo random function (PRF).  OpenVPN provides the
possibility to authenticate and encrypt the TLS handshake itself
using a pre-shared key or passphrase.  Furthermore, it supports
rekeying using TLS.
Paragraph (version B):
OpenVPN facilitates authentication using either a pre-shared static
key or using X.509 certificates and TLS.  In pre-shared key mode,
OpenVPN derives keys for encryption and authentication directly from
one or multiple symmetric keys.  In TLS mode, OpenVPN encapsulates a
TLS handshake, in which both peers must present a certificate for
authentication.  After the handshake, both sides contribute random
source material to derive keys for encryption and authentication
using the TLS pseudo random function (PRF).  OpenVPN provides the
possibility to authenticate and encrypt the TLS handshake itself
using a pre-shared key or passphrase.  Furthermore, it supports re-
keying using TLS.
Paragraph (version A):
For replay protection, OpenVPN assigns an identifier to each outgoing
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
combines a timestamp with an incrementing sequence number into a
64-bit identifier.  In TLS mode with CBC cipher mode, OpenVPN omits
the timestamp, so identifiers are only 32-bit.  This is sufficient
since OpenVPN can guarantee the uniqueness of this identifier for
each key, as it can trigger rekeying if needed.
Paragraph (version B):
For replay protection, OpenVPN assigns an identifier to each outgoing
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
combines a timestamp with an incrementing sequence number into a
64-bit identifier.  In TLS mode with CBC cipher mode, OpenVPN omits
the timestamp, so identifiers are only 32-bit.  This is sufficient
since OpenVPN can guarantee the uniqueness of this identifier for
each key, as it can trigger re-keying if needed.