jiebi/CodeConvo huggingface dataset:
Change:
establishment, or a label for a pre-shared key established externally. <del> For each ticket, the time since the client learned about the server configuration that it is using, in milliseconds.  This value is added modulo 2^32 to the "ticket_age_add" value that was included with the ticket, see NSTMessage.  This addition prevents passive observers from correlating connections unless tickets are reused.  Note: because ticket lifetimes are restricted to a week, 32 bits is enough to represent any plausible age, even in milliseconds.  For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value. </del> <ins> An obfuscated version of the age of the key.  ticket-age describes how to form this value for identities established via the NewSessionTicket message.  For identities established externally an obfuscated_ticket_age of 0 SHOULD be used, and servers MUST ignore the value. </ins> A list of the identities that the client is willing to negotiate with the server.  If sent alongside the "early_data" extension

Discussion:
…s , , .
NAME if you want to propose some revised text, I will TAL.
From Nikos's comment:
This is relating to . I will try to resolve both issues.
It is hard to understand the current text of Section 4.2.9.3 (Replay Properties). NAME explained me that a server should check: The server can tell: serverrecvtime == now serversendtime == one parameter in the ticket clientsendtime - clientrecvtime == ticketage == obfuscatedticketage + ticketage_add If this understanding is correct, I would suggest to add more explanation to the section.
Yes, that's correct. PRs welcome
I made a tweak to avoid referring to the "base value", in , though more changes may still be helpful.
Change:
TLS is enabled.  The guidance in Section 4.4 of RFC7925 applies. <del> The "NoSec" mode is mandatory-to-implement.  The system simply sends </del> <ins> The "NoSec" mode is optional-to-implement.  The system simply sends </ins> the packets over normal TCP which is indicated by the "coap+tcp" scheme and the TCP CoAP default port.  The system is secured only by keeping attackers from being able to send or receive packets from the

Discussion:
: Section 8.1 makes it Mandatory to Implement the protocol without any security ("NoSec"). This seems counter to best practice in the IETF, but I'll defer to the Security Area review. I Carsten's position that this could become optional. History: Some context - during the security discussions in the WG, there was a recommendation to "mirror" the similar section in RFC7252. URL states: The NoSec and RawPublicKey modes are mandatory to implement for this specification. which is why NoSec is MTI.
Change:
considerations apply. When using YAML as a more efficient format to serialize information <del> intended to be consumed as JSON, information can be discarded: this includes comments (see Section 3.2.3.3 of YAML) and alias nodes (see Section 7.1 of YAML), that do not have a JSON counterpart. </del> <ins> intended to be consumed as JSON, information not reflected in the representation graph and classified as presentation or serialization detail (see Section 3.2 of YAML) can be discarded.  This includes comments (see Section 3.2.3.3 of YAML), directives, and alias nodes (see Section 7.1 of YAML) that do not have a JSON counterpart. </ins> Implementers need to ensure that relevant information will not be lost during the processing.  For example, they might consider

Discussion:
in YAML and JSON, explicits that you need to use only information that is stored in the representation graph, not other. See
mention presentation and serialization details they cannot be used to interoperably convey information comments, ordering and anchor names fall in the above categories.
Change:
, for example: <del> to build paths that are input to a JSONPath implementation.  A single path may use a combination of bracket and dot notations. </del> <ins> A JSONPath expression may use a combination of bracket and dot notations. </ins> Dot notation is a shorthand way of writing certain bracket notations. <ins> This document treats the bracket notations as canonical and defines various shorthands in terms of bracket notation.  Examples and descriptions use shorthands where convenient. 1.3.3. </ins> A wildcard "*" (wildcard) in the expression "[*]" selects all children of an object or an array and in the expression "..[*]" selects all descendants of an object or an array.

Discussion:
This is a stab at addressing one NAME review comments in PR .
NAME If you don't think this PR is going in the right direction, please close it and we'll circle back to the matter later.
The term "current node" is traditionally used with iterating over children of structured nodes in filter selectors. Now it also appears in 3.3 Semantics chapter in a different context: To avoid confusion of readers, we might use a different term there. A good alternative would be "context node", which is also used by XPath in a similar context.
Perhaps a simple solution would be to avoid the use of the term in 3.3 as this term doesn't appear to be used elsewhere.
Please see the simplification in URL
Change:
Security protections in RATS may be applied at different layers, whether by a conveyance protocol, or an information encoding format. <del> This architecture expects conceptual messages (see messages) to be end-to-end protected based on the role interaction context.  For example, if an Attester produces Evidence that is relayed through some other entity that doesn't implement the Attester or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence. </del> <ins> This architecture expects conceptual messages to be end-to-end protected based on the role interaction context.  For example, if an Attester produces Evidence that is relayed through some other entity that doesn't implement the Attester or the intended Verifier roles, then the relaying entity should not expect to have access to the Evidence. </ins> 12.3.

Discussion:
Signed-off-by: Dave Thaler
** Section 12.2 Any solution that conveys information used for security purposes, whether such information is in the form of Evidence, Attestation Results, Endorsements, or appraisal policy ... Should reference values be included?
same changes, conceptual messages
Change:
As discussed above, MLS provides the highest level of security when its messages are delivered over a secure transport.  Any secure <del> channel can be used as a transport layer to protect MLS messages, such as QUIC RFC9000, TLS RFC8446, IPsec RFC6071, WireGuard WireGuard, or TOR TOR.  However, the MLS protocol is designed to consider the following threat-model: </del> <ins> channel, such as QUIC RFC9000, TLS RFC8446, can be used to transport MLS messages.  However, the MLS protocol is designed to consider the following threat-model: </ins> The attacker can read, write, and delete arbitrary messages inside the secure transport channel.

Discussion:
There have been a lot of comments about the inclusion of WireGuard and Tor as potential secure transports, but I actually think it's confusing to cite IPsec as well for layering issues. We don't have a real praxis for using things that aren't application-layer style protocols for protecting this kind of traffic, so I don't think we should encourage these. I've trimmed it to just QUIC and TLS.
Change:
Outputs: <del> "message": A "ClientRedemptionMessage" struct. </del> <ins> "message": A "ClientRedemptionRequest" struct. </ins> 3.2.7.

Discussion:
Rename IssuanceMessage and RedemptionMessage to IssuanceRequest and RedemptionRequest, respectively. Rename SecretKey to PrivateKey. Change to an integer value, rather than opaque vector. I also removed company-specific information, which is not really relevant for the document. (That's useful information, but not appropriate for a standards document, I think.) cc NAME NAME
Change:
PSKs change the PSK binder key derivation label.  In particular, the standard TLS 1.3 PSK binder key computation is defined as follows: <del> Imported PSKs replace the string "ext binder" with "imp binder" when deriving "binder_key".  This means the binder key is computed as follows: </del> <ins> Imported PSKs use the string "imp binder" rather than "ext binder" or "res binder" when deriving "binder_key".  This means the binder key is computed as follows: </ins> This new label ensures a client and server will negotiate use of an external PSK if and only if (a) both endpoints import the PSK or (b)

Discussion:
It's a bit confusing to use the term "replace" when discussing the string used for derivation. The text only references one of the strings used for derivation where the diagram references two.
Change:
The following example illustrates a hypothetical Background-Check Model solution that uses timestamps and requires roughly synchronized <del> clocks between the Attester, Verifier, and Relying Party. </del> <ins> clocks between the Attester, Verifier, and Relying Party.  The Attester conveys Evidence to the Relying Party, which treats it as opaque and simply forwards it on to the Verifier. </ins> The time considerations in this example are equivalent to those discussed under Example 1 above.

Discussion:
related to There is something foundational I am not following about this section. The interactions described here do not conform behaviors described in the terminology in Section 4 or the high-level reference architecture of Figure 1. I'm not sure how to reconcile this discrepancy. Minimally, these discrepancies in Figure 5 and 6 are not consistent with the roles defined in Section 4. [restated here but same feedback on -13] -- Figure 5. Shows the Attester consuming Attestation Results -- Figure 5. Shows the Attester producing Attestation Results -- Figure 6: Shows Relying party consuming Evidence -- Figure 6: Shows the Relying Party producing/passing Evidence The introductory text states that "[t]he discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns." I don't follow what is being illustrated in the context of RATS. What is the takeaway for implementers or designers from this section? [Author's response] URL [Roman's response on -15] The above github comment addressed a few issues from the -13 review, but not this one.
Reply by email: "The Attester does not consume the Attestation Result, but might cache it. "
The text explains the intent correctly regardless of how the lines are drawn. I can convince myself that it is correct draw the line through the box (or not). The important clarifying point should be that the end-to-end message flow as described in the conceptual architecture is preserved through the various topology models that may exist. Second point is there can be a large variety of topology models (aka hybrids) but none of these hybrids changes the expectation of end-to-end message flow.
also helps.
Change:
where EAD_4 is protected external authorization data, see AD. COSE constructs the input to the AEAD RFC5116 as follows: <del> Key K = EDHOC-Exporter( "EDHOC_message_4_Key", , length ) </del> <ins> Key K = EDHOC-Exporter( "EDHOC_message_4_Key", h'', length ) </ins> <del> Nonce N = EDHOC-Exporter( "EDHOC_message_4_Nonce", , length ) </del> <ins> Nonce N = EDHOC-Exporter( "EDHOC_message_4_Nonce", h'', length ) </ins> Plaintext P = ( ? EAD_4 )

Discussion:
The new definition of info in th ecurrent specification is. I noticed two problems with this while implementing. To create the array you need to parse context to see how many items it contains. Unless context is validated, length is not strictly defined (an attacker could create collisions) I suggest that info is changed to:
In the exporter, the application using EDHOC could input a context (a encoded CBOR sequence) that is not valid CBOR. That is not a big problem, but might lead to security issues in the future, if is assumed that info is valid CBOR. URL prefered sequence to array. I don't think bstr wrapping the sequence has the same problems as array wrapping the sequence. Array wrapping the info sequence seems like an unesasary step. I suggest.
We have also gotten comments disliking the use of any
Current specification could give the impression that there is a single maclength. But the mac length in message2 and message_3 may be different.
One fix is to update to
Change:
The parsing of a JSON text into a JSON value and what happens if a JSON text does not represent valid JSON are not defined by this <del> specification.  Sections RFC8259 and RFC8259 of RFC8259 identify specific situations that may conform to the grammar for JSON texts but are not interoperable uses of JSON, as they may cause unpredictable behavior.  The present specification does not attempt to define predictable behavior for JSONPath queries in these situations. </del> <ins> document.  Sections RFC8259 and RFC8259 of RFC8259 identify specific situations that may conform to the grammar for JSON texts but are not interoperable uses of JSON, as they may cause unpredictable behavior. This document does not attempt to define predictable behavior for JSONPath queries in these situations. </ins> Specifically, the "Semantics" subsections of Sections name-selector, wildcard, filter-selector, and descendant-segment describe behavior

Discussion:
Generally, use "this document" rather than "this specification". Then use the term specification judiciously. Prefer the term "language" to "platform".
Yep, environment is a nice synonym of platform. Thank you for addressing my concern!
Change:
extension. A request to finalize an order will result in error if the order <del> indicated does not have status "pending", if the CSR and order </del> <ins> indicated does not have status "ready", if the CSR and order </ins> identifiers differ, or if the account is not authorized for the identifiers indicated in the CSR.

Discussion:
When the "ready" status was added to the order process we missed a place in Section 7.4 where the specification claims an order should be in status "processing" when it is ready for finalization. This commit changes this sentence to say the order is ready for finalization when it is status "ready". Thanks to NAME for flagging this issue on-list.
Change:
terms of the granularity of padding, how padding is arranged in relation to the information that is being protected, whether padding is applied in the case of packet loss, and how an implementation <del> might control padding. </del> <ins> might control padding.  Redundant padding could even be counterproductive. </ins> <del> 10.2. </del> <ins> To mitigate attacks that rely on compression, disabling or limiting compression might be preferable to padding as a countermeasure. Use of padding can result in less protection than might seem immediately obvious.  At best, padding only makes it more difficult for an attacker to infer length information by increasing the number of frames an attacker has to observe.  Incorrectly implemented padding schemes can be easily defeated.  In particular, randomized padding with a predictable distribution provides very little protection; similarly, padding payloads to a fixed size exposes information as payload sizes cross the fixed-sized boundary, which could be possible if an attacker can control plaintext. 10.8. </ins> Several protocol elements contain nested length elements, typically in the form of frames with an explicit length containing variable-

Discussion:
The follow-on to ; depends on . DO NOT MERGE before lands. Imports most of the HTTP/2 Security Considerations text, modulo updates to reference HTTP/3 or http-core concepts. Suggestions on a more sensible structuring of concerns welcome; this still feels like a bit of a grab-bag.
There's a few places where it seems the new "field" terminology is applied inconsistently, but given the PR dependency chain maybe that will shake out. I'll take another look once other things have landed.
Given the chain, this PR should consistently use the new terminology. If I missed something, please flag it.
HTTP-core is making some terminology changes that HTTP/3 should track: In URL, "non-final" responses are "interim" responses In URL, terminology around header, field, value is changing Related to , but this is more than just pointing at the new documents.
NAME these comments/suggestion address my earlier one about use of headers. I might be applying things wrong.Looks good to me. Thanks for doing the hard work here.
Change:
specification for more information). The signature algorithm specified in the ciphersuite is the mandatory <del> algorithm to be used for the signatutes in MLSPlaintext and the tree signatures.  It can be different from the signature algorithm specified in credential field of ClientInitKeys. </del> <ins> algorithm to be used for signatures in MLSPlaintext and the tree signatures.  It MUST be the same as the signature algorithm specified in the credential field of the ClientInitKey objects in the leaves of the tree (including the ClientInitKeys used to add new members). </ins> The ciphersuites are defined in section mls-ciphersuites.

Discussion:
required a common signature algorithm, but allowed credentials to deviate. This PR adds the requirement that credentials be consistent.
Change:
contain the RFC7234 Age response header indicating the elapsed time between when the entry was placed in the HTTP cache and the current DOH response.  DNS API clients should subtract this time from the DNS <del> TTL if they are re-sharing the information in a non HTTP context (e.g., their own DNS cache) to determine the remaining time to live of the DNS record. </del> <ins> TTL in each RRset to determine the time remaining on the TTL. </ins> HTTP revalidation (e.g., via If-None-Match request headers) of cached DNS information may be of limited value to DOH as revalidation

Discussion:
URL unnecessary. The point here is to highlight the need to tweak the TTL to account for Age, not to go into why. It's actually a generic requirement that is not specific to translation to other contexts.
Change:
unusable Anonymous-2007 and by China to identify and block Tor relays Winter-2012.  Protocol identification has also been used for traffic management, such as the 2007 case where Comcast in the United States <del> used RST injection to interrupt BitTorrent Traffic Winter-2012. </del> <ins> used RST injection to interrupt BitTorrent Traffic Winter-2012.  In 2020, Iran deployed an allowlist protocol filter, which only allowed three protocols to be used (DNS, TLS, and HTTP) on specific ports and censored any connection it could not identify Bock-2020. 4.4. Another feature of some modern censorship systems is residual censorship, a punitive form of censorship whereby after a censor disrupts a forbidden connection, the censor continues to target subsequent connections, even if they are innocuous Bock-2021. Residual censorship can take many forms and often relies on the methods of technical interference described in the next section. An important facet of residual censorship is precisely what the censor continues to block after censorship is initially triggered. There are three common options available to an adversary: 2-tuple (client IP, server IP), 3-tuple (client IP, server IP+port), or 4-tuple (client IP+port, server IP+port).  Future connections that match the tuple of information the censor records will be disrupted Bock-2021. Residual censorship can sometimes be difficult to identify and can often complicate censorship measurement. Trade-offs: The impact of residual censorship is to provide users with further discouragement from trying to access forbidden content, though it is not clear how successful it is at accomplishing this. Empirical Examples: China has used 3-tuple residual censorship in conjunction with their HTTP censorship for years and researchers have reported seeing similar residual censorship for HTTPS.  China seems to use a mix of 3-tuple and 4-tuple residual censorship for their censorship of HTTPS with ESNI.  Some censors that perform censorship via packet dropping often accidentally implement 4-tuple residual censorship, including Iran and Kazakhstan Bock-2021. </ins> 5.

Discussion:
Hi team - Here's a pull request with some additional text and information to add to the RFC. Please let me know if there are things I should change or add or remove or fix - totally open to feedback! My changes are the following: Added text towards additional forms of TLS censorship (and citations for them): ESNI censorship, server certificate censorship, omitted SNI censorship Added text about residual censorship Added text about censorship in depth Added text about additional keyword blocking dynamics, there's been some recent research on this Added text about protocol filtering (such as Iran's protocol filter) Added some additional citations for various forms of censorship I'd be happy to break this up into multiple PRs if that's easier as well.
Kevin, if you can rebase your commits on top of the latest version, I'm happy to merge this PR. Thank you for your work on it!
Hi NAME - Just wanted to give this a bump as I close this tab. Let me know if there's any other work that should be added!
Change:
1.2. <del> TLS 1.3 was originally specified in RFC8446.  This document is solely an editorial update.  It contains updated text in areas which were found to be unclear as well as other editorial improvements.  In addition, it removes the use of the term "master" as applied to secrets in favor of the term "main" or shorter names where no term was neccessary. </del> <ins> TLS 1.3 was originally specified in RFC8446.  This document is a minor update to TLS 1.3 that retains the same version number and is backward compatible.  It tightens some requirements and contains updated text in areas which were found to be unclear as well as other editorial improvements.  In addition, it removes the use of the term "master" as applied to secrets in favor of the term "main" or shorter names where no term was necessary.  This document makes the following specific technical changes: Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by RFC8996. Removes ambiguity around which hash is used with PreSharedKeys and HelloRetryRequest. Require that clients ignore NewSessionTicket if they do not support resumption. Upgrade the requirement to initiate key update before exceeding key usage limits to MUST. Limit the number of permitted KeyUpdate messages. Restore text defining the level of "close_notify" to "warning". Clarify behavior around "user_canceled", requiring that "close_notify" be sent and that "user_canceled" should be ignored. Add a "general_error" generic alert. In addition, there have been some improvements to the security considerations, especially around privacy. </ins> 1.3.

Discussion:
Change "should" -> "SHOULD" around user_canceled Replicate the 8773 language to another place where external PSKs is discussed. Remove an OPEN ISSUE marker
Change:
Base Key: The secret value of an EPSK. <del> External Identity: The identity of an EPSK. </del> <ins> External Identity: A sequence of bytes used to identify an EPSK. </ins> Target protocol: The protocol for which a PSK is imported for use.

Discussion:
This isn't perfect either, but it concentrates on the functional side, namely that we use a sequence of bytes to identify PSKs.