jiebi/CodeConvo huggingface dataset:
Change:
that other frames are sent in addition to PADDING frames to elicit acknowledgments from the receiver. <del> An endpoint MUST NOT send more than one packet containing only an ACK frame per received packet that contains frames other than ACK and PADDING frames. </del> The receiver's delayed acknowledgment timer SHOULD NOT exceed the current RTT estimate or the value it indicates in the "max_ack_delay" transport parameter.  This ensures an acknowledgment is sent at least

Discussion:
Packets are acknowledged, though packet numbers are communicated to acknowledge them.
One high-level comment. I believe the intent was to move most of the text about sending ACKs from recovery to transport. Also, if we defined ack-eliciting in transport, I think this PR and some other text would read more clearly. I can do that in a follow up PR.
Thanks for cleaning this up. One more TODO down.
Change:
client include information used by the aggregators during aggregation in order to validate their corresponding output shares.  For example, Prio3 includes a distributed zero-knowledge proof of the input's <del> validity BBCGGI19 which the aggregators can jointly verify and reject </del> <ins> validity BBCGGI19 which the Aggregators can jointly verify and reject </ins> the report if it cannot be verified.  However, they do not learn anything about the individual report other than that it is valid.

Discussion:
Based on .
NAME can you please rebase? Some of the changes we improved on in now appear here.
Rebased.
Change:
those devices' clients could all present the user's application-layer identifiers. <del> If needed, applications may add application-specific unique identifiers to the "extensions" field of KeyPackage or LeafNode objects. </del> <ins> If needed, applications may add application-specific identifiers to the "extensions" field of a LeafNode object with the "application_id" extension. However, applications SHOULD NOT rely on the data in an "application_id" extension as if it were authenticated by the Authentication Service, and SHOULD gracefully handle cases where the identifier presented is not unique. </ins> 7.

Discussion:
At first I was going to make an extension for both KeyPackages and LeafNodes. But I was thinking and couldn't come up with a reason for KeyPackages to need this extension, so did just LeafNode.
Interim 2022-05-26: Agreement to merge is getting used a lot, so maybe or ? NAME to change to
What's the use case for this?
Mentioned at the last interim, but the use-case for this feature is either: giving applications an easier way to lookup the private key corresponding to their LeafNode giving applications a place to put client UUIDs
Change:
consume (at least) values G, F, D, AR0, AR1, K1, N1 as well as the key schedule secrets used to derive G (the "encryption_secret"), namely "init_secret" of epoch n-1 and "commit_secret", <del> "joiner_secret", "member_secret", "epoch_secret" of epoch n.  The client MAY retain (not consume) the values K0 and N0 to allow for out-of-order delivery, and SHOULD retain AR2 for processing future messages. </del> <ins> "joiner_secret", "epoch_secret" of epoch n.  The client MAY retain (not consume) the values K0 and N0 to allow for out-of-order delivery, and SHOULD retain AR2 for processing future messages. </ins> 8.6.

Discussion:
This is a small suggestion to move the definition of the to the end of the first Extract-Expand (KDF) cycle of the [key schedule]. This makes more sense from a cryptographic perspective as we would not be using anything from the middle of a KDF cycle. A related suggestion is to remove the from the document. I removed it from the key schedule, removed all the mentions to forget it as soon as possible and updated the description of deriving the and from the [welcoming new members] section. [key schedule]: URL [welcoming new members]: URL
Thanks for the quick fix, NAME !
Change:
private key.  The mechanism proposed in this document allows the delegation to be done off-line, with no per-transaction latency.  The figure below compares the message flows for these two mechanisms with <del> TLS 1.3 I-D.ietf-tls-tls13, where DC is delegated credentials. </del> <ins> TLS 1.3 I-D.ietf-tls-tls13. </ins> These two mechanisms can be complementary.  A server could use credentials for clients that support them, while using LURK to

Discussion:
No substantive changes, just grammatical nits and suggestions for clarifying the exposition. In the "Client Behavior" section (Section 3.1), I added a sentence explaining how to check the time-to-live to the first of the DC-validation steps. This might be helpful, as folks have been confused in the past about how to determine if a DC has expired.
LGTM
Change:
See the Security Considerations in I-D.ietf-tls-external-psk- importer for more information. <del> Where possible the master PSK (that which is fed into the importer) SHOULD be deleted after the imported keys have been generated.  This protects an attacker from bootstrapping a compromise of one node into the ability to attack connections between any node; otherwise the attacker can recover the master key and then re-run the importer itself. </del> <ins> Where possible the main PSK (that which is fed into the importer) SHOULD be deleted after the imported keys have been generated. This protects an attacker from bootstrapping a compromise of one node into the ability to attack connections between any node; otherwise the attacker can recover the main key and then re-run the importer itself. </ins> 7.1.

Discussion:
s7 includes the following and in light of 8446bis we should probable replace "master": Where possible the master PSK (that which is fed into the importer) SHOULD be deleted after the imported keys have been generated. This protects an attacker from bootstrapping a compromise of one node into the ability to attack connections between any node; otherwise the attacker can recover the master key and then re-run the importer itself.
Change:
The ACME client periodically contacts the CA to get updated certificates, stapled OCSP responses, or whatever else would be <del> required to keep the server functional and its credentials up-to- date. </del> <ins> required to keep the web server functional and its credentials up- to-date. </ins> In this way, it would be nearly as easy to deploy with a CA-issued certificate as with a self-signed certificate.  Furthermore, the

Discussion:
As pointed out by NAME on the ACME mailing list there are a few places where there was some potential ambiguity about what "server" meant. This PR is the result of a once-through pass looking for places where we could be more specific when saying "server". In most cases the default definition of "server" from the Terminology section applied and no change was made. I attempted to clarify any usage of "server" that wasn't qualified sufficiently to differentiate from the ACME server.
Change:
If the decrypted value's length is different from the advertised ESNIKeys.padded_length or the padding consists of any value other than 0, then the server MUST abort the connection with an <del> illegal_parameter alert.  Otherwise, the server uses the </del> <ins> "illegal_parameter" alert.  Otherwise, the server uses the </ins> PaddedServerNameList.sni value as if it were the "server_name" extension.  Any actual "server_name" extension is ignored, which also means the server MUST NOT send the "server_name" extension to the

Discussion:
Since the client's ESNI key share doesn't change across CHs in response to a HRR, the same AEAD IV would be used to encrypt/decrypt two different messages. This is an attempt to fix that, while also specifying the server-side HRR behavior. (Basically, check that the ESNI contents have not changed.)
Nice catch, Would it make more sense to instead use the KeyShare as a salt in the HKDF?
Or you could include the handshake transcript up to, but not including, the ClientHello. That is the empty string before HRR< but something else after.
That is a little iffy with cookie-only HelloRetryRequests. Those don't change the ClientHello key shares list, so the client would derive the same key + nonce pair. The client would also use the same plaintext so it's fine, but it seems an unnecessarily fragility.
Agreed. I think I prefer the "new DH" version.
Thank you for the changes! LGTM.
Change:
Use of connection IDs is specifically discouraged for NAT applications.  If a NAT hits an operational limit, it is recommended to rather drop the initial packets of a flow (see also sec- <del> filtering), which potentially triggers a fallback to TCP.  Use of the </del> <ins> filtering), which potentially triggers TCP fallback.  Use of the </ins> connection ID to multiplex multiple connections on the same IP address/port pair is not a viable solution as it risks connectivity breakage, in case the connection ID changes.

Discussion:
Per Al Morton's opsdir review, review the use of these three terms and correct where appropriate.
Change:
5.2.2. This message is used to provide explicit proof that an endpoint <del> possesses the private key corresponding to its certificate.  The </del> <ins> possesses the private key corresponding to its identity.  The </ins> definition for TLS 1.3 is: The algorithm field specifies the signature algorithm used (see

Discussion:
This changes a lot of text, since many places (perhaps rightfully so) assume the contents of the Certificate message are a normal X509 certificate. Some uses of EAs might just use the Certificate message as a vehicle for other identifying information. Thus, rather than box ourselves into a corner, this change generalizes the purpose of this Certificate to be that of an identity. Addresses .
The document's currently written in such a way that one might assume it can only be used to authenticate additional certificates. For example, the introduction states: (emphasis mine!) However, [1] suggests that other authentication mechanisms are possible. (Meta observation and question: what are the contents of the Authenticator messages in the OPAQUE EA flow? Section 6 discusses the possibility of an empty Authenticator, but the OPAQUE flow uses the extension to provide the server response. What OPAQUE seems to require is an empty but non-empty .) Perhaps we should generalize certificate-based authentication to arbitrary challenge-response authentication mechanisms? [1] URL
cc NAME
Change:
3.1. <del> [[OPEN ISSUE: Align this with best practice, cribbing from ACME.]] Errors SHOULD be reported in PPM at the HTTP layer, using an HTTP response code of 400.  The response payload is a Alert structure: where "task_id" is the associated PPM task (this value is always known, see task-configuration) and "payload" contains a string indicating the error that occurred.  When sent by an aggregator in response to an HTTP request, the response status is 400.  When sent in a request to an aggregator, the URL is always "[aggregator]/error", where "[aggregator]" is the URL of the aggregator endpoint. [[OPEN ISSUE: What is the URL? https://github.com/abetterinternet/ prio-documents/issues/108]] The following list defines a set of common errors. The message type for the payload of each request and response is unique for a given URL.  If ever a client, aggregator, or collector receives a request or response to a request with a malformed payload, then the receiver aborts and alerts the peer with "unrecognized message". Each POST request to an aggregator contains a "TaskID".  If the aggregator does not recognize the task, i.e., it can't find a "Param" for which the derived task ID matches the "TaskID", then it aborts and alerts the peer with "unrecognized task". [[TODO: Add error table here.]] </del> <ins> Errors can be reported in PPM both at the HTTP layer and within challenge objects as defined in iana-considerations.  PPM servers can return responses with an HTTP error response code (4XX or 5XX).  For example, if the client submits a request using a method not allowed in this document, then the server MAY return status code 405 (Method Not Allowed). When the server responds with an error status, it SHOULD provide additional information using a problem document RFC7807.  To facilitate automatic response to errors, this document defines the following standard tokens for use in the "type" field (within the PPM URN namespace "urn:ietf:ppm:acme:error:"): This list is not exhaustive.  The server MAY return errors set to a URI other than those defined above.  Servers MUST NOT use the PPM URN namespace for errors not listed in the appropriate IANA registry (see ppm-urn-space).  Clients SHOULD display the "detail" field of all errors.  The "instance" value MUST be the endpoint to which the request was targeted.  The problem document MUST also include a "taskid" member which contains the associated PPM task ID (this value is always known, see task-configuration). In the remainder of this document, we use the tokens in the table above to refer to error types, rather than the full URNs.  For example, an "error of type 'unrecognizedMessage'" refers to an error document with "type" value "urn:ietf:params:acme:error:unrecognizedMessage". </ins> This document uses the verbs "abort" and "alert with "[some error message]"" to describe how protocol participants react to various

Discussion:
ACME has a pretty well defined error structure, including RFC 8707 problem documents. We should look at adopting that.
Fixed by
Change:
If encoding as PublicMessage, compute the "membership_tag" value using the "membership_key". <del> If encoding as an PrivateMessage, encrypt the message using the </del> <ins> If encoding as a PrivateMessage, encrypt the message using the </ins> "sender_data_secret" and the next (key, nonce) pair from the sender's handshake ratchet.

Discussion:
URL
:+1: Thank you very much for all of the explicitly worked examples. What is the reason for MUST vs RECOMMENDED difference in the two different circumstances when validating the `lifetime` field? Consider adding a platitude about communicating nodes SHOULD use some method of time synchronization... "top of these basic mechanism" -> "top of these basic mechanisms" (or maybe "top of this basic mechanism") "in an PrivateContentTBE structure" -> "in a PrivateContentTBE structure"
Change:
All ECDSA computations MUST be performed according to ANSI X9.62 X962 or its successors.  Data to be signed/verified is hashed, and the result run directly through the ECDSA algorithm with no additional <del> hashing.  The default hash function is SHA-1 SHS.  However, an alternative hash function, such as one of the new SHA hash functions specified in FIPS 180-4 SHS SHOULD be used instead if the certificate containing the EC public key explicitly requires use of another hash function.  (The mechanism for specifying the required hash function has not been standardized, but this provision anticipates such standardization and obviates the need to update this document in response.  Future PKIX RFCs may choose, for example, to specify the hash function to be used with a public key in the parameters field of subjectPublicKeyInfo.)  [[OPEN ISSUE: This needs updating per 4492-bis https://github.com/tlswg/tls13-spec/issues/59]]. </del> <ins> hashing.  The SignatureAndHashAlgorithm parameter in the DigitallySigned object indicates the digest algorithm which was used in the signature. </ins> In the following example

Discussion:
This completes the removal of SHA-1 for CertificateVerify. There's no reason to allow it there at all
LGTM
Change:
To encrypt EncodedClientHelloInner, the client first needs to generate the HPKE encryption context.  It computes the encapsulated <del> key, context, HRR key (see hrr), and payload as: </del> <ins> key, context, HRR key (see client-hrr), and payload as: </ins> Note that the HPKE functions Deserialize and SetupBaseS are those which match "ECHConfig.kem_id" and the AEAD/KDF used with "context"

Discussion:
This fixes a few issues with the "Upon determining the true SNI" paragraph: It talkes about determining the "true SNI", but we should probably talk about the ClientHelloInner more generally. It refers to behavior in "the following section" which no longer matches. This is a remnant of before Shared Mode was described as a special case of Split Mode, so remove it. It says the server forwards messages unmodified, which isn't true. It needs to forward the decrypted ClientHello. It also needs to process HRR. I've cited the HRR section for the modified decryption procedure, which doesn't really exist right now, but is handling that.
Yup, this aligns with my understanding!
Change:
be used to receive multicast messages.  The Remote Endpoint can be used to filter incoming multicast from specific senders.  Such a Preconnection will only support calling Listen(), not Initiate(). <del> The accepted Connections are receive-only. </del> <ins> Calling Listen() will cause the Transport Services system to register for receiving multicast, such as issuing an IGMP join RFC3376 or using MLDv2 for IPV6 RFC4604.  Any Connections that are accepted from this Listener are receive-only. </ins> Similarly, specifying a multicast group address on the Remote Endpoint will indicate that the resulting connection will be used to send multicast messages, and that the Preconnection will support <del> Initiate() but not Listen().  The Connection created this way is </del> <ins> Initiate() but not Listen().  Any Connections created this way are </ins> send-only. A Rendezvous() call on Preconnections containing group addresses results in an EstablishmentError as described in rendezvous. <ins> See multicast-examples for more examples. </ins> 6.1.2. An Endpoint can have an alternative definition when using different

Discussion:
I realise I'm late reviewing this, but this approach seems pretty cumbersome. Why do we need two connections, once send only and one receive only, rather than a single bidirectional connection? It also seems cumbersome to implement: both objects will be bound to the same port, and so will receive the multicast packets once the group has been joined. The send-only must then filter out those received packets?
In the multicast endpoint section, we should have explicit examples for patterns of ASM and SSM. Listen(multicast address, port, interface) Get a connection from a specific remote endpoint Initiate a connection back to talk to that endpoint, etc
We should mention the IGMP joining in Implementation, etc too
If we haven't done so, should note than one process may receive from the same address with SO_REUSEADDR so that every incoming multicast or broadcast UDP datagram destined to the shared port is delivered to all.
NAME I think the other bits about reuse address belong in implementation, filed
See my comment on – this approach seems cumbersome
For SSM, -> send only, -> receive only, makes sense. But for ASM, I'm increasingly thinking that we also want -> multicast peer that can both send and receive on a single local port: you want sender and receiver to be bound to the same local address/port pair.
I feel uncomfortable here. I have been persuaded we should add ASM Multicast. I suggest try a PR and see if this is simple and helpful?
Interim: waiting on NAME
CSP to propose a PR to see if this needs to be taken in a different direction.
Change:
use with minimal risk of version- dependence. If these assumptions are invalid, this specification is likely to <del> lead to loss of packets that contain non-compliant DCIDs, and in extreme cases connection failure. </del> <ins> lead to loss of packets that contain unroutable DCIDs, and in extreme cases connection failure. </ins> Some load balancers might inspect elements of the Server Name Indication (SNI) extension in the TLS Client Hello to make a routing

Discussion:
and
I'd suggest 'Fallback' or another word than arbitrary. A definition of Arbitrary is: "Based on random choice or personal whim, rather than any reason or system." In fact, there are sensible constraints on this algorithm to ensure routing works correctly for non-compliant CIDs and connections don't fail.
Agreed.
In PR I suggested non-routable, though I realize non-conformant may also be an option. The sentence which caused me to suggest non-routable is: URL I'm happy to write a PR if others find non-compliant potentially confusing as well.
I like it. Let's go with it.
Thanks, this is a lot easier to read for me.
Change:
For each supported codec that is present in the offer, "a=rtpmap" and "a=fmtp" lines, as specified in RFC4566, Section 6, and <del> RFC3264, Section 6.1.  For audio, the codecs specified in I- D.ietf-rtcweb-audio, Section 3, MUST be supported.  Note that for simplicity, the answerer MAY use different payload types for codecs than the offerer, as it is not prohibited by Section 6.1. </del> <ins> RFC3264, Section 6.1.  The REQUIRED audio and video codecs to support are specified in I-D.ietf-rtcweb-audio (see Section 3) and I-D.ietf-rtcweb-video (see Section 5).  Note that for simplicity, the answerer MAY use different payload types for codecs than the offerer, as it is not prohibited by Section 6.1. </ins> If this m= section is for media with configurable frame sizes, e.g. audio, an "a=maxptime" line, indicating the smallest of the

Discussion:
lgtm with justin's comments.
Ping on this
overall this LG for consistency with the surrounding text, I would change the usage of "[XXXX] (see Section 3)" to "[XXXX], Section 3"
Change:
feedback mechanisms that SHOULD/MUST be supported is specified in I-D.ietf-rtcweb-rtp-usage, Section 5.1. <del> An "a=ssrc" line, as specified in RFC5576, Section 4.1, indicating the SSRC to be used for sending media, along with the mandatory "cname" source attribute, as specified in Section 6.1, indicating the CNAME for the source.  The CNAME MUST be generated in accordance with Section 4.9 of I-D.ietf-rtcweb-rtp-usage. If RTX is supported for this media type, another "a=ssrc" line with the RTX SSRC, and an "a=ssrc-group" line, as specified in RFC5576, section 4.2, with semantics set to "FID" and including the primary and RTX SSRCs. If FEC is supported for this media type, another "a=ssrc" line with the FEC SSRC, and an "a=ssrc-group" line with semantics set to "FEC-FR" and including the primary and FEC SSRCs, as specified in RFC5956, section 4.3.  For simplicity, if both RTX and FEC are supported, the FEC SSRC MUST be the same as the RTX SSRC. </del> If the bundle policy for this PeerConnection is set to "max- bundle", and this is not the first m= section, or the bundle policy is set to "balanced", and this is not the first m= section

Discussion:
a=ssrc and a=ssrc-group.
NAME note I still assume you might receive a=ssrc because it might come from non-JSEP endpoints. LMK if you want that removed.
Change:
2.1. <del> A JSONPath expression is a string which, when applied to a JSON value, the </del> <ins> A JSONPath is a string which, when applied to a JSON value, the </ins> , selects zero or more nodes of the argument and outputs these nodes as a nodelist.

Discussion:
Signed-off-by: Tim Bray Nothing fancy here, just like the title says.
LGTM, thanks.
Change:
This document describes TLS 1.3, which uses the version 0x0304.  This version value is historical, deriving from the use of 0x0301 for TLS 1.0 and 0x0300 for SSL 3.0.  In order to maximize backwards <del> compatibility, records containing an initial ClientHello MUST have </del> <ins> compatibility, records containing an initial ClientHello SHOULD have </ins> version 0x0301 and a record containing a second ClientHello or a ServerHello MUST have version 0x0303, reflecting TLS 1.0 and TLS 1.2 respectively.  When negotiating prior versions of TLS, endpoints

Discussion:
says: But the following text follows: MAY and MUST mismatch. Let's s/MUST/SHOULD/