jiebi/CodeConvo huggingface dataset:
Change:
the user in satisfying the conditions to escape captivity. Captive Portal API: Also known as API.  An HTTP API allowing User <del> Equipment to query its state of captivity within the Captive Portal. </del> <ins> Equipment to query information about its state of captivity within the Captive Portal.  This information might include how to obtain full network access (e.g. by visting a URI). </ins> Captive Portal API Server: Also known as API Server.  A server hosting the Captive Portal API.

Discussion:
The API provides more than just a simple boolean sttate: it allows the UE to learn how to escape captivity. To set the tone for a more complicated API, mention this in the terminology section's definition of the Captive Portal API.
This currently only mentions the state of captivity, whereas it should also include how to get out captivity.
Change:
they are presumed to exist in order to convey conceptual messages appropriately between roles. <del> For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles. As a system bus-connected entity, a Verifier consumes Evidence from other devices connected to the system bus that implement Attester roles.  As a wide-area network connected entity, it may implement an Attester role. </del> In essence, an entity that combines more than one role creates and consumes the corresponding conceptual messages as defined in this document.

Discussion:
The example used in roles and entities actually do not illustrate two aggregated/collapsed roles that talk with each other, as they seem to be entities in two different RATS setups?
Agreed to delete paragraph:"For example, an entity that both connects to a wide-area network and to a system bus is taking on both the Attester and Verifier roles. As a system bus-connected entity, a Verifier consumes Evidence from other devices connected to the system bus that implement Attester roles. As a wide-area network connected entity, it may implement an Attester role."
Change:
connection is in the draining state. An endpoint MAY transition from the closing period to the draining <del> period if it can confirm that its peer is also closing or draining. Receiving a CONNECTION_CLOSE frame is sufficient confirmation, as is receiving a stateless reset.  The draining period SHOULD end when the closing period would have ended.  In other words, the endpoint can use the same end time, but cease retransmission of the closing packet. </del> <ins> period if it receives a CONNECTION_CLOSE frame or stateless reset, both of which indicate that the peer is also closing or draining. The draining period SHOULD end when the closing period would have ended.  In other words, the endpoint can use the same end time, but cease retransmission of the closing packet. </ins> Disposing of connection state prior to the end of the closing or draining period could cause delayed or reordered packets to be

Discussion:
This doesn't seem implementable without a list of all the things that were sufficient.
That is the list. If you think it should be reworded, I'm happy to take a PR.
Change:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP <del> 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> <ins> 14 BCP14 when, and only when, they appear in all capitals, as shown here. </ins> This document uses the terminology established in QUIC-TRANSPORT.

Discussion:
This includes all the updates to references in transport. This includes new code again. See URL It would be possible to cite BCP38 as an RFC and avoid this, but I think that the BCP reference is correct. Not as sure about the BCP145 reference, as we need to point to the RFC directly to get the section reference, but I think that is OK on balance.
Change:
The collector decrypts these aggregate shares using the opposite process.  Specifically, given an encrypted input share, denoted <del> "enc_share", for a given batch interval, denoted "batch_interval", </del> <ins> "enc_share", for a given batch selector, denoted "batch_selector", </ins> decryption works as follows: where "sk" is the HPKE secret key, "task_id" is the task ID for the

Discussion:
The Aggregate Share Encryption section still had a few references to "batch interval", but the encryption process now uses the "batch selector".
Change:
They include: The SNI is probably also included in the general collection of <del> metadata by pervasive surveillance actors, for example to identify services used by surveillance targets. </del> <ins> metadata by pervasive surveillance actors RFC7258, for example to identify services used by surveillance targets. </ins> 2.2.

Discussion:
Trying to address the last comments (issue ).
NAME I hope this reflects our discussion.
Checking in after Roman's comments on the list.
Change:
be more consistent and to remove superfluous messages such as ChangeCipherSpec. <del> Elliptic curve algorithms are now in the base spec and includes new signature algorithms, such as ed25519 and ed448.  TLS 1.3 removed point format negotiation in favor of a single point format for each curve. </del> <ins> Elliptic curve algorithms are now in the base spec and new signature algorithms, such as ed25519 and ed448, are included. TLS 1.3 removed point format negotiation in favor of a single point format for each curve. </ins> Other cryptographic improvements including the removal of compression and custom DHE groups, changing the RSA padding to use

Discussion:
NAME I did not: 1) add the "Chosen ciphertext attacks against protocols based on the RSA encryption standard PKCS " reference because it's already in the [JSS15] reference that's later in the sentence. 2) I also didn't made [AEAD-LIMITS] normative.
Change:
The returned voucher contains an attribute, "est-domain", defined in redirected below.  The pledge is directed to continue enrollment <del> using the EST registrar found at that URI.  The pledge uses the pinned-domain-cert from the voucher to authenticate the EST registrar. </del> <ins> using the EST server found at that URI.  The pledge uses the pinned- domain-cert from the voucher to authenticate the EST server. </ins> The process starts, in step 1, when the Pledge establishes a Mutual TLS channel with the Cloud RA/MASA using artifacts created during the

Discussion:
what is the "EST Registrar"? It is not defined so far. Wouldn't it be better to use RFC 8995 terminology of "EST server" ? So if the cloud Registrar supplies the Voucher and that redirects to an owner's EST server, we can call that "EST server" or "owner EST server". It's not a Registrar, so not "EST Registrar" or "owner Registrar". The latter term is already used for the server that provides a voucher to the pledge. (Interesting to consider that the owner's EST server could be a Registrar i.e. handing out vouchers in theory, even if the cloud-Registrar-supporting-pledge already got its voucher from the cloud-Registrar. But let's not say such things in the document to avoid complicating it.)
Change:
Abstract This document describes the technical mechanisms used by censorship <del> regimes around the world to block or degrade Internet traffic.  It </del> <ins> regimes around the world to block or impair Internet traffic.  It </ins> aims to make designers, implementers, and users of Internet protocols aware of the properties being exploited and mechanisms used to censor end-user access to information.  This document makes no suggestions

Discussion:
…nce. defines censorship. fixes definition of identification in intro.
First, one thing that isn’t clear immediately from the introduction is who/what is a “censor”. I find it a little strange, actually, to suggest that a censor performs "aggregation". Is the censor an ISP? A government? Something else? For example, a government may have loose policies about what kind of content to censor (e.g., "hate speech"). An ISP might in turn implement these loose policies in different ways. Policies can also differ across a country, etc. The other terms---identification and prevention---are similarly confusing, although I think the term "identification" isn't as problematic as its (incorrect?) definition in the introduction. "Identification is the process by which censors determine whether content is blocked" - NO. I think it is the process by which a censor might classify traffic to determine whether to block a traffic flow or now. I would suggest something like: prescription, identification, and interference.
Wondering what you think about "design, identification, and interference"? I think for the purposes of todays 20:00 ET IETF drafts deadline, I'll change the terminology throughout to match prescription, identification, and interference and I'll correct the other things mentioned here (define censor, fix definition of identification in intro).
That seems a bit more clear, indeed! Ah, I didn't realize there was a deadline of today 2000h. Not sure I can get you a pull request by then, but will try.
I'll leave this open. You by no means need to get a pull request by 20:00! I just want to do my best to make changes responsive to your feedback. I'll leave this open and you can see what I've done (I'll be working on trying to clear out issues until then), and feel free to submit changes as you think are needed.
Change:
Change Controller: IESG <del> 9.9. </del> <ins> 9.10. </ins> IANA has added the media type 'application/edhoc' to the CoAP Content-Formats registry.

Discussion:
Discussion today in COSE on how to do RPK by value in EDHOC. Suggestions to send a COSE_Key or a C509. Additional suggestion from Carsten to use CWT. Several issues in the old GitHub on CWTs, that were not transfered to the new GitHub: URL URL URL Discussion to transfer CWT in kid, in Auxilery data, and as COSE header parameter. Transfering CWT is related to issues , , ,
I made a pull request for this URL I think it is essential that EDHOC supports CWT. CWTs are much more flexible than X.509 / C.509. I think both are needed. The need for CWT has been discussed since 2016. I think it was decided clear quite early that transporting CWT is needed but was a discussion on how to transfer them. In Aux Data, in COSE header parameter, or in the kid bstr. For some reason nothing was ever specified. TLS WG is discussing to add support for CWT. URL I think certificates and CWT needs to be included, I am not sure that we need a different format for RPK. Likely CWT or C509 can be used for this purpose.
I think it should be discussed if CWT is good enough for the . My initial understanding is that it is but this needs to be analyzed and discussed. My current thoughts. CWT needs to be supported in EDHOC. Most things in CWT is optional, it is likely an optimized enough format for the oportunistic / TOFU use case of "RPK". CWT is also very flexible. When CWT exist it would be strange to standardize a new format for transfereing a COSEKey unless it is really really needed to save bytes. CWT + Deterministic CBOR could maybe replace the discussion on how to integrity protect COSEKeys. We should at least remove the new subjectname from the COSEKey part in the EDHOC document. CWT and C509 can be used when subject name is needed. Does "Raw" COSE_Keys that are not CWT even need to be supported? Or would CWT / C509 / X.509 be enough
This change has now been done in the master branch, see a1b25ba and commits in its vicinity. Can we close the issue?
This has now been addressed.
Change:
9.3. <del> Header protection relies on the packet protection AEAD being a pseudorandom function (PRF), which is not a property that AEAD algorithms guarantee.  Therefore, no strong assurances about the general security of this mechanism can be shown in the general case. The AEAD algorithms described in this document are assumed to be PRFs. The header protection algorithms defined in this document take the form: This construction is secure against chosen plaintext attacks (IND- CPA) IMC. </del> <ins> NAN analyzes authenticated encryption algorithms which provide nonce privacy, referred to as "Hide Nonce" (HN) transforms.  The general header protection construction in this document is one of those algorithms (HN1).  Header protection uses the output of the packet protection AEAD to derive "sample", and then encrypts the header field using a pseudorandom function (PRF) as follows: The header protection variants in this document use a pseudorandom permutation (PRP) in place of a generic PRF.  However, since all PRPs are also PRFs IMC, these variants do not deviate from the HN1 construction. As "hp_key" is distinct from the packet protection key, it follows that header protection achieves AE2 security as defined in NAN and therefore guarantees privacy of "field", the protected packet header. Future header protection variants based on this construction MUST use a PRF to ensure equivalent security guarantees. </ins> Use of the same key and ciphertext sample more than once risks compromising header protection.  Protecting two different headers

Discussion:
This paper studies several "nonce hiding" transformations, of which the QUIC header protection algorithm is one. This change replaces the old analysis text with something a bit more crisp.
I'm really happy to see good research on this that confirms our intuitions about one of the most important QUIC-specific constructions. Thanks for doing this Chris. Are you planning to make a similar contribution to DTLS 1.3?
My pleasure. :-) Yep!
Change:
3.4. <del> This document defines a SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter </del> <ins> This document defines a SETTINGS_WEBTRANSPORT_MAX_SESSIONS parameter </ins> that allows the server to limit the maximum number of concurrent WebTransport sessions on a single HTTP/3 connection.  The client MUST NOT open more sessions than indicated in the server SETTINGS

Discussion:
Fix up references to setting names
The draft uses both but I presume they refer to the same thing, so lets pick one.
Ah, left over from a previous change, I believe. is the correct form, can update to match.
Yep sgtm
Change:
begin gathering candidates for each transport, using ones from the candidate pool if available. <del> If setRemoteDescription was previously called with an offer, and </del> <ins> If (1) setRemoteDescription was previously called with an offer, (2) </ins> setLocalDescription is called with an answer (provisional or final), <del> and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. </del> <ins> (3) the media directions are compatible, and (4) media is available to send, this will result in the starting of media transmission. </ins> 4.1.10.

Discussion:
clarified that there are four conditions, removed comment. issue 14
14) [rfced] Sections 4.1.9 and 4.1.10: We had trouble following the purpose of all of the "and"s in these sentences. Are four conditions set in these sentences, or fewer? Original: If setRemoteDescription was previously called with an offer, and setLocalDescription is called with an answer (provisional or final), and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. ... If setLocalDescription was previously called with an offer, and setRemoteDescription is called with an answer (provisional or final), and the media directions are compatible, and media is available to send, this will result in the starting of media transmission. Possibly: If (1) setRemoteDescription was previously called with an offer, (2) setLocalDescription is called with an answer (provisional or final), (3) the media directions are compatible, and (4) media is available to send, media transmission can start. ... If (1) setLocalDescription was previously called with an offer, (2) setRemoteDescription is called with an answer (provisional or final), (3) the media directions are compatible, and (4) media is available to send, media transmission can start.
need to keep 'this will result in the starting of media transmission'
There are 4 conditions that have to be satisfied, as noted.
Change:
Additionally, a malicious non-member can reroute handshakes between honest group members to connect them in unintended ways, as described <del> below.  (Note that this class of attack is not possible if each member uses the SNI extension RFC6066 and terminates the connection on mismatch.  See Selfie for details.)  Let the group of peers who know the key be "A", "B", and "C".  The attack proceeds as follows: </del> <ins> below.  Note that this class of attack is not possible if each member uses the SNI extension RFC6066 and terminates the connection on mismatch.  See Selfie for details. To illustrate the rerouting attack, consider the group of peers who know the PSK be "A", "B", and "C".  The attack proceeds as follows: </ins> "A" sends a "ClientHello" to "B".

Discussion:
Resolve comments from Ben Smyth.
NAME can you please cut a new version of the draft?
Done. Revision -02 has been submitted.
I am getting a permission error when I try to set the tag for "draft-ietf-tls-external-psk-guidance-02". Everything else is done, and I have used my local file to submit the Internet-Draft. Please set the tag when you have a minute.
Change:
A Verifier or Relying Party might need to learn the point in time (i.e., the "epoch") an Evidence or Attestation Result has been produced.  This is essential in deciding whether the included Claims <del> and their values can be considered fresh, meaning they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence. </del> <ins> can be considered fresh, meaning they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence. </ins> This section provides a number of details.  It does not however define any protocol formats, the interactions shown are abstract.

Discussion:
Section 10 first paragraph has the phrase "Claims and their values "; which is redundant. "Claims" is sufficient.
Change:
the lengths of the content and the padding, plus one for the inner content type, plus any expansion added by the AEAD algorithm. <del> The cid value of length indicated with cid_length, as agreed </del> <ins> The CID value of length indicated with cid_length, as agreed </ins> during the exchange. The AEAD-encrypted form of the serialized DTLSInnerPlaintext

Discussion:
It probably makes sense to be a little more consistent.
Makes sense. I will do this after the current wave of pull requests have been reviewed and accepted/rejected.
I addressed this issue in PR
Addressed with submitted draft version -04
I don't think that you need to change the grammar.
Change:
Different types of authenticators, using different token issuance protocols, can be used as Privacy Pass tokens. <del> This document defines a common HTTP authentication scheme (RFC9110), PrivateToken, that allows clients to redeem various kinds of Privacy Pass tokens. </del> <ins> This document defines a common HTTP authentication scheme (RFC9110, Section 11), PrivateToken, that allows clients to redeem various kinds of Privacy Pass tokens. </ins> Clients and relying parties interact using this scheme to perform the token challenge and token redemption flow.  Clients use a token

Discussion:
Previously, the document linked to RFC 7235, whose whole purpose was to discuss HTTP Authentication. Now you kjust link to RFC 9110, which all of HTTP semantics. Suggest that you link to Section 11 of RFC 9110 to make the reader's life easier.
Change:
4.3. <del> A different Captive Portal API URL could be returned in the following </del> <ins> A different Captive Portal API URI could be returned in the following </ins> cases: <del> Whenever a new Portal URL is received by end User Equipment, it SHOULD discard the old URL and use the new one for future requests to </del> <ins> Whenever a new Portal URI is received by end User Equipment, it SHOULD discard the old URI and use the new one for future requests to </ins> the API. 5.

Discussion:
This replaces any 'URL' terminology with 'URI'. It also adds an informative reference to RFC 3986 , as suggested. Fixes issue
Multiple reviewers have suggested that we use URI instead of URL. I think we should make this change, and add the informative reference.
Change:
authority information about an Endpoint.  The Context of an Endpoint is provided at registration time, and is used by the Resource Directory to resolve relative references inside the <del> registration into absolute URIs. </del> <ins> registration into absolute URIs.  This is a distinct concept from the "link context" defined in RFC8288. </ins> The target of a link is the destination address (URI) of the link. It is sometimes identified with "href=", or displayed as "<target>".  Relative targets need resolving with respect to the <del> Base URI (section 5.2 of RFC3986. </del> <ins> Base URI (section 5.2 of RFC3986.  This use of the term Target is consistent with RFC8288's use of the term. </ins> A resource in the Resource Directory (RD) containing registration

Discussion:
With the formal introduction of Target in 68bd92a9, this seems even more important to point out. Next steps: merge unless someone protests.
Change:
leader may already have computed the results and can return them immediately.  In either case, once the leader has obtained the helper's encrypted output share for the batch, it responds to the <del> collector's request with the CollectResp message: </del> <ins> collector's request with HTTP status 200 and a body consisting of a CollectResp message: </ins> [[OPEN ISSUE: What happens if this all takes a really long time.]] [TODO: Decide if and how the collector's request is authenticated.] <del> [[TODO: Define the fields]] </del> <ins> "leader_share" and "helper_share" are "EncryptedOutputShare"s as described in output-share-request, except that the "task_id", "batch_start", and "batch_end" used to encrypt the "OutputShare" are obtained from the "CollectReq". </ins> <del> [[OPEN ISSUE: change this to just have a list of shares </del> <ins> [[OPEN ISSUE: change CollectResp to just have a list of shares </ins> https://github.com/abetterinternet/prio-documents/issues/112]] [OPEN ISSUE: Describe how intra-protocol errors yield collect errors

Discussion:
Removes some TODOs, clarifies why we have HpkeConfig collectorconfigstruct PPMParamUrl collectorurl, and amends collect protocol so that leader output shares are encrypted to collector's HPKE config. Several response structures no longer have or fields if the appropriate task (and hence and hence ) can be inferred from the request.
I want to address in this PR as well, so downgrading to draft for now.
NAME NAME This is ready; please review at your convenience.
Thank you for the review, NAME This picked up some merge conflicts so I will wait for all of NAME changes to land and then rebase.
You should be able to rebase now. I am mostly done.
Rebased, reordered, ready for re-review
This seems to be a dupe fo -- can we close?
Per discussion in the call today, I think this issue is about updating the various PDU definitions to allow for multiple helpers. For instance, currently has fields and , but it should instead have . is the more complex problem of extending the protocol to handle >1 helper, which probably involves more rounds of communication. I'm going to grab this issue because I ran into which I think is related, so I'll fix both.
Right now only the helper's output share for a batch of reports is encrypted to the collector. We previously agreed that all input shares should be encrypted to the corresponding aggregator (URL). It makes sense to encrypt the leader's output share for the same reasons we discussed there. Along the way, the message format should be made to accommodate multiple helpers, as we did for the input shares.
Fixed in . Making "the message format [...] accommodate multiple helpers" is specifically tracked in and resolved by .