jiebi/CodeConvo huggingface dataset:
Change:
the pre-shared key to be used with a given handshake in association with a PSK or (EC)DHE-PSK cipher suite (see RFC4279 for background). <ins> All clients MUST send a valid "pre_shared_key" extension when offering any PSK cipher suites.  Servers MUST NOT negotiate use of a PSK cipher suite unless the client supplies a "pre_shared_key" extension.  If the extension is not provided and no alternative cipher suite is available, the server MUST close the connection with a fatal "missing_extension" alert.  (see mti-extensions) </ins> The "extension_data" field of this extension contains a "PreSharedKeyExtension" value:

Discussion:
Modified extension requirements based on recent list discussion. It's a little verbose with repeated boilerplate, but it's clear no matter which section you read now. I've also moved the relevant requirements up top to a consistent place for each extension's section. The level of strictness here is now: If attempting to negotiate and the mandatory extension isn't available: MUST error If just detecting an invalid combination, but not actively negotiating: MAY error SNI is clearly listed as MUST support, servers MAY require, and SHOULD error if required The "unsupportedextension" alert is reworded more generally and put in as the consequence for violating the pre-existing "MUST NOT" send the client-only extensions from a server requirements. Also added some more, namely the fact that "clientkey_share" is clearly an error to be sent from a server.
NAME & NAME Please take a look when you get a chance. Are we all on the same page with this language? Anything that needs tweaking to focus on the above better? Edited to add: Also, do I need to cut out SNI again, or is this wording ok? It's not requiring it to be sent, just noting it must be supported, which was agreed to on list a while ago, and noting the existing case that servers MAY require it with a way to indicate it using the new error alert.
NAME New commit pushed here with changes for your comments: "invalid" -> "prohibited" Text is now: "Servers MUST NOT negotiate use of cipher suites unless the client supplies a supported . If the extension is not provided and no alternative cipher suite is available, the server MUST close the connection with a fatal "missing_extension" alert." So, trying to find a viable cipher suite is preferred and the error is only required when there's nothing else to do. Edited to note: The latter doesn't contradict the mandatory error on negotiation without the needed extension, as the server simply has the (unlikely) chance of negotiating something completely different instead. The MAY error is still included later in the changeset, as discussed, so clients are still expected to always do this correctly or risk the server throwing an error.
NAME Ok, repushed with one-word change to clarify to "at least one group for each ephemeral key exchange algorithm". This excludes PSK, but is still fine for (EC)DHE when used with it. Seems like the simplest fix.
Change:
6. <del> The usage of id-kp-documentSigning EKU intends to prevent id-kp- emailProtection from being used for none-email purposes and id-kp- codeSigning used to sign objects other than binary codes.  This EKU does not introduce new security risks but instead reduces existing security risks by providing means to separate other EKUs used for communication protocols namely, TLS or S/MIME etc. in order to minimize the risk of cross protocol attacks. </del> <ins> The usage of id-kp-documentSigning EKU is to provide an alternative to id-kp-emailProtection being used for non-email purposes and id-kp- codeSigning being used to sign objects other than binary code.  This EKU does not introduce new security risks but instead reduces existing security risks by providing means to separate other EKUs used for communication protocols namely, TLS or S/MIME etc. in order to minimize the risk of cross protocol attacks. </ins> To reduce the risk of specific cross protocol attacks, the relying <del> party or relying party software may additionaly prohibit use of </del> <ins> party or relying party software may additionally prohibit use of </ins> specific combination of EKUs. While a specific protocol or signing scheme may choose to come up <del> with their own EKU, some may not have significant motive or resource to set up and manage thier own EKU.  This general document signing </del> <ins> with their own EKU, some may not have significant motive or resources to set up and manage their own EKU.  This general document signing </ins> EKU may be used as a stop gap for those that intend to set up their own EKU or those who do not intend to set up an EKU but still would <del> like to distinguish from other usage. </del> <ins> like to distinguish document signing from other usages. </ins> Introduction of this id-kp-documentSigning EKU value does not introduce any new security or privacy concerns.

Discussion:
This PR contains corrections to more accurate expression. This PR does not contains modification related to backwards compatibility and interoperability.
Thanks Sean I approved all above modifications.
Change:
8.6. <ins> Since the publication of RFC3552 there has been an increased awareness of the need to protect against endpoints that are compromised, malicious, or whose interests simply do not align with the interests of users I-D.arkko-arch-internet-threat-model-guidance. RFC7624 describes an updated threat model for Internet confidentiality, see sec-prop.  I-D.arkko-arch-internet-threat-model- guidance further expands the threat model.  Implementations and users SHOULD consider these threat models.  In particular, even data sent protected to the other endpoint such as ID_CRED and EAD can be used for tracking, see Section 2.7 of I-D.arkko-arch-internet-threat- model-guidance. 8.7. </ins> As CoAP provides Denial-of-Service protection in the form of the Echo option I-D.ietf-core-echo-request-tag, EDHOC itself does not provide countermeasures against Denial-of-Service attacks.  By sending a

Discussion:
IAB has started a program to look into updates of the Internet Threat Model. Looks like the outcome might be a guidance document. One new threat is centralised data collection where the other endpoint might not be acting in the interest of the users. URL URL There is not reason to change the protocol, but I think it would be good with some privacy considerations. Using the same credentail with several other endpoints enables tracking. I will make a PR soon with a reference to draft-arkko-arch-internet-threat-model-guidance
This has been merged for a while without any comments. Was discussed at the interim. Closing.
Looks good, I made some editorials.
Change:
1. In order to reduce latency and improve performance it can be useful <del> to reduce the amount of data exchanged during a Transport Layer Security (TLS) handshake. </del> <ins> to reduce the amount of data exchanged during a TLS handshake. </ins> RFC7924 describes a mechanism that allows a client and a server to avoid transmitting certificates already shared in an earlier

Discussion:
Now that TLS and DTLS are in the RFC editor's list of abbreviations as "common" there's no need to spell out Transport Layer Security anymore.
Change:
COSE constructs the input to the AEAD RFC5116 as follows: <del> Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", length ) </del> <ins> Key K = EDHOC-KDF( PRK_3e2m, TH_3, "K_3ae", h'', length ) </ins> <del> Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", length ) </del> <ins> Nonce N = EDHOC-KDF( PRK_3e2m, TH_3, "IV_3ae", h'', length ) </ins> Plaintext P = ( ID_CRED_I / bstr / int, Signature_or_MAC_3, ? EAD_3 )

Discussion:
The new definition of info in th ecurrent specification is. I noticed two problems with this while implementing. To create the array you need to parse context to see how many items it contains. Unless context is validated, length is not strictly defined (an attacker could create collisions) I suggest that info is changed to:
In the exporter, the application using EDHOC could input a context (a encoded CBOR sequence) that is not valid CBOR. That is not a big problem, but might lead to security issues in the future, if is assumed that info is valid CBOR. URL prefered sequence to array. I don't think bstr wrapping the sequence has the same problems as array wrapping the sequence. Array wrapping the info sequence seems like an unesasary step. I suggest.
We have also gotten comments disliking the use of any
Current specification could give the impression that there is a single maclength. But the mac length in message2 and message_3 may be different.
One fix is to update to
Change:
7. <del> Media distributors sometimes interact with RTP media packets sent by </del> <ins> Media Distributors sometimes interact with RTP media packets sent by </ins> endpoints, e.g., to provide recovery or receive commands via DTMF. When media packets are encrypted end-to-end, these procedures require <del> modification. </del> <ins> modification.  (End-to-end interactions, including end-to-end recovery, are not affected by end-to-end encryption.) </ins> Repair mechanisms, in general, will need to perform recovery on <del> encrypted packets (double-encrypted when using this transform).  When the recovery mechanism calls for the recovery packet itself to be encrypted, it is encrypted with only the outer, hop-by-hop key.  This allows a media distributor to generate recovery packets without </del> <ins> encrypted packets (double-encrypted when using this transform), since the Media Distributor does not have access to the plaintext of the packet, only an intermediate, E2E-encrypted form. When the recovery mechanism calls for the recovery packet itself to be encrypted, it is encrypted with only the outer, hop-by-hop key. This allows a media distributor to generate recovery packets without </ins> having access to the inner, end-to-end keys.  However, it also results in recovery packets being triple-encrypted, twice for the base transform, and once for the recovery protection.

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:
lead to loss of packets that contain non-compliant DCIDs, and in extreme cases connection failure. <ins> Some load balancers might inspect elements of the Server Name Indication (SNI) extension in the TLS Client Hello to make a routing decision.  Note that the format and cryptographic protection of this information may change in future versions or extensions of TLS or QUIC, and therefore this functionality is inherently not version- invariant. </ins> 10. QUIC-LB is intended to prevent linkability.  Attacks would therefore

Discussion:
Some load balancers today switch based on the SNI. Obviously, this is not version-invariant. We should add some language about this. What should such an LB when it encounters an unknown version? It probably has no choice but to forward it based on CID and hope for the best.
If the differing domains trust each other, the servers could helpfully generate Retry packets to redirect the client to the right place. This assumes a bunch of shared state, and that those servers support the same version while the LB does not. Of course, if version support differs, the VN process has serious problems.
Maybe encrypt sni will be the real standard later(see URL), I just think that there is no need for quic lb considering sni
Change:
5. <del> User Agents that enforce encryption MUST expose an elliptic curve Diffie-Hellman share on the P-256 curve FIPS186.  Public keys, such as are encoded into the "dh" parameter, MUST be in the form of an uncompressed point as described in X.692. </del> <ins> User Agents MUST expose an elliptic curve Diffie-Hellman share on the P-256 curve FIPS186. Public keys, such as are encoded into the "dh" parameter, MUST be in the form of an uncompressed point as described in X.692 (that is, a 65 octet sequence that starts with a 0x04 octet). The label for this curve is the string "P-256" encoded in ASCII (that is, the octet sequence 0x50, 0x2d, 0x32, 0x35, 0x36). </ins> 6.

Discussion:
Adam Langley and David Benjamin identified a risk with the proposed security design for push messages. In the existing design, a user agent shares two pieces of information with an application server that form the basis of authenticating messages. endpoint - The secrecy of the endpoint URL is used to protect the user agent from receiving unauthenticated and unwanted messages. Unfortunately, this URL is necessarily known to user agent, push service and application server, so any of those three can generate spam. DH public key - The secrecy of the Diffie-Hellman public key is relied on to ensure that a valid push message can't be sent by anyone other than the application server. Only the user agent and the application server know this information. The concern here is that a DH public key is not typically treated like a secret. That means that when it is used, there is no guarantee that an implementation won't leak bits of the public key. For instance, if an implementation isn't constant time with respect to its contents, . If this secret is leaked to the push service, then the push service is able to generate push messages that will be accepted by the user agent. Those messages will appear to come from the application server. In the modern spirit of belt-and-braces design for security protocols, this change adds a new authentication secret that the application server has to prove ownership of to send a message. This secret is mixed into the key derivation process. Any entity that doesn't know this value will be unable to derive a valid content encryption key. The suggested alternative, a HMAC key, was rejected on the basis that it increased the signaling load on the path from application server -> push service -> user agent. This provides similar protection without increasing the size of push messages. This change builds on martinthomson/http-encryption by adding the authentication secret to the context that is passed as the HKDF label.
Attention NAME
Updated to be based on martinthomson/http-encryption based on URL
Change:
sec.use-of-provisional-answer.  Here, Alice's endpoint sends an offer to Bob's endpoint to start an audio/video call.  Bob immediately responds with an answer that accepts the audio/video m= sections, but <del> marks them as sendonly (from its perspective), meaning that Alice </del> <ins> marks them as sendonly (from his perspective), meaning that Alice </ins> will not yet send media.  This allows the JSEP implementation to start negotiating ICE and DTLS immediately.  Bob's endpoint then prompts him to answer the call, and when he does, his endpoint sends

Discussion:
a=simulcast, a=rid a=imageattr (maybe) differing codecs/preferences for either side
I started on this; should be straightforward
Change:
independent of other connections that are not part of the same Connection Group. <del> Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite)), which serves to simplify the local send/receive functions and to filter the traffic for the specified addresses and ports RFC8085. </del> <ins> Connection establishment is only a local operation for a connectionless protocols, which serves to simplify the local send/ receive functions and to filter the traffic for the specified addresses and ports RFC8085 (for example using UDP or UDP-Lite transport without a connection handshake procedure). </ins> Once Initiate has been called, the Selection Properties and Endpoint information are immutable (i.e, an application is not able to later

Discussion:
replace DG by CL. Changed one oddity: /as to/ to /about/
"Connection establishment is only a local operation for a Datagram transport (e.g., UDP(-Lite))": I think the criterion is not Datagram transports but "transports without a handshake" or "connectionless protocols" as it is used later in the document.
I wrote, and I suggest we use "connectionless protocols" explicitly mentioning examples of UDP and UDP-Lite when used as a transport without a handshake.
To whoever plans to address this: I checked occurrences of the word "datagram" in the architecture and API drafts, and I found (only) one sentence that needs fixing on similar grounds, I think, in the API draft: in Section 8.1.4 "Timeout for keep alive packets". Surely the guidance regarding this matter in the UDP usage RFC is related to the fact that UDP(-Lite) is connectionless, not that it's datagram based.
Starting to fix this.
This LGTM
Change:
reliable transports such as TCP or TLS.  This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports.  It also formally updates RFC 7641 for use with these <del> transports, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. </del> <ins> transports, RFC 7959 to enable the use of larger messages over a reliable transport, and RFC 6455 to extend the well-known URI mechanism (RFC 5785) to the ws and wss URI schemes. </ins> 1.

Discussion:
Add to Updates Updated Abstract Added IANA section to update related references for Block1 and Block2
: 3: Since this draft defines new SZX value, I think the doc needs to update RFC7959. This point should be clarified more in the doc. My sense is that we should treat this as an update to RFC7959 based on the original language: and the use of "extension" in coap-tcp-tls: This also requires an IANA addition, since the entries for Block1 and Block2 need to also reference coap-tcp-tls in addition to RFC7959.
Change:
with other parties but does not let the attacker impersonate other parties in EDHOC exchanges with the compromised party.  Compromise of the long-term keys does not enable a passive attacker to compromise <del> future session keys.  Compromise of the HDKF input parameters (ECDH shared secret) leads to compromise of all session keys derived from that compromised shared secret.  Compromise of one session key does not compromise other session keys.  Compromise of PRK_out leads to compromise of all keying material derived with the EDHOC-Exporter. </del> <ins> future session keys (PRK_out).  Compromise of the HDKF input parameters (ECDH shared secret) leads to compromise of all session keys derived from that compromised shared secret.  Compromise of one session key does not compromise other session keys.  Compromise of PRK_out leads to compromise of all keying material derived with the EDHOC-Exporter. </ins> Based on the cryptographic algorithms requirements sec_algs, EDHOC provides a minimum of 64-bit security against online brute force

Discussion:
Issue
Minor comment, but reading through all the security claims, they multiple times refer to the term (for instance in ), which is not per say completely defined. I am not even sure there is any ambiguity, but is it still worth adding somewhere that this relates to ?
Yes, I assume session key most often refer to PRK_out. Could maybe refer to the exported application keys in some sentence. Let's go through all instances and make it clear what it refers to.
Change:
connection SHOULD fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback. <del> 11. </del> <ins> 12. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture

Discussion:
NAME should probably double-check my work here. This assumes that we take the compatible version upgrade stuff, but if we don't, there's only one sentence to remove. I've tried to keep it abstract enough that the details won't matter.
LGTM. Thank you for writing it down!
Moving this from quicwg/base-drafts to here.
NAME NAME can one of you maybe provide some text?
is probably exactly what needs to be said for this issue.
lgtm
Change:
determine whether an immediate or delayed acknowledgement should be generated after processing incoming packets. <del> Acknowledgements of packets carrying CRYPTO frames SHOULD be minimally delayed, to complete the handshake with minimal latency. Delaying them by a small amount, such as the local timer granularity, allows the endpoint to bundle any data sent in response with the ACK frame.  ACK frames SHOULD be sent immediately when the crypto stack indicates all data for that packet number space has been received. </del> Packets containing PADDING frames are considered to be in flight for congestion control purposes QUIC-RECOVERY.  Sending only PADDING frames might cause the sender to become limited by the congestion

Discussion:
Also removes obsolete text about acknowledging CRYPTO frames quickly, now that Initial and Handshake packet spaces have a maxackdelay of 0.
Sorry I'm late here but I think it would still be good to mention that congestion control usually is supposed to work on a RTT granularity and if you send less ACKs than one per RTT that can have an impact on cc. I don't think this has to be a normative requirement given you have normative requirements on maxackdelay and a reasonable default value but it would still be good to mention this dependency as cc is done on sender and ACKing on receiver and therefore it might not always that obvious.
The spec gives no reason (that I can see) as to why an ACK frame must be sent at least once per round trip (assuming there are ack-eliciting packets to acknowledge), effectively overwriting the ACK delay logic when the RTT is very small. If the RTT is smaller than the platform's timer granularity, this isn't really even possible. I propose to remove this requirement. If the WG instead feels that we should keep this requirement, then there should be a reasoning for it; and probably an update to the PTO calculation as well.
As I commented on the PR that this came up in, given we have an explicit maxackdelay that's now communicated, removing the 1 ACK per RTT requirement seems wise. TCP has no such recommendation and I'm unaware of any indications or proposals that it should have such a property.
NAME point that the RTT can be smaller than the platform's granularity is a good one. I agree that this text ought to be removed.
This is changing text in a SHOULD statement, so I believe it should be marked as design.
LGTM
Change:
media type structured syntax suffix registration form follows.  See MEDIATYPE for definitions of each of the registration form headings. <del> YAML Ain't Markup LanguageML (YAML) </del> <ins> YAML Ain't Markup Language (YAML) </ins> +yaml

Discussion:
addressing (and a few minor editorial changes thrown in as well).
This is probably left over from earlier drafts that did cover multiple media types.
There are a couple more places that use the plural form "media types". Unless I am missing something, these all should be changed to singular form.
It's and . I don't have preferences and the singular is OK to me. Feel free to PR :)
that's what i also thought but then again isn't a media type (as i am sure you know). let's make NAME the tie-breaker!
Let's go with the singular form.
fixed via