Draft: draft-pauly-taps-transport-security

Commentary: The one remaining item here is around address - agnosticism : I know the tcpcrypt draft asserts it , but I 'm unclear on how that would be implemented in practice in the kernel , both because : resolution and connection establishment are separate stacks complexity of state sharing for session caches makes server pools ( the most common reason for IP changing ) unlikely to implement it
Paragraph (version A):
tcpcrypt is a lightweight extension to the TCP protocol to enable
opportunistic encryption.
Paragraph (version A):
tcpcrypt extends TCP to enable opportunistic encryption between the
two ends of a TCP connection I-D.ietf-tcpinc-tcpcrypt.  It is a type
of TCP Encryption Protocol (TEP).  The use of a TEP is negotiated
using TCP headers during the initial TCP handshake.  Negotiating a
TEP also involves agreeing upon a key exchange algorithm.  If and
when a TEP is negotiated, the tcpcrypt key exchange occurs within the
data segments of the first packets exchanged after the handshake
completes.  The initiator of a connection sends a list of support
AEAD algorithms, a random nonce, and an ephemeral public key share.
The responder chooses an AEAD algorithm and replies with its own
nonce and ephemeral key share.  The traffic encryption keys are
derived from the key exchange.
Paragraph (version A):
Each tcpcrypt session is associated with a unique session ID; the
value of which is derived from the current shared secret used for the
session.  This can be cached and used to later resume a session.
Willingness to resume a session is signaled within the TCP-ENO
negotiation option during the TCP handshake I-D.ietf-tcpinc-tcpeno.
Session identifiers are rotated each time they are resumed.  Sessions
may also be re-keyed if the natural AEAD limit is reached.
Paragraph (version A):
tcpcrypt only encrypts the data portion of a TCP packet.  It does not
encrypt any header information, such as the TCP sequence number.
Paragraph (version A):
Forward-secure TCP packet encryption.
Paragraph (version A):
Session re-keying.
Paragraph (version A):
TCP (with option support).
Paragraph (version B):
Tcpcrypt is a lightweight extension to the TCP protocol to enable
opportunistic encryption with hooks available to the application
layer for implementation of endpoint authentication.
Paragraph (version B):
Tcpcrypt extends TCP to enable opportunistic encryption between the
two ends of a TCP connection I-D.ietf-tcpinc-tcpcrypt.  It is a
family of TCP encryption protocols (TEP), distinguished by key
exchange algorithm.  The use of a TEP is negotiated with a TCP option
during the initial TCP handshake via the mechanism described by TCP
Encryption Negotiation Option (ENO) I-D.ietf-tcpinc-tcpeno.  In the
case of initial session establishment, once a tcpcrypt TEP has been
negotiated the key exchange occurs within the data segments of the
first few packets exchanged after the handshake completes.  The
initiator of a connection sends a list of supported AEAD algorithms,
a random nonce, and an ephemeral public key share.  The responder
typically chooses a mutually-supported AEAD algorithm and replies
with this choice, its own nonce, and ephemeral key share.  An initial
shared secret is derived from the ENO handshake, the tcpcrypt
handshake, and the initial keying material resulting from the key
exchange.  The traffic encryption keys on the initial connection are
derived from the shared secret.  Connections can be re-keyed before
the natural AEAD limit for a single set of traffic encryption keys is
reached.
Paragraph (version B):
Each tcpcrypt session is associated with a ladder of resumption IDs,
each derived from the respective entry in a ladder of shared secrets.
These resumption IDs can be used to negotiate a stateful resumption
of the session in a subsequent connection, resulting in use of a new
shared secret and traffic encryption keys without requiring a new key
exchange.  Willingness to resume a session is signaled via the ENO
option during the TCP handshake.  Given the length constraints
imposed by TCP options, unlike stateless resumption mechanisms (such
as that provided by session tickets in TLS) resumption in tcpcrypt
requires the maintenance of state on the server, and so successful
resumption across a pool of servers implies shared state.
Paragraph (version B):
Owing to middlebox ossification issues, tcpcrypt only protects the
payload portion of a TCP packet.  It does not encrypt any header
information, such as the TCP sequence number.
Paragraph (version B):
Tcpcrypt exposes a universally-unique connection-specific session ID
to the application, suitable for application-level endpoint
authentication either in-band or out-of-band.
Paragraph (version B):
Forward-secure TCP payload encryption and integrity protection.
Paragraph (version B):
Connection re-keying.
Paragraph (version B):
Application-level authentication primitive.