jiebi/TextFlow huggingface dataset:
Original text:
3.3.5. CurveCP CurveCP is a UDP-based transport security protocol from <del> 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. </del>  3.4. 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, <del> 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. </del>  3.4.3.

Reviewer comments:
Addresses
Comment from Ekr'r review of -10: S 3.3.5. 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. 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 doesn't do key establishment and then use symmetric keys. (This is the same reason why we weren't able to use public key encryption for QUIC CID encryption). Reply from Kyle: 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!

Revised text:
3.3.5. CurveCP CurveCP is a UDP-based transport security protocol from  <ins> 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. </ins> 3.4. 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,  <ins> 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. </ins> 3.4.3.
Original text:
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 <del> 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. </del>  4. tcpcrypt <del> Packet Security Protocols: OpenVPN </del> 4.2. The following protocols all depend on the transport protocol to WireGuard  4.2.1. Of the protocols listed above that depend on the transport for

Reviewer comments:
Addresses
No objection, but I don'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 doesn't seem like that interesting a point to make here, as if TCP wasn'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 don'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.

Revised text:
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  <ins> 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. </ins> 4. tcpcrypt  4.2. The following protocols all depend on the transport protocol to WireGuard <ins> OpenVPN </ins> 4.2.1. Of the protocols listed above that depend on the transport for
Original text:
CurveCP <del> ESP </del>  WireGuard

Reviewer comments:
Address . IKE has mobility via MOBIKE (which makes ESP move, but it's more a property of IKE)
Yes, my impression was that we would keep the lists as well as the table?
Comment from Ekr's review of -10: o 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). How does this work in ESP, actually? DTLS sort of has this, in that it has a CID, but vague migration rules.
It may be better to mark this as IKEv2/ESP; it's MOBIKE that supports mobility.
This can be closed now, right?
Yup!
Interesting - so we do differentiate between ESP and IKEv2 here? (In Section 3.4.1 we say that "this document considers them together, since that is the most common pattern".) I'm okay with this and I've adjusted the summary table, which now has ESP and IKEv2 separately, in the other PR. As I'm not sure we want to put a reference into the summary table, I guess this means that we're keeping the protocol lists in addition to the summary table, which I'm also fine with.

Revised text:
CurveCP  <ins> IKEv2 </ins> WireGuard
Original text:
WireGuard  Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): The application can choose the algorithms that are supported for key exchange, signatures, and ciphersuites. IKEv2  Extensions (Application-Layer Protocol Negotiation): The application enables or configures extensions that are to be negotiated by the security protocol, such as ALPN RFC7301. directly, it is considered direct import; if the keys can only be shared by the handshake, they are considered non-importable. <del> Explicit import: QUIC, ESP </del>  Direct import: TLS, DTLS, tcpcrypt, MinimalT, WireGuard IKEv2  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. used directly in conjunction with the record protocol. Explicit export: TLS (for QUIC), DTLS (for SRTP), tcpcrypt, <del> IKEv2 </del>  Direct export: TLS, DTLS, MinimalT

Reviewer comments:
I'm pretty sure OpenVPN offers the following interfaces, because they are available as command line arguments in the openvpn tool: URL Identities and Private Keys: --cert option and --key Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): --auth alg Pre-Shared Key Import: I think explicit import, as the application can specify the PSK explicitly: --secret key Pre-Shared Key Export: I think Explicit export, because the OpenVPN documentation mentions RFC 5705, RFC 5705 mentions DTLS-SRTP, and DTLS-SRTP is classified as explicit export: keying-material-exporter label len Connection Termination: OpenVPN allows connection restart based on signals SIGHUP and SIGUSR1

Revised text:
WireGuard <ins> OpenVPN </ins> Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): The application can choose the algorithms that are supported for key exchange, signatures, and ciphersuites. IKEv2 <ins> OpenVPN </ins> Extensions (Application-Layer Protocol Negotiation): The application enables or configures extensions that are to be negotiated by the security protocol, such as ALPN RFC7301. directly, it is considered direct import; if the keys can only be shared by the handshake, they are considered non-importable.  <ins> Explicit import: QUIC, ESP, OpenVPN </ins> Direct import: TLS, DTLS, tcpcrypt, MinimalT, WireGuard IKEv2 <ins> OpenVPN </ins> 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. used directly in conjunction with the record protocol. Explicit export: TLS (for QUIC), DTLS (for SRTP), tcpcrypt,  <ins> IKEv2, OpenVPN </ins> Direct export: TLS, DTLS, MinimalT
Original text:
Connection Termination: The security protocol may be instructed to tear down its connection and session information.  This is needed <del> by some protocols to prevent application data truncation attacks. </del>  TLS

Reviewer comments:
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 didn't find anything on data truncation for IKEv2), but I think that's okay. Data truncation is just an example and we don'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) doesn'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.

Revised text:
Connection Termination: The security protocol may be instructed to tear down its connection and session information.  This is needed  <ins> 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. </ins> TLS
Original text:
tcpcrypt Pre-Shared Key Import: Either the handshake protocol or the <del> 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. </del>  <del> Explicit import: QUIC, ESP, OpenVPN </del>  <del> Direct import: TLS, DTLS, tcpcrypt, MinimalT, WireGuard </del>  <del> Non-importable: CurveCP </del>  5.2. IKEv2 <del> 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. </del>  <del> Explicit export: TLS (for QUIC), DTLS (for SRTP), tcpcrypt, IKEv2, OpenVPN </del>  <del> Direct export: TLS, DTLS, MinimalT </del>  <del> Non-exportable: CurveCP </del>  Key Expiration: The record protocol can signal that its keys are expiring due to reaching a time-based deadline, or a use-based

Reviewer comments:
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 SRTP themselves don'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 doesn't really have explicit import so much as a dependency on a handshake protocol that must be integrated.
NAME can you help on this one?
Ping NAME
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.

Revised text:
tcpcrypt Pre-Shared Key Import: Either the handshake protocol or the  <ins> application directly can supply pre-shared keys for use in encrypting (and authenticating) communication with a peer. </ins>  <ins> TLS DTLS QUIC ESP IKEv2 OpenVPN tcpcrypt </ins>  <ins> MinimalT </ins>  <ins> WireGuard </ins> 5.2. IKEv2  <ins> Shared Secret Export: The handshake protocol may provide an interface for producing shared secrets for application-specific uses. TLS DTLS tcpcrypt </ins>  <ins> IKEv2 </ins>  <ins> OpenVPN </ins>  <ins> MinimalT </ins> Key Expiration: The record protocol can signal that its keys are expiring due to reaching a time-based deadline, or a use-based
Original text:
identifying the interfaces between these protocols and both transport protocols and applications.  It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google <del> QUIC (gQUIC), tcpcrypt, Internet Key Exchange with Encapsulating Security Protocol (IKEv2 + ESP), SRTP (with DTLS), WireGuard, CurveCP, and MinimaLT.  For each protocol, this document provides a brief description.  Then, it describes the interfaces between these protocols and transports in transport-interface and the interfaces between these protocols and applications in application-interface. </del>  Selected protocols represent a superset of functionality and features a Transport Services system may need to support, both internally and Packet Security Protocols: <del> IKEv2 and ESP </del>  WireGuard Packet Security Protocols: <del> IKEv2 and ESP </del>  4.3. a separate module that will provide authentication, using EAP for example. <del> IKEv2 </del>  tcpcrypt ESP <del> IKEv2 </del>  OpenVPN QUIC <del> IKEv2 </del>  WireGuard MinimaLT <del> IKEv2 </del>  OpenVPN MinimaLT <del> IKEv2 </del>  Shared Secret Export (PSKE): The handshake protocol may provide an interface for producing shared secrets for application-specific tcpcrypt <del> IKEv2 </del>  OpenVPN CurveCP <del> IKEv2 </del>  WireGuard

Reviewer comments:
Address
URL Hi, I concur. However, I'd suggest changing the title of the section from "IKEv2 with ESP" to "IPsec". Regards, Valery.

Revised text:
identifying the interfaces between these protocols and both transport protocols and applications.  It examines Transport Layer Security (TLS), Datagram Transport Layer Security (DTLS), IETF QUIC, Google  <ins> QUIC (gQUIC), tcpcrypt, Internet Protocol Security (IPsec), SRTP (with DTLS), WireGuard, CurveCP, and MinimaLT.  For each protocol, this document provides a brief description.  Then, it describes the interfaces between these protocols and transports in transport- interface and the interfaces between these protocols and applications in application-interface. </ins> Selected protocols represent a superset of functionality and features a Transport Services system may need to support, both internally and Packet Security Protocols:  <ins> IPsec </ins> WireGuard Packet Security Protocols:  <ins> IPsec </ins> 4.3. a separate module that will provide authentication, using EAP for example.  <ins> IPsec </ins> tcpcrypt ESP  <ins> IPsec </ins> OpenVPN QUIC  <ins> IPsec </ins> WireGuard MinimaLT  <ins> IPsec </ins> OpenVPN MinimaLT  <ins> IPsec </ins> Shared Secret Export (PSKE): The handshake protocol may provide an interface for producing shared secrets for application-specific tcpcrypt  <ins> IPsec </ins> OpenVPN CurveCP  <ins> IPsec </ins> WireGuard
Original text:
cTLS plaintext records from encrypted records, TLS/DTLS records, and other protocols using the same 5-tuple. <del> The "profile_id" field allows the client and server to agree on which compression profile should be used for this session (see template- based-specialization).  This field MUST be set to zero if and only if no compression profile is used.  Non-zero values are negotiated out of band between the client and server, as part of the specification of the compression profile. </del> [[OPEN ISSUE: The profile_id is needed in the ClientHello to inform the server what compression profile to use.  For a ServerHello this field is not required.  Should we make this field optional?]] The cTLS ClientHello is defined as follows.  3.2. We redefine ServerHello in the following way.

Reviewer comments:
For cTLS/TCP, the CTLSCiphertext headers could easily all be the same size (1 byte type/flags, 2 byte length). For cTLS/UDP, the header sizes could be made more predictable. Suggestions: Always suppress sequence numbers and disallow connection IDs in cTLS/TCP, and after the first record in a datagram in cTLS/UDP. Move into the cTLS ClientHello struct.
Moving the profile_id into the ClientHello sounds good to me. Here is the PR: URL
Suppressing sequence numbers in cTLS/TCP sounds good to me as well. Here is the PR: URL
NAME closing as I think we addressed.

Revised text:
cTLS plaintext records from encrypted records, TLS/DTLS records, and other protocols using the same 5-tuple.  [[OPEN ISSUE: The profile_id is needed in the ClientHello to inform the server what compression profile to use.  For a ServerHello this field is not required.  Should we make this field optional?]] The cTLS ClientHello is defined as follows. <ins> The client uses the "profile_id" field to inform the server about the compression profile being used (see template-based-specialization). This field MUST be set to a zero-length value and only if no compression profile is used.  Non zero-length values are agreed out of band between the client and server, as part of the specification of the compression profile. </ins> 3.2. We redefine ServerHello in the following way.
Original text:
information may be inferred from the underlying layer. Normal DTLS does not provide a mechanism for suppressing the sequence <del> number field entirely.  In cases where a sequence number is not required (e.g., when a reliable transport is in use), a cTLS implementation may suppress it by setting the "suppressSequenceNumber" flag in the compression profile being used (see template-based-specialization).  When this flag is enabled, the S bit in the configuration octet MUST be cleared. </del>  2.3.

Reviewer comments:
I'm slightly concerned about the fact that we have two different wire behaviors with the same transcript, but because the integrity tag includes the header, I think it's OK. NAME would welcome your thoughts.
I think I have addressed this aspect already in PR URL
Correct. I thought Ben's suggestion to tie it to transport made more sense, but I'm not hard over on it.
Fine for me too.
S = "sequence number"

Revised text:
information may be inferred from the underlying layer. Normal DTLS does not provide a mechanism for suppressing the sequence  <ins> number field entirely.  When a reliable, ordered transport (e.g., TCP) is in use, the S bit in the configuration octet MUST be cleared and the sequence number MUST be omitted.  When an unreliable transport is in use, the S bit has its usual meaning and the sequence number MUST be included. </ins> 2.3.
Original text:
Value: a single "SignatureScheme" (RFC8446, Section 4.2.3) to use for authentication. <del> This is equivalent to a literal "signature_algorithms" extension consisting solely of this group. </del>  In JSON, the signature algorithm is listed by the code point name in RFC8446, Section 4.2.3. (e.g., ecdsa_secp256r1_sha256). If set to true, this element indicates that the client must authenticate with a certificate by sending Certificate and a <del> CertificateVerify message.  The server MUST omit the CertificateRequest message, as its contents are redundant. OPEN ISSUE: We don't actually say that you can omit empty messages, so we need to add that somewhere. </del>  In JSON, this value is represented as "true" or "false".

Reviewer comments:
Empty messages must now be included. If the body is known to be empty from the template, this costs one byte. This change also adjusts the explanation of and , and corrects the example.
NAME points out that EndOfEarlyData is an empty message that is semantically meaningful and cannot be predicted by the recipient.

Revised text:
Value: a single "SignatureScheme" (RFC8446, Section 4.2.3) to use for authentication.  <ins> This is equivalent to a placing a literal "signature_algorithms" extension consisting solely of this group in every extensions field where it is permitted to appear. </ins> In JSON, the signature algorithm is listed by the code point name in RFC8446, Section 4.2.3. (e.g., ecdsa_secp256r1_sha256). If set to true, this element indicates that the client must authenticate with a certificate by sending Certificate and a  <ins> CertificateVerify message.  If the CertificateRequest message does not add information not already conveyed in the template, the server SHOULD omit it. </ins> In JSON, this value is represented as "true" or "false".
Original text:
needed to know the minimum safe Finished size.  See RFC8446, Section E.1 for more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/ <del> TugB5ddJu3nYg7chcyeIyUqWSbA. </del>  In JSON, this length is represented as an integer. source of identity misbinding.  This is, however, entirely separable from the rest of the specification. <del> Transcript expansion also needs some analysis and we need to determine whether we need an extension to indicate that cTLS is in use and with which profile. </del>  6.

Reviewer comments:
LGTM.
Is it a design goal of this draft to support secure connection, even if the compression template is distributed over an untrusted channel? I believe it is a design goal, and I think it's probably achieved by the current draft (except for questions around the and keys), but it's not stated explicitly in the draft.

Revised text:
needed to know the minimum safe Finished size.  See RFC8446, Section E.1 for more on this, as well as https://mailarchive.ietf.org/arch/msg/tls/  <ins> TugB5ddJu3nYg7chcyeIyUqWSbA.  The minimum safe size may vary depending on whether the template was learned via a trusted channel. </ins> In JSON, this length is represented as an integer. source of identity misbinding.  This is, however, entirely separable from the rest of the specification.  <ins> Once the handshake has completed, this specification is intended to provide a fully secured connection even if the client initially learned the template through an untrusted channel.  However, this security relies on the use of a cryptographically strong Finished message.  If the Finished message has not yet been received, or the transcript hash has been truncated by use of a small "finished_size" template element value, an attacker could be using a forged template to impersonate the other party.  This should not impact any ordinary use of TLS, including Early Data (which is secured by the previously completed handshake). </ins> 6.