jiebi/CodeConvo huggingface dataset:
Change:
application server by a user agent.  The push message is included in the body of the request. <del> A push service MAY generate a 413 (Payload Too Large) status code in response to requests that include an entity body that is too large. Push services MUST NOT generate a 413 status code in responses to an entity body that is 4k (4096 bytes) or less in size. </del> <ins> A push service MAY return a 429 (Too Many Requests) status code RFC6585 when an application server has exceeded its rate limit for push message delivery to a push resource.  The push service SHOULD also include a Retry-After header RFC7231 to indicate how long the application server is requested to wait before it makes another request to the push resource. A push service MAY return a 413 (Payload Too Large) status code RFC7231 in response to requests that include an entity body that is too large.  Push services MUST NOT return a 413 status code in responses to an entity body that is 4k (4096 bytes) or less in size. </ins> 5.1.

Discussion:
Looks good aside from that one thing, the resolution of which I'll leave to your discretion.
As discussed in cc NAME The earlier proposal from JR - URL - was to include a reference to 429 with Retry-Header: URL The 429 status code indicates that the user has sent too many requests in a given amount of time ("rate limiting"). The response representations SHOULD include details explaining the condition, and MAY include a Retry-After header indicating how long to wait before making a new request. For example: HTTP/1.1 429 Too Many Requests Content-Type: text/html Retry-After: 3600 Would this address your requirements? ...Brian
Change:
(2001:db8:3456::b), scoped to SCTP.  The client can send and receive SCTP IP packets to the remote host. <del> 8.3. </del> <ins> 8.4. </ins> The following example shows a setup where a client is proxying UDP packets through an IP proxy in order to control connection

Discussion:
This is an editorial PR based on comments made by Chris Wood during his shepherd review of the document.
Change:
and to Alice's identity.  In this case, Alice has provided an identity assertion and so Bob's browser contacts Alice's identity provider (again, this is done in a generic way so the browser has no <del> specific knowledge of the IdP) to verify the assertion.  This allows the browser to display a trusted element in the browser chrome </del> <ins> specific knowledge of the IdP) to verify the assertion.  It is also possible to have IdPs with which the browser has a specific trustrelationship, as described in sec.trust-relationships.  This allows the browser to display a trusted element in the browser chrome </ins> indicating that a call is coming in from Alice.  If Alice is in Bob's address book, then this interface might also include her real name, a picture, etc.  The calling site will also provide some user interface

Discussion:
We'll leave this for later.
What's generic is the protocol, but if you have a third party IdP, trust has to be configured. Say that and point to 7.1
See also 5.1.3. Forward reference to 7.1
Change:
In a federated environment, version negotiation is more critical, to avoid forcing a downgrade attack by malicious 3rd party delivery services.  The negotiation could either be done in the <del> UserInitKeyBundle or in a separate handshake message. </del> <ins> ClientInitKeyBundle or in a separate handshake message. </ins> 7.

Discussion:
Addressed SV's comments Remove the client fanout concept (because of TreeKEM's handshake ordering requirements) Rename UserInitKeys to ClientInitKeys Minor editorial edits
drop client fanout specify why (policy enforcement, metadata protection) incorporated comments from SV check if it is necessary to define server-to-server message formats only one domain is responsible for a group
I'm very interested in the details of this, but was unable to attend the interim meeting. Does this mean that we are explicitly ruling out client fanout entirely? What metadata are we trying to protect here? You could in theory protect all the metadata with client fanout over Tor for example. Does domain here mean domain name? Why is that relevant? (I'd expect MLS to be independent of DNS) The kind of federated delivery service I'm hoping to be able to use with MLS is logically an append only list of messages published by each member. Where each member can read any other members queue and pull messages they don't have into their own queue (they push their own messages to their own queue only). This allows for diverse P2P topologies, and bandwidth efficient routing. This would be compatible with both and .
TreeKEM has the requirement of total ordering of handshake messages which doesn't work with client fanout. Therefore we drop the idea of client fanout until we have a better proposal on how to solve this. is more conceptual, it doesn't have to be an actual domain name.
Addressed in .
Change:
"[^]", which according to this grammar would parse as a positive character class containing the single character "^". <del> This is essentially XSD regexp without character class subtraction and multi-character escapes such as "s", "S", and "w". </del> <ins> This is essentially XSD regexp without character class subtraction, without multi-character escapes such as "s", "S", and "w", and without Unicode blocks. </ins> An I-Regexp implementation MUST be a complete implementation of this limited subset.  In particular, full Unicode support is REQUIRED; the

Discussion:
I think it is better to support script names than block names for and . Unicode block names are not supported by regexp implementations an interoperable way. Block names as specified in URL allow ASCII alpha-numerics, hyphens and spec. Unicode says these names are supposed to be matched using URL (which says to ignore case, whitespace, underscore, hyphens, and any initial prefix string "is"). But implementations don't do this and compare names using a wide variety of different rules (as partially described by "Unicode blocks" section of https://www.regular-URL). Usage of block names can easily be replaced by ranges. Furthermore, block names are not covered by the Unicode stability policy. Scripts names don't have such a wide range of characters (there are also 4-char short script names) and scripts are generally preferable to blocks for regexps as explained here: URL Script is in the minimal list of properties that Unicode requires but block is not URL
Thank you! Very useful input. We are having an interim meeting (per web conference) of the JSONPath WG at this very moment; I'll look at this later today.
I just looked again at XSD and see that sadly it doesn't support scripts in . Every major regex implementation that I am aware of that does Unicode and does support scripts (Go, PCRE, Java, C#, Ruby). So if XSD compatibility is crucial (not sure why it would be at this point), my suggestion would be just to get rid of blocks. One could argue that supporting only the general category in is consistent with not supporting character set intersection/difference: once you have multiple things (e.g. script and category), you really need to be able to have intersections/differences of them.
Change:
During pre-establishment the application specifies the Endpoints to be used for communication as well as its preferences via Selection Properties and, if desired, also Connection Properties.  Generally, <del> Connection Properties should be configured as early as possible, as they may serve as input to decisions that are made by the implementation (the Capacity Profile may guide usage of a protocol offering scavenger-type congestion control, for example).  In the remainder of this document, we only refer to Selection Properties because they are the more typical case and have to be handled by all implementations. The implementation stores these objects and properties as part of the </del> <ins> Connection Properties should be configured as early as possible, because they can serve as input to decisions that are made by the implementation (e.g., the Capacity Profile can guide usage of a protocol offering scavenger-type congestion control). The implementation stores these properties as a part of the </ins> Preconnection object for use during connection establishment.  For Selection Properties that are not provided by the application, the implementation must use the default values specified in the Transport

Discussion:
Implementation draft sec 3: "In the remainder of this document, we only refer to Selection Properties because they are the more typical case and have to be handled by all implementations. The implementation stores these objects and properties as part of the Preconnection object for use during connection establishment." I don't understand these two sentences. In the API doc it seems we use the term Transport Properties for both selection and configuration properties. Why do we only talk about selection properties in this doc? Also in the next sentence what's meant by "objects and properties"? I guess the object(s) that hold the properties? But then this is saying twice the same and we should only use one term to avoid confusion.
Also in the next section 3.1: "Once an application specifies its Transport Parameters" I guess that should be Transport Properties instead? Maybe it would also be good to say here "Once an application specifies its Transport Properties and Preference (required, prefer, ignore, avoid, prohibit - see section 5.2. of [draft-taps-arch])".
I agree; I suspect that this is ancient leftover text that should be cleaned up.
Some small changes suggested
Change:
updated once the key lifetime expires. In the current version of DTLS, the IP address and port of the peer <del> is used to identify the DTLS association.  Unfortunately, in some </del> <ins> are used to identify the DTLS association.  Unfortunately, in some </ins> cases, such as NAT rebinding, these values are insufficient.  This is <del> a particular issue in the Internet of Things when the device needs to enter extended sleep periods to increase the battery lifetime and is therefore subject to rebinding.  This leads to connection failure, with the resulting cost of a new handshake. </del> <ins> a particular issue in the Internet of Things when devices enter extended sleep periods to increase their battery lifetime.  The NAT rebinding leads to connection failure, with the resulting cost of a new handshake. </ins> This document defines an extension to DTLS to add a connection ID to <del> each DTLS record.  The presence of the connection ID is negotiated via a DTLS extension.  It also defines a DTLS 1.3 post-handshake message to change connection ids. </del> <ins> the DTLS record layer.  The presence of the connection ID is negotiated via a DTLS extension. </ins> 2.

Discussion:
Remove 1.3 references (based on Hannes's PR ); Protect CID; Initial sketch for explicit marking of CID records using ad hoc CTs.
I also do not understand that
Sorry, you're right. It needs to be in the MAC, but not the key derivation
I don't think we need to include the CID in the MAC since the CID is just the key name. In regular DTLS the 5 tuple is the key name and we don't include it in the MAC calculation either. If someone fakes a packet and places a wrong CID in there then they MAC will just fail since either (a) the wrong key will be looked up or (b) no key is found at all. In either case there is no issue.
Change:
to be compatible with version B and for B not to be compatible with A.  This could happen for example if version B is a strict superset of version A: if version A includes the concept of streams and STREAM <del> frames, and version B includes the concepts of streams and tubes along with STREAM and TUBE frames, then A would be compatible with B but B would not be compatible with A. </del> <ins> frames, and version B includes the concept of streams and the hypothetical concept of tubes along with STREAM and TUBE frames, then A would be compatible with B but B would not be compatible with A. </ins> Note that version compatibility does not mean that every single possible instance of a first flight will succeed in conversion to the

Discussion:
Instead of creating separate issues for each minor editorial comments I will put them all in this issue - I am not a fan of having normative language in the definitions. I feel those normative languages are out of context and hard to reason. It is the case for MSL definition. I would suggest that besides definition, we have some description where MSL is used and put the recommended value there. What is the difference between the initial version and original version ? if there is none why do we need to use two different call sign for the same thing? What is Tubes? we need to explain it. otherwise use other example.
I personally disagree. Mentioning the recommended value when defining the term makes it easier to understand and implement. Agreed, there was only one mention of "initial version" so I replaced that with original in It's a hypothetical example. That doesn't make it unhelpful.
:-) hmm, the example makes little sense if one does not understand the terms used in the example. If "Tube" is a hypothetical term here, then let's just mention that.
There was no reasoning, this was pulled out of a hat just like the original MSL from RFC 793. Can you send us a PR describing the reasoning you'd like to see added? Fair enough, I've added the word "hypothetical" to PR
Change:
carrying the "HpkePublicKey" and KEM identifier corresponding to the server, clients compute an HPKE encryption context as follows: <del> Note that the HPKE algorithm identifiers are those which match the client's chosen preference from "ECHConfig.cipher_suites". </del> <ins> Note that the HPKE functions Deserialize and SetupBaseS are those which match "ECHConfig.kem_id" and the client's chosen preference from "ECHConfig.cipher_suites". </ins> The client then generates a ClientHelloInner value.  In addition to the normal values, ClientHelloInner MUST also contain:

Discussion:
draft-irtf-cfrg-hpke-05 switched from Unmarshal to Deserialize. Switch ECH to match. See .
Cause I'm quite new to ECH, I'm little bit confused when reading this draft. So I want to ask some questions... Paragraph 7.1. Sending an encrypted ClientHello says... Q1. Is 'Unmarshal()' above equal to general meaning of unmarshalling -get public key from ECHConfig structure- ? Q2. I think 'hrr' in the fourth line is the abbreviation of 'HelloRetryRequest', is it correct? If so, could you add some explanation about that?
Q1: It should be defined in the HPKE draft, though it looks like the HPKE draft has since renamed it and it should probably say Deserialize now. URL Q2: hrr is HelloRetryRequest, yes. The use of the key is described later on in the HelloRetryRequest section. URL
The first line appears to be pseudocode for "interpret as a public key for the KEM algorithm identified by . IMO we should get rid of this pseudocode and say what is. NAME beat me to it!
Oh, it was Deserialize()... thanks!
Closing as resolved.
Change:
5.1. While any other E2EE KMS can be used with SFrame, there is a big <del> advantage if it is used with MLSARCH which natively supports very large groups efficiently.  When MLSPROTO is used, the endpoints keys (AKA Application secret) can be used directly for SFrame without the need to exchange separate key material.  The application secret is rotated automatically by MLSPROTO when group membership changes. </del> <ins> advantage if it is used with I-D.ietf-mls-architecture which natively supports very large groups efficiently.  When I-D.ietf-mls-protocol is used, the endpoints keys (AKA Application secret) can be used directly for SFrame without the need to exchange separate key material.  The application secret is rotated automatically by I- D.ietf-mls-protocol when group membership changes. </ins> 6.

Discussion:
This PR revises the encryption procedures in a few ways: Ciphersuites for AES-GCM are now included The combination of AES-CM and SHA2 is spelled out, including an AAD length prefix to guard against confusion attacks We use the RFC 5116 AEAD interface (in particular, no separate auth tag) ... and as a result the tag truncation is internal to the AES-CM+SHA combination SFrame encryption now includes the encoded header as AAD Depends on
Change:
value in more than one report if the leader responds with status 200 and an empty body. <del> The leader responds to requests with out-of-date "HpkeConfig.id" values, indicated by "EncryptedInputShare.config_id", with status 400 and an error of type 'outdatedConfig'.  Clients SHOULD invalidate any cached aggregator "HpkeConfig" and retry with a freshly generated Report.  If this retried report does not succeed, clients MUST abort and discontinue retrying. </del> <ins> The leader responds to requests whose leader encrypted input share uses an out-of-date "HpkeConfig.id" value, indicated by "HpkeCiphertext.config_id", with status 400 and an error of type 'outdatedConfig'.  Clients SHOULD invalidate any cached aggregator "HpkeConfig" and retry with a freshly generated Report.  If this retried report does not succeed, clients MUST abort and discontinue retrying. </ins> The leader MUST ignore any report whose nonce contains a timestamp that falls in a batch interval for which it has received at least one

Discussion:
When constructing HPKE contexts, we now include both sender and recipient roles, and the application label also includes the PPM version. I used here because we recently submitted draft-01 of and so the next submitted draft, which would include this change, will be . I also backported the definition of struct HpkeCiphertext from the interop PR because it makes everything tidier and should be non-controversial we can get a head-start on bringing those changes into main.
Fixed, thank you! I also rewrote the relevant paragraph to acknowledge that there's two encrypted input shares and that the leader should examine the HPKE config ID of the one intended for itself. Further, I recall NAME pointing out to me that should this draft get adopted by the WG, we'll reset to something like , so is the more appropriate application label.
There's one more instance of that needs to be changed to . Otherwise, LGTM.
Change:
different goal.  For instance, application-level encryption may be used for business purposes, such as avoiding piracy or enforcing geographic restrictions on playback, while transport-layer encryption <del> may be used to prevent media steam manipulation or to protect </del> <ins> may be used to prevent media stream manipulation or to protect </ins> manifests. This document does not take a position on whether those goals are

Discussion:
NAME and NAME - note that John's last comment hasn't been addressed in this PR yet.
Added a single comment for the subsequent sentence where you made a change.
NAME and NAME - Most of John's comments are nits and easy to resolve, but there are two that need thought. First, this comment So, let's think about this. We're looking at two, related statements, I'm wondering if it is correct to say Streaming is continuous transmission of media from a server to a client and its simultaneous consumption by the client. I'll make that change, and see if anyone objects. Second, this comment (followed by some excellent guesses about recourse) I read this text as saying that your streaming service is less complex if you have an intermediary that is modifying manifests during peak hours, than if you add that functionality to media servers that are already complex, especially if intermediaries are making a few well-understood changes to the manifests that only need to work for media players downstream on a given path, while a media server would have to maintain multiple versions of the manifests that that, in total, cover every possible modification that any intermediary would have done, and then figure out how to send each media player the appropriate version of the manifest for that media player. If that's what other people think, we can say that. If it's not what other people think, we need to talk.
The first one works for me ("Streaming is a continuous transmission of media"). For the second, yes, that was my intent. It is possible to deliver different manifests to different clients. Doing so based on some kind of aggregated estimate of the path load (possibly including peak hours/time of day, etc.) can do roughly the same job of reducing network load that was previously done with on-path edits to unencrypted manifests, but it adds a lot of complexity to the media service, which was previously instead taken on by (some of) the networks with a problem.
lgtm
Change:
operators of ACME-based CAs will need to keep in mind when configuring their services.  For example: <del> It is advisable to perform DNS queries via TCP to mitigate DNS forgery attacks over UDP </del> <ins> 10.1. </ins> <del> [[ TODO: Other operational considerations ]] </del> <ins> As noted above, DNS forgery attacks against the ACME server can result in the server making incorrect decisions about domain control and thus mis-issuing certificates.  Servers SHOULD verify DNSSEC when it is available for a domain.  When DNSSEC is not available, servers SHOULD perform DNS queries over TCP, which provides better resistance to some forgery attacks than DNS over UDP. </ins> <del> 10.1. </del> <ins> 10.2. </ins> In many cases, TLS-based services are deployed on hosted platforms that use the Server Name Indication (SNI) TLS extension to

Discussion:
Server side request forgery (SSRF) is possible through ACME when using http-01 because an attacker can use HTTP 3xx redirects to make the ACME verifier server perform an HTTP GET of any URL. Additionally, Boulder helpfully includes (part) of the HTTP body in the detail field of Unauthorized errors. In theory, an HTTP GET of any URL is idempotent and won't actually affect anything. But, if the ACME server returns any part of the HTTP body in error messages (like Boulder does), an attacker could potentially read sensitive data from internal servers. Typical targets for SSRF would be metadata services (like 169.254.169.254 in AWS or OpenStack), any not publicly exposed HTTP interface of the server's stack (like the HTTP API of the RabbitMQ management plugin), or any other internal HTTP server on the server's private network. Perhaps the IETF ACME protocol spec should acknowledge SSRF in its Security Considerations? One recommendation could be to not allow connections to internal network addresses. However, if someone wanted to use ACME for a private intranet CA, correct firewalling like that is much harder. The spec could also discourage including the HTTP body in an Unauthorized error's detail field. Or at least don't include the HTTP body if a redirect was followed. Also, this is mostly mitigated by the actual implementation of Let's Encrypt and Boulder. Notably, only 128 characters (maxResponseSize) of the HTTP body are . And it doesn't seem possible to get Let's Encrypt to access HTTP servers on any port other than 80 or 443, even with a port number specified in the redirect URL, which limits what an attacker could access. (I reported this privately to EMAIL before creating this GitHub issue. This is not an issue for Let's Encrypt.)
Thanks for reporting! Can you post this to the EMAIL mailing list for further discusion? Not everyone who participates in the WG follows the GitHub repo.