jiebi/CodeConvo huggingface dataset:
Code change:
malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PA parameters "PAParam" for which "PAAggregateReq.task_id" is equal to the task id derived from <del> "PAParam".  Next, it looks up the HPKE config and corresponding secret key associated with "PAAggregateReq.helper_hpke_config_id". If not found, then it aborts and alerts the leader with "unrecognized key config".  [NOTE: In this situation, the leader has no choice but to abort.  This falls into the class of error scenarios that are addressable by running with multiple helpers.] [TODO: Don't require all sub-requests to pertain to the same HPKE config.] </del> <ins> "PAParam". </ins> The response consists of the helper's updated state and a sequence of _sub-responses_, where the i-th sub-response corresponds to the sub-

Related discussion:
text: Update the aggregate request text to reflect recent protocol changes. Relax the requirement that all sub-requests use the same key config. Do URL, which was previously merged into the wrong branch.
NAME NAME please have a look when you can.
Per , the first step in the upload protocol is a POST to the leader server which returns information about helpers. In some yet to be specified cases, the response could include a challenge to be incorporated into reports. However I suspect that in most cases, the response will be static and so an idempotent, cacheable GET would be a better fit, especially since it would save clients a roundtrip to the helper on the hot path of submitting reports, and would make it possible for helpers to implement uploadstart by putting some static content in a CDN. HTTP GET requests don't have bodies, so we would have to figure out how to encode all the data in the current into the URI, which could be done as either path fragments in the URI (i.e., ) or as query parameters (i.e., ). We would of course need to make sure that don't preclude proof systems like the one alleged to exist in section 5.2 of "BBCp19".
Also, because the current protocol uses a POST for uploadstart, the implication is that for every report they submit, clients need to hit and then . If we make idempotent and cacheable, then that request can be skipped in the majority of cases. I suppose the significance of this depends on how we expect clients to use PDA: are they going to be continuously streaming hundreds or thousands of reports into the leader as events of interest occur (in which case I think eliminating requests is interesting) or are they expected to accumulate several reports locally before submitting them all in one or a few requests?
I agree this would be a good change, if we can swing it. It's notable that Prio v2 and HH don't require a random challenge from the leader. But as discussed, this is useful for other proof systems one might want to implement for Prio. For example, see the data type implemented here: URL See below for an explanation. There might be other ways to implement the challenge. One possibility is to derive the challenge from the TLS key schedule (or from whatever state the client and leader share for the secure channel).
Code change:
malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PA parameters "PAParam" for which "PAAggregateReq.task_id" is equal to the task id derived from <del> "PAParam".  Next, it looks up the HPKE config and corresponding secret key associated with "PAAggregateReq.helper_hpke_config_id". If not found, then it aborts and alerts the leader with "unrecognized key config".  [NOTE: In this situation, the leader has no choice but to abort.  This falls into the class of error scenarios that are addressable by running with multiple helpers.] [TODO: Don't require all sub-requests to pertain to the same HPKE config.] </del> <ins> "PAParam". </ins> The response consists of the helper's updated state and a sequence of _sub-responses_, where the i-th sub-response corresponds to the sub-

Related discussion:
text: NAME and NAME have both pointed out that adding this dependency on the underlying transport is problematic. Another possibility might be to use some external source of randomness that the leader trusts. comes to mind, though it is somewhat problematic because clients would effectively use the same randomness for some period of time. The security model of BBCp19 would need to be extended to account for this. (I believe this could be done.) Some other solution I'm missing? _ This data type is used to compute the mean and variance of each integer in a sequence of integers. To do so, the client encodes each integer of its input vector as a pair , where is the representation of as a bit vector and is equal to . To prove validity of its input, the proof needs to do two things: verify that (a) is indeed a bit vector, and (b) the integer encoded by is the square root of . In order to check these things efficiently, the proof system uses a random challenge generated by the leader. At a very high level, the client wants to prove that the following boolean conjunction holds: is 1 or 0 AND is 1 or 0 AND ... AND encodes the square root of . In Prio, we need to represent this conjunction as an arithmetic circuit, which the random challenge helps us do. In a bit more detail now: Let's rewrite this expression as w[0] AND w[1] AND ... AND w[s]. As an arithmetic circuit, this expression is actually , where if and only if w[i] is true. If the input is valid, then the expression should evaluate to . But because we're talking about field elements, a malicious client may try to play games like setting and so that the sum is still , but the statement is false. To detect this, we actually compute the following expression: , where is a randomly chosen field element. If the statement is true, then the expression evaluates to . If the statement is false, then with high probability, the expression will evaluate to something other than . (This idea comes from Theorem 5.3)
Thank you for the detailed explanalation NAME Having thought about it more, I suspect an HTTP GET wouldn't be the right way to support proof systems that need a challenge.
Code change:
malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PA parameters "PAParam" for which "PAAggregateReq.task_id" is equal to the task id derived from <del> "PAParam".  Next, it looks up the HPKE config and corresponding secret key associated with "PAAggregateReq.helper_hpke_config_id". If not found, then it aborts and alerts the leader with "unrecognized key config".  [NOTE: In this situation, the leader has no choice but to abort.  This falls into the class of error scenarios that are addressable by running with multiple helpers.] [TODO: Don't require all sub-requests to pertain to the same HPKE config.] </del> <ins> "PAParam". </ins> The response consists of the helper's updated state and a sequence of _sub-responses_, where the i-th sub-response corresponds to the sub-

Related discussion:
text: Assuming that a unique challenge is needed for every report[^1], then intuitively the leader would have to maintain a mapping of reports to issued challenges so that the leader and helper(s) can later use the challenge value when evaluating the client's proof. But now that the leader has to maintain state per-report, I think the upload protocol is missing a notion of a report identifier. The contains a , but IIUC the will be the same across many reports[^2] (e.g., if a browser is sending daily reports on how often users click a button, they use the same every time they submit). So needs to include a report ID, which must be echoed back to the leader in so that the leader can look up the challenge for the report. [^1] Is this true? Or would it suffice for each to use the same challenge across multiple reports? [^2] I notice that the design doc lacks a strong definition of a report and how it relates to tasks, inputs, measurements: because GET should be "safe" in the sense of not changing any server state, and it seems like the server would have to maintain a mapping of reports to issued challenges so that the leader and helper can later use the challenge value when evaluating the client's proof.
Continuing on the assumption that causes a state change on the leader, POST is then the appropriate HTTP method to use. , though it's a little unusual. There may be some big drawback to cacheable POST responses, but I think that might let us support proof systems that require live challenges while also eliminating the majority of requests when the proof system is such that the will change very rarely.
The requirement for the leader to keep state across upload start and upload finish may be avoidable. Suppose the leader has a long-lived PRF key K. It would could choose a random nonce N, compute R = PRF(K, N) as the challenge, and hand (N, R) to the client in its upload start response. The client would then use R to generate the proof and send N to the leader in its upload finish request. The leader could then re-derive R. NAME and I kicked around the idea of having the client generate a report ID. I think this may end up being useful, but we weren't sure if it was better to have the leader choose it or the client.
Code change:
malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PA parameters "PAParam" for which "PAAggregateReq.task_id" is equal to the task id derived from <del> "PAParam".  Next, it looks up the HPKE config and corresponding secret key associated with "PAAggregateReq.helper_hpke_config_id". If not found, then it aborts and alerts the leader with "unrecognized key config".  [NOTE: In this situation, the leader has no choice but to abort.  This falls into the class of error scenarios that are addressable by running with multiple helpers.] [TODO: Don't require all sub-requests to pertain to the same HPKE config.] </del> <ins> "PAParam". </ins> The response consists of the helper's updated state and a sequence of _sub-responses_, where the i-th sub-response corresponds to the sub-

Related discussion:
text: To conform to the security model of BBCp19, each report would need its own challenge. It may be possible to relax this, but this would be risky.
I like this a lot! I'm a big fan of deterministic derivation schemes like this -- besides reintroducing the possibility of an idempotent GET, eliminating storage requirements for challenges makes it much easier to scale up leaders. If the report IDs are big enough (UUIDs?) we could even use them as . I would say the leader, because if you let the client do it, then the leader would have to check for things like collisions with existing report IDs or other malicious ID choices. If the leader chooses it, then all it has to do is generate a few bytes of randomness. I agree.
NAME we'd appreciate your feedback on this issue because it involves security considerations for ZKP systems on secret-shared data [1]. I'll quickly sum up the problem so that you don't need to worry about the conversation above. The problem at hand regards systems like [1, Theorem 5.3] that require interaction between the prover and verifier. Specifically, we're considering a special case of Theorem 5.3 in which the verifier sends the prover a random "challenge" that is used to generate and verify a (non-interactive) FLPCP (call it ): We refer to the prover's first and second messages as "upload start" and "upload finish" respectively. Each message corresponds to an HTTP request made by a web client to a web server. Ideally, the verifier would be able to handle these requests statelessly, i.e., without having to store . Consider the following change. Suppose the verifier has a long-term PRF key . In response to an upload start request, it chooses a unique "upload id" --- maybe this is a 16-byte integer chosen at random --- and computes and sends to the prover. In the upload finish request, the prover sends so that the verifier can re-derive instead of needing to remember it: The (potential) problem with this variant is that a malicious client is able to replay a challenge as many times as it wants.
Code change:
malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PA parameters "PAParam" for which "PAAggregateReq.task_id" is equal to the task id derived from <del> "PAParam".  Next, it looks up the HPKE config and corresponding secret key associated with "PAAggregateReq.helper_hpke_config_id". If not found, then it aborts and alerts the leader with "unrecognized key config".  [NOTE: In this situation, the leader has no choice but to abort.  This falls into the class of error scenarios that are addressable by running with multiple helpers.] [TODO: Don't require all sub-requests to pertain to the same HPKE config.] </del> <ins> "PAParam". </ins> The response consists of the helper's updated state and a sequence of _sub-responses_, where the i-th sub-response corresponds to the sub-

Related discussion:
text: This behavior isn't accounted for in Definition 3.9, so when you try to "compile" this system into a ZKP on secret-shared data as described in Section 6.2 and consider its security with respect to Definition 6.4 (Setting I), you can no longer appeal to Theorem 6.6 to reason about its security. Our question is therefore: What impact do you expect this change to have on the soundness of the system? Can you think of an attack that exploits the fact that challenges can be replayed? My expectation is that the problem is merely theoretical, i.e., we ought to be able to close the gap with an appropriate refinement of Definition of 3.9 and reproving Theorem 5.3. [1] URL
Thanks for looping me in. In the discussion below, I am assuming that the client sends its data vector (called "x" in the paper [1]) at the same time as it sends its proof to the verifier. Even if the client sends its data vector in the first message, it seems that the client can reuse an (R,N) pair from upload request 1 to later submit upload request 2, in which case the client sees (R, N) before it chooses its data vector and proof. So I think we can assume that the client's data vector and proof can depend on the verifier's random value R. (I'll call this value "r" to match the paper.) For soundness: the client/prover must commit to its data vector before it learns the verifier's random value r. If the prover can choose its data value and proof in a way that depends on the verifier's randomness r, the soundness guarantee no longer holds. There is also an efficient attack. So I suspect that the stateless-verifier optimization is unsound. The attack works as follows: given r, the verifier finds a non-satisfying vector x such that sumi ri C(Ai(x)) = 0, again using the notation from Theorem 5.3 in the paper [1]. For the circuits C used in most applications, it will be easy to find such a vector x. Then, the prover constructs a proof that x that sumi ri C(Ai(x)) = 0.
Code change:
malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PA parameters "PAParam" for which "PAAggregateReq.task_id" is equal to the task id derived from <del> "PAParam".  Next, it looks up the HPKE config and corresponding secret key associated with "PAAggregateReq.helper_hpke_config_id". If not found, then it aborts and alerts the leader with "unrecognized key config".  [NOTE: In this situation, the leader has no choice but to abort.  This falls into the class of error scenarios that are addressable by running with multiple helpers.] [TODO: Don't require all sub-requests to pertain to the same HPKE config.] </del> <ins> "PAParam". </ins> The response consists of the helper's updated state and a sequence of _sub-responses_, where the i-th sub-response corresponds to the sub-

Related discussion:
text: The proof is valid, so the verifier will accept always. To remove interaction, the Fiat-Shamir-like technique in Section 6.2.3 is probably the best way to go. We only sketched the idea in the paper (without formal analysis or proof) but if it's going to be important for your application, I'm happy to sanity-check the protocol you come up with. Another idea—the details of which I have not checked carefully—would be to modify your protocol as follows: The prover sends its data vector x to verifiers, split into k shares x1, ..., xk—one for each of the k verifiers. Each verifier holds a PRF key ki computes ri = PRF(ki, xi) and they return r = r1 + ... + rk to the prover. The verifiers store no state. The prover computes the proof pi and sends (x1, pi1), ..., (xk, pik) to the verifiers—again, one for each of the k verifiers. Each verifier computes ri = PRF(ki, xi), they jointly compute r = r1 + ... + r_k, and check the proof using randomness r. The Fiat-Shamir-like approach seems slightly cleaner to me, since it only requires a single prover-to-verifier message. Either way, please let me know if I misunderstood your question or if anything else here is unclear. [1] URL
Thanks for the nice explanation, Henry. It's perfectly clear and answers my question. It also points to something that I, for one, missed the importance of: the need for the prover to "commit" to the input shares before generating the r-dependent proof. I appreciate you pointing this out. The only requirement for making upload start not idempotent is so that the randomness r can be sent to the client. It would be nice to do away with this requirement. I think the way forward is using the Fiat-Shamir technique. NAME I'll get cracking on this and let you know when I have something for you to look at.
NAME I believe the change is something like this. Let be a hash function with range . Suppose there are verifiers. The prover proceeds as follows: Splits its inputs into shares .
Code change:
malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PA parameters "PAParam" for which "PAAggregateReq.task_id" is equal to the task id derived from <del> "PAParam".  Next, it looks up the HPKE config and corresponding secret key associated with "PAAggregateReq.helper_hpke_config_id". If not found, then it aborts and alerts the leader with "unrecognized key config".  [NOTE: In this situation, the leader has no choice but to abort.  This falls into the class of error scenarios that are addressable by running with multiple helpers.] [TODO: Don't require all sub-requests to pertain to the same HPKE config.] </del> <ins> "PAParam". </ins> The response consists of the helper's updated state and a sequence of _sub-responses_, where the i-th sub-response corresponds to the sub-

Related discussion:
text: For each , do: Choose blinding factor from at random. Let . Set . Derive field element from (e.g., seed a PRNG with and map the output to a field element by rejection sampling on chunks of the output). Generate the proof using and . Split into shares . For each send to the -th verifier.
Yes, this looks right to me!
As of URL, the upload start request no longer exists. When we're ready to specify Prio, we'll want to include the Fiat-Shamir approach for protocols that use joint randomness. I've noted this and am closing the issue.
Code change:
match the one in the Welcome message, return an error. Decrypt the "encrypted_group_secrets" value with the algorithms <del> indicated by the ciphersuite and the private key corresponding to "init_key" in the referenced KeyPackage. </del> <ins> indicated by the ciphersuite and the private key "init_key_priv" corresponding to "init_key" in the referenced KeyPackage. </ins> If a "PreSharedKeyID" is part of the GroupSecrets and the client is not in possession of the corresponding PSK, return an error.

Related discussion:
text: As discussed in the virtual interim 2022-12-16, it is possible that extensions might be tempted to re-use HPKE public keys created for MLS. Even within MLS, we have two different public-key encryption cases, Welcome and Commit (though these currently use different keys). Currently, for Commit encryption, the HPKE parameter is set to the group context. The content of is actually undefined for Welcome encryption (!) This PR makes the following changes: Define general and functions that populte the HPKE parameter with an encoded label and context Apply these to Commit and Welcome encryption: Commit: label="UpdatePathNode", context= Welcome: label="Welcome", context= Add an IANA registry of public-key encryption labels (as for signing) There is also a bit of reorganization of the Ciphersuites section to split it into three subsections.
Note that any previous analysis of MLS had to take this particular reuse into account. This can't be the case for any arbitrary extensions reusing the key. So if MLS uses an extension that reuses the key, none of the existing analysis applies, which is a much bigger issue. This said, this reuse did decrease security -- it weakened FS in that a joiner had to hold on to their HPKE leaf key, which also allowed to decrypt the init secret from the welcome message, long after joining.
I think this captures what we discussed during the interim. FWIW, I'm wondering if we didn't have a domain separation issue in the past when we only had one HPKE public key in KeyPackages and used it for both the Welcome subsequently for UpdatePath as well. Either way, I think this is a good defense-in-depth mechanism.
Code change:
An endpoint uses a frame (type=0x04) to abruptly terminate the sending part of a stream. <del> After sending a , an endpoint ceases transmission and retransmission of frames on the identified stream.  A receiver of can discard any data that it already received on that stream. </del> <ins> After sending a , an endpoint ceases transmission of frames on the identified stream.  A receiver of can discard any data that it already received on that stream. </ins> The frame defines the following fields:

Related discussion:
text: Reset stream doesn't cease retransmission.
retransmission of WTSTREAM frames on the identified stream. A receiver of WTRESET_STREAM can discard any data that it already received on that stream." This is using TCP and should not talk about ceasing retransmissions.
Very good point! Will clean up
Code change:
method allowed for doing MAC-ed messages.  In COSE, all of the key management methods can be used for MAC-ed messages. <ins> The COSE_encrypt structure for the recipient is organized as follows: The 'protected', 'iv', 'aad', 'ciphertext' and 'recipients' fields MUST be null. The plain text to be encrypted is the key from next layer down (usually the content layer). At a minimum, the 'unprotected' field SHOULD contain the 'alg' parameter as well as a parameter identifying the shared secret. </ins> 5.2.2. In key wrapping mode, the CEK is randomly generated and that key is

Related discussion:
text: Correct descriptions of Direct and Key Agreement Direct Change examples in the back to have "real" examples - they are JSON rather than CBOR, but that makes them shorter and easier to read.
Code change:
unless the client instance has specifically requested it by use of the "split" flag. <ins> Flag values MUST NOT be included more than once. Additional flags can be defined by extensions using IANA. </ins> The following non-normative example shows a single access token bound to the client instance's key used in the initial request, with a management URL, and that has access to three described resources (one

Related discussion:
text: URL match the flags array in the token request. While this is technically a breaking change, I think we should consider this editorial as this should have been changed when we made the original change to use a flags array in the request in .
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: 8c793bb446d82f053536358106485568fc457842 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
You know, I had that thought, and I checked the request section and it doesn't have quotes. I'm going to add the quotes to both parts. This ended up with some other language changing, not just the examples, so let me know what you think.