jiebi/CodeConvo huggingface dataset:
Change:
3.1. <del> YAML is an evolving language and, in time, some features have been added, and others removed. </del> <ins> YAML is an evolving language and, over time, some features have been added and others removed. </ins> <del> While this document is based on a given YAML version YAML, media types registration does not imply a specific version.  This allows </del> <ins> While this document is based on a given YAML version YAML, the media type registration does not imply a specific version.  This allows </ins> content negotiation of version-independent YAML resources. Implementers concerned about features related to a specific YAML <del> version can specify it in the documents using the "%YAML" directive (see Section 6.8.1 of YAML). </del> <ins> version can specify it in documents using the "%YAML" directive (see Section 6.8.1 of YAML). </ins> 3.2.

Discussion:
addressing (and a few minor editorial changes thrown in as well).
This is probably left over from earlier drafts that did cover multiple media types.
There are a couple more places that use the plural form "media types". Unless I am missing something, these all should be changed to singular form.
It's and . I don't have preferences and the singular is OK to me. Feel free to PR :)
that's what i also thought but then again isn't a media type (as i am sure you know). let's make NAME the tie-breaker!
Let's go with the singular form.
fixed via
Change:
The signature field in an MLSPlaintext object is computed using the signing private key corresponding to the credential at the leaf in the tree indicated by the sender field.  The signature covers the <del> metadata and message content, with the signature field truncated. </del> <ins> plaintext metadata and message content, i.e., all fields of MLSPlaintext except for the "signature" field. </ins> The ciphertext field of the MLSCiphertext object is produced by supplying the inputs described below to the AEAD function specified

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:
3. <del> This specification uses a cryptographic context with two parts: an inner (end-to-end) part that is used by endpoints that originate and consume media to ensure the integrity of media end-to-end, and an outer (hop-by-hop) part that is used between endpoints and Media Distributors to ensure the integrity of media over a single hop and to enable a Media Distributor to modify certain RTP header fields. RTCP is also handled using the hop-by-hop cryptographic part.  The RECOMMENDED cipher for the hop-by-hop and end-to-end algorithm is </del> <ins> This specification uses a cryptographic context with two parts: The RECOMMENDED cipher for the hop-by-hop and end-to-end algorithm is </ins> AES-GCM.  Other combinations of SRTP ciphers that support the procedures in this document can be added to the IANA registry.

Discussion:
NAME added few nits to the commit
Oh, one things I think we should add ref to ABNF
Change:
participants know that at least one aggregator is defective, and it may be possible to identify the defector (i.e., if a majority of runs agree, and a single aggregator appears in every run that disagrees). <del> See #22 [1] for discussion. </del> <ins> See #22 [2] for discussion. </ins> 6.7.

Discussion:
Removes some TODOs, clarifies why we have HpkeConfig collectorconfigstruct PPMParamUrl collectorurl, and amends collect protocol so that leader output shares are encrypted to collector's HPKE config. Several response structures no longer have or fields if the appropriate task (and hence and hence ) can be inferred from the request.
I want to address in this PR as well, so downgrading to draft for now.
NAME NAME This is ready; please review at your convenience.
Thank you for the review, NAME This picked up some merge conflicts so I will wait for all of NAME changes to land and then rebase.
You should be able to rebase now. I am mostly done.
Rebased, reordered, ready for re-review
This seems to be a dupe fo -- can we close?
Per discussion in the call today, I think this issue is about updating the various PDU definitions to allow for multiple helpers. For instance, currently has fields and , but it should instead have . is the more complex problem of extending the protocol to handle >1 helper, which probably involves more rounds of communication. I'm going to grab this issue because I ran into which I think is related, so I'll fix both.
Right now only the helper's output share for a batch of reports is encrypted to the collector. We previously agreed that all input shares should be encrypted to the corresponding aggregator (URL). It makes sense to encrypt the leader's output share for the same reasons we discussed there. Along the way, the message format should be made to accommodate multiple helpers, as we did for the input shares.
Fixed in . Making "the message format [...] accommodate multiple helpers" is specifically tracked in and resolved by .
Change:
certainty that the inner traffic is congestion-controlled. If a client or UDP proxy with a connection containing a UDP proxying <del> request stream disables congestion control, it MUST NOT signal ECN support on that connection.  That is, it MUST mark all IP headers with the Not-ECT codepoint.  It MAY continue to report ECN feedback via ACK_ECN frames, as the peer may not have disabled congestion control. </del> <ins> request stream disables congestion control, it MUST NOT signal Explicit Congestion Notification (ECN) ECN support on that connection.  That is, it MUST mark all IP headers with the Not-ECT codepoint.  It MAY continue to report ECN feedback via QUIC ACK_ECN frames or the TCP "ECE" bit, as the peer may not have disabled congestion control. </ins> When the protocol running over UDP that is being proxied uses loss recovery (e.g., QUIC), and the underlying HTTP connection runs over

Discussion:
From AD Review: Expand the acronym and add a (normative!) reference.
I'm going to mark this editorial since it's just clarifying what ECN is, and I don't believe we've had any confusion on that point among working group members.
The second commit explicitly mentions the TCP ECN feedback mechanism, for completeness. And yes, this is editorial.
Change:
The "epoch" field increments by one for each GroupOperation that is processed <del> The "transcript" is updated by a GroupOperation message "operation" by appending "operation" to "transcript" </del> <ins> The "transcript_hash" is updated by a GroupOperation message "operation" in the following way: When a new one-member group is created (which requires no GroupOperation), the "transcript_hash" field is set to an all-zero vector of length Hash.length. </ins> 5.6.

Discussion:
There is no reason for the members of a conversation to keep the whole history of group operations, but they should agree on it.
Change:
set long enough to also allow for short idle time during a valid transmission. <del> RFC4787 requires a timeout that is not less than 2 minutes for most UDP traffic.  However, in practice, timers are sometimes lower, in the range of 30 to 60 seconds.  In contrast, RFC5382 recommends a timeout of more than 2 hours for TCP, given that TCP is a connection- oriented protocol with well- defined closure semantics. Even though QUIC has explicitly been designed to tolerate NAT rebindings, decreasing the NAT timeout is not recommended, as it may negatively impact application performance or incentivize endpoints to send very frequent keep-alive packets.  Instead it is recommended, even when lower timers are used for other UDP traffic, to use a timer of at least two minutes for QUIC traffic. </del> <ins> RFC4787 requires a network state timeout that is not less than 2 minutes for most UDP traffic.  However, in practice, a QUIC endpoint can experience lower timeouts, in the range of 30 to 60 seconds. In contrast, RFC5382 recommends a state timeout of more than 2 hours for TCP, given that TCP is a connection-oriented protocol with well- defined closure semantics.  Even though QUIC has explicitly been designed to tolerate NAT rebindings, decreasing the NAT timeout is not recommended, as it may negatively impact application performance or incentivize endpoints to send very frequent keep-alive packets. The recommendation is therefore that, even when lower state timeouts are used for other UDP traffic, a state timeout of at least two minutes ought to be used for QUIC traffic. </ins> If state is removed too early, this could lead to black-holing of incoming packets after a short idle period.  To detect this

Discussion:
This is an attempt to clearly say what the problem is with NAT state timeout and what is a recommended approach.
As this is advice for network operators and middlebox vendors, this reads to me as permission to use a lower timeout. I think that it still makes sense to maintain the recommendation in RFC 4787. The advice for applications (don't rely on 2 minutes) still applies, but a 2 minute recommendation is worth sticking to.
I thought the text is pretty clear in saying that a bit later: I would rather want to keep this part because the message really is: yes we know these too short timers are implemented for UDP but please, please use at least 2 minutes for QUIC. Maybe removing some paragraph breaks would make it clearer that these parts belong together? Also this part got now edited quite extensively, so I rather not change it again...
Each of the sentences looks fine to me, but together I also have a hard time seeing the recommendation v. current experience. Here is a proposal: .
This is better. With Mirja's suggestion.
Change:
their definition.  When encoding a "static vector", its length prefix is omitted. <ins> In addition to the static vectors implied by various template elements, "Extension.extension_data" is always static in cTLS if the extension is any type listed in Section 4.2 of RFC8446 except "padding".  cTLS implementations MUST be able to parse any of these extensions that the other party is permitted to send, but no other support is required. </ins> For example, suppose that the cTLS template is: Then, the following structure:

Discussion:
NAME Ping. This is the last thing blocking a refreshed cTLS draft.
Just missed this. LGTM
Change:
The QUIC Transport Protocol RFC9000 provides a secure, multiplexed connection for transmitting reliable streams of application data. <del> Reliability within QUIC is performed on a per-stream basis, so some frame types are not eligible for retransmission. </del> <ins> QUIC uses various frame types to transmit data within packets, and each frame type defines whether or not the data it contains will be retransmitted.  Streams of reliable application data are sent using STREAM frames. </ins> Some applications, particularly those that need to transmit real-time data, prefer to transmit data unreliably.  In the past, these

Discussion:
In the introduction, it says "Reliability within QUIC is performed on a per-stream basis, so some frame types are not eligible for retransmission" Is it really per-stream? Some frames are retransmitted even though they aren't associated with a stream. Really, the detection mechanism is packet-based, the retransmission decision is made on a per-frame basis, and for stream-specific frames there is the added consideration of stream state (i.e. do not resend if reset) I suggest replacing the sentence above with "Some QUIC frame types are not eligible for retransmission."
Do you have examples? It's common for an action to be attempted again, but not for the frame to be retransmitted. That's not quite right. QUIC does not retransmit stream frames, it instead looks at stream state to see what data needs to be retransmitted - there's an important conceptual difference there: let's say you had 100 bytes left in your packet and therefore sent 98 bytes of stream data and that got lost but now you have a full 1200 payload available, you shouldn't retransmit that 100 byte STREAM frame and instead create a new STREAM frame with as much data as you want to send. states:
So I agree with everything you're saying factually; this is an editorial, semantic gripe about what it means that reliability is on a per-stream basis and what it means that a frame is retransmitted. It's true that, for example, MAX_DATA frames aren't resent verbatim, but RFC 9000 addresses them in a section called "retransmission of information" due to the common-sense meaning of the term. What are you trying to communicate by saying that reliability is "on a per-stream basis"?
I agree that this sentence is confusing. Perhaps we just remove it entirely? NAME NAME thoughts?
NAME NAME made a proposal with
LGTM modulo one commentLGTM
Change:
The term "verification", when used, is usually synonym for "validation". <ins> A security-aware recursive name server, security-aware resolver, or security-aware stub resolver that is applying at least one of the definitions of validation (above), as appropriate to the resolution context.  For the same reason that the generic term "resolver" is sometimes ambiguous and needs to be evaluated in context (see dns-servers-and-clients), "validating resolver" is a context-sensitive term. </ins> DNSSEC keys that "only sign the apex DNSKEY RRset in a zone."(Quoted from RFC6781, Section 3.1)

Discussion:
…st label', and remove dbound. Fix affiliation. I suggest these before publication. This addresses issue 18.
Yep, these all seem great.
Change:
4. <del> External PSK authentication in TLS allows endpoints to authenticate connections using previously established keys.  These keys do not provide protection of endpoint identities (see endpoint-privacy), nor do they provide non-repudiation (one endpoint in a connection can deny the conversation).  Protection of endpoint identities and protection against an endpoint denying the conversation are possible when a fresh TLS handshake is performed. </del> <ins> When using external PSK authentication, the use of previously established PSKs allows TLS endpoints to authenticate the endpoint identities.  However, these keys do not provide privacy protection of endpoint identities (see endpoint-privacy), nor do they provide non- repudiation (one endpoint in a connection can deny the conversation). Protection of endpoint identities and protection against an endpoint denying the conversation are possible only when a fresh TLS handshake that authenticates the endpoints with certificates is performed. </ins> PSK authentication security implicitly assumes one fundamental property: each PSK is known to exactly one client and one server, and

Discussion:
This deals with many comments from the AD Evaluation. The comment on section 6.1 still needs to be resolved, and the NITS need to be addressed.
Chris's suggestions generally seem reasonable
Change:
Remove or reorder codecs (m=) <del> The following parameters may be controlled by constraints passed into </del> <ins> The following parameters may be controlled by options passed into </ins> createOffer/createAnswer.  As an open issue, these changes may also be be performed by manipulating the SDP returned from createOffer/ createAnswer, as indicated above, as long as the capabilities of the

Discussion:
Also fix a bunch of TODOs and a few places where text was obsolete. NAME NAME
I suspect we might need to say a bit more in this section this but this all looks good good so LGTM
Change:
is encoded here. contains the recipient information.  The field can have one of <del> three values.  * An array of COSE_Encrypt elements, one for each recipient.  * A single COSE_Element, encoded as an extension to the containing COSE_element, for a single recipient.  Single recipients can be encoded either this way or as a single array element.  * A 'null' value if there are no recipients. </del> <ins> three types: An array of COSE_Encrypt elements, one for each recipient. A single COSE_Element, encoded as an extension to the containing COSE_element, for a single recipient.  Single recipients can be encoded either this way or as a single array element. A 'null' value if there are no recipients. </ins> 4.1.

Discussion:
Add new tables to the end of the document about parameters which talk about types and possible column for integer indexes in the future
Change:
In order to prevent tampering by version-unaware middleboxes, Initial packets are protected with connection- and version-specific keys (Initial keys) as described in QUIC-TLS.  This protection does not <del> provide confidentiality or integrity against on-path attackers, but provides some level of protection against off-path attackers. </del> <ins> provide confidentiality or integrity against attackers that can observe packets, but provides some level of protection against attackers that cannot observe packets. </ins> The client and server use the Initial packet type for any packet that contains an initial cryptographic handshake message.  This includes

Discussion:
We weren't being consistent. This should help.
NAME said:
The first here is in the process of being addressed, see . I agree regarding "strong", but also agree regarding what to do about it. My proposal is to let close this issue.
NAME said:
Proposed resolution is URL
This is an improvement. Thanks.
Change:
these requests.  The authorization object is implicitly tied to the account key used to sign the request. <del> When a client receives an order from the server with "pending" entry in the authorizations array, it downloads the authorization resource by sending a GET request to the indicated URL.  If the client initiates authorization using a request to the new authorization resource, it will have already recevied the pending authorization object in the response to that request. </del> <ins> When a client receives an order from the server it downloads the authorization resource by sending a GET request to the indicated URL. If the client initiates authorization using a request to the new authorization resource, it will have already recevied the pending authorization object in the response to that request. </ins> 6.5.1.

Discussion:
As discussed at IETF 97, this PR removes the "requirements" abstraction, and changes the "requirements" field in an application/order object to be an "authorizations" field. This is a replacement for .
Let's Encrypt tell me that they have had a few reports of buggy clients creating enough pending authorizations to saturate their rate limits, so they need a way for clients to clear these out. These clients are also not keeping around authorization URLs, so they can't just go them. My proposed solution would be to re-add the "authorizations" field to the account object, which got lost in the refactor in or so. Together with deactivation, enabling clients to enumerate authorization URLs would solve this problem. You could also envision a more direct solution, offering an endpoint that just deletes all pending authorizations for a client or client+identifier.
This is definitely too specific to these buggy clients. For the flow, the list of orders is sufficient. It's true that technically you can create authorizations through a separate, optional, flow. But Let's Encrypt has no plans to implement that flow, because other CAs have said they cannot / would not implement it, so Let's Encrypt implementing it would split the market. I'm inclined to say let's not complicate the protocol, and hypothetical clients that want to do the flow with some hypothetical server need to keep proper track of their authzs. Also, I think the particular issue with hitting limits for pending authzs can be solved in several ways without modifying the protocol.
If is merged, I would expect that a reasonable ACME server supporting new-authz would return an exiting authz, instead of giving a rate limit error. Or return existing authz from the beginning.
Closing as a result of WG decision at IETF 98
Change:
As a result, the receiver of a conceptual message containing a timestamp cannot directly compare it to its own clock or timestamps. <del> Thus we use a suffix (a for Attester, v for verifier, and r for </del> <ins> Thus we use a suffix ("a" for Attester, "v" for Verifier, and "r" for </ins> Relying Party) on the IDs below indicating which clock generated them, since times from different clocks cannot be compared.  Only the delta between two events from the sender can be used by the receiver.

Discussion:
This pull request puts _X on all time points. Please review for accuracy.
I am neutral/okay with consistently adding suffixes to every event label
Change:
1. <del> Elliptic Curve Cryptography (ECC) has emerged as an attractive public-key cryptosystem, in particular for mobile (i.e., wireless) environments.  Compared to currently prevalent cryptosystems such as RSA, ECC offers equivalent security with smaller key sizes.  This is illustrated in the following table, based on Lenstra_Verheul, which gives approximate comparable key sizes for symmetric- and asymmetric- key cryptosystems based on the best-known algorithms for attacking them. Smaller key sizes result in savings for power, memory, bandwidth, and computational cost that make ECC especially attractive for constrained environments. </del> This document describes additions to TLS to support ECC, applicable to TLS versions 1.0 RFC2246, 1.1 RFC4346, and 1.2 RFC5246.  The use of ECC in TLS 1.3 is defined in I-D.ietf-tls-tls13, and is explicitly

Discussion:
Removed two paragraphs and a table full of motivation about why ECC is great. In 2016 this is no longer needed. ECC is already mainstream.
+1