jiebi/CodeConvo huggingface dataset:
Change:
As described in SIGMA, different levels of identity protection are provided to the Initiator and the Responder.  EDHOC protects the credential identifier of the Initiator against active attacks and the <del> credential identifier of the Responder against passive attacks.  The roles should be assigned to protect the most sensitive identity/ identifier, typically that which is not possible to infer from routing information in the lower layers. </del> <ins> credential identifier of the Responder against passive attacks.  An active attacker can get the credential identifier of the Responder by eavesdropping on the destination address used for transporting message_1 and send its own message_1 to the same address.  The roles should be assigned to protect the most sensitive identity/identifier, typically that which is not possible to infer from routing information in the lower layers. </ins> Compared to SIGMA, EDHOC adds an explicit method type and expands the message authentication coverage to additional elements such as

Discussion:
Good to describe that the known attack on Sigma is that the attacker create a new message_1, no attack is known where an active attacker modifies the ongoing connection (even if the lack of such attacks is likely not proven).
This seems ready to merge
Current draft says: "EDHOC protects the credential identifier of the Initiator against active attacks and the credential identifier of the Responder against passive attacks." Should probably point out that active attack would be a new message1 to the lower layer address as the other message1.
Change:
untrustworthy from the perspective of the JSEP implementation.  Thus, the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious <del> ones.  This is particularly relevant when we consider the SDP that is passed to setLocalDescription.  While correct API usage requires that the application pass in SDP that was derived from createOffer or </del> <ins> ones.  This is particularly relevant when one considers the SDP that is passed to setLocalDescription.  While correct API usage requires that the application pass in SDP that was derived from createOffer or </ins> createAnswer, there is no guarantee that applications do so.  The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead.

Discussion:
Explain more about use of max-bundle by implementations Explain sess-id limits Remove use of "we" throughout
Change:
04: <del> Resource oriented HTTP API. (#278, #398, #400) (*) </del> <ins> Introduce resource oriented HTTP API. (#278, #398, #400) (*) </ins> <del> Clarify security requirements for choosing VDAF verify key (#407, #411). </del> <ins> Clarify security requirements for choosing VDAF verify key. (#407, #411) </ins> <del> Clients must provide nonce and random input when sharding inputs. (#394, #425) (*) </del> <ins> Require clients to provide nonce and random input when sharding inputs. (#394, #425) (*) </ins> <del> Collection message now includes interval of time spanned by constituent reports. (#397, #403) (*) </del> <ins> Add interval of time spanned by constituent reports to Collection message.  (#397, #403) (*) </ins> Update share validation requirements based on latest security analysis. (#408, #410)

Discussion:
We need for this change to make sense.
DAP-04 will need some routine changes: [x] Update version tags for HPKE to () [x] Bump VDAF-03 to 05 () [x] Update change log () [x] Run spell check ()
Change:
Agent, which, if parsed successfully, will be added to the current and/or pending remote description according to the rules defined for Trickle ICE.  If the MID, m-line index, or candidate string provided <del> in the ICE candidate is invalid, an error is generated.  Connectivity checks will be sent to the new candidate. </del> <ins> in the ICE candidate is invalid, an error is generated.  If present, ufrag is used to determine which generation of ICE candidates the candidate belongs to; this resolves ambiguities when trickle ICE is in progress during an ICE restart.  If the ufrag is present and does not match any remote description, an error is generated.  If the ufrag is absent, the candidate MUST be assumed to belong to the most recently applied remote description.  Connectivity checks will be sent to the new candidate. </ins> This method can also be used to provide an end-of-candidates indication (as defined in I-D.ietf-ice-trickle) to the ICE Agent for

Discussion:
…sane peer.
NAME PTAL.
Just a quick drive-by review. LGTM with nits
Change:
The values in this registry shall be allocated under "IETF Review" policy for values strictly smaller than 64, and under "Specification <del> Required" policy otherwise (see RFC5226 for the definition of </del> <ins> Required" policy otherwise (see RFC8126 for the definition of </ins> relevant policies).

Discussion:
Addresses .
Just need to swap out RFC5226 with RFC8126.
Fixed by df35ba55dc4ffee1eb616898e044384782817a89, thanks!
Change:
The following subtype relationships depend on coercion: <del> "OptionalNode" is a subtype of "OptionalValue" via coercion since the "OptionalNode" instance "Node(n)" can be coerced to the "OptionalValue" instance "Value(v)", where "v" is the value of the node "n". </del> <ins> "OptionalNodeType" is a subtype of "OptionalValueType" via coercion since the "OptionalNodeType" instance "Node(n)" can be coerced to the "OptionalValueType" instance "Value(v)", where "v" is the value of the node "n". </ins> <del> "OptionalNode" is a subtype of "OptionalNodes" via coercion since the "OptionalNode" instance "Node(n)" can be coerced to the "OptionalNodes" instance "Nodes(l)", where "l" is a nodelist consisting of just the node "n". </del> <ins> "OptionalNodeType" is a subtype of "OptionalNodesType" via coercion since the "OptionalNodeType" instance "Node(n)" can be coerced to the "OptionalNodesType" instance "Nodes(l)", where "l" is a nodelist consisting of just the node "n". </ins> The type correctness of function expressions can now be defined in terms of this type system.

Discussion:
This is literally just a renaming of the names in the Type column of Table 13. I also noticed that the description doesn't account for non-nodelist inputs. I'll open another issue for that.
If I'm reading the right, it looks like the term is being used to mean different things depending on which column it's in. In column 1 ("Type") or column 3 ("Subtypes"), it's referring to the type system we're creating. In column 2 ("Abstract Instances"), it's referring to the underlying JSON(ish) value kind, i.e. , , , etc, plus . I think having the same word to define these things can be confusing for the reader, and maybe we need something else in one of these places to indicate the distinction. We've already done this for the type to distinguish it from the value.
I'm not sure there is a really good alternative. We could use for abstract instances, but in the rest of the spec, "value" implies a JSON value, so this doesn't seem quite right.
If "value" implies a JSON value (corresponding to the middle column), then we should change the others (the type name). It really is confusing.
In the interim, we decided to append the type names with "Type". I will create a PR for this.
I'm going to wait for to complete before going forward with this as they change the same chunk of text.
Thanks. That's why I am trying to tidy up and get it merged ASAP.
Thanks!
Change:
"AggregateContinueReq.task_id"'s parameters except its own, the leader sends a POST request to "[aggregator]/aggregate" with AggregateContinueReq as the payload and the media type set to <del> "message/dap-aggregate-continue-req". </del> <ins> "application/dap-aggregate-continue-req". </ins> 4.4.2.2.

Discussion:
In IANA all media types seem to be of "application" type instead of "message" type, this PR is to align the mismatch in the protocol description and adapt to the media types specified in IANA.
Nice catch!
Change:
thousands of IP addresses.  Despite these limitations, IP blocking is extremely effective because the user needs to proxy their traffic through another destination to circumvent this type of <del> identification. </del> <ins> identification.  In addition, IP blocking is effective against all protocols above IP, e.g.  TCP and QUIC. </ins> Port-blocking is generally not useful because many types of content share the same port and it is possible for censored applications to

Discussion:
This pull request adds findings about QUIC censorship. The changes are the following: References to my 2021 paper and 2022 OTF blog post on QUIC and HTTP/3 censorship. Details about QUIC's initial encryption of the ClientHello with a non-secret key. This initial encryption differs from traditional TLS over TCP. Requirements for the censor to apply Deep Packet Inspection to QUIC packets. Case of SNI blocking of QUIC traffic in Russia. Shallow packet inspection of QUIC traffic: IP blocking, UDP endpoint blocking, protocol blocking. Packet dropping as only observed interference method. Considerations on packet injection and connection reset in the context of QUIC.
Change:
[!@RFC5246].  This section provides an example of what the bits on the wire would look like for the <del> message that advertises support for both SRTP_AEAD_AES_128_GCM and SRTP_AEAD_AES_256_GCM RFC7714. </del> <ins> message that advertises support for both DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM I-D.ietf-perc-double. RFC Editor Note: Please replace the values 0009 and 000A in the following two examples with whatever code points IANA assigned for DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM and DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM. </ins> Thus, the encoding on the wire presented here in network bytes order would be this stream of octets:

Discussion:
This is a rebased version of from last October.
You want the MDD to be told "use DOUBLEAEADAES128GCMAEADAES128GCM", when it will actually only do have of it?
Another question: can we change the words "if IANA assigned" to something concrete? That is, we just make this assumption. Then, insert a note to RFC Editor to adjust these values as necessary before publication?
On MDD told to do double ... The TLS has to negotiate double or the endpoints will not do double. The endpoints can only do what is negotiated inside of TLS. Keep in mind our desing goal here is to minimize the code changes outside libsrtp to the endpoints and not worry too much about the amount of code on MDD and KDD. On IANA - yah fine with changing this to an RFC editor note to change values to whatever IANA assigned. I think we are at the point where we could have the chairs ask IANA for an early assignment to help pre standard implementations write code.
Change:
Note: In versions of TLS prior to TLS 1.3, this extension was named "elliptic_curves" and only contained elliptic curve groups.  See <del> RFC4492 and I-D.ietf-tls-negotiated-ff-dhe.  This extension was also used to negotiate ECDSA curves.  Signature algorithms are now negotiated independently (see signature-algorithms). </del> <ins> RFC4492 and RFC7919.  This extension was also used to negotiate ECDSA curves.  Signature algorithms are now negotiated independently (see signature-algorithms). </ins> The "extension_data" field of this extension contains a "NamedGroupList" value:

Discussion:
draft-ietf-tls-negotiated-ff-dhe is now RFC 7919. draft-mattsson-tls-ecdhe-psk-aead is now draft-ietf-tls-ecdhe-psk-aead.
Do we even need a reference to draft-ietf-tls-ecdhe-psk-aead with the new negotiation syntax?
NAME I removed it from the reference section. It was used in previous versions. But it is no longer referenced to by any text in the spec since version 15.
Change:
value of the SETTINGS_QPACK_MAX_TABLE_CAPACITY parameter (configuration) received from the decoder.  The decoder MUST treat a new dynamic table capacity value that exceeds this limit as a <del> connection error of type "HTTP_QPACK_ENCODER_STREAM_ERROR". </del> <ins> connection error of type QPACK_ENCODER_STREAM_ERROR. </ins> Reducing the dynamic table capacity can cause entries to be evicted; see eviction.  This MUST NOT cause the eviction of entries which are

Discussion:
I noticed that the QPACK error codes still started with the HTTPQPACK prefix, while the HTTP document has shifted to H3 as the prefix. I shortened the QPACK prefix to simply "QPACK", though "H3QPACK" could work, too. Along the way, I noticed that backticks were sometimes, but not always, used when referring to the error code names. We haven't been in the HTTP document, so I reconciled them to not. Again, this could go the opposite way. I also noticed that the settings are "SETTINGSQPACK" except in the IANA registration where they're simply "QPACK". I didn't touch those, but am open to feedback on whether that's worth trimming/reconciling.
NAME I don't need your approval, but I kind of do need NAME
Well, you did ask :)
NAME could you review and potentially merge?
Do it. You don't need my approval to do something that is so self-evidently a good idea.QPACK_ prefix WFM
Change:
current state using the Add message.  This information is encrypted for the new member using HPKE.  The recipient key pair for the HPKE encryption is the one included in the indicated ClientInitKey, <del> corresponding to the indicated ciphersuite. </del> <ins> corresponding to the indicated ciphersuite.  The "add_key_nonce" field contains the key and nonce used to encrypt the corresponding Add message; if it is not encrypted, then this field MUST be set to the null optional value. </ins> In the description of the tree as a list of nodes, the "credential" field for a node MUST be populated if and only if that node is a leaf

Discussion:
Prior drafts enabled encryption of handshake messages, via the common framing structure. This had the unfortunate effect of making it impossible to add new members! If an Add is sent encrypted, then the new joiner had no way to get the key to decrypt it. This PR adds the key and nonce for the Add encryption to the corresponding WelcomeInfo structure. This maintains the confidentiality of the Add because the WelcomeInfo is encrypted to the new joiner, while providing the new joiner the key material it needs to decrypt the Add.
I think we'll need to carefully study the impact of this one but this seems fine for now. In the future aligning the way we do and (for the new member) which both are PKE operations will probably allow us to merge and and remove that issue all together.
Change:
In many M2M applications, direct discovery of resources is not practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by <del> employing an entity called a Resource Directory (RD), which hosts registrations of resources held on other servers, allowing lookups to be performed for those resources.  This document specifies the web </del> <ins> employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources.  The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD.  This document specifies the web </ins> interfaces that a Resource Directory supports for web servers to <del> discover the RD and to register, maintain, lookup and remove resource descriptions.  Furthermore, new link attributes useful in conjunction with an RD are defined. </del> <ins> discover the RD and to register, maintain, lookup and remove information on resources.  Furthermore, new link attributes useful in conjunction with an RD are defined. </ins> 1.

Discussion:
I remember keeping web-links where it was beneficial to the text IMO OK with suggested change Peter chrysn schreef op 2018-11-09 16:43: Links: [1] URL [2] URL [3] URL
I'm fine with "Web Links" not being that prominent in the architecture any more; however, two mentions have survived in the three paragraphs above fig-arch, was that intentional?
Change:
This document describes the reference architecture, functional and security requirements for the Messaging Layer Security (MLS) protocol.  MLS provides a security layer for group messaging <del> applications with from two to a large number of clients.  It is meant to protect against eavesdropping, tampering, and message forgery. </del> <ins> applications, where the number of clients ranges from two to many. It is meant to protect against eavesdropping, tampering, and message forgery. </ins> 1.

Discussion:
This PR aims to fix some odd formulations, whilst maintaining the intended meaning of the sentences.
Thanks NAME !
Change:
Note that, as a PSK may have a different lifetime than an update, it does not necessarily provide the same Forward Secrecy (FS) or Post- <del> Compromise Security (PCS) guarantees as a Commit message. </del> <ins> Compromise Security (PCS) guarantees as a Commit message.  Unlike the key pairs populated in the tree by an Update or Commit, which always freshly generated, PSKs may be pre-distributed and stored.  This creates the risk that a PSK may be compromised in the process of distribution and storage.  The security that the group gets from injecting a PSK thus depends on both the entropy of the PSK and the risk of compromise.  These factors are outside of the scope of this document, but should be considered by application designers relying on PSKs. </ins> Each PSK in MLS has a type that designates how it was provisioned. External PSKs are provided by the application, while recovery and re-

Discussion:
Most of these were stale; see comments for more specifics. I opened as a general issue arising from the final TODO.
Discussed at 20211004 interim, will merge after adding text in comment. NAME create new issue for multiple PSKs and PR for cascading HKDF.
The "Sequencing of State Changes" and "Application Messages" sections date to very early in the document's life, and probably need some updates to reflect current thinking.
Closing for now, might reopen based on WGLC review.
Change:
Encrypt (seal) "request" with "aad" as associated data using "context", yielding ciphertext "ct". <del> Concatenate the three values of "aad", "enc", and "ct", yielding an Encapsulated Request "enc_request". </del> <ins> Concatenate the values of "aad", "enc", and "ct", yielding an Encapsulated Request "enc_request". </ins> Note that "enc" is of fixed-length, so there is no ambiguity in parsing this structure.

Discussion:
One question we might want to ask (even though I think we have the right answer already) is: should be included in AAD? I also removed the padding text, since we moved that to the bhttp spec.
It's a reasonable question, but I think we can safely assume that a single key can't be used with multiple KEMs.
In principle it might be possible, but I think we should prohibit it.
Change:
An "a=ice-options" line, with the "trickle" option, as specified in I-D.ietf-mmusic-trickle-ice, Section 4. <del> For each candidate that has been gathered during the most recent gathering phase, an "a=candidate" line, as specified in RFC5245, Section 4.3., paragraph 3. For the current default candidate, a "c=" line, as specified in RFC5245, Section 4.3., paragraph 6.  If no candidates have been gathered yet, the default candidate should be set to the 'null' value defined in I-D.ietf-mmusic-trickle-ice, Section 5.1. </del> An "a=fingerprint" line, as specified in RFC4572, Section 5; the algorithm used for the fingerprint MUST match that used in the certificate signature.

Discussion:
Update of ekr's PR . Details: Initial offers/answers have no candidates Add canTrickle property Add text regarding a=end-of-candidates Clarify dummy/null address/port stuff
lgtm
NAME can you review this before Friday?
I'll try and carefully read this tomorrow morning but I'm running out of time for today. It looked good on my quick skim of it but I want to read it carefully but don't expect to have issues with it.
On this morning's Editor's Call we discussed the topic of what trickle indicators should appear in the SDP. The trickle draft prescribes two indicators: a=ice-options:trickle a=end-of-candidates However, as agreed at the interim, JSEP agents always do trickle and just expose a canTrickle property. Accordingly, the conclusion was to interpret a=ice-options:trickle as "I can do trickle" (this is consistent with half-trickle) and thus JSEP agents always send it, even if canTrickle=false. So, we should insert a=end-of-candidates when gathering is done to mean "I am done trickling". This means that JSEP agents will generate a=ice-options:trickle in response even to offers which do not contain it. However, offerers should already ignore that. As before, it's up to the app to wait for all the candidates before sending the offer if canTrickle=false
Agreed
Sounds good!
Fixed by
Change:
The Issuer parameters can be obtained from an Issuer via a directory object, which is a JSON object (RFC8259, Section 4) whose values are <del> other JSON values (RFC8259, Section 3) for the parameters. </del> <ins> other JSON values (RFC8259, Section 3) for the parameters.  The contents of this JSON object are defined in directory-values. </ins> <del> Each "token-keys" JSON object contains the following fields and corresponding raw values. </del> <ins> Each "token-keys" JSON object contains the fields and corresponding raw values defined in tokenkeys-values. </ins> Issuers MAY advertise multiple token-keys for the same token-type to support key rotation.  In this case, Issuers indicate preference for

Discussion:
The caption for is: "'xxx' Well-Known URI", which is probably wrong.
This is a bit of a hard one to decide for me, but I think that you want to define a media type for the JSON directory. I know that in most cases the content will be served from a .well-known location, but that isn't always.
What would be the benefit of a media type here if the content will always be JSON? That is, I don't see how a media type would influence consumers of the resource.
So that you can make it clear that it is this specific JSON, as opposed to some other JSON.
The table appears without the text referring to it, even with an "as follows". It might be better to reference it directly.
Change:
shown with a '*'.  Once completed, endpoints are able to exchange application data. <del> An endpoint verifies support for Explicit Congestion Notification </del> <ins> An endpoint validates support for Explicit Congestion Notification </ins> (ECN) by observing whether the ACK frames acknowledging the first packets it sends carry ECN counts, as described in ecn-validation.

Discussion:
URL verified. Consistency in terms helps.
mentions /verification/ of ECN but defines /validation/ of ECN.: In section 9.2: the term /verify/ is used 3 times, but not explained: /verifies ECN capability/ and /verifies ECN support/ should these both be /validates ECN support/ ? … ALSO is there a difference between ECN support and ECN capability? - I didn’t expect a subtle difference, can we use one set of words instead? (and sorry if I compounded any confusion in the terms...)