jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-taps-transport-security

Commentary: Do you think this non - goal is helpful for people who are confused that " important " security protocols are omitted from this survey ? ( e.g. ) 
 This document is a survey of network security protocols and their interaction with transport and application protocols . It is clearly written and easy to read . I have a minor comment on the contents of this draft . It is not abundantly clear what the criteria was for selecting the subset of security protocols included in this draft . Some notable omissions include SSH , L2TP , and GRE . These seem like interesting omissions given their popularity in a number of deployment scenarios . Not a showstopper in my opinion , but interesting to note . 
 Proposal : Add a paragraph to non - goals saying that we are not attempting to provide a comprehensive survey of all security protocols , or a survey of all " important " protocols that a TAPS implementation would have to support . Perhaps this also is n't entirely clear in the Introduction , which says our included protocols represent " a superset of features a Transport Services system may need to support " . By this , we mean that it may need to implement any protocol that provides these features , and/or it may need to expose an interface to configure these features . We do NOT mean that the Transport Services System has to implement these exact protocols , or that it should limit itself to these protocols . But people might be misunderstanding it this way . 
 I think this is a fine idea -- thanks for the PR !
Paragraph (version B):
The protocols surveyed in this document represent a superset of
functionality and features a Transport Services system may need to
support.  It does not list all transport protocols that a Transport
Services system may need to implement, nor does it mandate that a
Transport Service system implement any particular protocol.
Paragraph (version B):
A Transport Services system may implement any secure transport
protocol that provides the described features.  In doing so, it may
need to expose an interface to the application to configure these
features.
Draft: draft-ietf-taps-transport-security

Commentary: This revises the description of SRTP and the relation between SRTP , DTLS , and  . 
 If we keep that headline , we need one for DTLS - SRTP too . Yes , that was intentional .  is just the record protocol . The key management is usually done by DTLS or occasionally by  . 
 Comment from Ekr 's review of -10 : Pre - Connection Interfaces [ … ] Also , I 'm not sure you want to omit tcpcrypt here , in that it does have a way to do external authentication by exporting a session ID . Also  allows for some sort of fingerprint - based auth .  ( and I believe  ) both have session caches . 
  uses , compared by the users , as an external authentication mechanism ( similar process to the Safety Numbers in Signal , I believe ) .  does maintain a session cache . 
 In other words ,  supports interfaces to Authentication Delegation and Session Cache Management , and DTLS - SRTP does not ? 
 Thanks for the reply . I 'm okay with merging these changes as they are , or you can add that one reference for  to have both .
Paragraph (version A):
Secure RTP (SRTP) is a profile for RTP that provides confidentiality,
message authentication, and replay protection for RTP data packets
and RTP control protocol (RTCP) packets RFC3711.  SRTP can use
different handshake protocols, such as DTLS in DTLS-SRTP RFC5764 or
ZRTP RFC6189.
Paragraph (version A):
ZRTP RFC6189 is an alternative key agreement protocol for SRTP.  It
uses standard SRTP to protect RTP data packets and RTCP packets, but
provides alternative key agreement and identity management protocols.
Key agreement is performed using a Diffie-Hellman key exchange that
runs on the media path.  This generates a shared secret that is then
used to generate the master key and salt for SRTP.
Paragraph (version B):
Secure RTP (SRTP) is a profile for RTP that provides confidentiality,
message authentication, and replay protection for RTP data packets
and RTP control protocol (RTCP) packets RFC3711.  SRTP provides a
record layer only, and requires a separate handshake protocol to
provide key agreement and identity management.
Paragraph (version B):
The commonly used handshake protocol for SRTP is DTLS, in the form of
DTLS-SRTP RFC5764.  This is an extension to DTLS that negotiates the
use of SRTP as the record layer, and describes how to export keys for
use with SRTP.
Paragraph (version B):
ZRTP RFC6189 is an alternative key agreement and identity management
protocols for SRTP.  ZRTP Key agreement is performed using a Diffie-
Hellman key exchange that runs on the media path.  This generates a
shared secret that is then used to generate the master key and salt
for SRTP.
Draft: draft-ietf-taps-transport-security

Commentary: Oh , and just double - checking : For PSK Export , SRTP and QUIC are a " No " ? Because the old text said " TLS ( for QUIC ) , DTLS ( for SRTP ) " . 
 Yeah , I think that since QUIC and  themselves do n't export , but just use the export from inner protocols , this makes sense as is . 
 Comment from Ekr 's review of -10 : I 'm not following any of the text around import . This direct / explicit distinction seems arbitrary , and weird for QUIC , because QUIC does n't really have explicit import so much as a dependency on a handshake protocol that must be integrated . 
 can you help on this one ? 
 Ping 
 We can do this for the export side of things , too . 
 Fixed in . 
 Thanks , looks good ! Just suggesting one tweak in the wording for the import text .
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):
Pre-Shared Key Import: 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 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):
Shared Secret Export: The handshake protocol may provide an
interface for producing shared secrets for application-specific
uses.
Draft: draft-ietf-taps-transport-security

Commentary: Add half a sentence to Connection Termination to address , which complained that this part ignores layering . I guess IKEv2 is the only protocol there that is not at the same layer as TCP or above . So maybe for IKEv2 , the Connection Termination interface prevents a different attack ( at least I did n't find anything on data truncation for IKEv2 ) , but I think that 's okay . Data truncation is just an example and we do n't need to enumerate all possible attacks . 
 Looks good ! 
 Comment from Ekr 's review of -10 : S 5.3 . o Connection Termination : The security protocol may be instructed to tear down its connection and session information . This is needed by some protocols to prevent application data truncation attacks . This seems like kind of a confusing section , I think partly because it ignores layering . The way I think of this is that we have an existing family of insecure protocols that have their own termination mechanisms ( e.g. , TCP FIN / RST ) . A security protocol that is under such a protocol ( e.g. , IPsec ) does n't need a secure termination mechanism because ( a ) the existing termination mechanism become secure and ( b ) it can just stop transmitting . By contrast , a security protocol that is above ( TLS ) or at the level of such a protocol ( QUIC , tcpcrypt ) needs its own secure termination mechanism , lest it be at the mercy of the transport .
Paragraph (version A):
Connection Termination: The security protocol may be instructed to
tear down its connection and session information.  This is needed
by some protocols to prevent application data truncation attacks.
Paragraph (version B):
Connection Termination: 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.
Draft: draft-ietf-taps-transport-security

Commentary: Addresses 
 No objection , but I do n't know OpenVPN . 
 Comment from Ekr 's review of -10 : Packet Security Protocols : o OpenVPN Well , sort of . OpenVPN needs TCP for its key establishment phase but not its transport phase . That does n't seem like that interesting a point to make here , as if TCP was n't available , it could just cut over to DTLS . 
 Agreed : My notes on OpenVPN say that it can run completely over UDP , in which case it provides its own reliability layer for handshake and key exchange , and no reliability for data packets . I guess that means that OpenVPN does not have any transport dependencies , so deleting it from Section 4.1 is correct and I do n't see any other place in Section 4 for it . I 'd say stating it can run over either TCP or UDP is enough here , so this PR is sufficient .
Paragraph (version A):
OpenVPN OpenVPN is a commonly used protocol designed as an
alternative to IPsec.  A major goal of this protocol is to provide a
VPN that is simple to configure and works over a variety of
transports.  OpenVPN encapsulates either IP packets or Ethernet
frames within a secure tunnel and can run over UDP or TCP.  For key
establishment, OpenVPN can use TLS as a handshake protocol or pre-
shared keys.
Paragraph (version B):
OpenVPN OpenVPN is a commonly used protocol designed as an
alternative to IPsec.  A major goal of this protocol is to provide a
VPN that is simple to configure and works over a variety of
transports.  OpenVPN encapsulates either IP packets or Ethernet
frames within a secure tunnel and can run over either UDP or TCP.
For key establishment, OpenVPN can use TLS as a handshake protocol or
pre-shared keys.
Draft: draft-ietf-taps-transport-security

Commentary: Addresses 
 Comment from Ekr'r review of -10 : S 3.3.5 . CurveCP [ CurveCP ] is a UDP - based transport security protocol from    . Unlike other security protocols , it is based entirely upon highly efficient public key algorithms . This removes many pitfalls associated with nonce reuse and key synchronization . This text is going to be confusing to people . Not to say that CurveCP is bad , and the primitives it uses are fast , but they 're not any faster than those used by TLS , QUIC , or tcpcrypt . I think the consensus here is that it 's not currently practical to have a general purpose transport protocol that does n't do key establishment and then use symmetric keys . ( This is the same reason why we were n't able to use public key encryption for QUIC CID encryption ) . Reply from  : Good point . We could discuss the tradeoff between performance and security that DJB was trying to achieve , but that is probably out - of - scope for this document , so we should stick to a value - free description ( e.g. , " based entirely on public key algorithms " ) and let it go with that . 
 LGTM !
Paragraph (version A):
CurveCP CurveCP is a UDP-based transport security protocol from
Daniel J.  Bernstein.  Unlike other security protocols, it is based
entirely upon highly efficient public key algorithms.  This removes
many pitfalls associated with nonce reuse and key synchronization.
CurveCP provides its own reliability for application data as part of
its protocol.
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):
WireGuard is an IP-layer protocol designed as an alternative to 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 B):
WireGuard is an IP-layer protocol designed as an alternative to IPsec
WireGuard for certain use cases.  It uses UDP to encapsulate IP
datagrams between peers.  Unlike most transport security protocols,
which rely on Public Key Infrastructure (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.
Draft: draft-ietf-taps-transport-security

Commentary: Addresses 
 Comment from Ekr 's review of -10 : S 5.2 . IKE has source address validation , no ? 
 Right ! I 'll change that in my summary table in .
Paragraph (version B):
Source Address Validation: 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.
Draft: draft-ietf-taps-transport-security

Commentary: This makes the relationship between this document and minset explicit .
Paragraph (version A):
This document provides a survey of commonly used or notable network
security protocols, with a focus on how they interact and integrate
with applications and transport protocols.  Its goal is to supplement
efforts to define and catalog transport services by describing the
interfaces required to add security protocols.  This survey is not
limited to protocols developed within the scope or context of the
IETF, and those included represent a superset of features a Transport
Services system may need to support.
Paragraph (version B):
This document provides a survey of commonly used or notable network
security protocols, with a focus on how they interact and integrate
with applications and transport protocols.  Its goal is to supplement
efforts to define and catalog transport services by describing the
interfaces required to add security protocols.  This survey is not
limited to protocols developed within the scope or context of the
IETF, and those included represent a superset of features a Transport
Services system may need to support.  Moreover, this document defines
a minimal set of security features that a secure transport system
should provide.
Paragraph (version A):
security features shared by these protocols.  Finally, the document
distills the application and transport interfaces provided by the
transport security protocols.
Paragraph (version B):
security features shared by these protocols.  The document groups
these security features into a minimal set of features, which every
secure transport system should provide in addition to the transport
features described in I-D.ietf-taps-minset, and additional optional
features, which may not be available in every secure transport
system.  Finally, the document distills the application and transport
interfaces provided by the transport security protocols.
Draft: draft-ietf-taps-transport-security

Commentary: As promised at IETF 103 , here 's a suggested definition of application dependency , to make it clearer what I 'm talking about . I have also dependencies for the mandatory features , so that it 's clear for all features whether they have any application dependencies . In addition , I changed the heading of the section because the section does not actually talk about transport dependencies anymore . What do you think ? 
 Yep , I agree . This change looks good . Thank you , good with these changes .
Paragraph (version A):
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 or application
dependency is unavailable.  In this context, an application
dependency is one required from an application in order to function.
Paragraph (version B):
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 or application
dependency is unavailable.
Paragraph (version B):
In this context, an application dependency is an aspect of the
security feature which can be exposed to the application.  An
application dependency may be required for the security feature to
function, or it may provide additional information and control to the
application.  For example, an application may need to provide
information such as keying material or authentication credentials, or
it may want to restrict which cryptographic algorithms to allow for
negotiation.
Paragraph (version A):
Note that most systems provide defailt trust stores used to
authenticate peers based on certificates.  In such systems,
applications need not provide any trust information.  Applications
running on systems without such a feature must necessary depend on
applications for this information so as to authenticate peers.
Paragraph (version B):
Application dependency: Application providing trust
information.  Note that most systems provide default trust
stores used to authenticate peers based on certificates.  In
such systems, applications need not provide any trust
information.
Paragraph (version B):
Application dependency: Application providing trust
information, see above.
Draft: draft-ietf-taps-transport-security

Commentary: From   : = Section 3.2.1 : " Starting with DTLS 1.3 , a connection identifier extension [ ... ] " The CID extension is also available in 1.2 . ( In 1.3 , the CID can be updated mid - session using post - handshake messages , which is an option you do n't have in 1.2 , but for the rest they are the same . ) = Section 3.2.3 : " The DTLS record protocol explicitly encodes record lengths " In 1.3 , the " short header " ( DTLSShortCiphertext ) drops the explicit length .
Paragraph (version A):
Security Feature: a specific feature that a network security layer
provides to applications.  Examples include authentication,
encryption, key generation, session resumption, and privacy.  A
feature may be considered to be Mandatory or Optional to an
application's implementation.
Paragraph (version B):
Security Feature: a specific feature that a network security layer
provides to applications.  Examples include authentication,
encryption, key generation, session resumption, and privacy.
Features may be Mandatory or Optional for an application's
implementation.
Paragraph (version A):
DTLS relies on unique UDP 4-tuples to allow peers with multiple DTLS
connections between them to demultiplex connections, constraining
protocol design slightly more than UDP: application-layer
demultiplexing over the same 4-tuple is not possible without trial
decryption as all application-layer data is encrypted to a
connection-specific cryptographic context.  Starting with DTLS 1.3 I-
D.ietf-tls-dtls13, a connection identifier extension to permit
multiplexing of independent connections over the same 4-tuple is
available I-D.ietf-tls-dtls-connection-id.
Paragraph (version A):
The DTLS record protocol explicitly encodes record lengths, so
although it runs over a datagram transport, it does not rely on
the transport protocol's framing beyond requiring transport-level
reconstruction of datagrams fragmented over packets.
Draft: draft-ietf-taps-transport-security

Commentary: Sort the protocols we describe based on perceived importance , popularity , etc . Basically , put non - standard ones at the end , and all else towards the front . 
 Correct ! 
 I 'm assuming the content itself has n't changed , just moved around ? It 's not obvious from the diff , so  if not and I 'll un - approve .
Paragraph (version A):
gQUIC is a UDP-based multiplexed streaming protocol designed and
deployed by Google following experience from deploying SPDY, the
proprietary predecessor to HTTP/2.  gQUIC was originally known as
"QUIC": this document uses gQUIC to unambiguously distinguish it from
the standards-track IETF QUIC.  The proprietary technical forebear of
IETF QUIC, gQUIC was originally designed with tightly-integrated
security and application data transport protocols.
Paragraph (version B):
Google QUIC (gQUIC) is a UDP-based multiplexed streaming protocol
designed and deployed by Google following experience from deploying
SPDY, the proprietary predecessor to HTTP/2.  gQUIC was originally
known as "QUIC": this document uses gQUIC to unambiguously
distinguish it from the standards-track IETF QUIC.  The proprietary
technical forebear of IETF QUIC, gQUIC was originally designed with
tightly-integrated security and application data transport protocols.
Draft: draft-pauly-taps-transport-security

Commentary: Looks good to me !
Paragraph (version B):
Authentication-only protocols such as TCP-AO RFC5925 and IPsec AH
RFC4302 are excluded from this survey.  TCP-AO adds authenticity
protections to long-lived TCP connections, e.g., replay protection
with per-packet Message Authentication Codes.  (This protocol
obsoletes TCP MD5 "signature" options specified in RFC2385.)  One
prime use case of TCP-AO is for protecting BGP connections.
Similarly, AH adds per-datagram authenticity and adds similar replay
protection.  Despite these improvements, neither protocol see general
use and lack critical properties important for emergent transport
security protocols: confidentiality, privacy protections, and
agility.  Thus, we omit these and related protocols from our survey.