jiebi/CodeConvo huggingface dataset:
Change:
[[OPEN ISSUE: Merge in DTLS Cookies?]] <del> The group which the client MUST use for its new ClientHello. </del> <ins> The mutually supported group the server intends to negotiate and is requesting a retried ClientHello/KeyShare for. </ins> <del> The "server_version", "cipher_suite" and "extensions" fields have the same meanings as their corresponding values in the ServerHello.  The </del> <ins> The server_version, cipher_suite, and extensions fields have the same meanings as their corresponding values in the ServerHello.  The </ins> server SHOULD send only the extensions necessary for the client to <del> generate a correct ClientHello pair. </del> <ins> generate a correct ClientHello pair.  As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions that were not first offered by the client in its ClientHello. </ins> Upon receipt of a HelloRetryRequest, the client MUST first verify <del> that the "selected_group" field corresponds to a group which was </del> <ins> that the selected_group field corresponds to a group which was </ins> provided in the "supported_groups" extension in the original <del> ClientHello.  It MUST then verify that the "selected_group" field does not correspond to a group which was provided in the "key_share" </del> <ins> ClientHello.  It MUST then verify that the selected_group field does not correspond to a group which was provided in the "key_share" </ins> extension in the original ClientHello.  If either of these checks fails, then the client MUST abort the handshake with a fatal "handshake_failure" alert.  Clients SHOULD also abort with

Discussion:
NAME You addressed the main ambiguity in URL . This fixes a few remaining issues. An itemized list: "handshakefailure" alert is fatal note it must be appended, not just "used", in the selectedgroup description (just using instead of appending creates a downgrade attack due to lack of authentication for this message, as discussed previously) clean up styling of variable names; the dominant style uses no quotes around variable names, but quotes around enum values (granted, this may not be the ideal style, but it is more or less consistently the case elsewhere in the document) note that the same rule as ServerHello applies: no extensions the client did not offer first update text to deal with possibility of omitted extension minor wording simplification specify error to use if "MUST" fails (could be a "SHOULD" error, here)
NAME Repushed commit with changes for comments. Changed description to not say used/amended, but rather describe what it actually represents directly: the group the server intends to negotiate and is requesting a retry for. (we don't need duplicated MUSTs here, and stating its actual meaning more explicitly is preferable) Changed text wrt selected group as suggested.
Rebased on top of PR (which still merges cleanly onto master, as of this moment; this does too) to avoid flip-flopping again on the omit vs. empty KeyShare for retry request.
Change:
The content to be signed This structure is intended to prevent an attack on previous versions <del> of previous versions of TLS in which the ServerKeyExchange format meant that attackers could obtain a signature of a message with a chosen, 32-byte prefix.  The initial 64 byte pad clears that prefix. </del> <ins> of TLS in which the ServerKeyExchange format meant that attackers could obtain a signature of a message with a chosen, 32-byte prefix. The initial 64 byte pad clears that prefix. </ins> The context string for a server signature is "TLS 1.3, server CertificateVerify" and for a client signature is "TLS 1.3, client

Discussion:
I think this is a typo. But I'm not sure since I'm not a native English speaker. Please check it out.
Change:
a host which only functions as an ACME server could place the directory under the path "/". <del> The object MAY additionally contain a key "meta".  If present, it </del> <ins> The object MAY additionally contain a field "meta".  If present, it </ins> MUST be a JSON object; each field in the object is an item of metadata relating to the service provided by the ACME server.

Discussion:
In the JSON , could be called a "field name" or a "key." We use both in this document, but we should consolidate one one. I think "field name" is better (and NAME agrees). In part this avoids any ambiguity with cryptographic keys.
Change:
holder) All of the challenges above that require an out-of-band query by the <del> server have a binding to the account private key, such that the only the account private key holder can successfully respond to the validation query: </del> <ins> server have a binding to the account private key, such that only the account private key holder can successfully respond to the validation query: </ins> HTTP: The value provided in the validation request is signed by the account private key.

Discussion:
editorial change
These LGTM as editorial. I note that the inclusion of "revoked" in URL is on the edge, but I think it was intended and could be merged as a result.
I did think the mentioned change might be an edge case, too, but came to the same conclusion. Happy to be of any help.
LGTM as well. Thanks NAME
Change:
before cryptographically validating the enclosed record(s) but instead perform a return routability check. <del> The newly introduced return_routability_check message contains a </del> <ins> The newly introduced "return_routability_check" message contains a </ins> cookie.  The cookie is a 8-byte field containing arbitrary data. <del> The return_routability_check message MUST be authenticated and </del> <ins> The "return_routability_check" message MUST be authenticated and </ins> encrypted using the currently active security context. The receiver that observes the peer's address and or port update MUST

Discussion:
Use a new extension type instead.
Yes, if tls-flags are not usable for DTLS 1.2, then go with this.
We'd like to use to negotiate RRC. At the moment, the document seems to be defined for (D)TLS 1.3 only, but the reason why the same scheme would not be applicable to 1.2 are not fully clear. For now (-01), optimistically, we are using it in a version agnostic fashion, hoping that eventually that will be the case. Achim has opened an . This issue is for tracking on the RRC side.
Change:
UDP Destination Port. <ins> Use/non-use of UDP checksum. </ins> This information MUST be provisioned per DetNet flow via configuration, e.g., via the controller RFC8655 or management plane. <ins> Not using the UDP checksum has to be evaluated on a case-by-case basis for a given network scenario based on the exception criteria's defined in RFC7510, particularly when IPv6 is used. </ins> It is the responsibility of the DetNet controller plane to properly provision both flow identification information and the flow specific

Discussion:
In chapter 5. Management and Control Information Summary one more bullet added + clarification text to the paragraph after the list.
Change:
the "keyid" parameter of the encrypted content coding header.  The uncompressed point form defined in X9.62 (that is, a 65 octet sequence that starts with a 0x04 octet) forms the entirety of the <del> "keyid". </del> <ins> "keyid".  Note that this means that the "keyid" parameter will not be valid UTF-8 as recommended in RFC8188. </ins> A push service is not required to support more than 4096 octets of payload body (see Section 7.2 of RFC8030).  Absent header (86

Discussion:
This is the best that I can do for this one..
I think this is as good as it gets.
Change:
according to this encoding, then the verifier MUST reject the JWS as malformed. <del> 6.6. </del> <ins> 6.5. </ins> Creation of resources can be rate limited by ACME servers to ensure fair usage and prevent abuse.  Once the rate limit is exceeded, the

Discussion:
This is my attempt to find a quick way out of this content-type mess. Replaces and
This also looks good to me, thanks for drafting it!
+1 - This looks like a low complexity path forward that resolves ambiguity.
Change:
somewhat challenging from a QoS perspective. Empirical Examples: Packet Dropping is a very common form of <del> technical prevention and lends itself to accurate detection given the unique nature of the time-out requests it leaves in its wake.  The Great Firewall of China uses packet dropping as one of its primary mechanisms of technical censorship Ensafi-2013.  Iran also uses Packet Dropping as the mechanisms for throttling SSH Aryan-2012. </del> <ins> technical interference and lends itself to accurate detection given the unique nature of the time-out requests it leaves in its wake. The Great Firewall of China uses packet dropping as one of its primary mechanisms of technical censorship Ensafi-2013.  Iran also uses Packet Dropping as the mechanisms for throttling SSH Aryan-2012. </ins> These are but two examples of a ubiquitous censorship practice. 4.2.

Discussion:
…nce. defines censorship. fixes definition of identification in intro.
First, one thing that isn’t clear immediately from the introduction is who/what is a “censor”. I find it a little strange, actually, to suggest that a censor performs "aggregation". Is the censor an ISP? A government? Something else? For example, a government may have loose policies about what kind of content to censor (e.g., "hate speech"). An ISP might in turn implement these loose policies in different ways. Policies can also differ across a country, etc. The other terms---identification and prevention---are similarly confusing, although I think the term "identification" isn't as problematic as its (incorrect?) definition in the introduction. "Identification is the process by which censors determine whether content is blocked" - NO. I think it is the process by which a censor might classify traffic to determine whether to block a traffic flow or now. I would suggest something like: prescription, identification, and interference.
Wondering what you think about "design, identification, and interference"? I think for the purposes of todays 20:00 ET IETF drafts deadline, I'll change the terminology throughout to match prescription, identification, and interference and I'll correct the other things mentioned here (define censor, fix definition of identification in intro).
That seems a bit more clear, indeed! Ah, I didn't realize there was a deadline of today 2000h. Not sure I can get you a pull request by then, but will try.
I'll leave this open. You by no means need to get a pull request by 20:00! I just want to do my best to make changes responsive to your feedback. I'll leave this open and you can see what I've done (I'll be working on trying to clear out issues until then), and feel free to submit changes as you think are needed.
Change:
The process of connection establishment completes when one leaf node of the tree has successfully completed negotiation with the Remote <del> Endpoint , or else all nodes of the tree have failed to connect.  The </del> <ins> Endpoint, or else all nodes of the tree have failed to connect.  The </ins> first leaf node to complete its connection is then used by the application to send and receive data.

Discussion:
Trying to address use of “remote” and "local"
The use of “remote” on its own offends me: “Some types of remote might …” could we make this “Remote Endpoint” to ease my reading? or whatever else is intended? Similarly can we change “locals” and “remote” here to something that is defined: “This can expose some or all of the candidate locals to the remote”
Remote Endpoint
Change:
for the URI MUST be https so that the User Equipment communicates with the User Portal over TLS. <ins> If the API receives a request for state that does not correspond to the requesting User Equipment, the API SHOULD deny access.  Given that the API might use the User Equipment's identifier for authentication, this requirement motivates id_recommended_hard. </ins> A caller to the API needs to be presented with evidence that the content it is receiving is for a version of the API that it supports. For an HTTP-based interaction, such as in I-D.ietf-capport-api this

Discussion:
A reviewer pointed out that we never really said that it was a desired proprety of the API that it limit access to a UE's state to itself. Add a requirement to that effect so we're explicit about that goal, and reference the identifier section that describes that it's a good property for the identity.
One thing we're not addressing here is a similar requirement on the User Portal. I feel like we should probably have one. Thoughts?
Thanks. Perhaps I'll do this in a separate PR to address
Roman writes, Martin agreed that we should do something like this in response to my question: We can add a requirement stating that the only the UE should be able to check its own state of captivity (work on the phrasing/normative text).
This sentence refers to URLs in the API blob, not the API itself. We definitely are okay with a common API URL or a guessable one. That’s an option.
Right. I'm not sure what I was thinking. NAME What about the URIs provided by the API itself? Do you have an opinion whether we should suggest that they be unguessable? One thought is that the API server and web portal could agree on an mechanism to cipher the UE's identifier, so that even if it's something possible guessable (i.e. the IP), and attacker couldn't spoof it.
Nice. I think that this is sufficient. The portal itself can use things like capability URLs to avoid needing this sort of check. (And then we're far into design and not architecture; this is nice because it talks about requirements.) If you feel motivated, you could add something, but it's tricky. The user portal doesn't need to use strong identifiers, because it can base its decisions on other things than the UE identifier. For instance, a capability URL (that is, a hard-to-guess URL) embedded in the API requires no external authentication.
Change:
4.4. <del> QUIC flow control provides a means of managing access to the limited buffers endpoints have for incoming data.  This mechanism limits the amount of data that can be in buffers in endpoints or in transit on the network.  However, there are several ways in which limits can produce conditions that can cause a connection to either perform suboptimally or deadlock. </del> <ins> QUIC flow control Section 4 of QUIC provides a means of managing access to the limited buffers endpoints have for incoming data.  This mechanism limits the amount of data that can be in buffers in endpoints or in transit on the network.  However, there are several ways in which limits can produce conditions that can cause a connection to either perform suboptimally or deadlock. </ins> Deadlocks in flow control are possible for any protocol that uses QUIC, though whether they become a problem depends on how

Discussion:
addresses
LGTM
URL should this be pointing to Section 2.2 or section 4.0 , flow control credit is described there? I also think it will be good if section 4.4 of this document points to Section 4.0 of RFC9000. specially when it talks about flow control credit updates.
I believe this reference was supposed to point to the following normative statement in 2.2: Section 4 is also relevant but there is also a pointer to section 4 at the end of section 2.2....
I don't think it is obvious here, also introducing "flow control credit" here does not help much without referencing to section 4.0 of RFC9000.
PR add a reference to section 4 of RFC9000 in section 4.4. of the applicability draft. I still think having the link to section 2.2 of RFC900 in section 4.3 is more clear. flow control credit is not a QUIIC specific term.
Change:
agreement properties of MLS will confirm that all members of the group agree on the content of these extensions. <del> Application messages carried by MLS are opaque; they can contain arbitrary data.  The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted.  Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. </del> 5.8. <ins> Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data.  Each application which uses MLS needs to define the format of its "application_data" and any mechanism necessary to negotiate the format of that content over the lifetime of an MLS group.  In many applications this means managing format migrations for groups with multiple members who may each be offline at unpredictable times. *RECOMMENDATION:* Use the default content mechanism defined in I- D.mahy-mls-content-neg, unless the specific application defines another mechanism which more appropriately addresses the same requirements for that application of MLS. The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted. Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. 5.9. </ins> The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can

Discussion:
As discussed in today's interim. This is essentially repushing which should not have been reverted.
URL
Interim 2022-06-09: Informational refence from RFC to a draft is allowed Agreement to just un-revert / re-land
Fixed in
Change:
agreement properties of MLS will confirm that all members of the group agree on the content of these extensions. <del> Application messages carried by MLS are opaque; they can contain arbitrary data.  The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted.  Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. </del> 5.8. <ins> Application messages carried by MLS are opaque to the protocol; they can contain arbitrary data.  Each application which uses MLS needs to define the format of its "application_data" and any mechanism necessary to negotiate the format of that content over the lifetime of an MLS group.  In many applications this means managing format migrations for groups with multiple members who may each be offline at unpredictable times. *RECOMMENDATION:* Use the default content mechanism defined in I- D.mahy-mls-content-neg, unless the specific application defines another mechanism which more appropriately addresses the same requirements for that application of MLS. The MLS framing for application messages also provides a field where clients can send information that is authenticated but not encrypted. Such information can be used by servers that handle the message, but group members are assured that it has not been tampered with. 5.9. </ins> The protocol aims to be compatible with federated environments. While this document does not specify all necessary mechanisms required for federation, multiple MLS implementations can

Discussion:
I added a short section after discussing architectural issues for content framing and negotiation. It suggests [1] if the application doesn't have a more specific proposal. [1] URL
URL
Interim 2022-06-09: Informational refence from RFC to a draft is allowed Agreement to just un-revert / re-land
Fixed in
Change:
exposed to a greater risk of denial of service attack.  While requests from application servers can be indirectly attributed to user agents, this is not always efficient or even sufficient. <del> Providing more information about the application server more directly to a push service allows the push service to better distinguish between legitimate and bogus requests. </del> <ins> Providing more information about the application server directly to a push service allows the push service to better distinguish between legitimate and bogus requests. </ins> Additionally, this design also relies on endpoint secrecy as any application server in possession of the endpoint is able to send messages, albeit without payloads.  In situations where usage of a subscription can be limited to a single application server, the <del> ability to associate said subscription with the application server provides could reduce the impact of a data leak. </del> <ins> ability to associate a subscription with the application server could reduce the impact of a data leak. 1.1. </ins> This document describes a system whereby an application server can volunteer information about itself to a push service.  At a minimum,

Discussion:
As discussed on the mailing list. NAME NAME can you review this? You can see a nicely formatted version .
This looks good, thanks! +NAME to take a look from the server-side perspective (notably, we'd have to parse and extract a value from header on the server).
Updated.
I think that the confusion here between 401 and 403 were not helped by the fact that they were completely inconsistent. Here are the revised rules: MUST send 401 if you absolutely require credentials and there are none MAY send 403 if the credentials are bad
403 "forbidden" should not be sent if credentials are bad - would only happen if credentials are good ( we verified that the caller is who he claims to be ), but he is forbidden to send, because the subscribe request specified a different sender is allowed. 401 is for missing or bad credentials - if there was no JWT token but the server expects one, of if the JWT provided is bad, doesn't matches the signature. , Martin Thomson EMAIL wrote:
URL , Costin Manolache EMAIL wrote:
NAME I believe that the text is correct. "bad" was perhaps too terse, maybe I should have said "403 MAY be sent if the credentials are present but insufficient to authorize the request"
Thanks. Sorry for being too picky, but I've seen some nasty bugs caused by 401/403 confusion. 403 and "bad" or "invalid" credentials can be interpreted as "invalidate current password and ask user" - in webpush it shouldn't be a huge problem, since the JWT tokens will almost never be invalid (unlike a regular account on password change or revoked token ). , Martin Thomson EMAIL wrote:
Change:
environment before the next environment is started.  In general, the number of layers may vary by device or implementation, and an Attesting Environment might even have multiple Target Environments <del> that it measures, rather than only one as shown in layered. </del> <ins> that it measures, rather than only one as shown by example in layered. </ins> 3.5.

Discussion:
Signed-off-by: Dave Thaler
The relatively abstract text in Layered Attestation Environments could really benefit from a common real world example, e.g. the thing formerly referred to as Secure Boot.
Are you saying that layered attestation is a form of staged boot with Verifiers on the local device? If so, Figure 3 is wrong since it doesn't show the local Verifiers. I think it is an overreach for RATS to classify all staged boot as a form of layered Attestation. See .
The example is so long that the reader misses that it's an example, and the details are too deep.
The illustration is no longer an abstract example.