jiebi/CodeConvo huggingface dataset:
Code change:
cipher suite, and the parameters defined in asym-msg4-proc. If any verification step fails the Initiator MUST send an EDHOC error <del> message back, formatted as defined in error, and the protocol MUST be </del> <ins> message back, formatted as defined in error, and the session MUST be </ins> discontinued. 7.2.

Related discussion:
text: Closing
Current specification mandates sending error messages upon certain failures. But in cases when message processing fails when no state has been allocated or when no connection identifier has been found or then a more appropriate action would be to just silently drop the message.
I think the MUST (if possible) is good. Debugging without any error messages is not nice. We now other protocols that it is good to mandate error messages. It is kind of obvious that can not send an error if you don't now where/how to send it. Don't know if that has to be pointed out....
Migth be good to not sent error if you are under a DoS attack.
This issue is addressed by pull request that also address availability
The PR has been discussed and merged. Closing
Code change:
receiving endpoint discards the message, if complying to the policy) may be obtained as part of normal resource discovery. <ins> Applications need to use a padding scheme if the content of a message can be determined solely from the length of the payload.  As an example, the strings "YES" and "NO" even if encrypted can be distinguished from each other as there is no padding supplied by the current set of encryption algorithms.  Some information can be determined even from looking at boundary conditions.  An example of this would be returning an integer between 0 and 100 where lengths of 1, 2 and 3 will provide information about where in the range things are.  Three different methods to deal with this are: 1) ensure that all messages are the same length.  For example using 0 and 1 instead of 'yes' and 'no'.  2) Use a character which is not part of the responses to pad to a fixed length.  For example, pad with a space to three characters.  3) Use the PKCS #7 style padding scheme where m bytes are appended each having the value of m.  For example, appending a 0 to "YES" and two 1's to "NO".  This style of padding means that all values need to be padded. </ins> 8. Privacy threats executed through intermediate nodes are considerably

Related discussion:
text: I don't know why your commit got included.
I think I do: I modified the commit in order to add the description (to close issues). Now there are 2 identical commits, one is the one above ( 30475e3) that does not close issues, the other is the one in the master branch (7d4cbc2)
Thanks for your contribution Jim
Code change:
sufficient, though it might be helpful to occasionally remind new contributors of these guidelines. <del> A choice to use GitHub is similar to the formation of a design team (see Section 6.5 of RFC2418) provided that the work uses a public repository.  That is, the output of any activity using GitHub needs to be taken to the Working Group mailing list and subject to approval, rejection, or modification by the Working Group as with any other input. </del> Working Group Chairs are responsible for ensuring that any policy they adopt is enforced and maintained.

Related discussion:
text: This is the way we've been treating this, so let's acknowledge that.
As I noted on the list, I don't think this is correct. I proposed alternate text.
Still LGTM. :-)
Code change:
If the server sends an "encrypted_client_hello" extension, the client MUST check the extension syntactically and abort the connection with <del> a "decode_error" alert if it is invalid. </del> <ins> a "decode_error" alert if it is invalid.  It otherwise ignores the extension and MUST NOT use the retry keys. </ins> Offering a GREASE extension is not considered offering an encrypted ClientHello for purposes of requirements in client-behavior.  In

Related discussion:
text: The intent was that the server always sends the retry keys (it cannot distinguish stale keys from GREASE when the client is actually trying to connect to the public name), while the client just ignores them, but I did a poor job of describing this, so add a key sentence. This addresses .
(EDITED.) To recap the discussion on , your point is that the client-facing server needn't attempt to distinguish GREASE from non-GREASE based on outer SNI, because if the outer SNI != public name, then the client knows to ignore the retry config and continue as usual. I think this is weird because if rejection was the intent, then the client is supposed to abort with "ech_required". So the server only knows that non-GREASE was intended once it receives this signal.
I mean, yeah, that's how this was designed and is what we merged to the spec. :-) This formulation, in particular, does not break if the client tries to connect to the public name (it's a perfectly valid URL) without knowing the ECH config (maybe it the HTTPS record didn't get through Do53) but still sends GREASE (because the intent is that every client can GREASE). It seems to me breaks this. Do you have an alternate formulation which keeps this working? Connecting to the public name is especially important if the public name is a non-throwaway domain. The only requirement on the public name is that it's some name which knows about and serves the client-facing server's config. (I.e. this particular backend server is the same entity as the client-facing server.) doesn't relax this requirement, since the public name continues to be the entity trusted to replace, and possibly disable, ECH on config mismatch.
I don't see this as an issue. If the client sends GREASE, it doesn't expect to use ECH, so it won't abort. The text here only requires that the client check the extension if present, and ignore it if absent.
I don't have an alternative formulation. I was evnisioning the public name only being verified on the ECH rejection path, or when neither real nor dummy ECH was offered to the client-facing server. I'm fine with rejection not being known until "ech_required". I support this PR as the resolution to .
Code change:
If the server sends an "encrypted_client_hello" extension, the client MUST check the extension syntactically and abort the connection with <del> a "decode_error" alert if it is invalid. </del> <ins> a "decode_error" alert if it is invalid.  It otherwise ignores the extension and MUST NOT use the retry keys. </ins> Offering a GREASE extension is not considered offering an encrypted ClientHello for purposes of requirements in client-behavior.  In

Related discussion:
text: NAME and I were sitting down and thinking and we realized the following scenario can happen: URL is on URL, which supports ECH URL has an HTTPS record, an A record, AAAA record pointing at the IP for URL A user of a browsers latest release that supports ECH and greases the extension is using a resolver that doesn't resolve HTTPS records This results in an ECH request being made with URL, and a rejection of the ECH. So now the question is what the client should do and what should servers expect? Try again, with the outer SNI the one matching the one in the new config Use the connection authoritatively for URL since the connection has already revealed the issue.
The intention was the latter, but the text could probably be clearer. I don't think there's much point in trying again since the name has already been revealed. See URL
NAME is this still an issue now that is merged?
I think the client behavior remains equally unspecified. In particular the lengthy argument NAME and I had about server enforcement of the client behavior I think isn't changed.
Care to file a PR, presuming the latter behavior is intended?
A proposed resolution is here: .
NAME a proposed fix has been merged. See .
I think this text works.
Code change:
If the client instance is capable of directing the end-user to a URL defined by the AS at runtime, the client instance indicates this by <del> sending the "redirect" field with the boolean value "true".  The means by which the client instance will activate this URL is out of scope of this specification, but common methods include an HTTP redirect, launching a browser on the end-user's device, providing a scannable image encoding, and printing out a URL to an interactive console.  While this URL is generally hosted at the AS, the client instance can make no assumptions about its contents, composition, or relationship to the AS grant URL. </del> <ins> including "redirect" in the array under the "start" key.  The means by which the client instance will activate this URL is out of scope of this specification, but common methods include an HTTP redirect, launching a browser on the end-user's device, providing a scannable image encoding, and printing out a URL to an interactive console. While this URL is generally hosted at the AS, the client instance can make no assumptions about its contents, composition, or relationship to the AS grant URL. </ins> If this interaction mode is supported for this client instance and request, the AS returns a redirect interaction response response-

Related discussion:
text: The boolean value "true" is no longer used to specify supported interaction start modes.
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: ef948b6b0b53f92352ec617e6074174e0a2eaa3f Inspect the deploy log: Browse the preview:
Code change:
identifiers; the precise semantics of such links are left to future specifications. <del> The following example shows a client performing an endpoint type (et) lookup with the value oic.d.sensor (which is currently a registered rt value): </del> <ins> The following example shows a client performing an endpoint lookup limited to endpoints of endpoint type "tag:example.com,2020:platform": </ins> 7.

Related discussion:
text: ... and a few other cases of example errors and use of unregistered names.
Code change:
The basic design philosophy of DTLS is to construct "TLS over datagram transport".  Datagram transport does not require nor provide reliable or in-order delivery of data.  The DTLS protocol preserves <del> this property for application data.  Applications such as media </del> <ins> this property for application data.  Applications, such as media </ins> streaming, Internet telephony, and online gaming use datagram transport for communication due to the delay-sensitive nature of transported data.  The behavior of such applications is unchanged when the DTLS protocol is used to secure communication, since the DTLS protocol does not compensate for lost or reordered data traffic. <ins> Note that while low-latency streaming and gaming use DTLS to protect data (e.g. for protection of a WebRTC data channel), telephony utilizes DTLS for key establishment, and Secure Real-time Transport Protocol (SRTP) for protection of data RFC5763. </ins> TLS cannot be used directly in datagram environments for the following five reasons:

Related discussion:
text: [BA] Do you mean "maximum retransmission timemout value"?
Addressed in
Code change:
authenticated negotiation of an application protocol (TLS uses ALPN ALPN for this purpose) <del> Endpoints can use packets sent during the handshake to test for Explicit Congestion Notification (ECN) support; see ecn.  An endpoint verifies support for ECN by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in ecn-validation. </del> The CRYPTO frame can be sent in different packet number spaces (packet-numbers).  The offsets used by CRYPTO frames to ensure ordered delivery of cryptographic handshake data start from zero in

Related discussion:
text: This is my best stab at it.
Erik Kline said:
I thought that section reference was wrong, but Section 7 does indeed mention ECN twice. Once is almost too much for this section. I checked the history and the commits that affected this text likely are the result of a merge, and one that either git resolved incorrectly for us, or one that we messed up. Either way, this is worth fixing.
one nit
Code change:
Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at <del> https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. Source code and issues list for this draft can be found at https://github.com/quicwg/ack-frequency [2]. </del> <ins> <https://mailarchive.ietf.org/arch/search/?email_list=quic>.  Source code and issues list for this draft can be found at <https://github.com/quicwg/ack-frequency>. </ins> <del> Working Group information can be found at https://github.com/quicwg [3]; </del> <ins> Working Group information can be found at <https://github.com/ quicwg>. </ins> 1.

Related discussion:
text: You aren't using URL, so remove it. I updated the links so that the text rendering doesn't include them twice.
Code change:
the key config specifies a KEM, KDF, or AEAD algorithm the client doesn't recognize. <del> If the set of supported helpers is empty, then the client aborts and alerts the leader with "no supported helpers".  Otherwise, for each supported helper the client issues a POST request to "[leader]/upload_finish" with a payload constructed as described below. </del> [OPEN ISSUE: Should the request URL encode the PA task?  This would be necessary if we make "upload_start" an idempotent GET per issue#48.]

Related discussion:
text: Partially addresses . (We also need to decide if/how to allow a particular PA protocol to use multiple helpers for privacy.) Right now, multiple helpers are used for redundancy in case one of the helpers dropped out. This removes this mechanism from the core protocol.
Squashed and rebased.
That's a good idea,
Hmm... Do we need to decide. Per our discussion on Wednesday, if the clients learn this out of band then we won't need this field at all because clients will get it separately and helpers don't need to know what the other helpers are, right?
My takeaway is that the parameters must contain all input needed to run the protocol, including the helpers. And all of this is configured out of band. You could punt everything except for the cryptographic goop out of the parameters structure, forcing clients to know the leader and helper and get their public keys out of band as well, which would be fine. It's just different. I think both work just fine, but I lean towards having params specify everything. It just seems simpler to me. That said... making public key discovery part of the client upload protocol here is more complex, I think. So, .
Squashed.
LGTM. Multiple helpers "for privacy" seems like it's inherently a per-protocol thing (Prio supports it, Hits does not). If and when we decide to address that, should we move this to the protocol-specific slot in PAParam?
Code change:
the request does not contain a fresh Echo option value, and the server cannot verify the freshness of the request in some other way, the server MUST NOT process the request further and SHOULD send a <del> 4.01 Unauthorized response with an Echo option. </del> <ins> 4.01 Unauthorized response with an Echo option.  The server MAY include the same Echo option value in several different responses and to different clients. </ins> The application decides under what conditions a CoAP request to a resource is required to be fresh.  These conditions can for example

Related discussion:
text: "The server MAY include the same Echo option value in several different responses and to different clients." Clarification based on Jim's review.
Code change:
HTTPS, which effectively treats the Fronting Server as an HTTP Proxy. In this solution, the client establishes a TLS connection to the Fronting Server, and then issues an HTTP Connect request to the <del> Hidden Server.  This will effectively establish an end-to-end HTTPS over TLS connection between the client and the Hidden Server, mitigating the issues described in nocontextsharing. </del> <ins> Hidden Server.  This will establish an end-to-end HTTPS over TLS connection between the client and the Hidden Server, mitigating the issues described in nocontextsharing. </ins> The HTTPS in HTTPS solution requires double encryption of every packet.  It also requires that the fronting server decrypts and relay

Related discussion:
text: …fix the various typos flagged by DKG, submit as WG draft.
Code change:
served out of cache, overriding the actual representation that the authoritative tenant provides. <del> Pushed responses for which an origin server is not authoritative (see connection-reuse) MUST NOT be used or cached. </del> <ins> Clients are required to reject pushed responses for which an origin server is not authoritative; see server-push. </ins> 10.5.

Related discussion:
text: In the HTTP/3 draft 30, section 4.4 on Server Push says and then adds in 10.4 (URL) I don't think normative requirements belong in security considerations except in reference to that requirement elsewhere. Also, requirements in general should clearly state who is responsible for implementing them, whereas the latter requirement implies a client (maybe). And sending CANCEL_PUSH is kind of like the MUST NOT, but not really the same thing; it seems a bit weak in response given that the server just tried to poison the client. I think the server MUST is an interop requirement because the client MUST NOT is a critical security requirement. I think both should be described in Server Push and merely noted in the Security Considerations, since they are really important. Way more important than the spec reads now. My guess is that this is editorial, but is the kind of thing that should be fixed before IESG last call.
The reason it's only a SHOULD CANCEL_PUSH is that the server can't know with certainty for which origins the client considers it authoritative. The server only knows for which origins it believes that it's authoritative. So having received a push the client considers out-of-bounds, the client can't know for sure whether it's a poisoning attempt or simply a difference in view. Yes, I think this is editorial, since the core request is to relocate existing text without changing the normative requirements.
Code change:
The creator of the group constructs an Init message as follows: <del> Fetch a UserInitKey for each member (including the creator) </del> <ins> Fetch a ClientInitKey for each member (including the creator) </ins> Identify a protocol version and cipher suite that is supported by all proposed members. Construct a ratchet tree with its leaves populated with the public <del> keys and credentials from the UserInitKeys of the members, and all other nodes blank. </del> <ins> keys and credentials from the ClientInitKeys of the members, and all other nodes blank. </ins> Generate a fresh leaf key pair for the first leaf

Related discussion:
text: Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 0 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by - - Last week, 8 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 5 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Code change:
*Collect:* The collector makes one or more requests to the leader in order to obtain the final output of the protocol.  Before the output can be computed, the aggregators (i.e, the leader and <del> helpers) need to have verified and aggregated a sufficient number </del> <ins> helper) need to have verified and aggregated a sufficient number </ins> of inputs.  Depending on the PA protocol, it may be possible for the aggregators to do so immediately when reports are uploaded. (See prio.)  However, in general it is necessary for them to wait until (a) enough reports have been uploaded and (b) the collector has made a request.  (See hits.) <del> [TODO: Say that the protocol involves multiple helpers.  The downside of using secret sharing is that the protocol requires at least two servers to be online during the entire data aggregation process.  To ameliorate this problem, we run the protocol in parallel with multiple helpers.] </del> 3. This section specifies a protocol for executing generic PA tasks.

Related discussion:
text: Partially addresses . (We also need to decide if/how to allow a particular PA protocol to use multiple helpers for privacy.) Right now, multiple helpers are used for redundancy in case one of the helpers dropped out. This removes this mechanism from the core protocol.
Squashed and rebased.
That's a good idea,
Hmm... Do we need to decide. Per our discussion on Wednesday, if the clients learn this out of band then we won't need this field at all because clients will get it separately and helpers don't need to know what the other helpers are, right?
My takeaway is that the parameters must contain all input needed to run the protocol, including the helpers. And all of this is configured out of band. You could punt everything except for the cryptographic goop out of the parameters structure, forcing clients to know the leader and helper and get their public keys out of band as well, which would be fine. It's just different. I think both work just fine, but I lean towards having params specify everything. It just seems simpler to me. That said... making public key discovery part of the client upload protocol here is more complex, I think. So, .
Squashed.
LGTM. Multiple helpers "for privacy" seems like it's inherently a per-protocol thing (Prio supports it, Hits does not). If and when we decide to address that, should we move this to the protocol-specific slot in PAParam?