Draft: draft-ietf-taps-transport-security

Commentary: Summarized the interfaces exposed to applications in a table to make Section 5 easier to read , see . I pretty much used the information as given in Section 5.1 to 5.3 as is , however , I have the following issues / questions : Are we intentionally missing gQUIC ? Is it the same as ( IETF ) QUIC ? Are we intentionally missing  ? Some entries list IKEv2 , some list ESP - I merged the two , as this document considers them together according to Section 3.4.1 . Is this correct here ? It looks to me like OpenVPN is missing some interfaces . For example , as far as I know , it is possible to provide an identity and private key for OpenVPN , and it is possible to choose which algorithms to support . Should we add these ? For Pre - Shared Key Import / Export : Is " non - importable " the same as " Interface is not exposed " ? For Pre - Shared Key Export : Is " TLS ( for QUIC ) " just " QUIC " and is "  ( for SRTP ) " just " SRTP " ? TLS and DTLS are also given on their own below . Do we want to delete the lists of protocols from Sections 5.1 to 5.3 once we have completed the table in Section 5.4 ? 
 Not sure – is the table is intended to represent plain SRTP or SRTP with some key management protocols ( which could be either DTLS or  ) ? 
 The table is intended to represent exactly the same as the lists of protocols in Sections 5.1 through 5.3 . As these lists only say " SRTP " without mentioning a specific key management protocol , I guess right now it represents SRTP . If the interfaces are independent of the key management protocol , then this is correct and we are intentionally missing  . But if there 's different interfaces for DTLS - SRTP and  , then we should separate them out . 
 DTLS - SRTP and  will have different interfaces , so we 'll need to separate them out . I 'll do a PR . 
 I updated the table from and and double - checked that the table matches the lists . Agree with keeping both the lists and the table . Sounds good ! Feel free to update the lists and then I 'll adjust the table . I think my other questions from the initial post have mostly been answered . I 'll just assume we are intentionally missing gQUIC from the lists and table . The one question I 'm still wondering about is Pre - Shared Import / Export : For PSK import , the lists say " Non - importable " for CurveCP , while  and IKEv2 are missing from the list . Are they the same , i.e. , should we explicitly put SRTP and IKEv2 as " Non - importable " ? Same question for PSK export , where for CurveCP it 's " Non - exportable " , while ESP and WireGuard are missing from the list . Please advise . 
 I think IKEv2 should be Direct Import for PSKI . Not sure about SRTP . For PSK export , it does n't really apply to either ESP or WireGuard , so I think they should be non - exportable . 
 Updated the table to match (  interfaces ) and resolved merge conflict . Double - checked that the table matches the lists and . I think this is good to go . 
 Comment from Ekr 's review of -10 : Pre - Connection Interfaces Configuration interfaces are used to configure the security protocols before a handshake begins or the keys are negotiated . This presentation seems pretty hard to follow , in that it 's a lot of work to figure out which in the long list of protocols does n't have this property . Maybe a summary table would help ? 
 Would it make sense to additionally provide clarifying examples for some of the protocols listed for each interface , where they might not be clear ? I do n't have a strong opinion , but to give an example , the session caching interface for tcpcrypt is very limited while the one for TLS is more capable .
Paragraph (version B):
CurveCP CurveCP is a UDP-based transport security protocol from
Daniel J.  Bernstein.  Unlike many other security protocols, it is
based entirely upon public key algorithms.  CurveCP provides its own
reliability for application data as part of its protocol.
Paragraph (version A):
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,
following conventions in I-D.ietf-taps-interface and I-D.ietf-taps-
arch.
Paragraph (version A):
Identities and Private Keys: The application can provide its
identities (certificates) and private keys, or mechanisms to
access these, to the security protocol to use during handshakes.
Paragraph (version B):
This section describes the interface surface exposed by the security
protocols described above.  We partition these interfaces into pre-
connection (configuration), connection, and post-connection
interfaces, following conventions in I-D.ietf-taps-interface and I-
D.ietf-taps-arch.
Paragraph (version B):
Note that not all protocols support each interface.  The table in
interface-protocols-table summarizes which protocol exposes which of
the interfaces.  In the following sections, we provide abbreviations
of the interface names to use in the summary table.
Paragraph (version B):
Identities and Private Keys (IPK): The application can provide its
identities (certificates) and private keys, or mechanisms to
access these, to the security protocol to use during handshakes.
Paragraph (version A):
Supported Algorithms (Key Exchange, Signatures, and Ciphersuites):
The application can choose the algorithms that are supported for
key exchange, signatures, and ciphersuites.
Paragraph (version B):
Supported Algorithms (Key Exchange, Signatures, and Ciphersuites)
(ALG): The application can choose the algorithms that are
supported for key exchange, signatures, and ciphersuites.
Paragraph (version A):
Extensions (Application-Layer Protocol Negotiation): The
application enables or configures extensions that are to be
negotiated by the security protocol, such as ALPN RFC7301.
Paragraph (version B):
Extensions (Application-Layer Protocol Negotiation) (EXT): The
application enables or configures extensions that are to be
negotiated by the security protocol, such as ALPN RFC7301.
Paragraph (version A):
Session Cache Management: The application provides the ability to
save and retrieve session state (such as tickets, keying material,
and server parameters) that may be used to resume the security
session.
Paragraph (version B):
Session Cache Management (CM): The application provides the
ability to save and retrieve session state (such as tickets,
keying material, and server parameters) that may be used to resume
the security session.
Paragraph (version A):
Authentication Delegation: The application provides access to a
separate module that will provide authentication, using EAP for
example.
Paragraph (version A):
Identity Validation: During a handshake, the security protocol
will conduct identity validation of the peer.  This can call into
the application to offload validation.
Paragraph (version B):
Authentication Delegation (AD): The application provides access to
a separate module that will provide authentication, using EAP for
example.
Paragraph (version B):
Pre-Shared Key Import (PSKI): Either the handshake protocol or the
application directly can supply pre-shared keys for use in
encrypting (and authenticating) communication with a peer.
Paragraph (version B):
Identity Validation (IV): During a handshake, the security
protocol will conduct identity validation of the peer.  This can
call into the application to offload validation.
Paragraph (version B):
Source Address Validation (SAV): The handshake protocol may
delegate validation of the remote peer that has sent data to the
transport protocol or application.  This involves sending a cookie
exchange to avoid DoS attacks.
Paragraph (version B):
Connection Termination (CT): The security protocol may be
instructed to tear down its connection and session information.
This is needed by some protocols, e.g., to prevent application
data truncation attacks in which an attacker terminates an
underlying insecure connection-oriented protocol to terminate the
session.
Paragraph (version A):
Key Update: The handshake protocol may be instructed to update its
keying material, either by the application directly or by the
record protocol sending a key expiration event.
Paragraph (version B):
Key Update (KU): The handshake protocol may be instructed to
update its keying material, either by the application directly or
by the record protocol sending a key expiration event.
Paragraph (version A):
Key Expiration: The record protocol can signal that its keys are
expiring due to reaching a time-based deadline, or a use-based
deadline (number of bytes that have been encrypted with the key).
This interaction is often limited to signaling between the record
layer and the handshake layer.
Paragraph (version A):
Mobility Events: The record protocol can be signaled that it is
being migrated to another transport or interface due to connection
mobility, which may reset address and state validation and induce
state changes such as use of a new Connection Identifier (CID).
Paragraph (version B):
Shared Secret Export (PSKE): The handshake protocol may provide an
interface for producing shared secrets for application-specific
uses.
Paragraph (version B):
Key Expiration (KE): The record protocol can signal that its keys
are expiring due to reaching a time-based deadline, or a use-based
deadline (number of bytes that have been encrypted with the key).
This interaction is often limited to signaling between the record
layer and the handshake layer.
Paragraph (version B):
Mobility Events (ME): The record protocol can be signaled that it
is being migrated to another transport or interface due to
connection mobility, which may reset address and state validation
and induce state changes such as use of a new Connection
Identifier (CID).
Paragraph (version B):
The following table summarizes which protocol exposes which
interface.