jiebi/CodeConvo huggingface dataset:
Code change:
the PTO expiry, subject to address validation limits; see Section 8.1 of QUIC-TRANSPORT. <del> Peers can also use coalesced packets to ensure that each datagram elicits at least one acknowledgement.  For example, clients can </del> <ins> Endpoints can also use coalesced packets to ensure that each datagram elicits at least one acknowledgement.  For example, a client can </ins> coalesce an Initial packet containing PING and PADDING frames with a 0-RTT data packet and a server can coalesce an Initial packet containing a PING frame with one or more packets in its first flight.

Related discussion:
text: This should resolve some parts of .
NAME If you wish, I will split this PR into small ones.
I have dropped the commit of "in flight".
I also changed into .
NAME The commit for "towards" has been dropped.
Thanks. BTW, that thing is an another odd English quirk.
Unfortunately, this PR bundles a bunch of unrelated changes. Some of them I like, some of them I don't.Thanks for the PR, NAME !
Code change:
1.4. This subsection provides a glossary of key terms related to the <del> Transport Services architecture.  It provides a simple description of </del> <ins> Transport Services architecture.  It provides a short description of </ins> key terms that are later defined in this document. Application: An entity that uses the transport layer for end-to-

Related discussion:
text: Feel free to approve or propose changes to improve this sentence in Arch.
BT: "I’m not convinced of the value of the glossary of terms, as it forwardrefs basically the entire document, and some of the definitions are so generic as to be potentially confusing (e.g. Event), so I think putting these up front reduces the document’s approachability and readability. I understand that some people like these (and other standards orgs make them mandatory, hi ETSI), so I won’t fight it." "Adding a sentence making it clear it’s safe to skip the glossary if you’re going to read the rest of the document would address my approachability concern completely. "
Code change:
Contains additional ranges of packets that are alternately not acknowledged (Gap) and acknowledged (ACK Range); see ack-ranges. <del> The three ECN Counts; see ack-ecn-counts. </del> <ins> The three ECN counts; see ack-ecn-counts. </ins> 19.3.1.

Related discussion:
text: This one slipped the net.
Either way is fine by me. Just ship it already :PThanks, Martin!
Code change:
General background and concepts of DetNet can be found in the DetNet Architecture RFC8655. <del> I-D.ietf-detnet-ip specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  This document focuses on the scenario where DetNet IP nodes are interconnected by a TSN sub-network. </del> <ins> RFC8939 specifies the DetNet data plane operation for IP hosts and routers that provide DetNet service to IP encapsulated data.  This document focuses on the scenario where DetNet IP nodes are interconnected by a TSN sub-network. </ins> The DetNet Architecture decomposes the DetNet related data plane functions into two sub-layers: a service sub-layer and a forwarding sub-layer.  The service sub-layer is used to provide DetNet service protection and reordering.  The forwarding sub-layer is used to provides congestion protection (low loss, assured latency, and <del> limited reordering).  As described in I-D.ietf-detnet-ip no DetNet specific headers are added to support DetNet IP flows, only the forwarding sub-layer functions are supported inside the DetNet domain.  Service protection can be provided on a per sub-network basis as shown here for the IEEE802.1 TSN sub-network scenario. </del> <ins> limited reordering).  As described in RFC8939 no DetNet specific headers are added to support DetNet IP flows, only the forwarding sub-layer functions are supported inside the DetNet domain.  Service protection can be provided on a per sub-network basis as shown here for the IEEE802.1 TSN sub-network scenario. </ins> 2.

Related discussion:
text: ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)
Code change:
resulting in connection failures. A server MUST clear the QUIC bit only after processing transport <del> parameters from a client.  A server cannot remember that a client </del> <ins> parameters from a client.  A server MUST NOT remember that a client </ins> negotiated the extension in a previous connection and clear the QUIC Bit based on that information. <del> An endpoint cannot clear the QUIC Bit without knowing whether the </del> <ins> An endpoint MUST NOT clear the QUIC Bit without knowing whether the </ins> peer supports the extension.  As Stateless Reset packets (Section 10.3 of QUIC) are only used after a loss of connection state, endpoints are unlikely to be able to clear the QUIC Bit on

Related discussion:
text: Inappropriate use of MAY, lack of MUST [NOT]. Thanks to Russ Housley for schooling me on the correct usage.
Code change:
"Upgrade". the request SHALL include a single "Upgrade" header with value <del> "masque-udp". </del> <ins> "connect-udp". </ins> For example, if the client is configured with URI template "https://proxy.example.org/{target_host}/{target_port}/" and wishes

Related discussion:
text: Should the upgrade token be "connect-udp" or "masque-udp" ? (issue based on by NAME
I vote for or something along those lines. "MASQUE" is good as a working group name, but I don't think it's helpful in the protocol to help people understand what the variant of CONNECT does.
Code change:
The EDHOC-KeyUpdate takes a context as input to enable binding of the updated PRK_out to some event that triggered the keyUpdate.  The Initiator and the Responder need to agree on the context, which can, <del> e.g., be a counter or a pseudorandom number such as a hash.  The Initiator and the Responder also need to cache the old PRK_out until it has verfied that the other endpoint has the correct new PRK_out. </del> <ins> e.g., be a counter or a pseudorandom number such as a hash.  To provide forward secrecy the old PRK_out and derived keys must be deleted as soon as they are not needed.  When to delete the old keys and how to verify that they are not needed is up to the application. </ins> I-D.ietf-core-oscore-key-update describes key update for OSCORE using EDHOC-KeyUpdate.

Related discussion:
text: Should be checked for conflicts with
I think fixing the comments above resolves conflict with , so can then be replaced by this.
This proposal for update in the key derivation description also addresses the clarifications requested in , thus replacing . We merge this to include it in -15 and enable further reviews.
This is not correct. How to derive and store PRKexporter is completely up to the implementation. One can derive PRKexporter everytime Exporter is called. This make it look like PRKout is overwritten. This should be formulated with and like TLS 1.3 or with and or something. How long to save the old keying material (PRKout, PRK_Exported, any derived keys) is likely up to the application. The importand thing is that they need to be deleted to give FS.
There was a request from someone that more guidance on the use of KeyUpdate should be expanded. Maybe not clear how you are supposed to alternate KeyUpdate and Exporter to get FS.
As you are considering making the KeyUpdate more detailed, I have a general design question. Are there use cases where one would expect Post-Compromise Security? That is, if one of the participant's PRK_out is compromised, a successful KeyUpdate mechanism between the two honest parties would heal them and lock out the attacker That is typically what is met by the double ratchet from the Signal app. The classical way to achieve that is roughly to have each party send out for the update fresh DH ephemeral shares, and add the corresponding DH secret inside the key derivation. (it would of course require more care than that in the details)
I think part of the plan is to make it less detailed and leave some stuff to the implementation/application :) The current KeyUpdate mechanism only gives forward secrecy. If you exchange some nonces and use them as a context you might get protection against an attacker is not monitoring all your traffic. I think details of this should be specified outside of EDHOC like in the OSCORE KeyUpdate draft in the CORE WG. The double ratchet was discussed in LAKE WG at an earlier point. The conclusion was that it added to much complexity to specify that as part of EDHOC. To get this kind of security an application has to rerun EDHOC frequently (like TLS 1.3).
Code change:
The EDHOC-KeyUpdate takes a context as input to enable binding of the updated PRK_out to some event that triggered the keyUpdate.  The Initiator and the Responder need to agree on the context, which can, <del> e.g., be a counter or a pseudorandom number such as a hash.  The Initiator and the Responder also need to cache the old PRK_out until it has verfied that the other endpoint has the correct new PRK_out. </del> <ins> e.g., be a counter or a pseudorandom number such as a hash.  To provide forward secrecy the old PRK_out and derived keys must be deleted as soon as they are not needed.  When to delete the old keys and how to verify that they are not needed is up to the application. </ins> I-D.ietf-core-oscore-key-update describes key update for OSCORE using EDHOC-KeyUpdate.

Related discussion:
text: Signal uses the Diffie-Hellman ratchet very often which makes it understandable to have on optimized Diffie-Hellman ratchet post-handshake. Contrained use cases of EDHOC can not do Diffie-Hellman as often as Signal so it was determined that requiring rerun of the full EDHOC was the best tradeoff. Should the EDHOC specification say more about the benefits of frequently rerunning Diffie-Hellman? I don't remember how much it says. I recently wrote a paragraph about this that was accepted to RFC8446bis.
This is not correct. PRKout does not need to be stored. An implementation can derive the application keys directly and never store PRKout. An implementation can also store PRK_exporter if they don't use EDHOC-KeyUpdate.
This is not enough. You need to be sure that the old key is not needed more.
I merged which addresses some points raised in this issue. Please review and comment if there is anything missing.
No comments received, so I assume this is fine. (KeyUpdate is now in an appendix.)
Code change:
QUIC carries TLS handshake data in CRYPTO frames, each of which consists of a contiguous block of handshake data identified by an offset and length.  Those frames are packaged into QUIC packets and <del> encrypted under the current TLS encryption level.  As with TLS over TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's </del> <ins> encrypted under the current encryption level.  As with TLS over TCP, once TLS handshake data has been delivered to QUIC, it is QUIC's </ins> responsibility to deliver it reliably.  Each chunk of data that is produced by TLS is associated with the set of keys that TLS is currently using.  If QUIC needs to retransmit that data, it MUST use the same keys even if TLS has already updated to newer keys. <del> One important difference between TLS records (used with TCP) and QUIC CRYPTO frames is that in QUIC multiple frames may appear in the same QUIC packet as long as they are associated with the same packet number space.  For instance, an endpoint can bundle a Handshake message and an ACK for some Handshake data into the same packet. </del> <ins> Each encryption level corresponds to a packet number space.  The packet number space that is used determines the semantics of frames. </ins> Some frames are prohibited in different packet number spaces; see Section 12.5 of QUIC-TRANSPORT.

Related discussion:
text: The first strikes "TLS" from encryption level The second removes misleading text about coalescing I'm suggesting that we replace it with explanatory language about encryption levels and packet number spaces. This context is now missing as a result of moving the referenced text to -transport.
Roman Danyliw said:
I'm going to suggest that the text I propose in addresses this first part of this. The higher/lower stuff seems like it could be better, but it's a lot of work to do carefully. I'm going to suggest that we could live with this, but I might leave this issue open and try to find a fix once other more pressing issues are dealt with.
NAME said:
This is really two comments, but I think we can dispense with both at the same time as the first is really trivial: The use of "TLS encryption level" is an unnecessary redundancy and inconsistent with other usage, so we can easily remove "TLS" there. The start of that paragraph is cruft. I'm going to suggest we only keep the last sentence, which was unquoted in this issue. But then I see that we are missing important context, so I'm going to suggest a little bit of text to replace it.
one suggestion, but lgtm
Code change:
An optional reference to a specification that describes the use of the setting. <ins> The value of the setting unless otherwise indicated.  SHOULD be the most restrictive possible value. </ins> The entries in the following table are registered by this document. Additionally, each code of the format "0x1f * N + 0x21" for integer

Related discussion:
text: I went with "Default" because that and "Initial Value" now have specific, related (but distinct) usages in the context of pre-SETTINGS settings. Swapping them seems like it would create unnecessary confusion.
Yeah that makes sense on a reread of section 7.2.5.2
Not a new issue but: RFC 7540 has a column for . I think it makes sense that HTTP/3 does similar. Originally posted by NAME in URL
Code change:
[ The CoAP option numbers 13 and 21 are both consistent with the <del> properties of the EDHOC Option defined in signalling, and they both </del> <ins> properties of the EDHOC Option defined in edhoc-option, and they both </ins> allow the EDHOC Option to always result in an overall size of 1 byte. This is because:

Related discussion:
text: Clean-up after URL As the content-from-edhoc branch seems to be the most up-to-date one (in which the parts changed are introduced in the first place), this builds on , and only the latest commit is actually relevant.
Compared to the original bstridentifier mapping, this is a different int-to-bstr mapping, but one that's most likely efficient to implement. I have not made any statement on the efficiencies, but some guidance we could give is that from a coding density point of view, numeric Cx should only be used with -24..23; for all other values, doing it in a bstr is just as good and saves a byte in OSCORE. (In fact we may want to make that normative, so that only the single-byte case needs to be implemented where this needs explicit implementation).
Code change:
D.draft-bormann-jsonpath-iregexp for performance issues in regular expression implementations.)  Implementers need to be aware that good average performance is not sufficient as long as an attacker can <del> choose to submit specially crafted JSONPath queries that trigger surprisingly high, possibly exponential, CPU usage. </del> <ins> choose to submit specially crafted JSONPath queries or arguments that trigger surprisingly high, possibly exponential, CPU usage or, for example via a naive recursive implementation of the descendant selector, stack overflow.  Implementations need to have appropriate resource management to mitigate these attacks. </ins> 5.2.

Related discussion:
text: Also add some general advice from URL See also . Ref: URL
Recursion is not really the problem, stack depth is (or any other uncontrolled resource usage triggered by queries into deeply nested structures). Grüße, Carsten
NAME Are you comfortable with this now, or would you perhaps like to suggest some other way to address the concerns of URL
Thank you.Looks good and informative to me.
Code change:
Message Properties can be set and queried using the Message Context: <del> These Message Properties may be generic properties or protocol- </del> <ins> These Message Properties may be generic properties or Protocol- </ins> specific Properties. For MessageContexts returned by send Events (see send-events) and

Related discussion:
text: We don't have "Protocol Properties" - two occurrences in -interface should really refer to "protocol-specific Properties", and two occurrences in -impl should really refer to properties.
URL Are Protocol Specific Properties and Protocol Properties same or different? Also note that we are first time defining the Protocol Properties in the interface document ( described along with Connection Properties) and not introduced in the architecture document. I think we should be clear about what we are defining where and describing where. I would suggest use of cross reference rather describing everything again and again, which might create confusion and inconsistency.
Oh, this seems like a mistake (great catch, thanks!) - "Protocol Properties" don't exist, I think we only have "protocol-specific Properties".
I caught this when reading the implementation doc. So it should be fixed there as well.
Code change:
guaranteed by a digital signature on each message from the sender's signature key. <ins> The signature keys held by group members are critical to the security of MLS against active attacks.  If a member's signature key is compromised, then an attacker can create KeyPackages impersonating the member; depending on the application, this can then allow the attacker to join the group with the compromised member's identity. For example, if a group has enabled external parties to join via external commits, then an attacker that has compromised a member's signature key could use an external commit to insert themselves into the group - even using a "resync"-style external commit to replace the compromised member in the group. Applications can mitigate the risks of signature key compromise using pre-shared keys.  If a group requires joiners to know a PSK in addition to authenticating with a credential, then in order to mount an impersonation attack, the attacker would need to compromise the relevant PSK as well as the victim's signature key.  The cost of this mitigation is that the application needs some external arrangement that ensures that the legitimate members of the group to have the required PSKs. </ins> 15.3. Post-compromise security is provided between epochs by members

Related discussion:
text: Of course, that position would entail accepting that compromise of signature keys would be sufficient to impersonate the user, but that doesn't seem all that surprising, at least to me. So this seems like a question of group policy to me. Either the group requires ReInit PSKs on resync (and you can't recover from all-but-signature-key state loss), or it doesn't (and signature keys are the last resort). This can be documented in the Security Considerations, in a new PR. As far as , I think it's probably still worth adding the precision, but I would change the PSK part to MAY if not remove it entirely.
There is also a practical issue with using PSKs to prove past membership, in that if there have been joins since Alice lost state, the new joiners won't have the PSK. This is of course a general issue with the proof-of-past-membership PSK, but it is particularly salient here.
Code change:
6. <ins> 6.1. </ins> This document requests that a code point be allocated from the "TLS ContentType registry.  This value must be in the range 0-31 (inclusive).  The row to be added in the registry has the following

Related discussion:
text: This PR looks good to me.
cTLS enumerates keys in the template, but does not explain how templates can be extended. Suggestion: Clients must reject the whole template if it contains any key they do not understand. The “optional” key holds a map of optional extensions that are safe to ignore.
Thanks for addressing your own issue with a PR. Creating an IANA registry for the keys used in the configuration data makes sense. I would, however, like to point out (and maybe we need to make this explicit) that the configuration information is defined for convenience but is not a mandatory-to-implement functionality for a stack.
Sure, some use cases can pre-arrange, or even hardcode, a specific configuration through a nonstandard channel. Some use cases (where the client and server are developed separately) obviously cannot.
Code change:
Error alert message.  In earlier versions of TLS, error alerts could be warnings or fatal.  In TLS 1.3, error alerts are always fatal and the only alerts sent at warning level are "close_notify" and <del> "user_cancelled", both of which indicate that the connection is not </del> <ins> "user_canceled", both of which indicate that the connection is not </ins> going to continue normally, see RFC8446. In TLS 1.3 RFC8446, error alerts are not mandatory to send after a

Related discussion:
text: Update the draft to use the same spelling as TLS RFC uses. Relates to issue
While reading draft-ietf-emu-eap-tls13-15 I noticed that section now uses which is the named used in but not in RFC 8446 itself. I first thought this was a typo, before a further look showed that this change was mentioned in IETF 110 . Suggestion: make clear which parts need to be looked up from RFC 8446bis. In addition to exporter terminology, the meeting slides above also discuss about usercancelled behavior on slide 10. For clarity, any updates from RFC 8446bis should be marked clearly.
It would be best not to have normative references that block on RFC 8446bis. Perhaps we can just reference that it is renamed from "exportermastersecret"
Sounds good. That should make clear where it comes from and that there's no need to file errata about unknown term and/or RFC 8446bis dependency. Taking another look at my comment about usercancelled behavior on slide 10; to clarify what I was meaning: The slides hint that clarifications in 8446bis are needed by EAP-TLS too. If so, this looks like a reference to RFC 8446bis too. Finally, one nit: the alert name in RFC 8446 is "usercanceled", not "user_cancelled" as in draft -15.
I made a PR with explaining that the document use the terminology from RFC8446bis. URL Do we need to say anything about usercancelled? RFC8446bis might do several clarifications and corrections. I think we should only mention things that are directly relevant for EAP-TLS 1.3 URL Current plan for RFC8446bis seems to be to ignore closenotify and I assume require close_notify after. This does not seem directly relevant for EAP-TLS 1.3. Or?
close issue?
Yes, please close this. I think it's now clear where exportersecret comes from. Also, thanks for the pointer to TLSv1.3 discussion. I agree usercanceled followed by close_notify discussion is not relevant for EAP-TLS 1.3. It's seems to be TLSv1.3 specification and implementation level detail as opposed to something that EAP-TLS 1.3 needs to directly react on.
This looks good to merge