Draft: draft-ietf-taps-transport-security

Commentary: WIP addressing . I do n't want to pull this as - is : I just want comments on the format and usefulness of this . This closes the circle created by the list of protocol features in section 3 , and indicates where we probably want more consistency and completeness in that list so the derivation of common optional features is more obvious . 
 Still a WIP . I have a bunch of comments as a result of doing this exercise : Feature availability for some protocol / feature combinations is not clear from the descriptions in the doc . Wireguard is IP encapsulation within UDP , but this is not stated anywhere in the doc . The set of features we list here should be called out or evident from the protocol features subsections under each protocol description . I think there 's still some confusion in sections around symmetric authentication vs. signatures , i.e. , AEAD - style authentication ( " packets belong to this session " ) vs. PKI endpoint authentication ( " this connection belongs to a peer I trust and is not being MITMed " ) . This may be a comment on the unfortunateness of the literature using " authenticated " for both . 
 Feature availability for some protocol / feature combinations is not clear from the descriptions in the doc . Can you give examples ? Can you please open an issue to address this ? See the other open pull request . :-) Where in particular are these things confused ? 
 ping ! 
 Sorry , am away for the holiday weekend . Feature availability for some protocol / feature combinations is not clear from the descriptions in the doc . The ones I have listed with a " ? " , for instance . I guessed on a few of the others , as well ( e.g. , configuration extensions for MinimalT ) . The right answer is for me to go back through this table and enumerate all the areas where the text is n't clear , and fix them . I 'll file an issue . Wireguard is IP encapsulation within UDP , but this is not stated anywhere in the doc . Will do . I think there 's still some confusion in sections around symmetric authentication vs. signatures , i.e. , AEAD - style authentication ( " packets belong to this session " ) vs. PKI endpoint authentication ( " this connection belongs to a peer I trust and is not being MITMed " ) . This may be a comment on the unfortunateness of the literature using " authenticated " for both . I 'm not quite sure what I was thinking here . After reading it through again , I think I 'm okay with how this is presented . 
 can you please update this PR ? 
 A few more questions : Is there any existing client puzzle / proof of work standardized for TLS or DTLS , or is as far as something 's gotten ? Same goes for IPsec ; I can find no standardized version of any of these things . Should algorithms like TLS , DTLS , etc . that support native authentication but also can export a cryptographic channel binding be listed as supporting authentication delegation ? My instinct is yes . 
 None that I 'm aware of ! Yes , I think that 's correct . 
 Will you be able to complete this PR this week ? 
 Yes , though I could use some guidance on the ? 's in the table , if you have enough context to resolve them . Otherwise , I will do some digging . 
 IKEv2+ESP / AD : Yes , via EAP(-TLS ) . IKEv2+ESP / AFN : Yes , via vendor and configuration payloads . SRTP+DTLS / CM : No .  : Omit , since it 's a variant ? WireGuard / CM : No , connections are bound to IP addresses . WireGuard / SC : No , session resumption is not supported . WireGuard / LHP : Yes , for transport packets only . MinimalT / AD : No . MinimalT / AFN : No . MinimalT / LHP : Yes . CurveCP / AD : No . 
 RFR . 
 Ship it . 
 It 's probably easier and more consumable to encode the matrix of protocols providing a particular feature as a table . 
 I 'm assigning this to you ,  . Will you have time to take a stab at it ? 
 Yep , I 'll work on it this afternoon .
Paragraph (version A):
Cryptographic algorithm negotiation: Transport security protocols
should permit applications to configure supported or enabled
cryptographic algorithms.
Paragraph (version A):
Application authentication delegation: Some protocols may
completely defer endpoint authentication to applications, e.g., to
reduce online protocol complexity.
Paragraph (version B):
Cryptographic algorithm negotiation (AN): Transport security
protocols should permit applications to configure supported or
enabled cryptographic algorithms.
Paragraph (version B):
Application authentication delegation (AD): Some protocols may
completely defer endpoint authentication to applications, e.g., to
reduce online protocol complexity.
Paragraph (version A):
Mutual authentication: Transport security protocols should allow
each endpoint to authenticate the other if required by the
application.
Paragraph (version B):
Mutual authentication (MA): Transport security protocols should
allow each endpoint to authenticate the other if required by the
application.
Paragraph (version A):
DoS mitigation: Transport security protocols may need to support
volumetric DoS prevention via, e.g., cookies or initiator-side
puzzles.
Paragraph (version A):
Connection mobility: Sessions should not be bound to a network
connection (or 5-tuple).  This allows cryptographic key material
and other state information to be reused in the event of a
connection change.  Examples of this include a NAT rebinding that
occurs without a client's knowledge.
Paragraph (version A):
Source validation: Source validation must be provided to mitigate
server-targeted DoS attacks.  This can be done with puzzles or
cookies.
Paragraph (version A):
Application-layer feature negotiation: The type of application
using a transport security protocol often requires features
configured at the connection establishment layer, e.g., ALPN
RFC7301.  Moreover, application-layer features may often be used
to offload the session to another server which can better handle
the request.  (The TLS SNI is one example of such a feature.)  As
such, transport security protocols should provide a generic
mechanism to allow for such application-specific features and
options to be configured or otherwise negotiated.
Paragraph (version A):
Configuration extensions: The protocol negotiation should be
extensible with addition of new configuration options.
Paragraph (version B):
DoS mitigation (DM): Transport security protocols may need to
support volumetric DoS prevention via, e.g., cookies or initiator-
side puzzles.
Paragraph (version B):
Connection mobility (CM): Sessions should not be bound to a
network connection (or 5-tuple).  This allows cryptographic key
material and other state information to be reused in the event of
a connection change.  Examples of this include a NAT rebinding
that occurs without a client's knowledge.
Paragraph (version B):
Source validation (SV): Source validation must be provided to
mitigate server-targeted DoS attacks.  This can be done with
puzzles or cookies.
Paragraph (version B):
Application-layer feature negotiation (AFN): The type of
application using a transport security protocol often requires
features configured at the connection establishment layer, e.g.,
ALPN RFC7301.  Moreover, application-layer features may often be
used to offload the session to another server which can better
handle the request.  (The TLS SNI is one example of such a
feature.)  As such, transport security protocols should provide a
generic mechanism to allow for such application-specific features
and options to be configured or otherwise negotiated.
Paragraph (version B):
Configuration extensions (CX): The protocol negotiation should be
extensible with addition of new configuration options.
Paragraph (version A):
Session caching (and management): Sessions should be cacheable to
enable reuse and amortize the cost of performing session
establishment handshakes.
Paragraph (version A):
Length-hiding padding: Applications may wish to defer traffic
padding to the security protocol to deter traffic analysis
attacks.
Paragraph (version B):
Session caching and management (SC): Sessions should be cacheable
to enable reuse and amortize the cost of performing session
establishment handshakes.
Paragraph (version B):
Length-hiding padding (LHP): Applications may wish to defer
traffic padding to the security protocol to deter traffic analysis
attacks.
Paragraph (version B):
The following table lists the availability of the above-listed
optional features in each of the analyzed protocols.  "Mandatory"
indicates that the feature is intrinsic to the protocol and cannot be
disabled.  "Supported" indicates that the feature is optionally
provided natively or through a (standardized, where applicable)
extension.