jiebi/CodeConvo huggingface dataset:
Code change:
"payload", as computed above. <ins> If optional configuration identifiers (see optional-configs)) are used, the "config_id" field MAY be empty or randomly generated. Unless specified by the application using (D)TLS or externally configured on both sides, implementations MUST compute the field as specified in encrypted-client-hello. </ins> 6.2. This section describes a deterministic padding mechanism based on the

Related discussion:
text: The spec describes an optional trial decryption mode, but most of the text contradicts it. This PR fixes the text up and tries to unify their processing models. In doing so, it flips the error handling from decrypterror to fallback to be consistent. This, combined with the ClientHelloOuterAAD change, plugs an active sticking out attack for free. It also makes easier because GREASE configid collisions with real configids are now harmless. Along the way, NAME and NAME observed that we're not authenticating the ECHConfig at all. (It used to be authenticated by way of the configid, which was a digest.) Instead, just pass the ECHConfig into the info field of the HPKE context. They also noticed the server rule about PSKs on ClientHelloOuter didn't work with GREASE. Instead, we can simply remove it.
This matches the acceptance signal length, and we've already accepted that probability of collision.
Code change:
of codecs sent to a remote party indicates what the local side is willing to receive, which, when intersected with the set of codecs the remote side supports, specifies what the remote side should send. <del> However, not all parameters follow this rule; for example, the fingerprints RFC8122 sent to a remote party are calculated based on the local certificate(s) offered; the remote party MUST either accept these parameters or reject them altogether, with no option to choose different values. </del> <ins> However, not all parameters follow this rule; some parameters are declarative and the remote side MUST either accept them or reject them altogether.  An example of such a parameter is the DTLS fingerprints RFC8122, which are calculated based on the local certificate(s) offered, and are not subject to negotiation. </ins> In addition, various RFCs put different conditions on the format of offers versus answers.  For example, an offer may propose an

Related discussion:
text: Second paragraph of 3.2, last sentence: at "these parameters or reject them" - "these" and "them" have ambiguous antecedents. It's not clear if you are trying to point to the parameters that don't follow the earlier stated rule, or all parameters. The sentence is complex. Splitting it up and finding a way to avoid the need for the semicolon will likely make it easier to say what you mean.
I agree that this is messy. Editorial.
LGTMLG with comment
Code change:
each Participant creates an initial Participant Application Secret to be used for its own sending chain: <del> Note that [sender] represent the uint32 value encoding the index of the participant in the ratchet tree. </del> <ins> Note that [sender] represents the index of the member in the roster. </ins> Updating the Application secret and deriving the associated AEAD key and nonce can be summarized as the following Application key schedule

Related discussion:
text: Fix for
NAME This might not be completely ideal, because of the group state but it currently does not change the key schedule, I am merging this because we need it for correct interop but feel free to get back to discuss a better way to do this in details.
There are at least two bugs in the message protection section that make it unimplementable: It calls for , but the third argument to as defined is a , not an octet string. It refers to a function , which is defined in TLS, but not here. ISTM the simplest way to fix these problems would to define and use it (1) as the basis for , (2) for deriving sender root secrets, and (3) for deriving keys and nonces.
Fixed by
Code change:
mechanism (e.g., WebSockets); upon receipt of that offer, the remote party installs it using the setRemoteDescription() API. <del> When the call is accepted, the callee uses the createAnswer() API to generate an appropriate answer, applies it using setLocalDescription(), and sends the answer back to the initiator over the signaling channel.  When the offerer gets that answer, it installs it using setRemoteDescription(), and initial setup is complete.  This process can be repeated for additional offer/answer exchanges. </del> <ins> To complete the offer/answer exchange, the remote party uses the createAnswer() API to generate an appropriate answer, applies it using the setLocalDescription() API, and sends the answer back to the initiator over the signaling channel.  When the initiator gets that answer, it installs it using the setRemoteDescription() API, and initial setup is complete.  This process can be repeated for additional offer/answer exchanges. </ins> Regarding ICE RFC5245, JSEP decouples the ICE state machine from the overall signaling state machine, as the ICE state machine must remain

Related discussion:
text: I was reading this draft and noticed a couple of minor wording issues that made the text not as clear as it could be. I don't believe the changes are controversial, or change the intention of the draft.
These changes look good - I agree the rewrite of the offer/answer paragraph is a nice improvement.
Looks fine to me
Code change:
One common practice is to use these continuous integration services to build a text or HTML version of a document.  This is then published to GitHub Pages, which allows users to view a version of <del> the most recent revision of a document.  Including prominent link to this version of the document (such as in the README) makes it easier for new contributors to find a readable copy of the most recent version of a draft. </del> <ins> the most recent revision of a document.  Including a prominent link to this version of the document (such as in the README) makes it easier for new contributors to find a readable copy of the most recent version of a draft. </ins> Continuous integration can also validate pull requests and other changes for errors.  The most basic check is whether the source file <del> can be transformed successful into a valid Internet-Draft.  For </del> <ins> can be transformed successfully into a valid Internet-Draft.  For </ins> example, this might include checking that XML source is syntactically correct. <del> For documents that use formal languages a part of specifications, such as schema or source code, a continuous integration system might also be used to validate any formal language that the document contains.  Tests for any source code that the document contains might be run, or examples might be checked for correctness. </del> <ins> For a document that use formal languages as part of the specification, such as schema or source code, a continuous integration system might also be used to validate any formal language that the document contains.  Tests for any source code that the document contains might be run, or examples might be checked for correctness. </ins> 8.

Related discussion:
text: A good start. Would you like to open another PR adding yourself as an author?
Let me know if what I created (experiences + author) needs to be something different. This is a very scary world for me. Ultra light description is next. Barbara
Code change:
"https://dnsserver.example.net/dns-query{?dns}" to resolve IN A records. <del> The requests are represented as message/dns typed bodies. </del> <ins> The requests are represented as application/dns-message typed bodies. </ins> The first example request uses GET to request www.example.com

Related discussion:
text: Fixes issue
The message/ tree requires that the sub-types contain other MIME messages, which DOH does not. Maybe use application/dns-message instead.
Code change:
to a single address over a single interface.  They also present a single stream to the application.  Software layers built upon sockets often propagate this limitation of a single-address single-stream <del> model.  The Transport Services architecture is designed to handle multiple candidate endpoints, protocols, and paths; and support multipath and multistreaming protocols. </del> <ins> model.  The Transport Services architecture is designed: to handle multiple candidate endpoints, protocols, and paths; to support candidate protocol racing to select the most optimal stack in each situation; to support multipath and multistreaming protocols; to provide state caching and application control over it. </ins> Transport Services implementations are meant to be flexible at connection establishment time, considering many different options and <del> trying to select the most optimal combinations (gathering and racing).  This requires applications to provide higher-level endpoints than IP addresses, such as hostnames and URLs, which are used by a Transport Services implementation for resolution, path selection, and racing.  Transport services implementations can further implement fallback mechanisms if connection establishment of one protocol fails or performance is detected to be unsatisfactory. </del> <ins> trying to select the most optimal combinations by racing them and measuring the results (see gathering and racing).  This requires applications to provide higher-level endpoints than IP addresses, such as hostnames and URLs, which are used by a Transport Services implementation for resolution, path selection, and racing.  Transport Services implementations can further implement fallback mechanisms if connection establishment of one protocol fails or performance is detected to be unsatisfactory. Information used in connection establishment (e.g. cryptographic resumption tokens, information about usability of certain protocols on the path, results of racing in previous connections) are cached in the transport services implementation.  Applications have control over whether this information is used for a specific establishment, in order to allow tradeoffs between efficiency and linkability. </ins> Flexibility after connection establishment is also important. Transport protocols that can migrate between multiple network-layer

Related discussion:
text: In (Arch) section 3.3, you are talking about racing before you've described what it is. At the point where you note that racing should only happen over stacks with identical security properties, note when doing so might introduce privacy issues and what can be done about them.
Describe what you mean by caching and why you might want to isolate sessions earlier.
Code change:
for the "Date" field to determine the time window over which the server will accept responses. <del> 7.4.2. </del> <ins> 7.5.2. </ins> An Oblivious Gateway Resource can reject requests that contain a "Date" value that is outside of its active window with a 400 series

Related discussion:
text: NAME noted that it was important to note that the Gateway needs to be trusted if gateway != target. As a practical matter, that means that you probably want gateway == target.
Hi, Since the gateways are seeing request/response pairs, there is a potential here for a side-channel attack at the gateway itself or at a relay. (if I understood the draft correctly - if not, please clarify my misunderstanding here). Are there mitigations planned for this type of issue that you could expand on in the Security Considerations section perhaps?
Does the new text in address this concern?
I don't think so, because the claim is the gateway does not have intimate knowledge of the contents of the request/response. If that assertion is true, the gateway shouldn't be able to ascertain information about the actual contents from those pairs (directly or indirectly, via a side-channel attack). If the burden is on the application developer to ensure that request/response pairs traversing the gateway are to be resilient to side-channel attacks of those pairings, then it would be good to explicitly call that out in this spec (perhaps in the security considerations section?) Thoughts?
NAME the gateway necessarily sees all request and response pairs, and will therefore always learn information about each transaction. This is fundamental to the design. Whether or not the gateway uses that information for malicious purposes, e.g., by providing different responses to different requests for the same target resource, depends on the trust model. And the change in addresses that. I don't think further text is needed here.
"Finally, a relay can also generate responses, though it assumed to not be able to examine the content of a request (other than to observe the choice of key identifier, KDF, and AEAD), so it is also assumed that it cannot generate an Encapsulated Response." I feel that a relay could certainly perform a side-channel attack here as well using R/R pairings.
Can you please be more specific here? What type of attack could the relay do to violate client privacy that is not already documented in the draft?
Typically in HTTPs scenarios, it is more difficult to perform side channel attacks as a flow observer, especially if multiplexing of requests and responses are performed.
Code change:
for the "Date" field to determine the time window over which the server will accept responses. <del> 7.4.2. </del> <ins> 7.5.2. </ins> An Oblivious Gateway Resource can reject requests that contain a "Date" value that is outside of its active window with a 400 series

Related discussion:
text: In this design, if I understand it correctly, the requests and responses are being broken out into distinct exchanges that the relay can see and therefore it makes it easier for a relay to perform these types of attacks that would be more difficult had the relay not been used in the first place. If my understanding of the protocol is incorrect here, please feel free to point that out.
You seem to be describing fingerprinting attacks, wherein the observer uses features extracted from otherwise encrypted traffic to try and learn information about the underlying (unencrypted) data. Yes, the relay does have a more fine-grained view of each exchange compared to a network observer in this protocol since it can see explicit message boundaries, and that might impact the efficacy of these attacks. This is partly already addressed in the document: We could extend this to note the relay's view of message boundaries. I don't think any additional text is needed for the gateway.
Whatever you feel is best. I think some language around the message level risks this creates vs non-relay scenarios might be helpful. Does the client intentionally break things up in a way that crosses the underlying application message boundaries (e.g. more like packetization) with a relay? I have more questions about the gateway functionality that we can discuss separately.
This means that the client really needs to trust that the gateway doesn't muck with it. As a practical matter, this incentivizes clients to choose a gateway that is effectively the same entity as the target. They don't have to, but the amount of trust required of the gateway is higher if gateway and target aren't operated by the same entity. We touch on this, but we could be clearer about it.
Code change:
A single stream provides ordering.  If the application requires certain data to be received in order, that data should be sent on <del> the same stream. </del> <ins> the same stream.  There is no guarantee of transmission, reception, or delivery order across streams. </ins> Multiple streams provide concurrency.  Data that can be processed independently, and therefore would suffer from head of line

Related discussion:
text: Based on the discussion in webtrans at IETF-110, I guess we could be more explicit that QUIC streams do not guarantee to be received in any particular order.
Code change:
On the other hand, reducing the frequency of packets that carry only acknowledgements reduces packet transmission and processing cost at <del> both endpoints.  It can also improve connection throughput on severely asymmetric links; see Section 3 of RFC3449. </del> <ins> both endpoints.  It can improve connection throughput on severely asymmetric links and reduce the volume of acknowledgment traffic using return path capacity; see Section 3 of RFC3449. </ins> A receiver SHOULD send an ACK frame after receiving at least two ack- eliciting packets.  This recommendation is general in nature and

Related discussion:
text: This is a small tweak of Gorry's suggestion.
Looks good to me.
I promised to raise an issue relating to this text: "It can also improve connection throughput on severely asymmetric links; see Section 3 of [RFC3449]." This partly addresss the case, but it does not yet note the implications of the return path traffic on congestion of the return path. I think this is a useful addition, because it helps alert the reader of the tradeoff ... which can be quite important for half-duplex/shared radio, etc where the spectrum consumed sending an ACK can even outweigh the cost of sending a data packet (because they use different design of PHY). I suggest: "It can improve connection throughput using severely asymmetric links and can also reduce the volume of acknowledgment traffic using return path capacity; see Section 3 of [RFC3449]."
Code change:
recovery (e.g., QUIC), and the underlying HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery mechanisms.  This can reduce performance as both can sometimes <del> independently retransmit the same data.  To avoid this, HTTP/3 datagrams SHOULD be used. </del> <ins> independently retransmit the same data.  To avoid this, UDP proxying SHOULD be performed over HTTP/3 to allow leveraging the QUIC DATAGRAM frame. </ins> 6.1.

Related discussion:
text: recovery (e.g., [QUIC]), and the underlying HTTP connection runs over TCP, the proxied traffic will incur at least two nested loss recovery mechanisms. This can reduce performance as both can sometimes independently retransmit the same data. To avoid this, HTTP/3 datagrams SHOULD be used. This text could maybe be clearer. Is it trying to say "You SHOULD use H3 + Datagram" or "You SHOULD use H3 and if you do you should use datagram". I.e., is it possible to use H3 but not datagram?
You're right, this is unclear. That text predates the refactor of HTTP/3 Datagram to HTTP Datagrams, so we should tweak it to say "To avoid this, UDP proxying SHOULD be performed over HTTP/3 to allow leveraging the QUIC DATAGRAM frame."
Code change:
the fact that the CEK is going to be known to both parties.  Thus the origination is always built on a presumption that "I did not send this message to myself." <ins> All of the authenticated encryption algorithms in this document use counter mode for the encryption portion of the algorithm.  This means that the length of the plain text will always be known as the cipher text length and the plain text length are always the same.  This information can enable passive observers to infer information based solely on the length of the message.  Applications for which this is a significant problem need to provide some type of padding algorithm so that the length of the message does not provide this information. </ins>

Related discussion:
text: This adds a security consideration for padding. THis addresses issue
With the move from CBC to GCM as a padding mode, there is now no padding for a S/MIME message at all. We should probably add a security consideration dealing with the fact that in some cases traffic analysis might be able to get at the content of an encrypted message based on its size.
Code change:
is specified in the coap-group resource. The presence sensor can learn the presence of groups that support <del> resources with rt=light in its own sector by sending the same request, as used by the luminary.  The presence sensor learns the multicast address to use for sending messages to the luminaries. </del> <ins> resources with rt=tag:example.com,2020:light in its own sector by sending the same request, as used by the luminary.  The presence sensor learns the multicast address to use for sending messages to the luminaries. </ins> 10.2.

Related discussion:
text: ... and a few other cases of example errors and use of unregistered names.
Code change:
such code to be read or tampered with by code outside that environment. <ins> Note that HKDF-Expand has a relativly small maximum output length of 255 * hash_length.  This means that when when SHA-256 is used as hash algorithm, message_2 cannot be longer than 8160 bytes. </ins> The sequence of transcript hashes in EHDOC (TH_2, TH_3, TH_4) do not make use of a so called running hash, this is a design choice as running hashes are often not supported on constrained platforms.

Related discussion:
text: Reformulating security of expand as stream cipher instead of removing. HKDF-Expand is very often used.Added note of HKDF-Expand length restriction.Key use for different algorithms is already covered by COSE. Nothing is special with use inside of EDHOC. The text is clearly not correct at as signate can also be used in other methods.
Channeling from Erik. Use of the HKDF as EDHOC-KDF for generation of KEYSTREAM2 and encryption of message2 induces a max size. For example, HKDF-SHA256 has max output size 255*32 = 8160 bytes.
Code change:
Origins.  Implementing mitigations discused in deployment and privacy is therefore necessary to ensure that Privacy Pass offers meaningful privacy improvements to end-users. <ins> 7.1. Depending on the Origin's token challenge, Clients can request and cache more than one token using an issuance protocol.  Cached tokens help improve privacy by separating the time of token issuance from the time of token redemption, and also allow Clients to reduce the overhead of receiving new tokens via the issuance protocol. As a consequence, Origins that send token challenges which are compatible with cached tokens need to take precautions to ensure that tokens are not replayed.  This is typically done via keeping track of tokens that are redeemed for the period of time in which cached tokens would be accepted for particular challenges. Moreover, since tokens are not intrinsically bound to Clients, it is possible for malicious Clients to collude and share tokens in a so- called "hoarding attack."  As an example of this attack, many distributed Clients could obtain cacheable tokens and them share them with a single Client to redeem in a way that would violate an Origin's attempt to limit tokens to any one particular Client. Depending on the deployment model, it can be possible to detect these types of attacks by comparing issuance and redemption contexts; for example, this is possible in the Joint Origin and Issuer model. </ins>

Related discussion:
text: NAME good suggestions! I merged them all.
This system extensively uses tokens that are only loosely bound to usage contexts. Possession of a token is pretty much all that is necessary. That means that tokens might be stolen or hoarded and then replayed. The architecture draft says nothing about this as a risk, but it probably should.
Agree, especially for for cached tokens. I thought we had mentioned this somewhere, but if not, let's make sure it's included.