jiebi/CodeConvo huggingface dataset:
Change:
"signature_algorithms" extension consisting solely of this group. indicates that the ClientHello.Random and ServerHello.Random <del> values are truncated to the given values.  When the transcript is </del> <ins> values are truncated to the given length.  When the transcript is </ins> reconstructed, the Random is padded to the right with 0s and the anti-downgrade mechanism in RFC8446), Section 4.1.3 is disabled. IMPORTANT: Using short Random values can lead to potential <del> attacks.  When Random values are shorter than 8 bytes, PSK-only modes MUST NOT be used, and each side MUST use fresh DH ephemerals.  The Random length MUST be less than or equal to 32 </del> <ins> attacks.  The Random length MUST be less than or equal to 32 </ins> bytes. <ins> [[Open Issue: Karthik Bhargavan suggested the idea of hashing ephemeral public keys and to use the result (truncated to 32 bytes) as random values.  Such a change would require a security analysis. ]] indicates whether the client has to be prepared to transmit a Certificate and a CertificateVerify message and whether the server has to transmit a CertificateRequest message. indicates in what order extensions appear in respective messages. This allows to omit sending the type.  If there is only a single extension to be transmitted, then the extension length field can also be omitted.  For example, imagine that only the KeyShare extension needs to be sent in the ClientHello as the only extension.  Then, the following structure is compressed down to (assuming the KeyShare group has been pre- agreed) </ins> Predefined ClientHello extensions, see {predefined-extensions} Predefined ServerHello extensions, see {predefined-extensions}

Discussion:
This update aims to bring the template-based optimization to the center and focuses on the certificiate-based authentication exchange. Included in this version is the idea to omit the random values transmitted by the client and the server by hashes of the ephemeral public keys.
Change:
and controls at a high level."  (Quoted from RFC6841, Section 2) A specialized piece of hardware that is used to create keys for <del> signatures and to sign messages.  In DNSSEC, HSMs are often used to hold the private keys for KSKs and ZSKs and to create the signatures used in RRSIG records at periodic intervals. </del> <ins> signatures and to sign messages without ever disclosing the private key.  In DNSSEC, HSMs are often used to hold the private keys for KSKs and ZSKs and to create the signatures used in RRSIG records at periodic intervals. </ins> Authoritative DNS servers that support DNSSEC often contain software that facilitates the creation and maintenance of DNSSEC

Discussion:
"each other" is clearer in English. I agree that "whole labels" is better and have changed the text.
At line 139, "each other" may be "others" ? At line 358, "full labels" may be "whole labels" or "each label".
Change:
associated with the ESNI name.  The server was unable to decrypt then ESNI name, so it should not resume them when using the cleartext SNI name.  This restriction allows a client to reject <del> resumptions in verify-public-name. </del> <ins> resumptions in auth-public-name. Note that an unrecognized ClientEncryptedSNI.record_digest value may be a GREASE ESNI extension (see grease-extensions), so it is necessary for servers to proceed with the connection and rely on the client to abort if ESNI was required.  In particular, the unrecognized value alone does not indicate a misconfigured ESNI advertisement (misconfiguration).  Instead, servers can measure occurrences of the "esni_required" alert to detect this case. </ins> If the ClientEncryptedSNI.record_digest value does match the cryptographic hash of a known ESNIKeys, the server performs the

Discussion:
(WG email coming shortly.) Update: This has been rebased to master, now that is merged. The new server behavior ("Improve ESNI robustness") means clients can send GREASE ESNI extensions without interop issues. Write some text recommending this, better meeting the "Do not stick out" criteria.
The GREASE section seems fine to me. (NAME is there other new material in this PR?) NAME NAME please have a look when possible.
It's whatever's in the second commit, so mostly that section but also a bit elsewhere: URL
I share the view that the GREASE section looks fine.
NAME Did you mean to leave the comments on URL (Notably the text already has seen a number of revisions here. I haven't gone back to update this PR yet. This PR was meant to just be the second commit.)
Ugh. Having something which claims to be a merged PR is kind of an attractive nusiance, then, no? Perhaps you can apply the changes here?
In my defense, I split them at your request and did include the following. ;-) But, sure, I can rebase this one. I figured was the bulk of the interesting bits (7401f55013f68ec47dad36b99977ad6aa881d9f1 is much smaller) so I figured we'd first and then I'd update this one at the end.
Sure, and I read that as "this is an accurate reflection of my put for both of these". But, sure, I can rebase this one. I figured Thanks.
Well, it was when I wrote that sentence. :-) Anyway, it's now been rebased and I've incorporated your comments as well.
Change:
5. The encrypted SNI is carried in an "encrypted_server_name" extension, <del> which contains an EncryptedSNI structure: </del> <ins> defined as follows: For clients (in ClientHello), this extension contains the following EncryptedSNI structure: </ins> The cipher suite used to encrypt the SNI.

Discussion:
This is a proposal to address the misrouting and key share replacement attacks identified by Ekr, Karthik, and Benjamin. Please help me improve it!
Some minor nits.
Change:
WT_STREAM_DATA_BLOCKED frames contain the following fields: <del> Stream ID: A variable-length integer indicating the WebTransport stream that is blocked due to flow control. </del> <ins> A variable-length integer indicating the WebTransport stream that is blocked due to flow control. </ins> <del> Maximum Stream Data: A variable-length integer indicating the offset of the stream at which the blocking occurred. </del> <ins> A variable-length integer indicating the offset of the stream at which the blocking occurred. </ins> 5.10.

Discussion:
Make the definition of fields use definition lists. Use superscripts where appropriate. Also, fix this so that it is 2^62-1 and not 2^61 (parentheses were used incorrectly).
Change:
Sending multiple packets into the network without any delay between them creates a packet burst that might cause short-term congestion and losses.  Implementations MUST either use pacing or limit such <del> bursts to the minimum of 10 * kMaxDatagramSize and max(2* kMaxDatagramSize, 14720)), the same as the recommended initial congestion window. </del> <ins> bursts to the initial congestion window, which is recommended to be the minimum of 10 * kMaxDatagramSize and max(2* kMaxDatagramSize, 14720)). </ins> As an example of a well-known and publicly available implementation of a flow pacer, implementers are referred to the Fair Queue packet

Discussion:
From discussion on people prefer the normative text to apply to the initial congestion window, not the specific value recommended in the recovery document. URL
I approve of this editorial change
Change:
2.2. Representations within a bundle are named by their "Content-Location" <del> (Section 8.7 of I-D.ietf-httpbis-semantics), which holds a URL.  This is also known as the representation's URL. </del> <ins> (Section 8.7 of I-D.ietf-httpbis-semantics).  This is also known as the representation's URL.  It is either an absolute-URI or a partial- URI (Section 2.7 of RFC7230).  In the latter case, the referenced URL is relative to the bundle's URL unless an additional section in the bundle specifies a different base URL. </ins> This identifying information for each representation is stored in an index (index-section) rather than in that representation's HTTP

Discussion:
Closes URL
Thanks. Sent URL
The context is URL The current format says: https://wpack-URL URL Given that, it seems the format already allows a relative URL in the index section, however, it'd be better to ask a clarification than guessing its intention. Using a relative URL is supposed to work? If so, we don't need to request a bundle format change to resolve URL
More context: https://chromium-URL This CL is intended to support relative URLs in web bundles for Subrerouce Web Bundle feature.
NAME What do you think about this? I think the section was introduced by this change in WICG/webpackage. URL
cc: NAME NAME
We need to specify how the keys in the index section are parsed, independent of their semantics as s. I'd intended that to eventually move to the when I removed the algorithms in , with the format spec here being less precise, but I think it was a mistake that I didn't even specify between absolute and relative URLs in the index. We should probably add a sentence here to say which it is. Since we have a use case for relative URLs, let's pick that one. This spec should say something about what the URLs are relative to. Probably a bundle-defined base URL, which defaults to the location of the bundle but can be overridden by a section's contents? And that it's an error if two sections independently set the base URL without their own definitions disambiguating?
I agree that the spec should clearly say that it supports relative URL. Created . Could you please reivew? I think when we introduce a new section, the section should be able to override the bundle's URL. But I don't know how useful it is yet.
This is a good idea, thank you (and apologies for the delay in providing feedback). I have added a small suggestion .
Thank you, this change looks good to me. I have a small suggestion below.Looks good, but please do run this by EMAIL before merging. Hi, WPACK folks. I'm Tsuyoshi Horo. I am working on Web Packaging in Chromium project. We are thinking about changing the spec of Web Bundles to support relative URLs. Currently, the spec says: (Section 8.7 of [I-D.ietf httpbis-semantics]), which holds a URL.

This is also known as the representation's URL And draft-ietf-httpbis-semantics-19 says: It seems the spec already supports relative URLs. But we'd like to make it clear. So, I created this pull request. URL Do folks here have any opinions on this change of the pull request? Thanks.
Change:
value of "N" unless explicitly requested, and adding a value with a "Recommended" value of "Y" requires Standards Action RFC8126. IESG Approval is REQUIRED for a Y->N transition. <ins> 11.1. IANA [shall rename/has renamed] the "extended_master_secret" value in the TLS ExtensionType Values registry to "extended_main_secret". IANA [shall create/has created] a value for the "general_error" alert in the TLS Alerts Registry with the value given in alert-protocol. </ins>

Discussion:
To keep the text in 8446bis and to avoid having people to read 8446 (and address the OPEN issues) in the IANA Considerations section - from IANA: If you want to keep the old actions in the document, we’d like to see those actions preceded by an introduction or sub-section (or more than one sub-section; however it’s appropriate to structure it) that tells us what the new actions are for this document.
The diffs are informative here - I think there's only adding general_error to TLS Alerts and updating the references to RFC 8446bis vice RFC 8446.
Apologies for any confusion - already address via .
Change:
The RTCP feedback extensions MUST only include those that are present in the most recent answer. <ins> The "a=rtcp" line MUST be added if the most recent answer did not include an "a=rtcp-mux" line; otherwise it MUST NOT be added. </ins> The "a=rtcp-mux" line MUST only be added if present in the most recent answer.

Discussion:
LGTM
What needs to happen to finish this one ?
NAME NAME I think this reflects our discussion in the bug.
LGTM
NAME back at you
Ugh, git push failing due to airplane wifi. Will update when it succeeds
done
Where are we on this. Is this waiting for justin ?
yes, we are waiting for justin
Change:
This document specifies two variants of the the two-message issuance protocol for Privacy Pass tokens: one that produces tokens that are privately verifiable, and another that produces tokens that are <del> publicly verifiable.  The privately verifiable issuance protocol optionally supports public metadata during the issuance flow. </del> <ins> publicly verifiable. </ins> 1.

Discussion:
From NAME issuance flow." Where does this metadata come up in the protocol? As far as I can tell, the two protocols look functionally equivalent modulo who can verify. Perhaps you removed metadata at some point? In particular, double check that the following claim in Section 6 is accurate: "The issuance protocol does not admit public or private metadata to bind additional context to tokens."
Change:
5.3.3. <ins> The createOffer method takes as a parameter an RTCAnswerOptions object.  Special processing is performed when generating a SDP description if the following constraints are present. 5.3.3.1. Handling of the "VoiceActivityDetection" option in answers is the same as is indicated for offers in sec.voiceactivitydetection1. </ins> 5.4. 5.5.

Discussion:
ORTA/ORTV can now be set to a number smaller than the number of MSTs, leading to a=sendonly settings. Also allowed VAD to work in CreateAnswer. ()
LGTM
NAME do you have any remaining concerns?
lgtm
LGTM
Per e-mail, I feel like the text around how to not change extant m= sections is confusing. Ignoring recycling, if we have N mediastreams of which O are old and are sendrecv and someone asks for offerToReceive=M, then we end up with: if O >= M: O sendrecv m= lines N - O sendonly m= lines if O < M: M sendrecv m= lines N - M sendonly m= lines I am fine with that, but I feel like the text may not make it entirely clear.
Change:
If the client sends a JWS signed with an algorithm that the server does not support, then the server MUST return an error with status code 400 (Bad Request) and type <del> "urn:ietf:params:acme:error:badSignatureAlgorithm" (see errors).  The problem document returned with the error MUST include an "algorithms" field with an array of supported "alg" values. </del> <ins> "urn:ietf:params:acme:error:badSignatureAlgorithm".  The problem document returned with the error MUST include an "algorithms" field with an array of supported "alg" values.  See errors for more details on the structure of error responses. </ins> Because client requests in ACME carry JWS objects in the Flattened JSON Serialization, they must have the "Content-Type" header field

Discussion:
EKR pointed out to me privately a couple of remaining issues after his AD review. This PR addresses those issues.
No complaints from me, looks good. Thanks NAME
Change:
YAML YAML is a data serialization format that is widely used on the Internet, including in the API sector (e.g. see oas) but the relevant <del> media type and structured syntax suffix are not registered by IANA. </del> <ins> media type and structured syntax suffix previously had not been registered by IANA. </ins> To increase interoperability when exchanging YAML data and leverage content negotiation mechanisms when exchanging YAML resources, this

Discussion:
addressing (and a few minor editorial changes thrown in as well).
This is probably left over from earlier drafts that did cover multiple media types.
There are a couple more places that use the plural form "media types". Unless I am missing something, these all should be changed to singular form.
It's and . I don't have preferences and the singular is OK to me. Feel free to PR :)
that's what i also thought but then again isn't a media type (as i am sure you know). let's make NAME the tie-breaker!
Let's go with the singular form.
fixed via
Change:
directly, it is considered direct import; if the keys can only be shared by the handshake, they are considered non-importable. <del> Explicit import: QUIC, ESP </del> <ins> Explicit import: QUIC, ESP, OpenVPN </ins> Direct import: TLS, DTLS, tcpcrypt, MinimalT, WireGuard

Discussion:
I'm pretty sure OpenVPN offers the following interfaces, because they are available as command line arguments in the openvpn tool: URL Identities and Private Keys: --cert option and --key Supported Algorithms (Key Exchange, Signatures, and Ciphersuites): --auth alg Pre-Shared Key Import: I think explicit import, as the application can specify the PSK explicitly: --secret key Pre-Shared Key Export: I think Explicit export, because the OpenVPN documentation mentions RFC 5705, RFC 5705 mentions DTLS-SRTP, and DTLS-SRTP is classified as explicit export: keying-material-exporter label len Connection Termination: OpenVPN allows connection restart based on signals SIGHUP and SIGUSR1
Change:
these resources.  This enables clients to bootstrap into the ACME authentication system. <del> The server MAY allow GET requests for certificate resources in order to allow certificates to be fetched by a lower-privileged process, e.g., the web server that will use the referenced certificate chain. (See I-D.ietf-acme-star for more advanced cases.)  A server that allows GET requests for certificate resources can still provide a degree of access control by assigning them capability URLs W3C.WD- capability-urls-20140218.  As above, if the server does not allow GET requests for a given resource, it MUST return an error with status code 405 "Method Not Allowed" and type "malformed". </del> 6.4. It is common in deployment for the entity terminating TLS for HTTPS

Discussion:
This exception doesn't actually improve interop for STAR clients, and it introduces complexity into the security analysis of ACME. STAR can easily solve the problem by defining a new field on orders that provides an explicitly GETtable URL, with whatever security properties the STAR project needs.
Do not merge this without discussion on the mailing list.
Merging based on out-of-band approval from NAME
Change:
Layer-2. <del> Layer-3. </del> Label-switched path. Multiprotocol Label Switching. <del> Provider Edge. </del> Packet Elimination Function. Packet Replication Function.

Discussion:
Note added to 5.1, that L4 multipath is out-of-scope. Please, check note and its placement that it is appropriate. URL URL Internet-Draft draft-ietf-detnet-ip-oam-URL is now available. It is a work item of the Deterministic Networking (DETNET) WG of the IETF. Title: Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane Authors: Greg Mirsky Mach(Guoyi) Chen David Black Name: draft-ietf-detnet-ip-oam-URL Pages: 9 Dates: 2024-02-05 Abstract: This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane. The IETF datatracker status page for this Internet-Draft is: URL There is also an HTML version available at: URL A diff from the previous version is available at: https://author-URL Internet-Drafts are also available by rsync at: URL
Hi Bernard, thank you for your thoughtful comments and helpful suggestions. The authors discussed them and updated the draft to address your concerns. I uploaded the new version: A new version of Internet-Draft draft-ietf-detnet-ip-oam-URL has been successfully submitted by Greg Mirsky and posted to the IETF repository. Name: draft-ietf-detnet-ip-oam Revision: 11 Title: Operations, Administration and Maintenance (OAM) for Deterministic Networks (DetNet) with IP Data Plane Date: 2024-02-05 Group: detnet Pages: 9 URL: URL Status: URL HTML: URL HTMLized: URL Diff: https://author-URL Abstract: This document discusses the use of existing IP Operations, Administration, and Maintenance protocols and mechanisms in Deterministic Networking networks that use the IP data plane. Please let us know whether these updates adequately address your comments. Our sincere thanks for your help in improving this document. Regards, Greg (on behalf of the authors)
Change:
mechanism. A second approach places the onus of timekeeping solely on the <del> appraising entity, e.g., the Verifier (for Evidence), or the Relying </del> <ins> appraising entity, i.e., the Verifier (for Evidence), or the Relying </ins> Party (for Attestation Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time synchronisation is otherwise impaired.  In this approach, a non-

Discussion:
Thomas suggests: The current paragraph looks wrong to me. When it says: [...] solely on the appraising entity, e.g., the Verifier (for Evidence), or the Relying Party (for Attestation Results),` should instead say: [...] solely on the remote attestation protocol initiator, e.g., the Relying Party (for Evidence or Attestation Results) and the Attester (for Attestation Results).
Change:
"alg" (Algorithm) "jwk" (JSON Web Key, for all requests not signed using an <del> existing account, e.g. newAccount) </del> <ins> existing account, e.g., newAccount) </ins> "kid" (Key ID, for all requests signed using an existing account)

Discussion:
Thanks to NAME .
Thanks NAME Merging with one review as this is strictly editorial. I’m not sure what the best forum is to report minor typographical issues, but: : "jwk" (JSON Web Key, for all requests not signed using an existing account, e.g. newAccount) ^^ Everyplace else in the spec puts a comma after “e.g.”, so I would think there should be one here as well. -Felipe Gasper
Change:
contain arbitrary values; implementations concerned about this SHOULD refuse to use connection ids. <del> An on-path adversary, who is able to observe the DTLS 1.2 protocol </del> <ins> An on-path adversary, who is able to observe the DTLS protocol </ins> exchanges between the DTLS client and the DTLS server, is able to link the observed payloads to all subsequent payloads carrying the <del> same connection id pair (for bi-directional communication).  In DTLS 1.3, it is possible to provide new encrypted connection IDs, though of course those IDs are immediately used on the wire.  Without multi- homing and mobility the use of the connection id is not different to the use of the 5-tuple. </del> <ins> same connection id pair (for bi-directional communication).  Without multi-homing or mobility, the use of the connection id is not different to the use of the 5-tuple. </ins> With multi-homing, an adversary is able to correlate the communication interaction over the two paths, which adds further privacy concerns.  In order to prevent this, implementations SHOULD attempt to use fresh connection IDs whenever they change local addresses or ports (though this is not always possible to detect). <del> In DTLS 1.3, The RequestConnectionId message can be used to ask for new IDs in order to ensure that you have a pool of suitable IDs. This document does not change the security properties of DTLS 1.2 RFC6347 and DTLS 1.3 I-D.ietf-tls-dtls13.  It merely provides a more robust mechanism for associating an incoming packet with a stored security context. </del> <ins> This document does not change the security properties of DTLS RFC6347.  It merely provides a more robust mechanism for associating an incoming packet with a stored security context. </ins> [[OPEN ISSUE: Sequence numbers leak connection IDs.  We need to update the document to address this.  One possibility would be the

Discussion:
Remove 1.3 references (based on Hannes's PR ); Protect CID; Initial sketch for explicit marking of CID records using ad hoc CTs.
I also do not understand that
Sorry, you're right. It needs to be in the MAC, but not the key derivation
I don't think we need to include the CID in the MAC since the CID is just the key name. In regular DTLS the 5 tuple is the key name and we don't include it in the MAC calculation either. If someone fakes a packet and places a wrong CID in there then they MAC will just fail since either (a) the wrong key will be looked up or (b) no key is found at all. In either case there is no issue.