jiebi/CodeConvo huggingface dataset:
Code change:
I added a clarification that the nonce is random. IMO the question of who randomly generates the nonce goes with the question of how participants agree upon PDAParams, which is to say it's outside the protocol.
On the 2021/7/7 design call we decided that the ID should be derived deterministically from the serialized PAParam by, for example, hashing it. This solves a few problems simultaneously. This settles the question of whether there should be 1:1 correspondence between a task ID and the parameters used for that task. NAME brought up an interesting question, which is how to make the task ID unique when two different data collection tasks use the same parameters. Thoughts?
The consensus here is to do SHA-256 over the PDAParams structure and use that as the 32 byte PDATaskID. However, hashing a protocol message requires us to decide on a canonical representation of a protocol message, which I think forces us to decide how to encode messages on the wire. I filed for that question. I'll proceed with a PR for this issue on the assumption that we'll pick JSON.
As I mentioned there, the assumption would be that we're adopting TLS' binary encoding. If so, in TLS notation, you would write as the hash of , which itself is a serialized data structure.
All we require is that each PAParam have some unique value, right? A random nonce would probably suffice. r.e. the encoding, yes, let's stick with TLS's wire format as NAME suggests.
Yes, my thinking was that we would just stick 16 bytes of random data in (a UUID's worth). I agree that we should stick with TLS binary encoding.
Approved, with the following suggestion: Let's leave a [TODO: ...] comment under the definition of for clarifying how it should be chosen.

Related discussion:
text: "proto": The PDA protocol, e.g., Prio or Hits.  The rest of the structure contains the protocol specific parameters. <del> Each task has a unique _task id_ derived from the PDA parameters: </del> <ins> Each task has a unique _task ID_ derived from the PDA parameters: The task ID of a "PDAParam" `is derived using the following procedure: </ins> <del> The task id is derived using the following procedure.  [TODO: Specify derivation of the task ID.] </del> <ins> Where "SHA-256" is as specified in FIPS180-4. </ins> 3.1.2.
Code change:
I added a clarification that the nonce is random. IMO the question of who randomly generates the nonce goes with the question of how participants agree upon PDAParams, which is to say it's outside the protocol.
On the 2021/7/7 design call we decided that the ID should be derived deterministically from the serialized PAParam by, for example, hashing it. This solves a few problems simultaneously. This settles the question of whether there should be 1:1 correspondence between a task ID and the parameters used for that task. NAME brought up an interesting question, which is how to make the task ID unique when two different data collection tasks use the same parameters. Thoughts?
The consensus here is to do SHA-256 over the PDAParams structure and use that as the 32 byte PDATaskID. However, hashing a protocol message requires us to decide on a canonical representation of a protocol message, which I think forces us to decide how to encode messages on the wire. I filed for that question. I'll proceed with a PR for this issue on the assumption that we'll pick JSON.
As I mentioned there, the assumption would be that we're adopting TLS' binary encoding. If so, in TLS notation, you would write as the hash of , which itself is a serialized data structure.
All we require is that each PAParam have some unique value, right? A random nonce would probably suffice. r.e. the encoding, yes, let's stick with TLS's wire format as NAME suggests.
Yes, my thinking was that we would just stick 16 bytes of random data in (a UUID's worth). I agree that we should stick with TLS binary encoding.
Approved, with the following suggestion: Let's leave a [TODO: ...] comment under the definition of for clarifying how it should be chosen.

Related discussion:
text: The helper handles well-formed requests as follows.  (As usual, malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PDA parameters "PDAParam" for which <del> "PDAAggregateReq.task_id" is equal to the task id derived from </del> <ins> "PDAAggregateReq.task_id" is equal to the task ID derived from </ins> "PDAParam". The response consists of the helper's updated state and a sequence of
Code change:
I added a clarification that the nonce is random. IMO the question of who randomly generates the nonce goes with the question of how participants agree upon PDAParams, which is to say it's outside the protocol.
On the 2021/7/7 design call we decided that the ID should be derived deterministically from the serialized PAParam by, for example, hashing it. This solves a few problems simultaneously. This settles the question of whether there should be 1:1 correspondence between a task ID and the parameters used for that task. NAME brought up an interesting question, which is how to make the task ID unique when two different data collection tasks use the same parameters. Thoughts?
The consensus here is to do SHA-256 over the PDAParams structure and use that as the 32 byte PDATaskID. However, hashing a protocol message requires us to decide on a canonical representation of a protocol message, which I think forces us to decide how to encode messages on the wire. I filed for that question. I'll proceed with a PR for this issue on the assumption that we'll pick JSON.
As I mentioned there, the assumption would be that we're adopting TLS' binary encoding. If so, in TLS notation, you would write as the hash of , which itself is a serialized data structure.
All we require is that each PAParam have some unique value, right? A random nonce would probably suffice. r.e. the encoding, yes, let's stick with TLS's wire format as NAME suggests.
Yes, my thinking was that we would just stick 16 bytes of random data in (a UUID's worth). I agree that we should stick with TLS binary encoding.
Approved, with the following suggestion: Let's leave a [TODO: ...] comment under the definition of for clarifying how it should be chosen.

Related discussion:
text: Each POST request to an aggregator contains a "PDATaskID".  If the aggregator does not recognize the task, i.e., it can't find a <del> "PDAParam" for which the derived task id matches the "PDATaskID", </del> <ins> "PDAParam" for which the derived task ID matches the "PDATaskID", </ins> then it aborts and alerts the peer with "unrecognized task". 4.
Code change:
Addressed the following comments: [Per IETF 110] Add text on the order of native CDDL approach for handling version is used. If a future version of SWID is published which alters the semantics of exists fields, a future version of CoSWID SHOULD (MUST?) use a different tag to represent it. [daw: A new paragraph was added to section 2 detailing how index values are used to support revisions and extensions.] [Per IETF 110] see -16. Use ISO SWID reference for the IANA registry and if desired, used [SEMVER] as an informal reference in the text [daw: This has been done in section 4.1.] [daw: The FIXME markers have been replaced with actual text.] [daw: Section 7 now details the construction of a signed CoSWID. A SHOULD sign requirement was also added to section 7.] [Per IETF 110] We discussed adding language on the order of "This document specifies a data format and an associated integrity mechanism agnostic of a deployment. Application which choose to use CoSWID will need to specify explicit guidance which security properties are needed and under which circumstances." > ** [-15] Section 6. Per "When an authoritative tag is signed, the software [daw: Authenticating the signer is the software provider will require a match between a CoSWID entity and the signer. We are working out a means to do this.] 2 [daw: Not sure which tags this applies to? Signing? All of section 2?] [daw: done.] [daw: This confusing text has been removed.] [daw: done.] [daw: We added a note about this.] [daw: Done.] [daw: Added signature validation as a way.] Regards, Roman

Related discussion:
text: stored or transported, as compared to the less efficient text-based form of the original vocabulary. <ins> Through use of CDDL-based integer labels, CoSWID allows for future expansion in subsequent revisions of this specification and through extensions (see model-extension).  New constructs can be associated with a new integer index.  A deprecated construct can be replaced by a new construct with a new integer index.  An implementation can use these integer indexes to identify the construct to parse.  The CoSWID Items registry, defined in iana-coswid-items, is used to ensure that new constructs are assigned a unique index value on a first-come, first-served basis.  This approach avoids the need to have an explicit CoSWID version. </ins> The root of the CDDL specification provided by this document is the rule "coswid" (as defined in tagged):
Code change:
Addressed the following comments: [Per IETF 110] Add text on the order of native CDDL approach for handling version is used. If a future version of SWID is published which alters the semantics of exists fields, a future version of CoSWID SHOULD (MUST?) use a different tag to represent it. [daw: A new paragraph was added to section 2 detailing how index values are used to support revisions and extensions.] [Per IETF 110] see -16. Use ISO SWID reference for the IANA registry and if desired, used [SEMVER] as an informal reference in the text [daw: This has been done in section 4.1.] [daw: The FIXME markers have been replaced with actual text.] [daw: Section 7 now details the construction of a signed CoSWID. A SHOULD sign requirement was also added to section 7.] [Per IETF 110] We discussed adding language on the order of "This document specifies a data format and an associated integrity mechanism agnostic of a deployment. Application which choose to use CoSWID will need to specify explicit guidance which security properties are needed and under which circumstances." > ** [-15] Section 6. Per "When an authoritative tag is signed, the software [daw: Authenticating the signer is the software provider will require a match between a CoSWID entity and the signer. We are working out a means to do this.] 2 [daw: Not sure which tags this applies to? Signing? All of section 2?] [daw: done.] [daw: This confusing text has been removed.] [daw: done.] [daw: We added a note about this.] [daw: Done.] [daw: Added signature validation as a way.] Regards, Roman

Related discussion:
text: integrity measurements for files.  The ISO-19770-2:2015 XML schema uses XML DSIG to support cryptographic signatures. <del> Signing CoSWID tags follows the procedues defined in CBOR Object Signing and Encryption RFC8152.  A CoSWID tg MUST be wrapped in a </del> <ins> Signing CoSWID tags follows the procedures defined in CBOR Object Signing and Encryption RFC8152.  A CoSWID tag MUST be wrapped in a </ins> COSE Single Signer Data Object (COSE_Sign1) that contains a single signature and MUST be signed by the tag creator.  The following CDDL specification defines a restrictive subset of COSE header parameters
Code change:
Addressed the following comments: [Per IETF 110] Add text on the order of native CDDL approach for handling version is used. If a future version of SWID is published which alters the semantics of exists fields, a future version of CoSWID SHOULD (MUST?) use a different tag to represent it. [daw: A new paragraph was added to section 2 detailing how index values are used to support revisions and extensions.] [Per IETF 110] see -16. Use ISO SWID reference for the IANA registry and if desired, used [SEMVER] as an informal reference in the text [daw: This has been done in section 4.1.] [daw: The FIXME markers have been replaced with actual text.] [daw: Section 7 now details the construction of a signed CoSWID. A SHOULD sign requirement was also added to section 7.] [Per IETF 110] We discussed adding language on the order of "This document specifies a data format and an associated integrity mechanism agnostic of a deployment. Application which choose to use CoSWID will need to specify explicit guidance which security properties are needed and under which circumstances." > ** [-15] Section 6. Per "When an authoritative tag is signed, the software [daw: Authenticating the signer is the software provider will require a match between a CoSWID entity and the signer. We are working out a means to do this.] 2 [daw: Not sure which tags this applies to? Signing? All of section 2?] [daw: done.] [daw: This confusing text has been removed.] [daw: done.] [daw: We added a note about this.] [daw: Done.] [daw: Added signature validation as a way.] Regards, Roman

Related discussion:
text: provide a signature on a signature allowing for a proof that a signature existed at a given time (i.e., a timestamp). <ins> A CoSWID SHOULD be signed, using the above mechanism, to protect the integrity of the CoSWID tag.  See the security considerations (in sec-sec) for more information on why a signed CoSWID is valuable in most cases. </ins> 8. This specification allows for tagged and untagged CBOR data items
Code change:
Addressed the following comments: [Per IETF 110] Add text on the order of native CDDL approach for handling version is used. If a future version of SWID is published which alters the semantics of exists fields, a future version of CoSWID SHOULD (MUST?) use a different tag to represent it. [daw: A new paragraph was added to section 2 detailing how index values are used to support revisions and extensions.] [Per IETF 110] see -16. Use ISO SWID reference for the IANA registry and if desired, used [SEMVER] as an informal reference in the text [daw: This has been done in section 4.1.] [daw: The FIXME markers have been replaced with actual text.] [daw: Section 7 now details the construction of a signed CoSWID. A SHOULD sign requirement was also added to section 7.] [Per IETF 110] We discussed adding language on the order of "This document specifies a data format and an associated integrity mechanism agnostic of a deployment. Application which choose to use CoSWID will need to specify explicit guidance which security properties are needed and under which circumstances." > ** [-15] Section 6. Per "When an authoritative tag is signed, the software [daw: Authenticating the signer is the software provider will require a match between a CoSWID entity and the signer. We are working out a means to do this.] 2 [daw: Not sure which tags this applies to? Signing? All of section 2?] [daw: done.] [daw: This confusing text has been removed.] [daw: done.] [daw: We added a note about this.] [daw: Done.] [daw: Added signature validation as a way.] Regards, Roman

Related discussion:
text: do this, CoSWID tags can be created by any party and the CoSWID tags collected from an endpoint could contain a mixture of vendor and non- vendor created tags.  For this reason, a CoSWID tag might contain <del> potentially malicious content.  Input sanitization and loop detection are two ways that implementations can address this concern. </del> <ins> potentially malicious content.  Input sanitization, loop detection, and signature verification are ways that implementations can address this concern. </ins> 10.
Code change:
Addressed the following comments: [Per IETF 110] Add text on the order of native CDDL approach for handling version is used. If a future version of SWID is published which alters the semantics of exists fields, a future version of CoSWID SHOULD (MUST?) use a different tag to represent it. [daw: A new paragraph was added to section 2 detailing how index values are used to support revisions and extensions.] [Per IETF 110] see -16. Use ISO SWID reference for the IANA registry and if desired, used [SEMVER] as an informal reference in the text [daw: This has been done in section 4.1.] [daw: The FIXME markers have been replaced with actual text.] [daw: Section 7 now details the construction of a signed CoSWID. A SHOULD sign requirement was also added to section 7.] [Per IETF 110] We discussed adding language on the order of "This document specifies a data format and an associated integrity mechanism agnostic of a deployment. Application which choose to use CoSWID will need to specify explicit guidance which security properties are needed and under which circumstances." > ** [-15] Section 6. Per "When an authoritative tag is signed, the software [daw: Authenticating the signer is the software provider will require a match between a CoSWID entity and the signer. We are working out a means to do this.] 2 [daw: Not sure which tags this applies to? Signing? All of section 2?] [daw: done.] [daw: This confusing text has been removed.] [daw: done.] [daw: We added a note about this.] [daw: Done.] [daw: Added signature validation as a way.] Regards, Roman

Related discussion:
text: Aligned excerpt examples in I-D text with full CDDL <del> Fixed titels where title was referring to group instead of map </del> <ins> Fixed titles where title was referring to group instead of map </ins> <del> Added missig date in SEMVER </del> <ins> Added missing date in SEMVER </ins> Fixed root cardinality for file and directory, etc.
Code change:
Completes
We collapsed IKEv2 and ESP into IPsec. Should we remove ESP from feature lists, e.g., the list of protocols that support PSK import?
Agreed, we should make sure this is consistent. One of our features, Key Expiration, currently only mentions ESP though. Is this actually an IPsec feature now, do we remove the feature, or is there another solution?

Related discussion:
text: This interaction is often limited to signaling between the record layer and the handshake layer. <del> ESP </del> <ins> IPsec </ins> Mobility Events (ME): The record protocol can be signaled that it is being migrated to another transport or interface due to
Code change:
…/security and security/transport dependencies.
NAME can you please take a look before Wednesday?
Yep, I will review Monday morning.
I think this is fine. We can do further tweaks in subsequent PRs.

Related discussion:
text: 4. There exists a common set of features shared across the transport <del> protocols surveyed in this document.  The mandatory features should be provided by any transport security protocol, while the optional features are extensions that a subset of the protocols provide.  For clarity, we also distinguish between handshake and record features. </del> <ins> 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. </ins> 4.1. <del> 4.1.1. </del> <ins> Segment encryption and authentication: Transit data must be protected with an authenticated encryption algorithm. </ins> <del> Forward-secure segment encryption and authentication: Transit data must be protected with an authenticated encryption algorithm. </del> <ins> Forward-secure key establishment: Negotiated keying material must come from an authenticated, forward-secure key exchange protocol. </ins> Private key interface or injection: Authentication based on public key signatures is commonplace for many transport security
Code change:
…/security and security/transport dependencies.
NAME can you please take a look before Wednesday?
Yep, I will review Monday morning.
I think this is fine. We can do further tweaks in subsequent PRs.

Related discussion:
text: connection must be authenticated before any data is sent to said party. <del> Source validation: Source validation must be provided to mitigate server-targeted DoS attacks.  This can be done with puzzles or cookies. 4.1.2. Pre-shared key support: A record protocol must be able to use a pre-shared key established out-of-band to encrypt individual messages, packets, or datagrams. </del> <ins> 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. </ins> 4.2. <del> 4.2.1. </del> Mutual authentication: Transport security protocols must allow each endpoint to authenticate the other if required by the application. <ins> Transport dependency: None. Application dependency: Mutual authentication required for application support. Connection mobility: Sessions should not be bound to a network connection (or 5-tuple).  This allows cryptographic key material and other state information to be reused in the event of a connection change.  Examples of this include a NAT rebinding that occurs without a client's knowledge. Transport dependency: Connections are unreliable or can change due to unpredictable network events, e.g., NAT re-bindings. Application dependency: None. Source validation: Source validation must be provided to mitigate server-targeted DoS attacks.  This can be done with puzzles or cookies. Transport dependency: Packets may arrive as datagrams instead of streams from unauthenticated sources. Application dependency: None. </ins> Application-layer feature negotiation: The type of application using a transport security protocol often requires features configured at the connection establishment layer, e.g., ALPN
Code change:
…/security and security/transport dependencies.
NAME can you please take a look before Wednesday?
Yep, I will review Monday morning.
I think this is fine. We can do further tweaks in subsequent PRs.

Related discussion:
text: mechanism to allow for such application-specific features and options to be configured or otherwise negotiated. <ins> Transport dependency: None. Application dependency: Specification of application-layer features or functionality. </ins> Configuration extensions: The protocol negotiation should be extensible with addition of new configuration options. <ins> Transport dependency: None. Application dependency: Specification of application-specific extensions. </ins> Session caching and management: Sessions should be cacheable to enable reuse and amortize the cost of performing session establishment handshakes. <del> 4.2.2. </del> <ins> Transport dependency: None. </ins> <del> Connection mobility: Sessions should not be bound to a network connection (or 5-tuple).  This allows cryptographic key material and other state information to be reused in the event of a connection change.  Examples of this include a NAT rebinding that occurs without a client's knowledge. </del> <ins> Application dependency: None. </ins> 5. This section describes the interface surface exposed by the security <del> protocols described above, with each interface.  Note that not all protocols support each interface. </del> <ins> protocols described above.  Note that not all protocols support each interface.  We partition these interfaces into pre-connection (configuration), connection, and post-connection interfaces. </ins> 5.1.
Code change:
…/security and security/transport dependencies.
NAME can you please take a look before Wednesday?
Yep, I will review Monday morning.
I think this is fine. We can do further tweaks in subsequent PRs.

Related discussion:
text: key exchange, signatures, and ciphersuites. Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2, SRTP <del> Session Cache The application provides the ability to save and retrieve session state (such as tickets, keying material, and server parameters) that may be used to resume the security session. </del> <ins> Session Cache Management The application provides the ability to save and retrieve session state (such as tickets, keying material, and server parameters) that may be used to resume the security session. </ins> Protocols: TLS, DTLS, QUIC + TLS, MinimalT Authentication Delegation