jiebi/CodeConvo huggingface dataset:
Change:
to encrypt or decrypt a message. Post-compromise security is also provided for new groups by members <del> regularly generating new InitKeys and uploading them to the Delivery Service, such that compromised key material won't be used when the member is added to a new group. </del> <ins> regularly generating new KeyPackages and uploading them to the Delivery Service, such that compromised key material won't be used when the member is added to a new group. </ins> 15.4. <del> InitKeys are intended to be used only once.  That is, once an InitKey has been used to introduce the corresponding client to a group, it SHOULD be deleted from the InitKey publication system.  Reuse of InitKeys can lead to replay attacks. </del> <ins> KeyPackages are intended to be used only once.  That is, once a KeyPackage has been used to introduce the corresponding client to a group, it SHOULD be deleted from the KeyPackage publication system. Reuse of KeyPackages can lead to replay attacks. </ins> <del> An application MAY allow for reuse of a "last resort" InitKey in order to prevent denial of service attacks.  Since an InitKey is </del> <ins> An application MAY allow for reuse of a "last resort" KeyPackage in order to prevent denial of service attacks.  Since a KeyPackage is </ins> needed to add a client to a new group, an attacker could prevent a client being added to new groups by exhausting all available <del> InitKeys. </del> <ins> KeyPackages. </ins> 15.5.

Discussion:
Complete the renaming of InitKeys -> KeyPackages; and GroupInfo -> PublicGroupState
Comment by NAME Hmmm :P
Cf. RFC 8446 We could provide some more citations to the analyses that are now in the literature if you think that would help.
CC NAME NAME NAME for citations
They are also in this architecture document PR: URL
Oh good, I'll just add a citation over to mls-architecture.
Change:
Using the specification above, we can give some example parameterizations.  For example, the current Privacy Pass browser <del> extension PPEXT has over 150,000 active users (from Chrome and Firefox).  As a result, log_2(U/A) is approximately 5 and so the maximum value of I should be 4. </del> <ins> extension PPEXT has nearly 300000 active users (from Chrome and Firefox).  As a result, log_2(U/A) is approximately 6 and so the maximum value of I should be 3. </ins> If the value of U is much bigger (e.g. 5 million) then this would <del> permit I = log_2(5000000/5000)-1 = 8 issuers. </del> <ins> permit I = (log_2(5000000/5000)-1)/2 ~= 4 issuers. </ins> 9.

Discussion:
Add allowances in protocol doc for redemption metadata Provide privacy analysis of including metadata to architecture doc Update privacy parametrizations cc NAME NAME NAME (I don't know everyone's github usernames, so feel free to add others who will be interested in reviewing).
LGTM
The main protocol document assumes that VOPRF is the main instantiation of PrivacyPass. It also has support for ciphersuites that augment this particular instantiation. It's not clear how we'd "extend" this protocol to support other features, such as public verifiability or the k-bits of metadata. These seem to be separate "modes" or "configurations" of PrivacyPass. (I don't think it makes sense to try and cast the metadata bit variant as a different ciphersuite for the main instantiation.) I propose we add some text describing different configurations. A configuration is an instantiation of the PrivacyPass API with certain properties. A configuration may (should?) also be extensible where applicable, e.g., in the ServerUpdate message or IssuanceRequest/Response messages. Interoperability across configurations would be unsupported, as they have would like have fundamentally different properties. Some initial configurations that come to mind are: PrivacyPass with no metadata bits (VOPRF construction) PrivacyPass with k metadata bits (Google's design) PrivacyPass with public verifiability (blind signatures?) cc NAME
Added some more information about supporting additional metadata in . As discussed elsewhere, I think the way to go here is for extensions to just specify new ciphersuites with associated privacy/security guarantees.
A number of applications expect the Servers to be able to add a small amount of metadata to the Privacy Pass protocol. We should add a discussion on how metadata should be added to tokens, and then describe the subsequent impact that this would have on the client's expected privacy budget. Generally speaking, adding a bit of metadata to tokens is likely to have a very similar impact to introducing an extra Issuer, and so this is something that will have to be covered in the general parametrization guidelines in the architecture document. Specific mechanisms for adding metadata to tokens are yet to be proposed, but may appear as alternative instantiations in the protocol document, or be specified separately as individual extensions.
LGTM. We’ll need to work through the extensibility support for the metadata bit variant next.
Change:
1. <del> This document specifies a modern abstract programming interface (API) atop the high-level architecture for transport services defined in I- D.ietf-taps-arch.  It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime.  It is intended to replace the traditional BSD sockets API as the common interface to the transport layer, in environments where endpoints select from multiple interfaces and potential transport protocols. </del> <ins> This document specifies a modern abstract application programming interface (API) atop the high-level architecture for transport services defined in I-D.ietf-taps-arch.  It supports the asynchronous, atomic transmission of messages over transport protocols and network paths dynamically selected at runtime.  It is intended to replace the traditional BSD sockets API as the common interface to the transport layer, in environments where endpoints select from multiple interfaces and potential transport protocols. </ins> As applications adopt this interface, they will benefit from a wide set of transport features that can evolve over time, and ensure that

Discussion:
Resolving Editorial NiTs in section 1
Section 1: This section contains a RFC2119 keyword that precedes the definition! We use the words /abstract programming interface/ and the acronym /API/ but never tie these together. NiTs: /provide applications a way to/provide a way for applications to/ /as it comes at the cost of reduced portability/because it can reduce the portability./ /How these abstract concepts/The way these abstract concepts/ /is largely dependent on/mostly depends on/
A PR for this issue has already been merged.
Looks good to me, thanks for doing this!
Change:
allows a client to look up an account URL based on an account key (see finding-an-account-url-given-a-key). <ins> An optional field for binding the new account with an existing non-ACME account (see external-account-binding ). </ins> The server MUST ignore any values provided in the "orders" fields in account bodies sent by the client, as well as any other fields that it does not recognize.  If new fields are specified in the future,

Discussion:
1) Include optional field in the Account Creation section with a forward pointer to the external account binding section. 2) Include the mandatory "orders" field in the example new account response. 3) Correct the "orders" field type in Section 9.7.1 to match the type from 7.1.2 Thanks to NAME for flagging these issues on the WG Mailing List.
Change:
RFC EDITOR PLEASE DELETE THIS SECTION. <ins> draft-10 Re-enable constant-time Add (*) </ins> draft-09 Remove blanking of nodes on Add (*)

Discussion:
When we converted to the Proposal/Commit scheme, one of the consequences was that Adds became O(N) instead of O(1), since they had to Committed and commits encrypt the committer's direct path to the remainder of the tree. This is ~log(N) in the nice case and ~N in the worst case. At the time, we noted that one could special-case Add-only Commits in the future and make the update to the direct path optional in that case. This PR implements that suggestion. The leaf KeyPackage for the Commit is moved into the DirectPath struct, and the whole DirectPath is made optional. The optional value MUST be provided for: A Commit committing an update or remove A "just update my path" Commit covering no proposals
So we do go forward one epoch, but with an all-zero commit secret. Do I understand that correctly?
NAME That's correct. The idea is that you don't need to send the current group any additional entropy, you just need them to hash forward. Note that this could change the FS/PCS guarantees available. But I don't think we ever proposed that Add would cause any FS/PCS changes to the group, so maybe this doesn't matter.
Add should give FS guarantees in so far as that the new member shouldn't be able to decrypt old messages or derive old keys. But I think ratcheting forward should do the trick. We should note, though, that this breaks the (implicit) assumption that a commit always introduces fresh key material to the group. As far as I can see, that's not breaking anything right now, but we should keep it in mind.
Note: The latest commit fixes a gap that was discovered in .
See the flexibility question.
Change:
A "Trusted Application Manager (TAM)" server is responsible for managing the applications running in the TEE of a client device.  To do this, the TAM wants to assess the state of a TEE, or of <del> applications in the TEE, of a client device.  The TEE attests to the TAM, which can then decide whether the TEE is already in compliance with the TAM's latest policy, or if the TAM needs to uninstall, update, or install approved applications in the TEE to bring it back into compliance with the TAM's policy. </del> <ins> applications in the TEE, of a client device.  The TEE conducts a remote attestation procedure with the TAM, which can then decide whether the TEE is already in compliance with the TAM's latest policy, or if the TAM needs to uninstall, update, or install approved applications in the TEE to bring it back into compliance with the TAM's policy. </ins> A device with a trusted execution environment capable of running trusted applications that can be updated

Discussion:
Diffs look longer than they really are just because text was moved around due to the ordering point raised on the design team call. Also, I found that "Verifying Relying Party" was used in this section without actually being defined so I defined it in context in that sentence (line 686). Also added subsection headings for each role to make it easier to read and refer to. The "recursion" aspect is dealt with by example in the new text starting at line 692, which was the simplest way I could find to do it, where I found that trying to use the term "recurse" or similar just made it harder for me to understand. Other places just refer back to that example. Signed-off-by: Dave Thaler
Change:
5. The security properties of token challenges vary depending on whether <del> the challenge is interactive or not, as well as whether the challenge is per-origin or not.  For example, non-interactive, cross-origin tokens can be replayed from one party by another, as shown below. </del> <ins> the challenge contains a redemption context or not, as well as whether the challenge is per-origin or not.  For example, cross- origin tokens with empty contexts can be replayed from one party by another, as shown below. </ins> <del> Interactive token challenges require clients to obtain matching </del> <ins> Context-bound token challenges require clients to obtain matching </ins> tokens when challenged, rather than presenting a token that was <del> obtained in the past.  This means that issuance and redemption events will occur at approximately the same time.  For example, if a client is challenged for an interactive token at time T1 and then subsequently obtains a token at time T2, a colluding issuer and origin can link this to the same client if T2 is unique to the client.  This linkability is less feasible as the number of issuance events at time T2 increases.  Depending on the "max-age" token challenge attribute, clients MAY try to augment the time between getting challenged then redeeming a token so as to make this sort of linkability more difficult.  For more discussion on correlation risks between token issuance and redemption, see I-D.ietf-privacypass- architecture. </del> <ins> obtained in the past.  This can make it more likely that issuance and redemption events will occur at approximately the same time.  For example, if a client is challenged for a token with a unique context at time T1 and then subsequently obtains a token at time T2, a colluding issuer and origin can link this to the same client if T2 is unique to the client.  This linkability is less feasible as the number of issuance events at time T2 increases.  Depending on the "max-age" token challenge attribute, clients MAY try to augment the time between getting challenged then redeeming a token so as to make this sort of linkability more difficult.  For more discussion on correlation risks between token issuance and redemption, see I- D.ietf-privacypass-architecture. </ins> Applications SHOULD constrain tokens to a single origin unless the use case can accommodate such replay attacks.

Discussion:
We should consider renaming to . This value doesn't need to be a nonce, it's just some origin-selected context that it is binding to. We can also rename the in the Token struct to to make it clear what role it has.
Change:
receipt of a min_ack_delay that is greater than the received max_ack_delay as a connection error of type PROTOCOL_VIOLATION.  Note that while the endpoint's max_ack_delay transport parameter is in <del> milliseconds (Section 18.2 in QUIC-TRANSPORT), min_ack_delay is </del> <ins> milliseconds (Section 18.2 of QUIC-TRANSPORT), min_ack_delay is </ins> specified in microseconds. 4.

Discussion:
merging.
If it doesn't change it, we should say so. If it allows it to be reduced, then we need to understand what the limits are(ie: it can't be lowered to 1us presumably?). Admittedly, the way we're using maxackdelay should be safe to assuming a 0 value, since the SRTT will accrue the excess.
Change:
Properties (datatransfer).  Message Properties can also be specified during data transfer to affect specific Messages. <del> Connection: A Connection object represents an active transport protocol instance that can send and/or receive Messages between local and remote systems.  It holds state pertaining to the underlying transport protocol instance and any ongoing data transfer.  This represents, for example, an active connection in a connection-oriented protocol such as TCP, or a fully-specified 5-tuple for a connectionless protocol such as UDP. </del> <ins> Connection: A Connection object represents one or more active transport protocol instances that can send and/or receive Messages between local and remote systems.  It holds state pertaining to the underlying transport protocol instances and any ongoing data transfers.  This represents, for example, an active connection in a connection-oriented protocol such as TCP, or a fully-specified 5-tuple for a connectionless protocol such as UDP.  It can also represent a pool of transport protocol instance, e.g., a set of TCP and QUIC connections to equivalent endpoints, or a stream of a multi-streaming transport protocol instance. </ins> Listener: A Listener object accepts incoming transport protocol connections from remote systems and generates corresponding

Discussion:
This updates the definition of a TAPS connection to allow a TAPS implementation to do connection pooling and multi-streaming. It removes the limitation from a TAPS connection to relate to exactly one underlying transport connection and hints that underlying transport connections my be created automatically. This is one result of the discussion around PR .
All comments should be addressed – ready for merge
Thanks for the changes! LGTM.
That seems OK, can we fix: / It can also represent a pool of transport protocol instance/ to be /instances/ or whatever the plural is of a transport protocol instance? Gorry
The arch definition of connection should add a sentence to say that there may be multiple flows (MPTCP, MPQUIC, or even connection pooling) below the abstraction. This was assumed but not stated.
May be fixed by PR
Solved by
LGTM modulo the small fixes pointed out by NAME
Change:
payloads, even if the individual messages are integrity protected, it is still possible for an attacker to maliciously replace a later operation's blocks with an earlier operation's blocks (see <del> Section 2.5 of I-D.mattsson-core-coap-actuators).  Therefore, the </del> <ins> Section 2.5 of I-D.mattsson-core-coap-attacks).  Therefore, the </ins> integrity protection of each block does not extend to the operation's request body.

Discussion:
We've mentioned outdated draft names at times. Details in individual commits, point-to-point updated in-PR too. The DTLS change is not so much an update but a not to the editor that they may update the reference at their discretion when the publication sequence is clear; I don't want to pull another normative dependency into our cluster because we don't normatively need anything from 1.3.
Change:
A document editor can still use GitHub independently for documents that they edit, even if the Working Group does not expressly choose <del> to use GitHub.  Any such public repository MUST follow the guidelines in BCPs 78 and 79 (COPYRIGHT, IPR) and bear notices to that effect. This recognizes that editors have traditionally chosen their own methods for managing the documents they edit but preserves the need for contributors to understand their obligations with respect to IETF processes. </del> <ins> to use GitHub.  Any such public repository MUST follow the IETF Note Well and bear notices; see notices.  This recognizes that editors have traditionally chosen their own methods for managing the documents they edit but preserves the need for contributors to understand their obligations with respect to IETF processes. </ins> 3.2.

Discussion:
This consolidates text about notices in the "communicating policies" section, which seems most appropriate.
Thanks!
Change:
receives, at the cost of some fidelity, depending on the quality of the remote VAD algorithm. <ins> If the "VoiceActivityDetection" option is specified, with a value of "false", the browser MUST NOT omit "CN" codecs.  For codecs that have their own internal silence suppression support, the appropriate fmtp parameters for that codec MUST be specified to indicate that silence suppression for received audio is not desired.  For example, when using the Opus codec, the "usedtx=0" parameter would be specified in the offer. Note that setting the "VoiceActivityDetection" parameter when generating an offer is a request to receive audio with silence suppression.  It has no impact on whether the local endpoint does silence suppression for the audio it sends. The "VoiceActivityDetection" option does not have any impact on the setting of the "vad" value in the signaling of the client to mixer audio level header extension described in RFC6464, Section 4. </ins> 5.3. When createAnswer is called, a new SDP description must be created

Discussion:
We reviewed the handling for G.729 and it's similar to Opus; there's a dtx=foo fmtp parameter to control receipt of DTX. I suggest we leave this parameter to createOffer as an indication on whether you want the remote side to use DTX, and add a frob on RtpSender (TBD exactly where) to directly control whether you use DTX. That frob is out of scope for this PR. For the PSAP/E911 case, the call will typically be over PCMU, and so it's covered through either of a) setting this parameter (which drops CN from the offered codecs), or b) the PSAP not responding with CN in the answer. So that's not an issue. We may need to add some text in the handling-a-remote-description section to make it clear that if the remote side says to use DTX (either through presence of CN, or usedtx=1), DTX MUST be engaged by the browser. We could also spell out the no-DTX case, if desired.
So plan is make this just about SDP, both offer and answer, along lines of Justin text. Then file issue to deal with happens with RTP sender.
Put in all Justin's comments from prev review.
In some codecs (e.g., Opus) requests to not do silence suppression are advisory. We should consider whether we require browsers to respect them so that counterparties which need the browser to not do silence suppression can force that.
I think it would make the most sense for this to behave identically regardless of codec. IOW, if not offered, it can't be indicated in the answer. The answer can of course reject a proposal to use VAD (currently via AnswerOptions), but there could perhaps be another surface for this.
Decision in Kirkland: if offer indicates no VAD (either through lack of CN, or usedtx=0), answer MUST not specify VAD. This is done on a per-codec basis, e.g. if answerer receives CN + usedtx=0, and answerer says Vad:True, answer will have CN + usedtx=0.
Fixed by
Change:
4.2.2. <del> When using the response-interact-finish with the "push" method, the AS signals to the client instance that interaction is complete and the request can be continued by sending an HTTP POST request to the client instance's callback URL sent in request-interact-callback- push. </del> <ins> When using the response-interact-finish, the AS signals to the client instance that interaction is complete and the request can be continued by sending an HTTP POST request to the client instance's callback URL sent in request-interact-callback-push. </ins> The entity message body is a JSON object consisting of the following two fields:

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 681a99c7e9be294002d224d914dbb452a5d278bf Inspect the deploy log: Browse the preview:
Change:
the early data.  It is not possible for the server to accept only a subset of the early data messages. <ins> Request that the client send another ClientHello by responding with a HelloRetryRequest.  A client MUST NOT include the "early_data" extension in its followup ClientHello. </ins> In order to accept early data, the server server MUST have accepted a PSK cipher suite and selected the the first key offered in the client's "pre_shared_key" extension.  In addition, it MUST verify

Discussion:
ClientHello mentions that earlydata should be removed, but earlydata doesn't mention it. Editorial.
Change:
order of attributes), others (like the relative order of links from different contexts) are deemed irrelevant and not preserved. <del> For serialization, a (so far unspecified) packing was picked, resulting in a binary CBOR file with this CBOR diagnostic notation: </del> <ins> For serialization, the use of the packing described with the conversion results in a binary CBOR file with this CBOR diagnostic notation: [ TBD: Numbers are made up ] </ins> Note that the "temperature-c" interface and "sensor" resource type get code points in the link-format dictionary because they are of

Discussion:
As a result of , a mismatch in terminology remained: While the information model talks of a "root node", the Document Semantics section still talks of retrieval contexts; these are the same thing, and wording needs to be aligned. (This is especially relevant when converting with RDF; see upcoming commit in ).