Draft: draft-pauly-taps-transport-security

Commentary: Looks good to me .
Paragraph (version A):
SRTP - Secure RTP - is a profile for RTP that provides
confidentiality, message authentication, and replay protection for
data and control packets RFC3711.  SRTP packets are encrypted using a
session key, which is derived from a separate master key.  Master
keys are derived and managed externally, e.g., via DTLS, as specified
in RFC 5736 RFC5763.
Paragraph (version B):
SRTP - Secure RTP - is a profile for RTP that provides
confidentiality, message authentication, and replay protection for
data and control packets RFC3711.  SRTP packets are encrypted using a
session key, which is derived from a separate master key.  Master
keys are derived and managed externally, e.g., via DTLS, as specified
in RFC 5763 RFC5763, under the control of a signaling protocol such
as SIP RFC3261 or WebRTC I-D.ietf-rtcweb-security-arch.
Paragraph (version B):
SRTP adds confidentiality and optional integrity protection to RTP
data packets, and adds confidentially and mandatory integrity
protection to RTP control (RTCP) packets.  For RTP data packets, this
is done by encrypting the payload section of the packet and
optionally appending an authentication tag (MAC) as a packet trailer,
with the RTP header authenticated but not encrypted.  The RTP header
itself is left unencrypted to enable RTP header compression RFC3545.
For RTCP packets, the first packet in the compound RTCP packet is
partially encrypted, leaving the first eight octets of the header as
cleartext to allow identification of the packet as RTCP, while the
remainder of the compound packet is fully encrypted.  The entire RTCP
packet is then authenticated by appending a MAC as packet trailer.
Paragraph (version B):
Packets are encrypted using session keys, which are ultimately
derived from a master key and some additional master salt and session
salt.  SRTP packets carry a 2-byte sequence number to partially
identify the unique packet index.  SRTP peers maintain a separate
rollover counter (ROC) for RTP data packets that is incremented
whenever the sequence number wraps.  The sequence number and ROC
together determine the packet index.  RTCP packets have a similar,
yet differently named, field called the RTCP index which serves the
same purpose.
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 signalling (SIP) channel.
Paragraph (version B):
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):
Partial encryption, protecting media payloads and control packets
but not data packet headers.
Paragraph (version B):
Optional authentication of data packets; mandatory authentication
of control packets.
Paragraph (version B):
External signaling protocol to manage RTP parameters and locate
and identify peers, e.g., SIP RFC3261 or WebRTC I-D.ietf-rtcweb-
security-arch.