jiebi/CodeConvo huggingface dataset:
Change:
added terms from the vulnerability assessment scenario
Hi Danny, I still want to highlight one last time that we will have 3-4 different kinds of capability in the terminology in -10 if we pull this in. I understand this to be a basis of discussion still :) I am not sure if that is the case, though! Let me elaborate. We have in SACM used by the architecture: Capability: : The extent of an SACM component's ability enabled by the functions it is composed of. Capabilities are propagated by a SACM component and can be discovered by or negotiated with other SACM components. For example, the capability of a SACM Provider may be to provide endpoint management data, or only a subset of that data. We have in i2nsf, referenced in the sacm terminology: We have the VA Terms: +Endpoint management capability: +: An enterprise IT capability managing endpoint identity, endpoint information, and associated metadata on an ongoing basis. +Vulnerability management capability: +: An enterprise IT capability managing endpoint vulnerabilities and associated metadata on an ongoing basis by ingesting vulnerability description information and vulnerability detection data, and performing a vulnerability assessment. "Managed" in i2nsf means "has interface on the management-plane". I still do not understand what managing actually means in the context of an VA capability :) What potential functions are propagated as capabilities? What is their input? What is their output? Is it possible that the two VA capabilities are actually tasks? Viele Grüße, Henk TL;DR I will pull these terms in, but we will have to align these terms better. On 07/08/2016 01:56 PM, Danny Haynes wrote:

Discussion:
results.  Types, classes or the characteristics of an individual target endpoint are defined via endpoint profiles. <ins> An enterprise IT capability managing endpoint identity, endpoint information, and associated metadata on an ongoing basis. </ins> The task by which endpoint attributes are evaluated. The resulting value from having evaluated a set of posture

general, it cannot be simply assumed that the source of time a target endpoint uses is synchronized or trustworthy. <ins> Information pertaining to the existence of a flaw or flaws in software, hardware, and/or firmware, which could potentially have an adverse impact on enterprise IT functionality and/or security. Vulnerability description information should contain enough information to support vulnerability detection. A type of guidance extracted from vulnerability description information that describes the specific mechanisms of vulnerability detection that is used by an enterprise's vulnerability management capability to determine if a vulnerability is present on an endpoint. An enterprise IT capability managing endpoint vulnerabilities and associated metadata on an ongoing basis by ingesting vulnerability description information and vulnerability detection data, and performing a vulnerability assessment. The process of determining whether a set of endpoints is vulnerable according to the information contained in the vulnerability description information. </ins> 3. This memo includes no request to IANA.
Change:
Replace "DST" and "daylight savings time" with "daylight saving time" Replace "timezone" with "time zone" Properly capitalize "Unicode Consortium" Improve phrasing
If you don't have time to work further on this very useful PR, I could merge it and fix these three nits.
Please don't add material to this one. We went the opposite direction in the last interim, so I'm about to remove some of this text.
OK, I pushed a commit just before your last comment but will withhold any further changes.
Sorry for the unsmooth handling of this PR. I now cherry-picked from this PR. Can I ask you to rebase to main and see what remaining parts you want to pursue?
My last message was too close to the holidays. Do you want to rebase this PR? Or do you think it is essentially covered by my cherry-picking?
Thanks for the ping, NAME Almost everything was covered by the cherry-picking, but a few things remain. I have rebased the PR to include only those.

Discussion:
information to the timestamp. This document does not address extensions to the format where the <del> semantic result no longer is a fixed timestamp that is referenced to </del> <ins> semantic result is no longer a fixed timestamp that is referenced to </ins> a (past or future) UTC time.  For instance, it does not address: Future time given as a local time in some specified time zone,

Actual keys are registered by supplying the information in record: <del> 'Identifier' contains the key name. </del> <ins> 'Identifier' contains the key name.  A key name ending with a hyphen/ minus sign ""-"" is a namespace that covers all timestamp tag keys beginning with that prefix. </ins> 'Description' contains the name and description of the namespace.

4. <del> Define a registry that can contain both namespaces and keys. Namespaces can be recognized by ending with a hyphen/minus.  Actual keys do not.  See registered for the detailed information (to be edited). </del> <ins> IANA is requested to establish a registry called "Timestamp Suffix Tag Keys".  Each entry in the registry shall consist of the information described in registered.  Initial contents of the registry are specified in namespaced. </ins> The policy is "RFC required", "Specification Required", ??? RFC8126.
Change:
Minor fix of 3.3, now that we have 3.4. There is still a certain amount of redundancy between the two sections, which might be smoothened out by further editorial action. For now, let's get agreement on Section 2 before further tinkering.

Discussion:
IXDTF strings such as: <del> are internally inconsistent, as Europe/Paris does not use a time zone offset of "+01:00" in July 2022.  The time zone hint given in the suffix tag is elective, though, so the recipient is not required to act on the inconsistency; it can treat the Internet Date/Time Format string as if it were: </del> <ins> are internally inconsistent (see inconsistent), as Europe/Paris did not use a time zone offset of "+01:00" in July 2022.  The time zone hint given in the suffix tag is elective, though, so the recipient is not required to act on the inconsistency; it can treat the Internet Date/Time Format string as if it were: </ins> Similar with:
Change:
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 isn'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!

Discussion:
set of protocols and algorithms that are requested by applications or by a system policy. <ins> 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. 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. </ins> 2. The following terms are used throughout this document to describe the
Change:
Read through the Opsdir review we recently got. Not sure we want to add anything to that BGP questions, but there was also a minor editorial nit, which this PR fixes. Now the order of these protocols is the same as in the table.

Discussion:
QUIC <del> ESP IPsec OpenVPN </del> tcpcrypt MinimaLT <ins> IPsec ESP </ins> WireGuard <ins> OpenVPN </ins> 5.2. Identity Validation (IV): During a handshake, the security
Change:
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 added 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, NAME good with these changes.

Discussion:
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 <del> dependency is unavailable.  In this context, an application dependency is one required from an application in order to function. </del> <ins> dependency is unavailable. 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. </ins> 5.1.

Record or datagram confidentiality and integrity. <ins> Application dependency: None. </ins> Forward-secure key establishment. <ins> Application dependency: None. </ins> Public-key certificate based authentication. <ins> 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. </ins> Unilateral responder authentication. <del> 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. </del> <ins> Application dependency: Application providing trust information, see above. </ins> 5.2.
Change:
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 .

Discussion:
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 <del> to avoid DoS attacks.  Protocols: QUIC + TLS, DTLS, WireGuard </del> <ins> to avoid DoS attacks. </ins> DTLS QUIC <ins> IKEv2 </ins> WireGuard 5.3.
Change:
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!

Discussion:
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> <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, <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> <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.
Change:
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.

Discussion:
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> <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 <del> Packet Security Protocols: OpenVPN </del> 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
Change:
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.

Discussion:
CurveCP <del> ESP </del> <ins> IKEv2 </ins> WireGuard
Change:
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

Discussion:
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. <del> Explicit import: QUIC, ESP </del> <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, <del> IKEv2 </del> <ins> IKEv2, OpenVPN </ins> Direct export: TLS, DTLS, MinimalT
Change:
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.

Discussion:
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> <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
Change:
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.

Discussion:
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> <ins> application directly can supply pre-shared keys for use in encrypting (and authenticating) communication with a peer. </ins> <del> Explicit import: QUIC, ESP, OpenVPN </del> <ins> TLS DTLS QUIC ESP IKEv2 OpenVPN tcpcrypt </ins> <del> Direct import: TLS, DTLS, tcpcrypt, MinimalT, WireGuard </del> <ins> MinimalT </ins> <del> Non-importable: CurveCP </del> <ins> WireGuard </ins> 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> <ins> Shared Secret Export: The handshake protocol may provide an interface for producing shared secrets for application-specific uses. TLS DTLS tcpcrypt </ins> <del> Explicit export: TLS (for QUIC), DTLS (for SRTP), tcpcrypt, IKEv2, OpenVPN </del> <ins> IKEv2 </ins> <del> Direct export: TLS, DTLS, MinimalT </del> <ins> OpenVPN </ins> <del> Non-exportable: CurveCP </del> <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