jiebi/CodeConvo huggingface dataset:
Change:
Key generation <del> Sign the protected content and metadata </del> <ins> Sign the plaintext metadata - the group ID, epoch, sender index, and content type - as well as the message content </ins> <del> Encrypt the sender information using the random nonce and the key derived from the sender_data_secret </del> <ins> Randomly generate sender_data_nonce and encrypt the sender information using it and the key derived from the sender_data_secret </ins> Encrypt the content using a content encryption key identified by the metadata

Discussion:
Here's the Weekly Digest for : This week, 8 issues were created. Of these, 4 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :heart: , by :heart: , by :heart: , by The issue most discussed this week has been: :speaker: , by It received 9 comments. This week, no pull requests has been proposed by the users. This week, 4 users have contributed to this repository. They are , , , and . This week, no user has starred this repository. This week, there have been 4 commits in the repository. These are: :hammerandwrench: Merge pull request from rozbb/mlsplaintext-signature Multiple clarifications around Framing by :hammerandwrench: Merge pull request from rozbb/hpke-encrypt Clarify how HPKE ciphertexts are computed by :hammerandwrench: by :hammerand_wrench: by # RELEASES This week, no releases were published. That's all for this week, please watch :eyes: and star :star: to receive next weekly updates. :smiley:
Change:
receiver does not notify the sender of the window size.) The "right" edge of the window represents the highest validated <del> sequence number value received on the session.  Records that contain sequence numbers lower than the "left" edge of the window are </del> <ins> sequence number value received on the association.  Records that contain sequence numbers lower than the "left" edge of the window are </ins> rejected.  Records falling within the window are checked against a list of received records within the window.  An efficient means for performing this check, based on the use of a bit mask, is described

Discussion:
This should make things correct. We might consider getting rid of the term connection or association entirely, but each is problematic: association is a historical term but we also use connection a lot anyway.
It's a shame that "association" is so firmly entrenched. I don't see "association" being used much anyway. Good that you have removed "session" though.
Change:
the removed leaf An existing participant receiving a Remove message first verifies the <del> signature on the message, then verifies its identity proof against the identity tree held by the participant.  The participant then updates its state as follows: </del> <ins> signature on the message.  The participant then updates its state as follows: </ins> Update the roster by setting the credential in the removed slot to the null optional value

Discussion:
Fixes for points 1, 2, 4, 7 in .
I think a bunch of these are probably relics of previous versions. For reference, the page numbers listed are from the PDF version of draft 3 of the protocol: [x] 1 - p6: is mentioned, but it is not defined anywhere in the specification. Perhaps is intended.[x] 2 - p19: A field is mentioned, but only is present. Also it's unclear which function is supposed to be used here. It can't be ciphersuite-dependent, since it has to be the same for every Participant.[x] 3 - p22: is used in a diagram, but never defined. I think this is important, and it's mentioned elsewhere.[x] 4 - p24: is mentioned, but never defined. Is it supposed to say ?[ ] 5 - p25: The underlying Hash that HMAC uses can't be defined by anyone's ciphersuite. This is group state, and everyone has to agree on this.[x] 6 - p28: Mentioned "update secret" again without explanation.[x] 7 - p29: "identity tree" is mentioned, but I can't tell what that's referring to. Also "update secret" is here.[x] 8 - p35: is mentioned, but never defined. Perhaps is intended.
Thanks a lot for the review, this is very useful. I have a pass planned for this week and will fix these issues :)
NAME A PR was opened with fixes for points 1, 2, 4, 7. Point 8 was already solved. An issue has been opened to solve points 3 and 6 related to the update secret definition. I tried to figure out your point 5 but I didn't understand it, can you give details ?
Sorry for the delay. I think point 5 was a misunderstanding over when a common ciphersuite is established in the protocol. I'm still not 100% clear on it, but I think I'm just missing something simple. Consider it withdrawn.
Ok, then these issues are fixed by and . Thanks
Change:
maximally pack packets to minimize bandwidth consumption and computational costs with one or multiple same data frames.  If not enough data available to send QUIC may even wait for a short time, <del> trading of latency and bandwidth effeciency.  This time might either </del> <ins> trading of latency and bandwidth efficiency.  This time might either </ins> be pre-configured or can the dynamically adjusted based on the <del> observed sending pattern of the application.  If the apllication </del> <ins> observed sending pattern of the application.  If the application </ins> requires low latency, with only small chunks of data to send, it may be valuable to indicate to QUIC that all data should be send out immediately.  Or if a certain sending pattern is know by the <del> application, it might also provide valuabe to QUIC how long it should wait to bundle frame into a packet. </del> <ins> application, it might also provide valuable guidance to QUIC how long it should wait to bundle frame into a packet. </ins> 4.3.

Discussion:
Tried to make '4. Use of Streams' a little more readable around exposing max allowed/used/open stream info to applications. (Not a native speaker but my best-effort after reading the draft.)
Change:
addresses, while still satisfying all of the recommended properties. This raises some challenges to the components of the network.  For example, if the User Equipment tries to access the network with <del> multiple IP addresses, should the enforcement device and API Server </del> <ins> multiple IP addresses, should the Enforcement Device and API Server </ins> treat each IP address as a unique User Equipment, or should it tie the multiple addresses together into one view of the subscriber?  An implementation MAY do either.  Attention should be paid to IPv6 and

Discussion:
We were using "Captive Portal Enforcement", "Captive Portal Enforcement Device" and "Enforcement Device", with varying capitilisation, inconsistently throughout the document. Address that by defining the component as "Captive Portal Enforcement Device", and using that term in section headings, and "Enforcement Device" everywhere else. Fixes issue
Looks good to me
Used in different ways: Captive Portal Enforcement, enforcement device, etc.
I think keeping it shorter is likely better. ? Caps to make it clear it's a first class component in the architecture?
Change:
gap with Zero Trust.  The credentials used for authentication and admission control can be manipulated on the endpoint.  Attestation can fill this gap through the generation of a compound credential <del> called AR-augmented Evidence. This compound credential is rooted in the hardware based Attesting Environment of an endpoint, plus the trustworthiness of a Verifier. The overall solution is known as "Below Zero Trust" as the compound credential cannot be manipulated or spoofed by an administrator of an endpoint with root access.  This solution is not adversely impacted by the potential drawbacks with pure background-check described above. </del> <ins> called AR-augmented Evidence.  This compound credential is rooted in the hardware based Attesting Environment of an endpoint, plus the trustworthiness of a Verifier.  The overall solution is known as "Below Zero Trust" as the compound credential cannot be manipulated or spoofed by an administrator of an endpoint with root access.  This solution is not adversely impacted by the potential drawbacks with pure background-check described above. </ins> To kick-off the "Below Zero Trust" compound credential creation sequence, a Verifier evaluates an Attester and returns signed

Discussion:
Based on request from Yogesh for a new Configuration encoded claim.
Thanks Eric! As you may have guessed, we have an immediate use for this 36 :-)
Change:
The "right" edge of the window represents the highest validated sequence number value received on the session.  Records that contain sequence numbers lower than the "left" edge of the window are <del> rejected.  Packets falling within the window are checked against a list of received packets within the window.  An efficient means for </del> <ins> rejected.  Records falling within the window are checked against a list of received records within the window.  An efficient means for </ins> performing this check, based on the use of a bit mask, is described in Section 3.4.3 of RFC4303.  If the received record falls within the <del> window and is new, or if the packet is to the right of the window, then the packet is new. </del> <ins> window and is new, or if the record is to the right of the window, then the record is new. </ins> <del> The window MUST NOT be updated until the packet has been deprotected </del> <ins> The window MUST NOT be updated until the record has been deprotected </ins> successfully. 4.5.2.

Discussion:
NAME
I think that the older versions of the spec were good at using the term "datagram" to refer to the thing that holds DTLS records. This version now uses "packet" in a good number of places. Sometimes I think that it means "record", other times "datagram". I'm sure that this is just the influence of QUIC and it can be fixed easily.
Actually 6357 uses "packet" all over the place. I'll do an audit, but I'm not going to ones that mean IP packet.
Change:
5. <del> TBD: Provide complete security requirements and analysis. </del> <ins> One of the goals of this protocol is to improve the security of the communication between client hosts and Captive Portal systems. Client traffic is protected from passive listeners on the local network by requiring TLS-encrypted connections between the client and the Captive Portal API server, as described in api-details.  All communication between the clients and the API server MUST be encrypted. In addition to encrypting communications between clients and Captive Portal systems, this protocol requires a basic level of authentication from the API server, as described in server-auth. Specifically, the API server MUST present a valid certificate on which the client can perform revocation checks.  This allows the client to ensure that the API server has authority for a hostname that can be presented to a user. It is important to note that while the server authentication checks can validate a specific hostname, it is certainly possible for the API server to present a valid certificate for a hostname that uses non-standard characters or is otherwise designed to trick the user into believing that its hostname is some other, more trustworthy, name.  This is a danger of any scenario in which a hostname is not typed in by a user. </ins> 5.1.

Discussion:
Adding a security considerations section to describe the security benefits that are added, along with the concern about trusting any hostnames even after authentication. I'd like to get some form of this in soon, and then rev the document before the IETF 105 cutoff.
thanks for starting this. looks like a good text to start with. Should we also propose something to the privacy section ?
We have a bit in the privacy section already, so I was going to leave it for now. If you have suggested text, let me know and I’ll add it!
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> Commonly used terms in the document are described below.

Discussion:
For those drafts that are in AUTH48.
This PR makes me happy.9000! Very cool!
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and <del> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </ins> Commonly used terms in the document are described below.

Discussion:
kramdown-rfc2629 inserts a non-breaking space when expanding , which xml2rfc subsequently mangles to produce invalid XML. Rather than deal with that, insert the boilerplate with regular spaces instead. Note that this is necessary to make work properly, as that tool drops the non-breaking whitespace character between "BCP" and "14".
URL (I need to follow up regarding the use of non-breaking whitespace generally).
This seems fine, but I assume you've separately filed the appropriate bugs to fix the regular tools?
Change:
CoAP over TCP message format.  All messages are also untyped. fig-flow-comparison illustrates the difference between CoAP over UDP <del> and CoAP over reliable transport.  The removed Type (no type) and Message ID fields are indicated by dashes. </del> <ins> and CoAP over reliable transport.  The removed Type and Message ID fields are indicated by dashes. </ins> 2.2.

Discussion:
Replacing "CoAP over TCP, TLS and Websockets" with "CoAP over reliable transports" is a good idea to reduce repetition. I feel it might be a good idea to clarify when we refer to reliable transports, that we actually refer to stream-based reliable transports. Datagram-based reliable transports (eg DCCP, QUIC, etc) exist, which render the Message Framing layer in Figure 1 unnecessary. I'm not advocating that we run CoAP over QUIC, DCCP etc but perhaps clarification would be wise.
See also
I would add a note to the terminology section that CoAP over reliable transports refers to stream-based transport protocols, such as TCP.
Sounds reasonable: The term "reliable transport" only refers to stream-based transport protocols such as TCP.
URL The term "reliable transport" only refers to stream-based transport protocols such as TCP. We could say more explicitly: sequenced/order-preserving, reliable... (Stream might be byte stream or message stream.) s/only refers/is used only to refer/
NAME - I would probably avoid "sequenced" which suggests sequence numbers and acknowledgements which are the mechanism to provide reliability. Perhaps too much detail? How about: The term "reliable transport" is used only to refer to transport protocols such as TCP which provide reliable and ordered delivery of a byte-stream.
NAME wrote: This concisely clarifies my initial concern, and I'm ok with this.
Change:
the identities in the client's list. Each PSK is associated with a single Hash algorithm.  For PSKs <del> established via the ticket mechanism (NSTMessage), this is the Hash used for the KDF on the connection where the ticket was established. </del> <ins> established via the ticket mechanism (NSTMessage), this is the KDF Hash algorithm on the connection where the ticket was established. </ins> For externally established PSKs, the Hash algorithm MUST be set when the PSK is established, or default to SHA-256 if no such algorithm is defined.  The server must ensure that it selects a compatible PSK (if

Discussion:
HKDF-Expand-Label has changed between draft -19 and -20, clarify that "HDF Hash" refers to the hash algorithm and not a version-specific instance of HKDF-Expand-Label which is populated with a hash algorithm.
Change:
When an ack-eliciting packet is transmitted, the sender schedules a timer for the PTO period as follows: <del> kGranularity, smoothed_rtt, rttvar, and max_ack_delay are defined in ld-consts-of-interest and ld-vars-of-interest. </del> The PTO period is the amount of time that a sender ought to wait for an acknowledgement of a sent packet.  This time period includes the estimated network roundtrip-time (smoothed_rtt), the variation in the

Discussion:
I proposed to remove this sentence here because all these values have actually been just defined in the previous sections. If a pointer to the appendix is desired, I think that should be mentioned earlier (e.g. in the intro already) that these lists existing in the appendix.
This seems fine to me, but I'd like NAME opinion as well.
Change:
"task_expiration" time, if so the Aggregator MAY mark the input share as invalid with the error "task-expired". <ins> Finally, if an Aggregator cannot determine if an input share is valid. it MUST mark the input share as invalid with error "report- dropped".  This situation arises if, for example, the Aggregator has evicted from long-term storage the state required to perform the check.  (See reducing-storage-requirements for details.) If all of the above checks succeed, the input share is not marked as invalid. </ins> 4.4.1.5. Input share preparation consists of running the preparation-state

Discussion:
Clarify that is used when it's impossible to determine if an input share is valid. One situation we need this for is when an Aggregator drops some anti-replay state in order to reduce storage costs. This should result in data loss in the worst case, not a loss of privacy.
Since , aggregators are required to store report nonces for batch intervals that have not yet been collected. This is necessary in order to prevent replay attacks. The problem is that nothing guarantees that a batch interval will be collected in a timely manner: In theory, it's possible that aggregators will have to store nonce sets indefinitely. To prevent this, there needs to be a way for the aggregators to agree on when to stop accepting reports for a given batch interval. The strawman solution is to allow each aggregator to, at its own discretion, ignore a report if it can't confirm if the report was replayed or not. The problem is that this potentially leads to unnecessary data loss.
I propose resolving this with .
Change:
at a data receiver.  Experience shows that this cost reduction can be significant for high bandwidth connections. <del> Similarly, receiving UDP packets can also be CPU intensive, and reducing acknowledgement frequency reduces this cost at a data sender. </del> <ins> Similarly, receiving and processing UDP packets can also be CPU intensive, and reducing acknowledgement frequency reduces this cost at a data sender. </ins> Severely asymmetric link technologies, such as DOCSIS, LTE, and satellite links, connection throughput in the data direction

Discussion:
Plus fixing one spot where it said 2^14, but I think it should have been 2^24
Change:
that were completed.  Each entry is a URL from which an authorization can be fetched with a GET request. <del> The status of the authorization.  This field MUST have the same value as it does in the underlying authorization object. A URL from which the authorization can be fetched with a GET request. </del> A URL for the certificate that has been issued in response to this order.

Discussion:
Removed unnecessary paragraphs from authorizations field description in order object.
Thanks NAME not sure how I missed that in :)
Change:
want to advertise support for delegated credentials or limit the number of probes that a server can perform. <del> 6.6. </del> <ins> 7.6. </ins> When TLS 1.2 servers support RSA key exchange, they may be vulnerable to attacks that allow forging an RSA signature over an arbitrary

Discussion:
From Martin: I wonder how much more needs to be said about expiration dates and allowance for clock skew. We haven't had any trouble with the mechanism proposed here (to my knowledge), but we've had plenty of trouble with ESNI deployment. Maybe the design here is sufficiently superior that it is less susceptible to problems, but it's not clear that this is indeed the case. Our implementation follows the spec when it comes to the validity period, but we can't really prevent skew from causing credentials to be rejected. What this does is that it creates a fixed notBefore equivalent for the DC that is relative to the notAfter. This effectively means that servers need to set valid_time values that aren't too far in the future based on their tolerance for client clock skew. For a 7-day credential, you might get 5 good days of use. A little bit of a nod in this direction might go a long way to avoiding deployment problems.
Fixed in
Change:
TLS Hash Algorithm RFC5246 and TLS SignatureAlgorithm registries to also refer to this document. <del> 14. </del> <ins> 15. </ins> Specification Required RFC5226 registry requests are registered after a three-week review period on the (tbd but maybe tls-reg-

Discussion:
"Supported Groups" also needed a "Recommended" column.
NAME We've also got FF DHE groups in this registry. Got a feeling for which should be "Yes"?
Much like the ciphers we need to add a "recommended" column for curves/groups. Adding this column was suggested during review of 4492bis.
Change:
This leads to the following full HTTP request message: <del> [[ See issue #109 [34] ]] </del> <ins> [[ See issue #109 [32] ]] </ins> When the verifier receives an attached JWS request, it MUST parse and validate the JWS object.  The signature MUST be validated against the

Discussion:
update token rotation response and requirements add considerations for the difficulties of rotating and revoking stateless tokens add considerations on rotation in unreliable networks
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 2284ffefdc540b8743400e9463fb65fc99070d4a Inspect the deploy log: Browse the preview:
Rotation the Access Token: Editor's note: The net result is that the client's always going to use the management URL that comes back. But should we let the server omit it from the response if it doesn't change? That seems like an odd optimization that doesn't help the client.
Close by making inclusion of URI REQUIRED.
Rotating the Access Token: Editor's note: We could also use different verbs to signal whether or not the old token should be kept around or not, instead of using a token flag to do this.
Keep "MUST if possible" here. If you want two access tokens, use the grant API not the token rotation API. The rotation mechanism should be for getting a new value for an existing token and replacing it, not for minting entirely new separate tokens (which is what the grant continuation/update API is for). We need to keep "if possible" for the case of using stateless tokens (fully self-contained JWTs), and add a discussion on when it might not be possible.
a few minor comments
Change:
Examples> that contains a set of testing examples as well.  Each example is found in a JSON file that contains the inputs used to create the example, some of the intermediate values that can be used <del> in debugging the example and the output of the example presented in both a hex and a CBOR diagnostic notation format.  Some of the examples at the site are designed failure testing cases; these are </del> <ins> for debugging, and the output of the example.  The results are encoded using both hexadecimal and CBOR diagnostic notation format. Some of the examples are designed to test failure case; these are </ins> clearly marked as such in the JSON file.  If errors in the examples in this document are found, the examples on GitHub will be updated, and a note to that effect will be placed in the JSON file.

Discussion:
Add in response for IANA review on all documents SecDir review by Nancy on -algs GenArt review on -struct