jiebi/CodeConvo huggingface dataset:
Change:
uses peculiar names such as ES256 for ECDSA with SHA-256, A128 for AES-128, and Ed25519 for the curve edwards25519.  Algorithms need to be specified with enough parameters to make them completely <del> determined.  The MAC length MUST be at least 8 bytes.  EDHOC is currently only specified for use with key exchange algorithms of type ECDH curves, but any Key Encapsulation Method (KEM), including Post- </del> <ins> determined.  The MAC length MUST be at least 8 bytes.  Any cryptographic algorithm used in the COSE header parameters in ID_CRED is selected independently of the cipher suite.  EDHOC is currently only specified for use with key exchange algorithms of type ECDH curves, but any Key Encapsulation Method (KEM), including Post- </ins> Quantum Cryptography (PQC) KEMs, can be used in method 0, see pqc. Use of other types of key exchange algorithms to replace static DH authentication (method 1,2,3) would likely require a specification

Discussion:
I added a recommendation as well. I think this can be merged.
Looks fine to me, merging
states Then has which is using -15 (SHA-256/64), not -16 (SHA-256) for the hash. How was this decision arrived at?
Thanks for the comment. The hash algorithm used in x5t is independent of the EDHOC cipher suite, that should probably be mentioned in the draft. I will make a PR with some text on this.I don't think there was any discussion on this, but SHA-256/64 feels like a natural choice. As EDHOC integrity protects the whole certificate the length of the hash does not have any security relevance, the hash is just used to find the certificate, not to prove it is the correct one. Using SHA-256 would increase overhead with 24 bytes per message without any benefits. An implementation supporting SHA-256 can easily support SHA-256/64 (as it is just a truncated SHA-256).
NAME Than I need to run an update on test vectors for p256 as I have switched to SHA256. I will make an update to use SHA256/64 and pull request
Yes, please do. Using SHA-256 in x5t is just a waste of 24 bytes in message2 and message3. We should maybe give some recommendations in the draft regarding this, but I think it is hard to give normative requirements as x5t is just one example and future COSE header parameters and EAD might use cryptographic algorithms. The algortithms in X.509 in another example on algorithms not controlled by the cipher suite, Somebody might use a cert with a P-521 authentication key where the CA used RSA-PSS to sign the certificate together with cipher suite 2/3. Maybe the draft should recommend the use of algorithms from the ciphersuite also in cose headers, EAD, X.509, CWT, etc. In the case of x5t the recommendation could be to use the same hash function but with as much truncation as possible.
Can we close this now?
Works for me - thanks.
Change:
blind RSA documents also apply in the Privacy Pass use-case. Considerations related to broader privacy and security concerns in a multi-Client and multi-Issuer setting are deferred to the <del> Architecture document ARCHITECTURE. </del> <ins> Architecture document ARCHITECTURE.  Moreover, deployment-specific considerations regarding Client privacy when running the issuance protocol, especially with respect to Client-specific identifiers such as IP addresses that are revealed to the Attester and Issuer during issuance, are also discussed in Section 4 of ARCHITECTURE. </ins> Beyond these considerations, it is worth highlighting the fact that Client TokenRequest messages contain truncated token key IDs.  This

Discussion:
Split attesters and issuers are not required for the basic issuance protocol, but we should explain (in a sentence or so) that if you are using a split attester, the client sends the request to the attester, and the attester forwards the request to the issuer if it accepts the client.
For better clarity and consistency, I recommend adding a sequence diagram depicting this model considering the sequence diagrams that outline other models.
Agreed. This would be a good thing to include. I'll take this and add it.
In a split attester/issuer scenario, the issuer needs to authenticate the attester in some way (e.g., TLS client cert). In a combined attester/issuer scenario, the actual protocol might be something proprietary (or covered by an as-yet-unwritten spec) that extends the base issuance protocol, e.g., adding an attestation header, user login cookie, or adding extra challenge/response rounds to confirm identity. If these issues are "in scope" then they should be defined here. If they are "out of scope" then it would be helpful context to reader to describe what is expected to be handled by a proprietary extension.
NAME we discuss these things in the architecture document where deployment models are discussed. But we should mention the impact that different deployment models have on the basic issuance protocol in the -protocol spec.
Change:
ECPointFormat ECCurveType <ins> IANA is requested to prepend "TLS" to the names of the previous three registries. </ins> For each name space, this document defines the initial value assignments and defines a range of 256 values (NamedCurve) or eight values (ECPointFormat and ECCurveType) reserved for Private Use.  The

Discussion:
if both draft-ietf-tls-iana-registry-updates and this draft add TLS to the registry names then all the registry will have a consistent naming scheme.
Ship it
Shipped
LGTM
Change:
does not lose any information from the JSON value.  EXI uses the XML types. <del> New entries can be added to the registration by either Expert Review or IESG Approval as defined in RFC5226.  Experts should exercise their own good judgment but need to consider that shorter labels should have more strict review. </del> <ins> New entries can be added to the registration by Expert Review as defined in RFC8126.  Experts should exercise their own good judgment but need to consider that shorter labels should have more strict review. </ins> All new SenML labels that have "base" semantics (see senml-base) MUST start with character 'b'.  Regular labels MUST NOT start with that

Discussion:
Is there a reason we keep it for label registrations?
NAME Good point; same considerations apply to both. Will fix.
From Peter's review: or IESG Approval as defined in [RFC5226]. confusion.
It means that if something needs to happen and AD can make it happen without firing the expert which creates so much bad will that an AD would much rather wit 6 months for the expert to respond. All it says if the AD can do this or the expert can. I don't care much.
NAME Our AD had preference to have just Expert review in order for people to not think there are two paths but show clear preference. If things are slow, the IESG is next on the appeal path, so ADs can do it anyway.
Addressed by PR
Note that even with we still have the dual policy on the labels. Bug or feature?
On the "Our AD had preference to have just Expert review " ... I'm fine with this.
NAME The dual policy was fixed with the latest commit. Although perhaps we want to have more guidelines for the expert to follow?
Change:
Within the data m= section, the "a=mid", "a=ice-ufrag", "a=ice-pwd", "a=candidate", "a=fingerprint", and "a=setup" lines MUST be included <del> as mentioned above, along with an "a=fmtp:webrtc-datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </del> <ins> under the conditions described above, along with an "a=fmtp:webrtc- datachannel" line and an "a=sctp-port" line referencing the SCTP port number as defined in I-D.ietf-mmusic-sctp-sdp, Section 4.1. </ins> If "a=group" attributes with semantics of "BUNDLE" are offered, corresponding session-level "a=group" attributes MUST be added as

Discussion:
NAME NAME Is this approximately right?
Looks close enough to me - lets land this then tune with future PRs
LG with nits
Change:
When bytes in flight is smaller than the congestion window and sending is not pacing limited, the congestion window is under- <del> utilized.  When this occurs, the congestion window SHOULD NOT be increased in either slow start or congestion avoidance.  This can happen due to insufficient application data or flow control limits. </del> <ins> utilized.  This can happen due to insufficient application data or flow control limits.  When this occurs, the congestion window SHOULD NOT be increased in either slow start or congestion avoidance. </ins> A sender that paces packets (see pacing) might delay sending packets and not fully utilize the congestion window due to this delay.  A

Discussion:
Addresses comments 2, 4, 7, 8, 9, and 11.
one tiny suggestion, but lgtm -- thanks for doing this!
Change:
By definition, an application error is defined by the application- level protocol running on top of QUIC (e.g., HTTP/3). <del> As such, we cannot define it here directly.  Though we provide an extension point through the use of the CDDL "socket" mechanism. </del> <ins> As such, it cannot be defined here directly.  Applications MAY use the provided extension point through the use of the CDDL "socket" mechanism. </ins> Application-level qlog definitions that wish to define new ApplicationError strings MUST do so by extending the

Discussion:
Work towards resolving , for the QUIC events document.
This is great. There are 2-3 instances in the h3 document as well that could use similar re-wording. I'll post a PR for that
Change:
Clients then encrypt the second ClientHelloInner using this new HPKE context.  In doing so, the encrypted value is also authenticated by <del> echo_hrr_key. </del> <ins> echo_hrr_key.  The rationale for this is described in flow-hrr- hijack. </ins> Client-facing servers perform the corresponding process when decrypting second ClientHelloInner messages.  In particular, upon

Discussion:
Addresses . This is for motivating some of our design decisions (and documenting what we know along the way). I meant to do this a while ago, but never got around to it. In particular, it describes why we have the following three bindings: Transcript to ECHO secret (to prevent client reaction attacks). CH1 to CH2 (to prevent HRR oracles). ClientHello to resumption PSK binder (to prevent resumption oracles). I'm sure the language and presentation can be improved, so suggestions to that effect are very much welcome! cc NAME NAME NAME NAME NAME NAME NAME
Thanks for the feedback! I incorporated your suggestions and clarified a few more things. I'm merging as-is since they seemed mostly editorial.
Addressed in .
Change:
state = handshake_confirmed <del> 4.8. </del> <ins> 4.7. </ins> e.g., path_updated

Discussion:
Connection retried was never properly specced. The main reason is that a retried connection is completely separate from the original connection attempt, except for the value, and as such is usually logged in a separate file / separate context from the original connection qlog data. Current qlog deployments either have other ways of correlating retried connections with the original attempts, or don't need to do this. Either way, there is no tangible need for at this time.
I don't think that's correct. You also take your Connection IDs with you to the new connection. quic-go logs it to the same file, as it is the same connection attempt. I don't see value in though.
Change:
measurement value in more than one report if the leader responds with HTTP status code 200 OK and an empty body. <del> If the leader does not recognize the task ID, then it responds with HTTP status code 400 Bad Request and an error of type "unrecognizedTask". </del> <ins> If the leader does not recognize the task ID, then it MUST abort with error "unrecognizedTask". </ins> The leader responds to requests whose leader encrypted input share uses an out-of-date "HpkeConfig.id" value, indicated by <del> "HpkeCiphertext.config_id", with HTTP status code 400 Bad Request and an error of type 'outdatedConfig'.  Clients SHOULD invalidate any cached aggregator "HpkeConfig" and retry with a freshly generated Report.  If this retried report does not succeed, clients MUST abort and discontinue retrying. </del> <ins> "HpkeCiphertext.config_id", with error of type 'outdatedConfig'. Clients SHOULD invalidate any cached aggregator "HpkeConfig" and retry with a freshly generated Report.  If this retried report does not succeed, clients MUST abort and discontinue retrying. </ins> The Leader MUST ignore any report pertaining to a batch that has already been collected.  (See early-input-share-validation for

Discussion:
Addresses issue URL
I don't think that's true. : >DAP servers can return responses with an HTTP error response code (4XX or 5XX). For example, if the client submits a request using a method not allowed in this document, then the server MAY return HTTP status code 405 Method Not Allowed. So maybe we do need to specify that the status should be 400 (client error) and not 500 (server error). FWIW, has several places where it dictates HTTP 400 inline in the text, so I think it's OK for us to do that. I agree we should be consistent about using MUST throughout the document. Curiously, ACME has some examples where the 400 error response is a MUST, but the 200 success response has no all-caps applied to it. :
NAME NAME thanks for the comments, I've specified 400 in the errors section and shortened the words elsewhere.
Error types are either double quoted or code formatted, the text seems to encourage both: But these format are not consistent, some examples: It would be much clearer if we choose one style and make it consistent across the text.
The current protocol text doesn't specify what participants should do when a task ID is not recognized, there are two places unrecognized task are mentioned: In the table, it has: mentions "404 Not Found and an error of type unrecognizedTask", which seems to conflict with most implementation's choice of error code 400 (NAME ) The text should specify error 400 with type is used in every API that receives unrecognized task ID.
This would be useful I think. Would you mind sending a PR, NAME
NAME will do, create this issue to remind myself.
PR merged
Change:
ascending order by "ExtensionType", and a single "ExtensionType" MUST NOT appear in both lists.  If the "version", "dh_group", or "signature_algorithm" element appears in the template, the <del> corresponding "ExtensionType" MUST NOT appear here. </del> <ins> corresponding "ExtensionType" MUST NOT appear here.  The "pre_shared_key" "ExtensionType" MUST NOT appear in either list. </ins> OPEN ISSUE: Are there other extensions that would benefit from special treatment, as opposed to hex values.

Discussion:
NAME Ping. This is the last thing blocking a refreshed cTLS draft.
Just missed this. LGTM
Change:
A KeyPackage object specifies a ciphersuite that the client supports, as well as providing a public key that others can use for key <del> agreement.  The client's identity key can be updated throughout the </del> <ins> agreement.  The client's signature key can be updated throughout the </ins> lifetime of the group by sending a new KeyPackage with a new <del> identity; the new identity MUST be validated by the authentication service. </del> <ins> signature key; the new signature key MUST be validated by the authentication service. </ins> When used as InitKeys, KeyPackages are intended to be used only once and SHOULD NOT be reused except in case of last resort.  (See

Discussion:
The public key in a credential is introduced without a special name and the field in the BasicCredential is currently called public_key, which is not very expressive. A few paragraphs below, it is referenced as "Identity Key" or simply "Identity", which is a bit misleading, as Credentials are supposed to contain an additional "identity" which is not the key. I propose we clear up the terminology a bit here and refer to the public key contained in a Credential as "Signature Key".
Change:
along with allowing secure multiparty RTP with loose coordination and efficient communication of per-source keys. <ins> In cases where the DTLS termination point is more trusted than the media relay, the protection that DTLS affords to EKT key material can allow EKT keys to be tunneled through an untrusted relay such as a centralized conference bridge.  For more details, see I-D.ietf-perc- private-media-framework. </ins> 5.1. DTLS-SRTP RFC5764 uses an extended DTLS exchange between two peers to

Discussion:
This PR addresses IESG review comments from Ben Kaduk, Alexey Melnikov, and Eric Rescorla (while he was still SEC AD).
LGTM
Change:
be encrypted the packet in repair mode (i.e., with only the hop-by- hop key). <ins> If the Media Distributor were to cache the inner, E2E-encrypted payload and retransmit that with an RTX OSN field prepended, then the modifications to the payload would cause the inner integrity check to fail at the receiver. </ins> A typical RTX receiver would decrypt the packet, undo the RTX transformation, then process the resulting packet normally by using the steps in decrypt. 7.2. <del> When using RED RFC2198 with double, the primary encoding MAY contain RTP header extensions and CSRC identifiers but non primary encodings cannot. The sender takes encrypted payload from the cached packets to form the RED payload.  Any header extensions from the primary encoding are copied to the RTP packet that will carry the RED payload and the other RTP header information (SSRC, SEQ, CSRC, etc.) are set to the same as the primary payload.  The RED RTP packet is then encrypted in repair mode and sent. The receiver decrypts the payload to find the encrypted RED payload. Note a media relay can do this decryption as the packet was sent in repair mode that only needs the hop-by-hop key.  The RTP headers and header extensions along with the primary payload and PT from inside the RED payload (for the primary encoding) are used to form the encrypted primary RTP packet which can then be decrypted with double. The RTP headers (but not header extensions or CSRC) along with PT from inside the RED payload corresponding to the redundant encoding are used to from the non-primary payloads.  The time offset and packet rate information in the RED data MUST be used to adjust the sequence number in the RTP header.  At this point the non primary packets can be decrypted with double. Note that Flex FEC I-D.ietf-payload-flexible-fec-scheme is a superset of the capabilities of RED.  For most applications, FlexFEC is a better choice than RED. </del> <ins> When using RED RFC2198 with double, the processing at the sender and receiver is the same as when using RED with any other SRTP transform. The main difference between double and any other transform is that in an intermediated environment, usage of RED must be end-to-end.  A Media Distributor cannot synthesize RED packets, because it lacks access to the plaintext media payloads that are combined to form a RED payload. Note that FlexFEC may often provide similar or better repair capabilities compared to RED.  For most applications, FlexFEC is a better choice than RED; in particular, FlexFEC has modes in which the Media Distributor can synthesize recovery packets. </ins> 7.3.

Discussion:
This PR responds to IESG review comments from Magnus Westerlund, except for his comments on RED, which I haven't quite figured out how to address yet.
LGTM with nits
Change:
Section 4.2.10 of TLS13).  It then sends the application data in 0-RTT packets. <del> Early data within the TLS connection MUST NOT be used.  As it is for other TLS application data, a server MUST treat receiving early data on the TLS connection as a connection error of type PROTOCOL_VIOLATION. </del> 4.6. A server accepts 0-RTT by sending an early_data extension in the

Discussion:
This is a point NAME makes in , but it probably pays to make it more clearly. This was possible in earlier iterations of the draft, so it's worth stamping out residual mentions.
Section 4.5 of quic-tls: Early data within the TLS connection MUST NOT be used. As it is for other TLS application data, a server MUST treat receiving early data on the TLS connection as a connection error of type PROTOCOL_VIOLATION. As there is no way to express TLS application data (no record headers!) I believe there is no way for the proposed error condition to occur. I propose we strike the paragraph, though we might mention that this condition is impossible for clarity.
Change:
IANA is requested to assign CoAP Content-Format IDs for the SenML PATCH and FETCH media types in the "CoAP Content-Formats" sub- <del> registry, within the "CoRE Parameters" registry RFC7252.  All IDs are assigned from the "IETF Review or IESG Approval" range.  The assigned IDs are show in tbl-coap-content-formats. </del> <ins> registry, within the "CoRE Parameters" registry RFC7252.  The assigned IDs are shown in tbl-coap-content-formats. </ins> 5.2.

Discussion:
“Are show”
Should clarify that null value for deleting records should always be in "v" field regardless of the value type used in the Record.
Also example of deleting would be useful
Change:
Although still a work in progress, I-D.pfister-capport-pvd proposes a mechanism for User Equipment to be provided with PvD Bootstrap <del> Information containing the URI for the JSON-based API described in section_api. </del> <ins> Information containing the URI for the API described in section_api. </ins> 2.3. The purpose of a Captive Portal API is to permit a query of Captive Portal state without interrupting the user.  This API thereby removes <del> the need for User Equipment to perform clear-text "canary" HTTP queries to check for response tampering. </del> <ins> the need for User Equipment to perform clear-text "canary" (see app- additional) queries to check for response tampering. </ins> The URI of this API will have been provisioned to the User Equipment. (Refer to section_provisioning).

Discussion:
One of the reviewers had a bunch of nits. This addresses all of them in one commit. See The issue for the list of nits.
Benjamin writes: Clarify to implementations of captive portals -> "huge variety of preexisting portals and ..." Take the suggestion. Is it sufficient to just say "SHOULD have a non-spoofable mechanism..."? How about "... the operating system could avoid updating the default route to a device on the captive WiFi network until ..." Note: We're changing MAY to could here to address Alvaro's review comment. This is a bit ambiguous. It's meant to basically say: "Stop interacting with the API". We canprobably rephrase to "If certificate validation fails, the User Equipment MUST NOT make any calls tothe API Server". Remove HTTP Do it Do it The identifier. Will update. Fix it. Do it. Do it.
Working on this. Will have a PR up tomorrow.
LGTM. Some small tweaks suggested.
Change:
Server Hello message is obfuscated using the Initial secret. The Client Completion datagram does not expose any additional <del> information; however, recognizing it can be used to determine that a </del> <ins> information; however, as the destination connection ID is server- selected, it usually is not the same ID than in the Client Initial datagram.  Client Completion datagram can be used to determine that a </ins> handshake has completed (see sec-confirm), and for three-way handshake RTT estimation as in sec-rtt.

Discussion:
this addresses a comment from NAME in issue
In the interests of timely completion of the document, will go ahead and merge this; please open an issue if this doesn't work for you NAME :)
... doesn't make it clear that only the Initial from the client (and only those sent before receiving packets from the server) contain a Destination Connection ID field that can be used to decrypt the packet. Any initial from the server, or any initial sent by a client after receiving Initial packets from the server, probably won't work.
Hmm, this is the last paragraph. Too late?
More broadly, it would be nice if Sec 2.4 discussed the property that the server CID changes pretty much immediately. We wouldn't want people to bind to a 2-tuple of CIDs and have that immediately fail.
NAME I create PR based on your comment. Is that sufficient? NAME which section are you talking about?
I think will fix NAME comment here.