jiebi/CodeConvo huggingface dataset:
Change:
This document will request IANA to register the following entry in the "HTTP/3 Settings" registry: <del> 0xffd277 (note that this will switch to a lower value before publication) H3_DATAGRAM 0 provisional (permanent if this document is approved) This Document IETF HTTP_WG; HTTP working group; ietf-http-wg@w3.org </del> 7.2. This document will request IANA to register the following entry in the "HTTP/3 Error Codes" registry: <del> 0x4A1268 (note that this will switch to a lower value before publication) H3_DATAGRAM_ERROR Datagram or capsule protocol parse error provisional (permanent if this document is approved) This Document IETF HTTP_WG; HTTP working group; ietf-http-wg@w3.org </del> 7.3. This document will request IANA to register the following entry in the "HTTP Field Name" registry: <del> Capsule-Protocol None provisional (permanent if this document is approved) This document None </del> 7.4. This document establishes a registry for HTTP capsule type codes. The "HTTP Capsule Types" registry governs a 62-bit space. Registrations in this registry MUST include the following fields: <del> A name or label for the capsule type. The value of the Capsule Type field (see capsule-protocol) is a 62-bit integer. An optional reference to a specification for the type.  This field MAY be empty. </del> Registrations follow the "First Come First Served" policy (see Section 4.4 of IANA-POLICY) where two registrations MUST NOT have the same Type.

Discussion:
It's shorter and apparently the tagging is what is now required later on in the RFC process anyway.
Change:
messages) that indicate when an IP packet is dropped because it is larger than the local router MTU.  DPLPMTUD can also optionally use these messages.  This use of ICMP messages is potentially vulnerable <del> to off-path attacks that successfully guess the addresses used on the path and reduce the PMTU to a bandwidth-inefficient value. </del> <ins> to attacks by entities that cannot observe packets but might successfully guess the addresses used on the path.  These attacks could reduce the PMTU to a bandwidth-inefficient value. </ins> An endpoint MUST ignore an ICMP message that claims the PMTU has decreased below QUIC's smallest allowed maximum datagram size.

Discussion:
We weren't being consistent. This should help.
NAME said:
The first here is in the process of being addressed, see . I agree regarding "strong", but also agree regarding what to do about it. My proposal is to let close this issue.
NAME said:
Proposed resolution is URL
This is an improvement. Thanks.
Change:
the packet elimination on the packet processing pipeline is implementation specific. <ins> [Note to editor - Clean up local-id when dealing with PREF text] </ins> 4.3. DetNet service layer introduces also packet reordering functionality

Discussion:
I have started to address the comments as agreed on the call 2nd May. Before I do a more significant edit next week I want to test out the pull mechanism,
Merged Stewart's first three commits to the master.
I wonder why we need to have/propose two approaches for the aggregation?
Change:
There are cryptographic limits on the amount of plaintext which can be safely encrypted under a given set of keys.  AEAD-LIMITS provides an analysis of these limits under the assumption that the underlying <del> primitive (AES or ChaCha20) has no weaknesses.  Implementations SHOULD do a key update as described in key-update prior to reaching these limits.  Note that it is not possible to perform a KeyUpdate for early data and therefore implementations SHOULD not exceed the limits when sending early data. </del> <ins> primitive (AES or ChaCha20) has no weaknesses.  Implementations MUST either close the connection or do a key update as described in key- update prior to reaching these limits.  Note that it is not possible to perform a KeyUpdate for early data and therefore implementations MUST not exceed the limits when sending early data.  Receiving implementations SHOULD NOT enforce these limits, as future analyses may result in updated values. </ins> For AES-GCM, up to 2^24.5 full-size records (about 24 million) may be encrypted on a given connection while keeping a safety margin of

Discussion:
but tell receiving implementations not to enforce them. This addresses . NAME PTAL.
Limits on Key Usage (Section 5.5): Since key updates are necessary for security, I think MUST (rather than SHOULD) is appropriate. (And similarly in the sentence that follows: "Note that it is not possible to perform a KeyUpdate for early data and therefore implementations SHOULD not exceed the limits when sending early data.")
IIRC there was a disagreement on when the rekeying should happen, and more specifically, the limits for Chacha20-Poly1305 are higher than the limit imposed by TLS sequence numbers, so there's no need to rekey if all you support is Chacha20...
NAME That seems compatible with MUST: Section 5.5 also notes: It follows that implementations might not do a key update.
I don't necessarily object to a MUST but I think as with the limit on KeyUpdate it would need to be paired with a MUST NOT enforce on the receiver. As I understand it, these bounds aren't necessarily tight, so we might have some results that allowed fewer rekeys in the future.
Change:
required to validate the challenge.  A client should attempt to fulfill one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid. <del> For final authorizations, it contains the challenges that were successfully completed. </del> For authorizations created as a result of a newOrder request containing a DNS identifier with a value that contained a wildcard

Discussion:
In section 7.1.4 "Authorization Objects" the "challenges" field is described as containing: Later, after discussing the array entries a duplicate sentence appears: This is already covered by the initial description of what a final authorization's challenges array holds and so this commit removes the second redundant sentence.
Change:
21.10. <del> This document defines QUIC Version Negotiation packets version- </del> <ins> This document defines QUIC Version Negotiation packets in version- </ins> negotiation, which can be used to negotiate the QUIC version used between two endpoints.  However, this document does not specify how this negotiation will be performed between this version and

Discussion:
Typically we use "in {{}}" or "(see {{}})", so this lines up with that.
Change:
4.3. <del> Capability and Settings messages (CSM) are used for two purposes: </del> <ins> Capabilities and Settings messages (CSM) are used for two purposes: </ins> Each capability option advertises one capability of the sender to the recipient.

Discussion:
One more 7.01 change to 7.00. Removed redundant requirement for references to abort: MAY immediately abort the connection (see Section 4.6) . since the Abort section already has the SHOULD.
URL Signaling s/Share/Relate/ (the nodes do not "share these characteristics") Shut down s/Ordered/Orderly/ Provide diagnostic information when terminating a connection in ... 4.3. Capability and Settings Messages (CSM) Hmm, should this be "Capabilities and Settings Messages"? (Need to change throughout.) s/A/One/ s/Capability and Settings message/CSM/ s/and/. Further CSM/ s/settings/setting/ 4.3.2. Max-Message-Size Capability Option (above 1152?)
URL Appendix B. Negotiating Protocol Versions s/Capability and Settings/Capabilities and Settings Messages (CSM)/
URL Cl.4.5/4.6: The text mentions a "diagnostic payload", is some standard envisaged for this or is it implementation dependent? This is implementation dependent, although it might be helpful to adapt or reference - URL
Reviewed in more detail. There is a reference to RFC7252 in an earlier section URL
Perhaps the RFC7252 references needs to be emphasized more. Options: Blockquote related RFC7252 Section 5.5.2 in section 4.1 to call more attention to it Include an xref with each related normative statement The simplest mitigation is the xref: A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown. The details are in the options. A diagnostic payload (see Section 5.5.2 of [RFC7252]) MAY be included.
Change:
RFC8613) typically only breaks the security of the data in the forged packet. <ins> As the EDHOC protocol is terminated when verification fails, the security against online attacks is given by the sum of the strength of the verified signatures, MACs (including MAC in AEAD).  As an example, if EDHOC is used with method 3, cipher suite 2, and message_4, the Responder is authenticated with 128-bit security against online attacks (the sum of the 64-bit MACs in message_2 and message_4).  The same principle applies for MACs in an application protocol keyed by EDHOC as long as EDHOC is rerun when verification of the first MACs in the application protocol fail.  As an example, if EDHOC with method 3 and cipher suite 2 is used as in Figure 2 of I-D.ietf-core-oscore-edhoc, 128-bit mutual authentication against online attacks can be achieved after completion of the first OSCORE request and response. </ins> After sending message_3, the Initiator is assured that no other party than the Responder can compute the key PRK_out.  While the Initiator can securely send protected application data, the Initiator SHOULD

Discussion:
NAME Do you or David have any comment on the formulation?
NAME We needed to merge this PR to prepare for -17, but we are of course still interested in your comments :-)
No comment to do ;). It's good.
This is the outcome of the work by Baptiste Cottier and David Pointcheval related to The conclusions form Baptiste and David is that after receiving message4 the Initiator has authenticated the Responder with a strength of the combined MACs in message2 and message4. I.e. if both MACs are 64 bits, they work together as a 128 bit MAC. The same thing apply to application messages such as OSCORE used as message 4,5,6,..... but this comes with the additional requirement that the security association has to be terminated and EDHOC redone in the case that verification of the OSCORE MAC fails. The same apply to the draft-ietf-core-oscore-edhoc where 2 MACs are sent in flight 3 URL The same priciple should apply to modes with signatures where a signature in message2 combined with a MAC in message_4 gives the strenght of the signature and the MAC combined. Baptiste and David have not investigated this formally.
Good. Terminology comment: You use first "authenticated with 128-bit security" and then "128-bit mutual authentication". I assume that means the same in security terms (although one is unilateral and the other mutual). No mentioning of online attacks here. Is it clear how that relates to "64-bit security against online brute force attacks" which is stated in another security consideration? "can be achieved after verification of the first OSCORE Response". This is correct in its brevity, but the use of "verification" gives the impression that it is the verification of OSCORE Response is what makes this achieved, rather than it is the completion of the processing of the OSCORE request and OSCORE response that are the moments in time when, with the appropriate measures, security can be achieved. Perhaps replace "verification" with "completion".
Change:
MUST NOT consider these streams to have any meaning upon receipt. The payload and length of the stream are selected in any manner the <del> implementation chooses. </del> <ins> implementation chooses.  Implementations MAY terminate these streams cleanly, or MAY abruptly terminate them.  When terminating abruptly, the error code H3_NO_ERROR or a reserved error code (http-error- codes) SHOULD be used. </ins> 7.

Discussion:
Pleasantly, the same formula we've used for grease values elsewhere in HTTP/3 does not collide with any currently-assigned error code, so I've just reused it. (We'll need to be cautious about 0x119, though.) The same logic could be applied to transport error codes, but there's not much point. If you're intolerant of the way your peer closed the connection, you might erroneously... close the connection? Editorial-ish: A recommendation which reserves some error code space we haven't used; modifies the IANA instructions. Doesn't mandate or prohibit anything new.
Constraining the recommendation on grease streams, because sending any error code potentially generates an error code that has semantics to your peer of which you are unaware.
The discussion on made us conclude that the reason for doing this is that we want to safeguard our ability to define new error codes. Greasing might help with that.
Since you'd probably want want the grease to not sacrifice connections it might make sense to couple grease error codes to H3 grease streams. Also, what about greasing of transport-level error codes? Can't play the stream tricks there.
Unknown error codes are supposed to be equivalent to H3NOERROR. Perhaps a recommendation (SHOULD) to substitute a grease code with non-zero probability when you would have sent NO_ERROR? And MAY use them when terminating grease streams, sure.
Looks fine to me. I wonder how much this will end up doing anything...LG, but I think it's worth accepting Martin's suggestion.
Change:
error since the client instance will be unable to complete the request without authorization. <del> The AS SHOULD apply suitable timeouts to any interaction mechanisms </del> <ins> The AS SHOULD handle any interact request as a one-time-use mechanism and SHOULD apply suitable timeouts to any interaction mechanisms </ins> provided, including user codes and redirection URLs.  The client instance SHOULD apply suitable timeouts to any callback URLs.

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Built Explore the source changes: 72feabe3d5e229b7516edd76777e3186dfd09f91 Inspect the deploy log: Browse the preview:
Still need to explain better how to do that, will track as part of lifecycle discussion
explains how an existing request can be modified by a PATCH request to the continuation endpoint. My question is, what happens if such a PATCH request is sent while the interaction for the associated grant request is not yet finished? I feel like this should not be allowed, but could not find any information anywhere in Section 5 that this is actually forbidden. Section 5.3 also says that the PATCH request may include post-interaction responses. I assume this means that by specifying an interaction reference in the PATCH request the interaction can be finished by the PATCH request, so the question would be what happens if the interaction is not finished and the PATCH request does not contain an interaction reference?
In Section 3.3.4 it says If the PATCH request is considered a continuation request (which is reasonable since it is sent to the continuation URI), this would prohibit a PATCH request before the interaction finishes. However, if no interaction finish mode is used, this does not apply.
I believe the cases are covered (a PATCH can't be done when it is pending), even if we could make things clearer probably : using PATCH instead of POST aims to provide better signal/control of when the partial update can be made as part of a continuation request (and it needs to use the continue access token) when the client can't receive a finish method (redirect or push), then it will need to poll regularly (cf 5.2)
Summary from editor's discussion: The grant process is stateful, a grant goes from (requested) -> (pending approval) -> (approved), at least. The PATCH request only makes sense to an (approved) grant, the post-interaction requests only make sense for the (pending) grant. We can call out this stateful nature and constrain different requests and inputs to specific states.
Proposed solution to make a state diagram and add state description in the overall protocol discussion.
Modifying an Existing Request: Editor's note: The net result of this is that interaction requests are really only meant to be responded to exactly once by the AS.

This isn't spelled out explicitly, but could be included in Section 2.5 and/or Section 3.3.
This feeds into the overall discussion of "what can be sent when" and the lifecycle of the grant within the API; I do think that these artifacts should be one-time-use, especially the nonces.
Change:
certificate and can therefore read these 1-RTT packets. A sender SHOULD restart its PTO timer every time an ack-eliciting <del> packet is sent or acknowledged, when the handshake is confirmed (Section 4.1.2 of QUIC-TLS), or when Initial or Handshake keys are </del> <ins> packet is sent or acknowledged, or when Initial or Handshake keys are </ins> discarded (Section 4.9 of QUIC-TLS).  This ensures the PTO is always set based on the latest estimate of the round-trip time and for the correct packet across packet number spaces.

Discussion:
Ian is right, we would lose the Initial discard condition. Drop the Handshake key drop condition.
NAME -- you're right, but I think that only applies to Initial here, since hs confirmed is the same as hs keys getting dropped. Take a look at the new text.
NAME said:
Yes, this should be only about handshake confirmation. Thanks for catching this!
Change:
addition to the "encrypted_client_hello" extension, the server MUST abort with an "illegal_parameter" alert. <del> First, the server collects a set of candidate ECHConfigs.  This set is determined by one of the two following methods: </del> <ins> First, the server collects a set of candidate ECHConfig values.  This list is determined by one of the two following methods: </ins> <del> Compare ClientECH.config_id against identifiers of known ECHConfigs and select the ones that match, if any, as candidates. </del> <ins> Compare ClientECH.config_id against identifiers of each known ECHConfig and select the ones that match, if any, as candidates. </ins> <del> Collect all known ECHConfigs as candidates, with trial decryption below determining the final selection. </del> <ins> Collect all known ECHConfig values as candidates, with trial decryption below determining the final selection. </ins> Some uses of ECH, such as local discovery mode, may randomize the ClientECH.config_id since it can be used as a tracking vector.  In

Discussion:
See .
I left this out because I figure there may be cases where there is no "published" ECHConfigList. (Maybe the config is baked in the app?)
Ah fair, that might be too precise. I think it still makes sense for that case to have the baked-in thing be an ECHConfigList than an ECHConfig, just for consistency. (I'm envisioning that ECHConfigList is the "public API" for client ECH and your TLS library might just that one byte string as input.) How about s/published/server's/?
That'd work :)
NAME done!
LGTMThanks, Chris!
Change:
Using these reserved epoch values a receiver knows what cipher state has been used to encrypt and integrity protect a message. <del> Implementations that receive a payload with an epoch value for which no corresponding cipher state can be determined MUST generate a "unexpected_message" alert.  For example, if a client incorrectly uses epoch value 5 when sending early application data in a 0-RTT exchange.  A server will not be able to compute the appropriate keys and will therefore have to respond with an alert. </del> <ins> Implementations that receive a record with an epoch value for which no corresponding cipher state can be determined SHOULD handle it as a record which fails deprotection. </ins> Note that epoch values do not wrap.  If a DTLS implementation would need to wrap the epoch value, it MUST terminate the connection.

Discussion:
What was the motivation for this change?
The idea was to bring us in line with the normal handling for invalid records, which is to ignore them rather than send an alert and tear things down. DTLS associations are supposed to be robust against injected packets. I suspect that there is also some remnant of the previous state of affairs when just incrementing the epoch was all that was needed to generate new keys, as opposed to requiring KeyUpdate+ACK, though that's not directly related to making this change.
Flagging as consensus-needed.
Change:
parties can derive application keys with other labels or run EDHOC again. <ins> Requirement for how to securely generate, validate, and process the ephermeral public keys depend on the elliptic curve.  For X25519 and X448, the requirements are defined in RFC7748.  For secp256r1, secp384r1, and secp521r1, the requirements are defined in Section 5 of SP-800-56A.  For secp256r1, secp384r1, and secp521r1, at least partial public-key validation MUST be done. </ins> 8.3. For many constrained IoT devices it is problematic to support more

Discussion:
This was suggested in CFRG during the discussion on HPKE Elliptic-Curve-Point-to-Octet-String Conversion. The compact representation used in EDHOC can be used whenever compact output is used in ECDH (which it almost always is). Important to differenctiate between the wire format, the validation done, and the algorithm for multiplication. EDHOC only touch the wire format, and do not loosen any validation requirements or recommend any particular algorithms form multiplication. Suggestion oflline that it might be better to specify that the "y-bit" is set to 0 instead of giving the implementor an option. Suggestion offline that the draft should refer to SECG in addition or instead of NIST.
I made a PR trying to capture the suggestion from CFRG. I think the PR is ready to merge.
on page 14 would it not be suitable to add that IDCREDx = { x5chain : certificate in DER }, for x = I or R,
Very timely comment. I just made an update to this effect, see b5346fb. I didn't want to include this kind of notation as it requires explanation. Is it good enough?
Suggest to give it a bullet as well. Göran Selander schreef op 2021-02-22 11:26: Links: [1] URL [2] URL [3] URL
Change:
may have implementation-specific default handlers.  The application should not assume that ignoring Events (e.g., Errors) is always safe. <del> pre-establishment, establishment, sending, receiving, and termination describe the details of application interaction with Objects through Actions and Events in each phase of a Connection, following the phases (Pre-Establishment, Establishment, Data Transfer, and Termination) described in Section 4.1 of I-D.ietf-taps-arch. </del> 3.1. The following usage examples illustrate how an application might use

Discussion:
At the end of the API summary, there's a paragraph that looks like a "Structure of this document" discussion - should it be in a different place? The list in the paragraph is odd - why is Section 8, for instance, not in the list?
Change:
and retransmissions of data in CRYPTO frames are sent at a previous encryption level.  These packets MAY also include PADDING frames. <del> 4.11.1. </del> <ins> 4.9.1. </ins> Packets protected with Initial secrets (initial-secrets) are not authenticated, meaning that an attacker could spoof packets with the

Discussion:
This adds a short introductory section to the three sections that deal with 0-RTT. That might help contextualize and help contain the spaghetti structure that this section seems to have.
Thanks Nick. I took it in a slightly different direction, but I think that I captured this.
One high-order bit: Using 0-RTT as a noun doesn't sound right, though we do use it informally in that sense. My suggestion use of "The 0-RTT handshake delay feature" or "0-RTT delay before sending application data" as appropriate.This change looks good.
Change:
state with other clients.  A client is defined by the cryptographic keys it holds. <del> A linear sequence of epochs in which each epoch depends on its </del> <ins> A group represents a logical collection of clents that share a common secret value at any given time.  Its state is represented as a linear sequence of epochs in which each epoch depends on its </ins> predecessor. A state of a group in which a specific set of authenticated

Discussion:
The definition of an MLS group in the 2nd paragraph of the Protocol Overview is really good. Let's use it as the definition in the Terminology section as well.