Draft: draft-pauly-taps-transport-security

Commentary: Future protocols include OTR , Ntor , TAP , ATLS ,  , and NoiseSocket . We can always add them in a rev before London ! 
 I updated the text based on your comments . As for the tcpcrypt PR : sounds good . Please feel free to add yourself as an author in that PR , if you feel so inclined . :-) 
 I 'll submit this content by the end of day today , just so the draft does n't expire . If you 've time , could you please review the  section ? ( No rush -- we can always submit a new version with any edits you may have . ) 
 I 'll take a look , but it 'll likely be next week ... 
 No problem ! I 'll plan on submitting the new draft today . We can apply your feedback if and when you have to review it next week . 
 Looks mostly good . I 'll ask more questions out - of - band re : where we 're going with this . I will also submit a PR shortly for the tcpcrypt section . Looks good to me ! Thanks for writing up .
Paragraph (version A):
The initial QUIC messages are sent without encryption in order to
start the TLS handshake.  Once the handshake has generated keys, the
subsequent messages are encrypted.  The TLS 1.3 handshake for QUIC is
used in either a single-RTT mode or a fast-open zero-RTT mode.  When
zero-RTT handshakes are possible, the encryption first transitions to
use the zero-RTT keys before using single-RTT handshake keys after
the next TLS flight.
Paragraph (version B):
Initial QUIC messages (packets) are encrypted using "fixed" keys
derived from the QUIC version and public packet information
(Connection ID).  Packets are later encrypted using keys derived from
the TLS traffic secret upon handshake completion.  The TLS 1.3
handshake for QUIC is used in either a single-RTT mode or a fast-open
zero-RTT mode.  When zero-RTT handshakes are possible, the encryption
first transitions to use the zero-RTT keys before using single-RTT
handshake keys after the next TLS flight.
Paragraph (version B):
WireGuard is a layer 3 protocol designed to complement or replace
IPsec WireGuard.  Unlike most transport security protocols, which
rely on PKI for peer authentication, WireGuard authenticates peers
using pre-shared public keys delivered out-of-band, each of which is
bound to one or more IP addresses.  Moreover, as a protocol suited
for VPNs, WireGuard offers no extensibility, negotiation, or
cryptographic agility.
Paragraph (version B):
WireGuard is a simple VPN protocol that binds a pre-shared public key
to one or more IP addresses.  Users configure WireGuard by
associating peer public keys with IP addresses.  These mappings are
stored in a CryptoKey Routing Table.  (See Section 2 of WireGuard for
more details and sample configurations.)  These keys are used upon
WireGuard packet transmission and reception.  For example, upon
receipt of a Handshake Initiation message, receivers use the static
public key in their CryptoKey routing table to perform necessary
cryptographic computations.
Paragraph (version B):
x25519 Curve25519 and HKDF RFC5869 for ECDH and key derivation.
Paragraph (version B):
ChaCha20+Poly1305 RFC7539 for packet authenticated encryption.
Paragraph (version B):
BLAKE2s BLAKE2 for hashing.
Paragraph (version B):
There is no cryptographic agility.  If weaknesses are found in any of
these algorithms, new message types using new algorithms must be
introduced.
Paragraph (version B):
WireGuard is designed to be entirely stateless, modulo the CryptoKey
routing table, which has size linear with the number of trusted
peers.  If a WireGuard receiver is under heavy load and cannot
process a packet, e.g., cannot spare CPU cycles for point
multiplication, it can reply with a cookie similar to DTLS and IKEv2.
This cookie only proves IP address ownership.  Any rate limiting
scheme can be applied to packets coming from non-spoofed addresses.
Paragraph (version B):
Optional PSK-based session creation.
Paragraph (version B):
Mutual client and server authentication.
Paragraph (version B):
Stateful, timestamp-based replay prevention.
Paragraph (version B):
Cookie-based DoS mitigation similar to DTLS and IKEv2.
Paragraph (version B):
Datagram transport.
Paragraph (version B):
Out-of-band key distribution and management.
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 5736 RFC5763.
Paragraph (version B):
Numerous encryption modes are supported.  For popular modes of
operation, e.g., AES-CTR, The (unique) initialization vector (IV)
used for each encryption mode is a function of the RTP SSRC
(synchronization source), packet index, and session "salting key".
Paragraph (version B):
SRTP offers replay detection by keeping a Replay List of already seen
and processed packet indices.  If a packet arrives with an index that
matches one in the Replay List, it is silently discarded.
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 signalling (SIP) channel.
Paragraph (version B):
Optional replay protection with tunable replay windows.
Paragraph (version B):
Out-of-order packet receipt.
Paragraph (version B):
External key derivation and management mechanism or protocol,
e.g., DTLS RFC5763.
Paragraph (version B):
This document summarizes existing transport security protocols and
their interfaces.  It does not propose changes to or recommend usage
of reference protocols.