jiebi/CodeConvo huggingface dataset:
Change:
Application data may be protected using the agreed application algorithms (AEAD, hash) in the selected cipher suite (see cs) and the application can make use of the established connection identifiers <del> C_I and C_R (see ci).  EDHOC may be used with the media type application/edhoc+cbor-seq defined in media-type. </del> <ins> C_I and C_R (see ci).  Media types that may be used for EDHOC are defined in media-type. </ins> The Initiator can derive symmetric application keys after creating EDHOC message_3, see exporter.  Protected application data can

Discussion:
There are now two different media types defined. Padding was missing from the list that EDHOC adds.
Change:
Version Negotiation (see version, and Section 17.2.1 of QUIC- TRANSPORT, the version number field has a special value (0x00000000) that identifies the packet as a Version Negotiation <del> packet. </del> <ins> packet.  QUIC versions that start with 0xff are IETF drafts.  QUIC versions that start with 0x0000 are reserved for IETF consensus documents, for example the QUIC version 1 is expected to use version 0x00000001. </ins> source and destination connection ID: short and long packet headers carry a destination connection ID, a variable-length field

Discussion:
This PR adds a new section on extracting the SNI. I also copied (most of) the pseudo code from Davids document into the appendix. We need to decide if we want to keep this and if so, potentially add some more explanation there. Also we could further strengthen the point out that both the 5-tuple and conn ID can change (as in David's doc). There is already text directly following the new SNI section on "flow association". If we want stronger text there, maybe we can capture that in a separate issue though.
I don't think that you should include the entirety of David's code. There are ways in which that will contribute to ossification. Indeed, I don't think that it is helpful to list draft versions here either.
Change:
Connection Properties: The Connection Properties are used to configure protocol-specific options and control per-connection <del> behavior of the Transport System.  For example, a protocol- specific Connection Property can express that if UDP is used, the </del> <ins> behavior of the Transport System; for example, a protocol-specific Connection Property can express that if UDP is used, the </ins> implementation ought to use checksums.  Note that the presence of such a property does not require that a specific protocol will be used.  In general, these properties do not explicitly determine

Discussion:
Note that Security Considerations and Acknowledgments changes are newline-rewrap only.
Change:
3.2. A document in the binary format MAY reference values from an external <del> dictionary.  This helps to reduce representation size and processing cost.  Dictionary references can be used in place of link relation types, link targets, operation types, submission targets, form field types, and form field values. </del> <ins> dictionary using Packed CBOR I-D.ietf-cbor-packed.  This helps to reduce representation size and processing cost. </ins> <del> 3.2.1. A dictionary reference is encoded as an unsigned integer.  Where a dictionary reference cannot be expressed unambiguously, the unsigned integer is tagged with CBOR tag TBD6, as follows: </del> <ins> Dictionary references can be used subject to [ yet to be defined ] profiling. </ins> <del> A dictionary reference MUST NOT refer to a dictionary value that would otherwise not be syntactically allowed in that position.  For example, a dictionary reference in the position of a link relation type cannot refer to a Boolean value; it can only refer to an IRI. </del> <ins> Implementers should note that Packed CBOR is not designed to be uncompressed, but to be used in a compressed form.  In particular, constrained devices may operate without even knowing what a given dictionary entry expands to (as long as they know its meaning) . </ins> <del> 3.2.2. </del> <ins> 3.2.1. </ins> The "application/coral+cbor" media type for documents in the binary format is defined to have a "dictionary" parameter that specifies the

Discussion:
This replaces the previous mechanism of having bespoke dictionaries with Packed CBOR. Other places in the text still talk of "dictionaries", but that's not necessarily wrong, it's a term even used occasionally in packed.
Change:
replay attacks, and randomness discussed in QUIC-TLS should be taken into account when deploying and using QUIC. <ins> Further, migration to an new address exposes a linkage between client addresses to the server and may expose this linkage also to the path if the connection ID cannot be changed or flows can otherwise be correlated.  When migration is supported, this needs to be considered with respective to user privacy. </ins> Application developers should note that any fallback they use when QUIC cannot be used due to network blocking of UDP should guarantee the same security properties as QUIC; if this is not possible, the

Discussion:
This would be my proposal of a few small additions based on the discussion on list and at the last meeting (IETF-112) about privacy implications after migration regarding exposure of linkable user IP addresses to the server. The text doesn't give any recommendations but at least mentions it in the relevant sections.
I left a few suggestions, but this is heading in a good direction.
Change:
deciding whether the entity is authorized to perform some operation <ins> A piece of asserted information, often in the form of a name/value pair.  (Compare /claim/ in RFC7519) </ins> A secure statement that some entity (typically a manufacturer) vouches for the integrity of an Attester's signing capability

Discussion:
I think we must define claim in the terminology section. The term claim originates from JWT, but JWT doesn't really define it.
The fact that "claim" is used throughout both RFC 7519 (JWT) and RFC 8392 (CWT) without any formal definition, means that it's clearly ok to have an RFC that does not define claim in its terminology section or anywhere else. I would favor following those precedents and not trying to retroactively invent some definition we have to agree on.
URL defines Claim as: Claim A piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value.
If the term is defined elsewhere, is that definition used consistently with ours? Claim A piece of information asserted about a subject. A claim is represented as a name/value pair consisting of a Claim Name and a Claim Value. URL Claim: : A piece of information asserted about a subject. (consistently with {{RFC7519}}) A claim is usually represented by as a name/value pair.
Change:
where the authorization decisions are very dynamic and/or where the received access token itself is a reference rather than a self-contained token.  More information about introspection in <del> OAuth 2.0 can be found in I-D.ietf-oauth-introspection. </del> <ins> OAuth 2.0 can be found in RFC7662. </ins> 3.2.

Discussion:
I went through the overview section and updated the text. The text is already good and only a few minor changes had to be made. I believe we may need to determine (some time in the future) whether it is worthwhile to combine the introduction with the text in the overview section since there is some overlap.
I spotted a few sentences that were missing a word to make sense. I'll go through and try to fix this on Monday, unless someone else manages before me. Otherwise the changes look fine.
Change:
MUST be returned. Next, the SessionDescription is parsed into a data structure, as <del> described in the sec.parsing-a-desc section below.  If parsing fails for any reason, processing MUST stop and an error MUST be returned. </del> <ins> described in the sec.parsing-a-desc section below. </ins> Finally, the parsed SessionDescription is applied as described in the sec.applying-a-local-desc section below.

Discussion:
It seems like there are two implementation strategies here: Keep a parsed version Re-parse. I think we probably could dispense with this sentence, but I don't object to it, because I think of "lookup in cache" as "parse".
Knowing how things go in the real world, I'm a bit reluctant to make this change, but it should address Adam's concern.
Change:
4. <del> RFC8358 specifies the conventions for digital signatures on Internet- Drafts.  This is one of the intended use cases for the general document signing key purpose described in this document.  RFC8358 uses CMS to digitally sign a wide array of files such as ASCII, PDF, EPUB, HTML etc.  Currently, there are no specification regarding key purposes for certificates signing those files except those which are defined by the software vendor. </del> The signed contents of Internet-Drafts are primarily intended to be consumed by people.  To be more precise, contents are intended to be shown to a person in a printable or displayable form by means of

Discussion:
changes are followings We accepeted your comment We accepeted your comment we stop using term "trust program" and changed as following "KeyPurposeIds are used in a PKI governed by the vendor or a set of specific group of vendors." "Unless certificates are governed by a vendor(s) specific PKI, certificates that indicate usage for document signing.." We accepeted your comment >(e.g. - When the end user encounters... >Editorially, please split this large "(e.g.," text block into distinct sentences. we divided the sentence, and clarified the relationship between KeyPurposeIds owning vendor and another vendor. We accepeted your comment We accepeted your comment prescribed behavior for RFC8358. We accepeted your comment We accepeted your comment as follows We removed secound MAY, and numbering. We further clarified the " outside of scope" case where it is up to software. We clarified order of "Excluded KeyPurposeId procedure" and Permitted KeyPurposeId procedure. we accept your change and changed as follow. "TLS (id-kp-clientAuth) or S/MIME (id-kp-emailProtection) etc."
Change:
defines an algorithm for encrypting sequence numbers, see sne. Note that sequence number encryption is used for all encrypted DTLS 1.3 records irrespective of whether a CID is used or not. <ins> Unlike the sequence number, the epoch is not encrypted.  This may improve correlation of packets from a single connection across different network paths. </ins> DTLS 1.3 encrypts handshake messages much earlier than in previous DTLS versions.  Therefore, less information identifying the DTLS

Discussion:
LGTM.
DTLS and QUIC share a lot of characteristics when it comes to protection of records/packets, but the DTLS sequence number encryption covers marginally less than the header protection in QUIC. Notably, this doesn't include the epoch in DTLS, where QUIC protects its one-bit epoch value. This avoids one issue QUIC has with respect to overuse of keys under an attempted forgery attack, because the choice of key is always clear, but it does mean that the epoch can be used to improve correlation between activity on different network paths. I don't think that this needs to be fixed, but it should be noted in the security considerations.
Change:
prepended C_I, see coap). Decrypt CIPHERTEXT_2, see asym-msg2-proc, and, if present, discard <del> padding. </del> <ins> the padding PAD_2. </ins> Make ID_CRED_R and (if present) EAD_2 available to the application for authentication- and EAD processing.

Discussion:
This is an editorial change.
If there is a risk someone thinks that padding in the messages must be the same we could use PAD2, PAD3, PAD_4.
If I understand correctly, the PAD is to hide the length of the messages. If the three messages share the same PAD length, it is enough for one of the message to have a length known by the attacker, e.g. if EAD_4 is of constant length across all sessions, to leak the length of the PAD, and thus the length of the other messages contents. As such, 3 distinct padding lengths would be strictly better. Otherwise, as the encryptions are distinct (different key streams), I on my side don't see any weird cryptographic interactions that would be possible. (a side question is does the padding in message 2 leads to potential for padding oracles attacks, where the attacker could try to flip a few bytes of the cyphertext and learn some information based on which step of the processing fail. However, that is covered by I guess)
This is an editorial change. I merged the PR and will close this issue. No and yes. SIGMA and EDHOC and TLS 1.3 does not provide confidentiality of the second flight to active attackers (except maybe the signature). In SIGMA and EDHOC and attacker can modify the second flight and gain information. But this attack seems very uninteresting compared to attacks where the attacker modifies message_1.
Change:
The entries in the iana-error-table are registered by this document. <ins> Additionally, each code of the format "0x1f * N + 0x21" for integer values of N (that is, "0x21", "0x40", ..., through "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. </ins> 11.2.4. This document establishes a registry for HTTP/3 unidirectional stream

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:
in TLS notation from TLS13, Section 3. This document uses the terms "Client", "Origin", "Issuer", "Issuance <del> Protocol", and "Token" as defined in I-D.ietf-privacypass- architecture.  It additionally uses the following terms in more specific ways: </del> <ins> Protocol", and "Token" as defined in ARCHITECTURE.  It additionally uses the following terms in more specific ways: </ins> Issuer key: Keying material that can be used with an issuance protocol to create a signed token.

Discussion:
We could omit the authenticator value and just focus on how Token is constructed based on TokenChallenge, but it seems reasonable to include the authenticator so folks can also test that they're computing the token key ID correctly. Generated from .
Change:
Before beginning the preparation step, Aggregators are required to perform the following generic checks. <ins> Check that the decrypted input share can be decoded.  If not, the input share MUST be marked as invalid with the error "unrecognized_message". </ins> Check if the report has already been aggregated with this aggregation parameter.  If this check fails, the input share MUST be marked as invalid with the error "report_replayed".  This is

Discussion:
Allows helpers to reject reports from too far in the future, matching the leader check detailed in "Upload Requests". We add for this case, and allow the leader to try the report again later. Requires helpers to mark undecodable decrypted input shares as invalid with ().
The DAP specification defines a number of error modes, which ultimately end up mapped to error codes defined in section 3.1. Currently, the specified behavior does not describe how to treat message-deserialization failures, in any of client-aggregator, aggregator-aggregator, or collector-aggregator communications. We should consider specifying this. Initial thoughts: Moving to (with a new error code?) or makes sense to me, for deserialization errors during the aggregation process. It'd be very nice if one "bad" client report didn't fail the entire aggregation job, e.g. we should probably specify behavior that limits the "blast radius" of a badly-serialized message. We could leave this unspecified; I suppose the risk is that different implementations might treat this error mode with different semantics (e.g. some will fail a single report, some will fail the entirety of the aggregation job).
(This fell out of discussion on URL; FWIW, Janus will currently transition a report aggregation to if it fails to decode a message, though of course that's just one implementation's choice.)
Change:
2.1.1. Full-featured hosts are either configured manually with a <del> registration domain, or use the "dr._dns-sd._udp.<domain>" query (RFC6763) to learn the default registration domain from the network. RFC6763 says to discover the registration domain using either ".local" or a network-supplied domain name for <domain>.  Services using SRP MUST use the domain name received through the DHCPv4 Domain Name option (RFC2132), if available, or the Neighbor Discovery DNS Search List option RFC8106.  If the DNS Search List option contains more than one domain name, it MUST NOT be used.  If neither option is available, the Service Registration protocol is not available on the local network. </del> <ins> registration domain, or discover the default registration domain as described in RFC6763.  If this process does not produce a default registration zone, the Service Registration protocol is not discoverable on the local network using this mechanism.  Other discovery mechanisms are possible, but are out of scope for this document. </ins> Manual configuration of the registration domain can be done either by <del> querying the list of available registration zones ("r._dns-sd._udp") and allowing the user to select one from the UI, or by any other means appropriate to the particular use case being addressed.  Full- featured devices construct the names of the SRV, TXT, and PTR records describing their service(s) as subdomains of the chosen service registration domain.  For these names they then discover the zone apex of the closest enclosing DNS zone using SOA queries RFC8765. Having discovered the enclosing DNS zone, they query for the "_dnssd-srp._tcp.<zone>" SRV record to discover the server to which they should send DNS updates.  Hosts that support SRP Updates using TLS use the "_dnssd-srp-tls._tcp.<zone>" SRV record instead. </del> <ins> querying the list of available registration domains ("r._dns-sd._udp") and allowing the user to select one from the UI, or by any other means appropriate to the particular use case being addressed.  Full-featured devices construct the names of the SRV, TXT, and PTR records describing their service(s) as subdomains of the chosen service registration domain.  For these names they then discover the zone apex of the closest enclosing DNS zone using SOA queries RFC8765.  Having discovered the enclosing DNS zone, they query for the "_dnssd-srp._tcp.<zone>" SRV record to discover the server to which they should send SRP updates.  Hosts that support SRP Updates using TLS use the "_dnssd-srp-tls._tcp.<zone>" SRV record instead. </ins> 2.1.2.

Discussion:
The text describing the behavior of full-featured hosts specified behavior that conflicted with the behavior specified in RFC6763 not because a change was needed, but because I just misunderstood how it worked. This change updates that text to simply refer to the relevant section in RFC6763. In addition, the term "zone" was used where "domain" should have been used, and the term "DNS Update" was used to refer to something that should only ever be an SRP update, so these errors are also corrected.
Change:
malformed payload, then the receiver aborts and alerts the peer with "unrecognized message". <del> Each POST request to an aggregator contains a "PATask".  If the </del> <ins> Each POST request to an aggregator contains a "PATaskID".  If the </ins> aggregator does not recognize the task, i.e., it can't find a <del> "PAParam" for which "PATask.id == PAParam.task.id", then it aborts and alerts the peer with "unrecognized task". </del> <ins> "PAParam" for which the derived task id matches the "PATaskID", then it aborts and alerts the peer with "unrecognized task". </ins> 4.

Discussion:
by removing the field from each of the protocol messages. Partially addresses by establishing that the task id is derived from the PA parameters for a task. We still need to specify this procedure.
On the 2021/7/7 design call we decided that the ID should be derived deterministically from the serialized PAParam by, for example, hashing it. This solves a few problems simultaneously. This settles the question of whether there should be 1:1 correspondence between a task ID and the parameters used for that task. NAME brought up an interesting question, which is how to make the task ID unique when two different data collection tasks use the same parameters. Thoughts?
The consensus here is to do SHA-256 over the PDAParams structure and use that as the 32 byte PDATaskID. However, hashing a protocol message requires us to decide on a canonical representation of a protocol message, which I think forces us to decide how to encode messages on the wire. I filed for that question. I'll proceed with a PR for this issue on the assumption that we'll pick JSON.
As I mentioned there, the assumption would be that we're adopting TLS' binary encoding. If so, in TLS notation, you would write as the hash of , which itself is a serialized data structure.
All we require is that each PAParam have some unique value, right? A random nonce would probably suffice. r.e. the encoding, yes, let's stick with TLS's wire format as NAME suggests.
Yes, my thinking was that we would just stick 16 bytes of random data in (a UUID's worth). I agree that we should stick with TLS binary encoding.
This seems unnecessary.
The PATask is always the first bit of a protocol message, and the version is the first bit of the PATask. I figured it would be helpful to version each message because messages are carried by HTTP requests. There might be a simpler/better way to do this.
I don't think we should assume that's the case. If we want to have the version not determined at the URL level (a mistake, IMO) then we should have some sort of message wrapper that contains that, rather than overloading PATask.
I'm inclined to agree with NAME we're discussing versioning the whole API in , so PATask doesn't need to also provide version information.

So, setting aside the question of message format versions, is there any value in maintaining a version on PATasks at the protocol level? I say no, because we want to be able to treat different PATasks completely independently and don't otherwise have any notion of a relationship between any two PATasks in the protocol.
Change:
QUIC's stream multiplexing feature allows applications to run multiple streams over a single connection, without head-of-line <del> blocking between streams, associated at a point in time with a single five-tuple.  Stream data is carried within frames, where one QUIC packet on the wire can carry one or multiple stream frames. </del> <ins> blocking between streams.  Stream data is carried within frames, where one QUIC packet on the wire can carry one or multiple stream frames. </ins> Streams can be unidirectional or bidirectional, and a stream may be initiated either by client or server.  Only the initiator of a

Discussion:
It is sort of redundant (because it says connection) and maybe sort of misleading (QUIC connections only use a single 5-tuple at a time, so it is maybe correct, but also maybe not).