Draft: draft-ietf-taps-transport-security

Commentary: TLS 1.3 record protocol never transmits raw application data . ( Also consider alerts ) Do n't enable TLS compression . Record protocol hidden from server , too . tls - record - limit reference instead of    Client authentication is optional , no ? Update QUIC for stream0 changes 
 Addressed in . 
 Wireguard is IP encapsulation within UDP , but this is not stated anywhere in the doc . 
 Addressed in . 
 The main problem that I see is a missing " red thread ” - e.g. when deriving the security features in section 4 : as a reader , I would expect there to be a 1:1 mapping from the protocol features in section 3 to the security features in section 4 , yet there is n’t . For example : sec . 3.10 , CurveCP , has , in sec . 3.10.2 , protocol features such as “ 1 - RTT session bootstrapping ” and “ Sender - chosen explicit nonces , … ” , and these are not listed in section 4 as such . I guess this is okay because “ Protocol features ” are internal details , not exposed to an application ? But then this should be made clear in section 3 , and the security features that we see listed in section 4 should be listed in sec . 3 per protocol with the same wording so that we can see a connection from section 3 to section 4 . Similarly , what is the rationale for making some features mandatory and some optional in section 4 ? Reasons for this choice should be explicitly laid out at the beginning of section 4 . Maybe the reason can be derived from section 5 … see below : Once you ’ve laid out the “ interface ” ( I ’ll come to that ) as you do in section 5 , just from looking at this list , it ’s easy to see that TLS gives us everything except : Authentication Delegation Explicit ( as opposed to “ direct ” ) pre - shared key import Transport mobility … and none of these are mandatory according to section 4 ( so maybe that could be seen as a reason to not make them mandatory ? ) . TLS could be a general recommendation , combined with an explanation that , if you want one of these things listed above , you need to implement a protocol other than TLS , but then you need to be aware of the protocol dependencies that such a protocol choice brings with it . Generally , as an implementer of a transport system , this document now tells me quite clearly which features I must offer ( and it tells me which protocols I then must support ) . However , the trade - offs are not so clear . I see trade - offs in the protocol dependencies that you list in section 3 ; then there are Transport Dependencies listed in section 4 , but only for the optional features , and it says “ None ” almost everywhere … yet , in section 3 , there are tons of “ Protocol Dependencies ” , so I find this surprising . Another missing “ red thread ” : why do the transport features have different names in sections 4 and 5 ? I would expect to find “ Transport mobility ” in section 4 , but there it ’s “ Connection mobility ” . Similarly , I ’d expect to find “ Session cache management ” ( from sec . 5.1 ) in section 4 , but there it ’s called “ Session caching and management ” . I think the whole document would look much more uniform and better structured with some clearer mappings - from section 3 to the listed security features in section 4 and the “ interfaces ” in section 5 . This brings me to the next issue : I think there ’s a terminology problem with this document . The terminology section , in line with all other TAPS documents , mentions “ confidentiality ” as an example of a “ Transport Feature ” . Further down , “ Security Feature ” is introduced . Given the description of Transport Feature , a Security Feature is a special case of a Transport Feature . Maybe the first sentence of the Security Feature definition could be changed to say “ A Transport Feature that a network security layer provides to applications . ” Section 3 then talks about “ Protocol features ” ; these are maybe not offered to applications , so I think it ’s fine to use this term , but you should also define it in the Terminology section . Then , Section 5 talks about Transport Security Protocol Interfaces - but that term is n’t defined anywhere . I think these “ interfaces ” are really Security Features , no ? Actually , given that they seem to be the same but with slightly different wording , I wonder if sections 4 and 5 could be merged … or maybe they should be switched in order : section 5 should appear first , calling them Security Features , and then what is now Section 4 could come after , deriving which ones of them are mandatory and optional , as well as list transport / application dependencies . Some smaller things / nits : I find it strange that this draft cites only RFC 8095 but no other TAPS documents . In particular , because it complements draft - ietf - taps - minset in the process of TAPS , I think it should reference back to it . ( The minset draft says that it does n’t discuss security because this is covered in draft - ietf - taps - transport - security , but then draft - ietf - taps - transport - security only says that it complements RFC 8095 - this gives readers following the link from minset a confusing context ) . Section 3.2.3 : Path MTU Discovery surprised me here . What does that mean ? That DTLS relies on an application implementing PMTUD ( as it ’s over UDP ) , and then telling DTLS about it ? Does n’t DTLS do this on its own ? Why not ? Sorry for asking a DTLS question , surely it ’s me … but just listing PMTUD as a dependency is n’t a good enough explanation , I think . sec . 3.3 : when I first read “ A mapping for QUIC over TLS 1.3 has been specified to provide this handshake ” , I was surprised . I mean , given that TLS runs over TCP , this sentence sounds like something really does n’t match here . Only in sec . 3.3.3 you explain “ TLS within QUIC relies on a reliable stream abstraction for its handshake ” . Well that ’s what I thought , but then this should probably be brought earlier - “ mapping for QUIC over TLS 1.3 ” just sounds like QUIC uses TLS , which uses TCP , which is of course wrong . Maybe it ’s just the word “ over ” - using “ with ” instead would already make this clearer . sec . 3 sentence 1 : “ … security protocols that are currently used to … ” sec 3.3.1 1st sentence after bullet list : “ The QUIC transport layer supportS multiple streams … ” Same para , 3rd sentence : “ The TLS handshake , along with further records , are sent over this stream . ” - did you mean to say “ The TLS handshake messages ” ? sec 3.4 , line 2 : “ either as for creating tunnels ( tunnel - mode ) ” - I think the “ as ” should be removed here ? penultimate sentence of sec . 3.5.1 : “ … DTLS - offered certificates match that which are offered over SIP ” - is “ that ” correct here ? ( should it be “ the ones ” or something like that ? ) 10.1 par 5 : This begins with “ Unlike TCP , … ” - is n’t this strange to say , for being too obvious ? Or did you mean to say tcpcrypt ? Well actually even TCP has cookies for some form of “ source validation ” , with TFO . Of course that ’s a limited use , but … maybe simply removing “ Unlike TCP ” here would make this clearer . 2 , “ Mutual authentication ” and “ Source validation ” : the sentence describing these features says “ must ” , yet it ’s in the section of optional features . While this does n’t really matter , it makes for a slightly surprising read , and would IMO be better as a factual statement - e.g. “ Transport security protocols allow each endpoint to authenticate the other … ” and “ Source validation is provided to mitigate … ” Sec 5.1 . : missing line break after : Session Cache Management Connection Termination Pre - Shared Key Export … and before “ Protocols ” in the “ Identity Validation ” item . 
 I agree with  's first paragraph : I think that is one aspect of what  is talking about when he refers to motivation for including some protocols and not others . One nit in what he says : I think this is at a layer below TLS . TLS over TCP does n't give us transport mobility , but TLS over ( say ) MPTCP would in an internet that was MPTCP - safe , without any modifications to TLS . This applies to his later comment re : TLS . TLS is a specification for a protocol that runs over a ( reliable in - order ) stream abstraction , that typically runs over TCP . TCP is mentioned exactly once in the final TLS 1.3 draft , as part of the session ticket freshness discussion with respect to delays and retransmissions . 
 I agree regarding both points . I 'm not sure how I 'll address the second just yet . 
 Addressed in .
Paragraph (version B):
Record: Framed protocol messages.
Paragraph (version A):
Connection Mobility: a property of a connection that allows it to
be multihomed or resilient across network interface or address
changes.
Paragraph (version B):
Connection Mobility: a property of a connection that allows it to
be multihomed or resilient across network interface or address
changes, e.g., NAT rebindings that occur without an endpoint's
knowledge.  Mobility allows cryptographic key material and other
state information to be reused in the event of a connection
change.
Paragraph (version A):
In this section, we enumerate Security Features exposed by protocols
discussed in the remainder of this document.  Protocol security
properties that are unrelated to the API surface exposed by such
protocols, such as client or server identity hiding, are not listed
here as features.
Paragraph (version B):
In this section, we enumerate Security Features exposed by protocols
discussed in the remainder of this document.  Security Features
extend the set of Transport Features described in RFC8095 and
provided by Transport Services implementations.  Protocol security
properties that are unrelated to the API surface exposed by such
protocols, such as client or server identity hiding, are not listed
here as features.
Paragraph (version B):
Session caching and management: Manage session state cache used
for subsequent connections aimed towards amortizing connection
establishment costs.
Paragraph (version A):
Application-layer feature negotiation: Securely negotiate
application-specific functionality.
Paragraph (version A):
DoS mitigation (cookie or puzzle based): Peer DoS mitigation via
explicit proof of origin (cookie) or work mechanisms (puzzles).
Paragraph (version A):
Optional length-hiding and anti-amplification padding: Protocol-
drive record padding aimed at hiding plaintext message length and
mitigating amplification attack vectors.
Paragraph (version B):
Application-layer feature negotiation: Securely negotiate
application-specific functionality, including those necessary for
connection handling and management, e.g., the TLS parent
connection protocol type via ALPN RFC7301 or desired application
identity via SNI RFC6066.
Paragraph (version B):
Configuration extensions: Add protocol features via extensions or
configuration options.  TLS extensions are a primary example of
this feature.
Paragraph (version B):
Source validation (cookie or puzzle based): Peer source validation
and DoS mitigation via explicit proof of origin (cookie) or work
mechanisms (puzzles).
Paragraph (version B):
Length-hiding padding: Protocol-drive record padding aimed at
hiding plaintext message length and mitigating amplification
attack vectors.
Paragraph (version A):
The handshake protocol serves several purposes, including: peer
authentication, protocol option (key exchange algorithm and
ciphersuite) negotiation, and key derivation.  Peer authentication
may be mutual; however, commonly, only the server is authenticated.
X.509 certificates are commonly used in this authentication step,
though other mechanisms, such as raw public keys RFC7250, exist.  The
client is not authenticated unless explicitly requested by the server
with a CertificateRequest handshake message.  Assuming strong
cryptography, an infrastructure for trust establishment, correctly-
functioning endpoints, and communication patterns free from side
channels, server authentication is sufficient to establish a channel
resistant to eavesdroppers.
Paragraph (version B):
The handshake protocol serves several purposes, including: peer
authentication, protocol option (key exchange algorithm and
ciphersuite) negotiation, and key derivation.  Peer authentication
may be mutual; however, commonly, only the server is authenticated.
X.509 certificates are commonly used in this authentication step,
though other mechanisms, such as raw public keys RFC7250, exist.  The
client is not authenticated unless explicitly requested by the
server.
Paragraph (version A):
The handshake protocol is also extensible.  It allows for a variety
of extensions to be included by either the client or server.  These
extensions are used to specify client preferences, e.g., the
application-layer protocol to be driven with the TLS connection
RFC7301, or signals to the server to aid operation, e.g., Server Name
Indication (SNI) RFC6066.  Various extensions also exist to tune the
parameters of the record protocol, e.g., the maximum fragment length
RFC6066.
Paragraph (version B):
The handshake protocol is also extensible.  It allows for a variety
of extensions to be included by either the client or server.  These
extensions are used to specify client preferences, e.g., the
application-layer protocol to be driven with the TLS connection
RFC7301, or signals to the server to aid operation, e.g., Server Name
Indication (SNI) RFC6066.  Various extensions also exist to tune the
parameters of the record protocol, e.g., the maximum fragment length
RFC6066 and record size limit I-D.ietf-tls-record-limit.
Paragraph (version A):
Optional length-hiding padding (starting with TLS 1.3).
Paragraph (version B):
Configuration extensions.
Paragraph (version B):
Optional record-layer padding (starting with TLS 1.3).
Paragraph (version A):
Since DTLS runs over an unreliable, unordered datagram transport,
it does not require any reliability features.
Paragraph (version A):
The QUIC transport layer support multiple streams over a single
connection.  The first stream is reserved specifically for a TLS
connection.  The TLS handshake, along with further records, are sent
over this stream.  This TLS connection follows the TLS standards and
inherits the security properties of TLS.  The handshake generates
keys, which are then exported to the rest of the QUIC connection, and
are used to protect the rest of the streams.
Paragraph (version A):
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):
The QUIC transport layer support multiple streams over a single
connection.  QUIC implements a record protocol for TLS handshake
messages to establish a connection.  These messages are sent in
special INITIAL and CRYPTO frames I-D.ietf-quic-transport, types of
which are encrypted using different keys.  INITIAL frames are
encrypted using "fixed" keys derived from the QUIC version and public
packet information (Connection ID).  CRYPTO frames are encrypted
using TLS handshake secrets.  Once TLS completes, QUIC uses the
resultant traffic secrets to for the QUIC connection to protect the
rest of the streams.  QUIC supports 0-RTT (early) data using
previously negotiated connection secrets.  Early data is sent in
0-RTT packets, which may be included in the same datagram as the
Initial and Handshake packets.
Paragraph (version A):
QUIC transport relies on TLS 1.3 for peer authentication and
initial key derivation.
Paragraph (version A):
TLS within QUIC relies on QUIC for reliable handshake record
transmission and receipt.
Paragraph (version B):
QUIC transport relies on TLS 1.3 for key exchange, peer
authentication, and shared secret derivation.
Paragraph (version A):
IKEv2 RFC7296 and ESP RFC4303 together form the modern IPsec protocol
suite that encrypts and authenticates IP packets, either as for
creating tunnels (tunnel-mode) or for direct transport connections
(transport-mode).  This suite of protocols separates out the key
generation protocol (IKEv2) from the transport encryption protocol
(ESP).  Each protocol can be used independently, but this document
considers them together, since that is the most common pattern.
Paragraph (version B):
IKEv2 RFC7296 and ESP RFC4303 together form the modern IPsec protocol
suite that encrypts and authenticates IP packets, either for creating
tunnels (tunnel-mode) or for direct transport connections (transport-
mode).  This suite of protocols separates out the key generation
protocol (IKEv2) from the transport encryption protocol (ESP).  Each
protocol can be used independently, but this document considers them
together, since that is the most common pattern.
Paragraph (version A):
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):
TCP.
Paragraph (version B):
TCP Encryption Negotiation Option (ENO).
Paragraph (version B):
WireGuard is a layer 3 protocol designed to complement or replace
IPsec WireGuard for certain use cases.  It uses UDP to encapsulate IP
datagrams between peers.  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 A):
Connection mobility (tunnel-based).
Paragraph (version B):
Connection mobility (based on tunnel identifiers).
Paragraph (version A):
Unlike TCP, the server employs cookies to enable source validation.
After receiving the client's initial packet, encrypted under the
server's long-term public key, the server generates and returns a
stateless cookie that must be echoed back in the client's following
message.  This cookie is encrypted under the client's ephemeral
public key.  This stateless technique prevents attackers from
hijacking client initialization packets to obtain cookie values to
flood clients.  (A client would detect the duplicate cookies and
reject the flooded packets.)  Similarly, replaying the client's
second packet, carrying the cookie, will be detected by the server.
Paragraph (version B):
Servers use cookies for source validation.  After receiving a
client's initial packet, encrypted under the server's long-term
public key, a server generates and returns a stateless cookie that
must be echoed back in the client's following message.  This cookie
is encrypted under the client's ephemeral public key.  This stateless
technique prevents attackers from hijacking client initialization
packets to obtain cookie values to flood clients.  (A client would
detect the duplicate cookies and reject the flooded packets.)
Similarly, replaying the client's second packet, carrying the cookie,
will be detected by the server.
Paragraph (version A):
1-RTT session bootstrapping.
Paragraph (version A):
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 A):
Segment or datagram encryption and authentication: Transit data
must be protected with an authenticated encryption algorithm.
Paragraph (version A):
Forward-secure key establishment: Negotiated keying material must
come from an authenticated, forward-secure key exchange protocol.
Paragraph (version A):
Public-key (raw or certificate) based authentication:
Authentication based on public key signatures is commonplace for
many transport security protocols.
Paragraph (version A):
Responder authentication: The endpoint (receiver) of a new
connection must be authenticated before any data is sent to said
party.
Paragraph (version A):
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 A):
Cryptographic algorithm negotiation (AN): Transport security
protocols should permit applications to configure supported or
enabled cryptographic algorithms.
Paragraph (version A):
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 (MA): Transport security protocols should
allow each endpoint to authenticate the other if required by the
application.
Paragraph (version A):
DoS mitigation (DM): Transport security protocols may need to
support volumetric DoS prevention via, e.g., cookies or initiator-
side puzzles.
Paragraph (version A):
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 A):
Source validation (SV): 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 (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 A):
Configuration extensions (CX): The protocol negotiation should be
extensible with addition of new configuration options.
Paragraph (version A):
Session caching and management (SC): Sessions should be cacheable
to enable reuse and amortize the cost of performing session
establishment handshakes.
Paragraph (version A):
Length-hiding padding (LHP): Applications may wish to defer
traffic padding to the security protocol to deter traffic analysis
attacks.
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.  They were selected on the basis that they are either
(a) required for any secure transport protocol or (b) nearly
ubiquitous amongst common secure transport protocols.  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 or datagram encryption and authentication: Protect transit
data with an authenticated encryption algorithm.
Paragraph (version B):
Forward-secure key establishment.
Paragraph (version B):
Public-key (raw or certificate) based authentication.
Paragraph (version B):
Unilateral responder authentication.
Paragraph (version B):
Pre-shared key support.
Paragraph (version B):
Application dependency: Anti-replay protections or hints of
data idempotency.
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.
Paragraph (version A):
Pre-Shared Key Import
Either the handshake protocol or the application directly can
supply pre-shared keys for the record protocol use for encryption/
decryption and authentication.  If the application can supply keys
directly, this is considered explicit import; if the handshake
protocol traditionally provides the keys directly, it is
considered direct import; if the keys can only be shared by the
handshake, they are considered non-importable.
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,
following conventions in I-D.ietf-taps-interface and I-D.ietf-taps-
arch.
Paragraph (version B):
Pre-Shared Key Import Either the handshake protocol or the
application directly can supply pre-shared keys for the record
protocol use for encryption/decryption and authentication.  If the
application can supply keys directly, this is considered explicit
import; if the handshake protocol traditionally provides the keys
directly, it is considered direct import; if the keys can only be
shared by the handshake, they are considered non-importable.