Draft: draft-ietf-taps-transport-security

Commentary: … /security and security / transport dependencies . 
 can you please take a look before Wednesday ? 
 Yep , I will review Monday morning . 
 I think this is fine . We can do further tweaks in subsequent PRs .
Paragraph (version A):
There exists a common set of features shared across the transport
protocols surveyed in this document.  The mandatory features should
be provided by any transport security protocol, while the optional
features are extensions that a subset of the protocols provide.  For
clarity, we also distinguish between handshake and record features.
Paragraph (version A):
Forward-secure segment encryption and authentication: Transit data
must be protected with an authenticated encryption algorithm.
Paragraph (version B):
There exists a common set of features shared across the transport
protocols surveyed in this document.  Mandatory features constitute a
baseline of functionality that an application may assume for any TAPS
implementation.  Optional features by contrast may vary from
implementation to implementation, and so an application cannot simply
assume they are available.  Applications learn of and use optional
features by querying for their presence and support.  Optional
features may not be implemented, or may be disabled if their presence
impacts transport services or if a necessary transport service is
unavailable.
Paragraph (version B):
Segment encryption and authentication: Transit data must be
protected with an authenticated encryption algorithm.
Paragraph (version B):
Forward-secure key establishment: Negotiated keying material must
come from an authenticated, forward-secure key exchange protocol.
Paragraph (version A):
Pre-shared key support: A record protocol must be able to use a
pre-shared key established out-of-band to encrypt individual
messages, packets, or datagrams.
Paragraph (version B):
Pre-shared key support: A security protocol must be able to use a
pre-shared key established out-of-band or from a prior session to
encrypt individual messages, packets, or datagrams.
Paragraph (version B):
Application dependency: Mutual authentication required for
application support.
Paragraph (version B):
Transport dependency: Connections are unreliable or can change
due to unpredictable network events, e.g., NAT re-bindings.
Paragraph (version B):
Transport dependency: Packets may arrive as datagrams instead
of streams from unauthenticated sources.
Paragraph (version A):
This section describes the interface surface exposed by the security
protocols described above, with each interface.  Note that not all
protocols support each interface.
Paragraph (version B):
Application dependency: Specification of application-layer
features or functionality.
Paragraph (version B):
Application dependency: Specification of application-specific
extensions.
Paragraph (version B):
This section describes the interface surface exposed by the security
protocols described above.  Note that not all protocols support each
interface.  We partition these interfaces into pre-connection
(configuration), connection, and post-connection interfaces.
Paragraph (version A):
Handshake interfaces are the points of interaction between a
handshake protocol and the application, record protocol, and
transport once the handshake is active.
Paragraph (version A):
Pre-Shared Key Export
The handshake protocol will generate one or more keys to be used
for record encryption/decryption and authentication.  These may be
explicitly exportable to the application, traditionally limited to
direct export to the record protocol, or inherently non-exportable
because the keys must be used directly in conjunction with the
record protocol.
Paragraph (version B):
Pre-Shared Key Export The handshake protocol will generate one or
more keys to be used for record encryption/decryption and
authentication.  These may be explicitly exportable to the
application, traditionally limited to direct export to the record
protocol, or inherently non-exportable because the keys must be
used directly in conjunction with the record protocol.
Paragraph (version A):
Record interfaces are the points of interaction between a record
protocol and the application, handshake protocol, and transport once
in use.
Paragraph (version A):
Encrypt application data
The application can send data to the record protocol to encrypt it
into a format that can be sent on the underlying transport.  The
encryption step may require that the application data is treated
as a stream or as datagrams, and that the transport to send the
encrypted records present a stream or datagram interface.
Paragraph (version A):
Decrypt application data
The application can receive data from its transport to be
decrypted using record protocol.  The decryption step may require
that the incoming transport data is presented as a stream or as
datagrams, and that the resulting application data is a stream or
datagrams.