jiebi/CodeConvo huggingface dataset:
Change:
collect sub-protocol.  (See batch-validation.)  If both checks succeed, the input share is not marked as invalid. <ins> Check if the report is too far into the future.  Implementors can provide for some small leeway, usually no more than a few minutes, to account for clock skew.  If a report is rejected for this reason, the Aggregator SHOULD mark the input share as invalid with the error "report_too_early". </ins> Check if the report's timestamp has passed its task's "task_expiration" time, if so the Aggregator MAY mark the input share as invalid with the error "task_expired".

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:
label is a tstr set to the name of the derived key, IV or MAC; i.e., "KEYSTREAM_2", "MAC_2", "K_3ae", "IV_3ae", or "MAC_3". <del> context is a CBOR sequence, i.e., zero or more encoded CBOR data items </del> <ins> context is a bstr </ins> length is the length of output keying material (OKM) in bytes

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:
It has the digitalSignature KeyUsage (see the KeyUsage extension defined in RFC5280). <ins> A new extension was chosen instead of adding a new Extended Key Usage (EKU) to be compatible with deployed TLS and PKI software stacks without requiring CAs to issue new intermediate certificates. </ins> 5. This document registers the "delegated_credentials" extension in the

Discussion:
From Russ: I guess I ask the authors to add a paragraph to the rationale section that says something about why this extension was used instead of an extended key usage. From Watson: One of the hard requirements for our deployment was that the same certificate be useable with DCs and without. A different EKU would be more problematic then an extension for this purpose, and while it might be more or less irritating for implementors depending on how their stack works (sorry Rich - https://boringssl-URL might serve as inspiration, but the client side got dropped for similar issues). We know the extension doesn't bust things, I don't know an EKU would, and the root program issues make me hesitate.
Addressed in
Change:
value using: [sender] denotes the sending side.  The value of Secret for each <del> record type is shown in the table below. </del> <ins> category of data is shown in the table below. </ins> <del> All the traffic keying material is recomputed whenever the underlying Secret changes (e.g., when changing from the handshake to Application Data keys or upon a key update). </del> <ins> Alerts are sent with the then current sending key (or as plaintext if no such key has been established.)  All the traffic keying material is recomputed whenever the underlying Secret changes (e.g., when changing from the handshake to Application Data keys or upon a key update). </ins> 7.4.

Discussion:
I cannot find any specification in RFC8446 of which key is used to encrypt an alert or heartbeat sent before Finished (I assume it is the applicationtrafficsecret). It is definitly possible that this information is somewhere in the document and that I just do not find it. The document seems to treat "record type" and "content type" as synonyms. Are both terms needed? I would suggest updating table in section 7.3 to make it complete. Record type "Application Data" should probably be everything that is not a Handshake. It would be good to say something about post-handshake messages in section 7.3. Post-handshake messages have record type/content type Handshake but does not follow what the table in 7.3 says.
The key is not specified as some errors can make it impossible for the peer to send an alert under specific key, so the used key is implicit—the currently used one, whichever it happens to be, including plaintext.
True, thank for reminding me. That is quite simple. Given that, I think the table in Section 7.3 is confusing and and not even correct. It claims to give the secret for each record type, but only lists 2. "0-RTT Application" is not a record type..... It gives the idea that the secret follows from the record type, which is not correct. It claims that record type Handshake is protected with [sender]handshaketraffic_secret, but record type handshake is protected with all three secrets depending on the state. I think it would probably be better to remove the table in 7.3 than to keep the current version. Even better would be to replace 7.3 with a more correct description.
Change:
An example set of protocol messages for this method can be found in example-auth-code. <del> 1.5.2. </del> <ins> 1.5.3. </ins> In this example flow, the client instance is a device that is capable of presenting a short, human-readable code to the user and directing

Discussion:
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: a48ba2e1204e2294f34f8550971f65f684ea7992 Inspect the deploy log: Browse the preview:
Sec. 1.5 (Sequences) would be clearer if we named the top sequence - all other sequences have been named. Maybe "main authorization flow"?
The sequences have not been names per say, they just happen to be related to a subtitle. We could of course create a new subsection, but the idea was to place this sequence above the others.
This is purely editorial. Naming it would make it easier to refer to this sequence.
Change:
<del> Hypertext Transfer Protocol Version 3 (HTTP/3) </del> <ins> HTTP/3 </ins> Abstract

Discussion:
This PR covers questions asked during Auth48 which aren't pure copyediting, but seem to have a straightforward single-location fix. Individual commits, so it's easy to pull one out if someone disagrees.
In , the RFC Editor asks:
Either A or B is better, but I have no preference.
Fixed in , but GitHub won't automatically close until it hits .
Change:
6.4. <del> When packet protection keys are discarded (see Section 4.8 of QUIC- </del> <ins> When packet protection keys are discarded (see Section 4.9 of QUIC- </ins> TLS), all packets that were sent with those keys can no longer be acknowledged because their acknowledgements cannot be processed anymore.  The sender MUST discard all recovery state associated with

Discussion:
So there are a couple of section references in the doc that points the wrong section in other documents. Section 6.2.1: "A sender SHOULD restart its PTO timer every time an ack-eliciting packet is sent or acknowledged, when the handshake is confirmed (Section 4.1.2 of [QUIC-TLS]), or when Initial or Handshake keys are discarded (Section 9 of [QUIC-TLS])", should that last ref be to section 4.9 in QUIC-TLS?"Section 6.4: "see Section 4.8 of [QUIC-TLS])" This is now Section 4.9.Section B.2: maxdatagramsize: The sender's current maximum payload size. Does not include UDP or IP overhead. The max datagram size is used for congestion window computations. An endpoint sets the value of this variable based on its PMTU (see Section 14.1 of [QUIC-TRANSPORT]), with a minimum value of 1200 bytes." Should that Section 14.1 reference be to 14.2.
Thank you for catching these, NAME
Change:
RFC7540 provide some further advice on mitigations within an HTTP/2 context. <del> The HTTPS connection also authenticates the DNS API server but does not inherently assure of authenticity of DNS data.  A DNS API client may choose to trust answers from a particular DNS API server, much as a DNS client might choose to trust answers from its recurvise DNS resolver.  A DNS API client may also perform full DNSSEC validation of answers received from a DNS API server. </del> [[ From the WG charter: The working group will analyze the security and privacy issues that

Discussion:
Reverts dohwg/draft-ietf-doh-dns-over-https
Change:
specification QUIC-TLS.  This split is performed to enable light- weight versioning with different cryptographic handshakes. <del> 10. </del> <ins> 11. </ins> QUIC provides integrity protection for its version negotiation process.  This process assumes that the set of versions that a server

Discussion:
addresses issue
I think the applicability draft may benefit from exploring connection migration strategies as described in: URL
Do we also need to say anything about use of 0-byte CID? See quicwg/base-drafts
The transport draft already says:
addressed by PR and one more sentence
I don’t see any text related to connection migration on that PR.
sorry wrong PR; should be and is already merged
good modulo typos
Change:
4.3. <del> As with CoAP over TCP, both endpoints MUST send a Capabilities and </del> <ins> As with CoAP over TCP, each endpoint MUST send a Capabilities and </ins> Settings message (CSM see csm) as their first message on the WebSocket connection.

Discussion:
Partially addresses
It is analogous, because the structure of the subregistry is slightly different (additional column). We can add a sentence that the value of the additional column does not influence the choice of the policy. Good point. OK, “update” is not the right word them. Good point. It was smeared all over the document, and then we collected it in an appendix. I don’t think anyone would have a strong opposition against making it a mainline section. Should we?
In general, I prefer to separate out unrelated issues (editorial or not) to simplify tracking/closing: Regarding: There are at least three similar cases of "both endpoints" which would need to be corrected together.
NAME - Regarding Ben's comment (which you seem to concur with ...): 7.6: The "updates" in this section are confusing. I understand this to mean that the procedures for TCP and WS are identical to those for UDP except for the mentioned steps. But the language of the form of "This step from [RFC7252] is updated to:" makes it sound like this intends to actually change the language in 7252 to this new language. If the latter, then that effectively removes UDP support from 7252 as updated. This could easily be fixed by changing that to something to the effect of "When using TCP, this step changes to ..." The text actually updates RFC7252 to address all cases. I don't see how it effectively removes UDP support since the text is additive. For example: This step from [RFC7252]: If does not equal the request’s destination UDP port, include a Uri-Port Option and let that option’s value be . is updated to: If does not equal the request’s destination UDP port or TCP port, include a Uri-Port Option and let that option’s value be .
NAME - I do not feel strongly about moving Appendix A - but I'm open to suggestions. It's hard to find the right place in the flow - perhaps before/after Section 6?
This issue is partially addressed by - which I'm merging now since I'm on leave for the next two weeks. The other potential editorial changes are pending responses from NAME
Change:
needed for encrypting the Certificate message.  Thus, the client will fail to decrypt the Certificate and abort the connection. <del> 10.8.2. </del> <ins> 10.7.2. </ins> This attack aims to exploit server HRR state management to recover information about a legitimate ClientHello using its own attacker-

Discussion:
The misrouting content no longer applies since the backend server sees the full CH, with the true SNI.
Change:
attack. However, as the operating systems and application(s) that make use of <del> this information know that they are connecting to a captive-portal </del> <ins> this information know that they are connecting to a captive portal </ins> device (as opposed to intercepted connections where the OS/ application may not know that they are connecting to a captive portal or hostile device) they can render the page in a sandboxed

Discussion:
2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...) [Gahforthe_hyphens a87eb8d] 2 typos, and normalize the usage of hyphens (captive-portal vs captive portal). We use no hyphen (to match arch doc), except when referring to the option (to match the registry...)
Change:
1. Privacy Pass tokens are unlinkable authenticators that can be used to <del> anonymously authorize a client (see ARCHITECTURE).  A client possessing such a token is able to prove that it was able to get a token issued by a token issuer - based on some check from a token issuer, such as authentication or solving a CAPTCHA - without allowing the relying party redeeming the client's token (the origin) to link it with issuance flow. </del> <ins> anonymously authorize a client (see ARCHITECTURE).  Tokens are generated by token issuers, on the basis of authentication, attestation, or some previous action such as solving a CAPTCHA.  A client possessing such a token is able to prove that it was able to get a token issued, without allowing the relying party redeeming the client's token (the origin) to link it with the issuance flow. </ins> Different types of authenticators, using different token issuance protocols, can be used as Privacy Pass tokens.

Discussion:
From editor copy today: I found this intro to be a bit clunky. I didn't read the ARCHITECTURE reference yet but don't think that should be a prerequisite to comprehension of the first para. How about something like
Change:
current mechanisms such as DoH, DoT, and DoQ, as well as future mechanisms. <del> A DNS resolver using TCP or UDP port 53 without encryption. </del> <ins> A DNS resolver using a transport without encryption, historically TCP or UDP port 53. </ins> 3.

Discussion:
CC NAME I might suggest a slightly less binding wording where port 53 is concerned for the Unencrypted Resolver definition. Perhaps: "A DNS resolver using a transport without encryption, historically TCP or UDP port 53." I'd be in favor of using more RFC 8174 "SHOULD/SHOULD NOT" text in place of "ought [not] to". Specifically, for the text about address family support, consider perhaps something like: OLD: ... The Designated Resolver can support more address families than the Unencrypted Resolver, but it ought not to support fewer. NEW: ... The Designated Resolver MAY support more address families than the Unencrypted Resolver, but it SHOULD NOT support fewer. I wonder if it's good to require that clients MUST NOT/SHOULD NOT accept certificates claiming to be for URL This might be over-specifying things and/or it might be a check against some types of misconfigurations.
Change:
sending messages without Request-Tag options whenever possible, and using short values when the absent option can not be recycled. <ins> The Request-Tag options MAY be present in request messages that carry a Block2 option even if those messages are not part of a blockwise request operation (this is to allow the operation described in simpleproxy).  The Request-Tag option MUST NOT be present in response messages, and MUST NOT be present if neither the Block1 nor the Block2 option is present. </ins> 3.4. 3.4.1.

Discussion:
Changes in response to Carsten's comments Disposition: Will merge soon if nobody objects.
Updated to match the changes to master
Change:
may be delivered to the receiving application out of order.  This property is used for protocols that support preservation of data ordering, see prop-ordering, but allow out-of-order delivery for <del> certain messages. </del> <ins> certain messages, e.g., by multiplexing independent messages onto different streams. </ins> 7.4.4.

Discussion:
Just a proposal...
Well, you could do it with streams in SCTP as well so as an example it seems approriate. And good with an example I think.
Yes, we do have actually these kind of examples in many cases in the doc and I just thought when reading one could help here as well.
I don't understand why one would need streams for this in SCTP, but it doesn't matter. As I said I have no strong opinion, I'm fine with adding this example (and I just fixed the nit).
NAME you do not need to, as there are multiple ways to do it in SCTP, but you could.
Change:
wolfSSL: Applications configure PSKs with callbacks similar to OpenSSL. <del> 6.3.1. </del> <ins> 6.1.1. </ins> Section 5.1 of RFC4279 mandates that the PSK identity should be first converted to a character string and then encoded to octets using UTF-

Discussion:
explain how tls exporter helps with KDF and mitigating selfie attacks. added text on psk identity usage.
I left it empty for Owen (NAME He was planning to contribute some text on PSK collisions (between external PSKs and between external and internal PSKs).
I'll merge and will remove it for now. Owen can add it when he gets around to his PR.
LGTM pending one orphan section!
Change:
multi-homing or mobility, the use of the CID is not different to the use of the 5-tuple. <ins> An on-path adversary can also black-hole traffic or create a reflection attack against third parties because a DTLS peer has no means to distinguish a genuine address update event (for example, due to a NAT rebinding) from one that is malicious.  This attack is of concern when there is a large asymmetry of request/response message sizes. </ins> With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further privacy concerns.  The lack of a CID update mechanism makes this

Discussion:
... IANA consideration section based on issue raised by Sean (see URL) ... Security consideration section based on issue raised by Thomas (see URL)
This PR aims to replace PR & PR
A couple of tweaks are needed for the IANA Considerations Section: Based on input from the IANA TLS DEs, it seems like we need a column added to the TLS ExtensionType Values registry to indicate that an extension is DTLS-only. The column values for TLS 1.3 and Recommended are missing. Suggest blank for TLS 1.3 and N for Recommended. Add a note to say that connectionid is DTLS1.2 only. Add instructions for IANA to assign "Y" to DTLS-okay column for tls12cid content type.
That results in "DTLS only" for TLS extensions and "DTLS-OK" for TLS parameters. I'm not sure, if that just represents more the "current" usage than the "logic" behind it. I would be afraid, that this will hold up other ideas, which doesn't match that "only for extensions / ok for parameters" pattern.
I am not sure what "DTLS-OK" for TLS parameters means
For TLS parameters there's a column "DTLS-OK", And for TLS extensions a column "DTLS only". Does this explain my comment?
We added text to the draft-ietf-tls-dtls-connection-id-06 about the IANA consideration section. I believe this issue is closed.
Change:
Each distinct EKT parameter set that is used MUST be associated with a distinct SPI value to avoid ambiguity. <del> All EKT message other that ShortEKTField MUST have a length as second from the last element.  This is the length in octets of either the FullEKTField/ExtensionEKTField including this length field and the following message type. </del> <ins> All EKT message other that ShortEKTField have a length as second from the last element.  This is the length in octets of either the FullEKTField/ExtensionEKTField including this length field and the following message type. </ins> The last byte is used to indicate the type of the EKTField.  This MUST be 2 in the FullEKTField format and 0 in ShortEKTField

Discussion:
EKTMsgLength All EKT message other that ShortEKTField must have a length as second from the last element. This is the length in octets of either the FullEKTField/ExtensionEKTField including this length field and the following message type.
Change:
An HTTP message (request or response) consists of: <del> the header section, sent as a single HEADERS frame (see frame- headers), </del> <ins> the header section, including message control data, sent as a single HEADERS frame (see frame-headers), </ins> optionally, the content, if present, sent as a series of DATA frames (see frame-data), and

Discussion:
The diff looks larger than it is; I moved some sections around to more closely resemble the TOC of the HTTP/2 spec, and changed a section title that seemed a bit odd a year later. The relocated sections haven't changed. Old TOC: HTTP Request Lifecycle HTTP Message Exchanges Field Formatting and Compression Request Cancellation and Rejection Malformed Requests and Responses The CONNECT Method HTTP Upgrade Server Push New TOC: Expressing HTTP Semantics in HTTP/3 HTTP Message Framing Request Cancellation and Rejection Malformed Requests and Responses HTTP Fields HTTP Control Data Request Pseudo-Header Fields Response Pseudo-Header Fields The CONNECT Method HTTP Upgrade Server Push Comparison H2 TOC: Expressing HTTP Semantics in HTTP/2 HTTP Message Framing Malformed Messages HTTP Fields Field Validity Connection-Specific Header Fields Compressing the Cookie Header Field HTTP Control Data Request Pseudo-Header Fields Response Pseudo-Header Fields Server Push Push Requests Push Responses The CONNECT Method The Upgrade Header Field URL then some further sections as well.
Http-core introduces a new term, "control data," and HTTP/2 has been updated to use this term. HTTP/3 has not. While it was not raised in Auth48, it might be appropriate to align this terminology before we publish these documents together.
This seems like a good change for consistency, even if it might cause the document editor some short term pain.
Closed in .