jiebi/CodeConvo huggingface dataset:
Change:
generation of keys until it receives the KeyUpdate from the other side. <ins> Both sender and receiver must encrypt their KeyUpdate messages with the old keys.  Additionally, both sides MUST enforce that a KeyUpdate with the old key is received before accepting any messages encrypted with the new key.  Failure to do so may allow message truncation attacks. </ins> 7. In order to begin connection protection, the TLS Record Protocol

Discussion:
The current wording of KeyUpdate a bit ambiguous, and leaves out certain areas needed for enforcement and might result in a security issue if not implemented correctly A sender of the keyupdate has no choice of which key to encrypt the keyupdate with, however the recipient does. It has 2 choices: a. Use old key and reset the sequence number after acking the keyupdate b. Use the new key for the key update and reset the sequence number before acking the keyupdate. This distinction is very important for security. If a client uses option b), this causes a security vuln. Because the sequence numbers are reset after a key update, an attacker could truncate (application data) records from the old stream, wait for the key update from the client, and then let new packets through. The client or server has no way of figuring out this has happened. If a receiver verifies that the KeyUpdate is received with the old key before accepting messages encrypted with the new key, then this attack is prevented.
Excellent point. I will merge this. Please also file a PR adding yourself to acknowledgements.
Change:
on each packet sent. When in use, the latency spin bit in each direction changes value <del> once per round-trip time (RTT) any time that both endpoints are sending packets continuously.  An on-path observer can observe the time difference between edges (changes from 1 to 0 or 0 to 1) in the spin bit signal in a single direction to measure one sample of end- to-end RTT.  This mechanism follows the principles of protocol measurability laid out in IPIM. </del> <ins> once per RTT any time that both endpoints are sending packets continuously.  An on-path observer can observe the time difference between edges (changes from 1 to 0 or 0 to 1) in the spin bit signal in a single direction to measure one sample of end-to-end RTT.  This mechanism follows the principles of protocol measurability laid out in IPIM. </ins> Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of

Discussion:
Refers to quicwg. This also addresses /extremely limited/ ECN visibility (limited for sure, but we don't need to say "extremely"). Fixed multiple definitions of RTT Refered to metrics, etc for encrypted traffic wrt network-layer measurement via a REF.
Thanks for the suggestions from Ian and Mirjay, they were of course incorporated.
Change:
Verify that the LeafNode is compatible with the group's parameters.  If the GroupContext has a "required_capabilities" <del> extension, then the required extensions and proposals MUST be listed in the LeafNode's "capabilities" field. </del> <ins> extension, then the required extensions, proposals, and credential types MUST be listed in the LeafNode's "capabilities" field. Verify that the credential type is supported by all members of the group, as specified by the "capabilities" field of each member's LeafNode, and that the "capabilities" field of this LeafNode indicates support for all the credential types currently in use by other members. </ins> Verify the "lifetime" field:

Discussion:
This PR adds a way for the members of a group to indicate the credential types they support, and how to negotiate which credential types may be used in a group.
I discussed this offline with NAME and we arrived at: We might need multiple credentials later (as I suspect) If we do that (say in an extension), we will need to update this text We should capture the general theory that covers both single- and multiple-credential cases The proposed additions here just abstract the principle of universal compatibility (which we need in a single-credential world) to one of "at least something" compatibility (which is more compatible with a multi-credential world).> The types of credential that may be used in a group is restricted to what all I think this is too restrictive if we adopt PR . I think it is between the client and its AS if all the clients need to support every credential type used in the group. If you agree with the concept, I am happy to propose slight changes.I think this makes sense.
Change:
see frame-max-push-id.  A smaller value indicates the client will reject pushes with Push IDs greater than or equal to this value. Like the server, the client MAY send subsequent GOAWAY frames so long <del> as the specified Push ID is strictly smaller than all previously sent values. </del> <ins> as the specified Push ID is no greater than any previously sent value. </ins> Even when a GOAWAY indicates that a given request or push will not be processed or accepted upon receipt, the underlying transport

Discussion:
Move "A client that is unable to retry requests [...]" sentence from the beginning of an entirely unrelated paragraph to somewhere more appropriate. Change Push ID requirement on subsequent GOAWAY frames. This was presumably an oversight, because "An endpoint MAY send multiple GOAWAY frames indicating different identifiers [...]" paragraph above is pretty clear and covers both directions already.
Change:
transport parameter is only sent by a server.  Servers MAY choose to only send a preferred address of one address family by sending an all-zero address and port (0.0.0.0:0 or ::.0) for the other <del> family. </del> <ins> family.  IP addresses are encoded in network byte order. </ins> The maximum number of connection IDs from the peer that an endpoint is willing to store.  This value includes only connection

Discussion:
Byte order of IP addresses in PreferredAddress is not explicitly stated. In practice, most OSs keep them in network byte order, and the spec says integers are in network byte order, however the fields for ip addresses are defined as opaque data. The byte order should be stated on this spec.
Change:
Section 4.2.2 of HTTP. When an HTTP/2 connection is established, both the client and server <del> have to send a SETTINGS_ENABLE_WEBTRANSPORT setting to indicate that they both support WebTransport over HTTP/2. The server also needs to send a SETTINGS_WEBTRANSPORT_MAX_SESSIONS setting with a value greater than "0" to indicate the number of concurrent sessions it is willing to receive. </del> <ins> have to send a SETTINGS_WEBTRANSPORT_MAX_SESSIONS setting with a value greater than "0" to indicate that they both support WebTransport over HTTP/2.  For servers, the value of the setting is the number of concurrent sessions the server is willing to receive. Clients cannot receive incoming WebTransport sessions, so any value greater than "0" sent by a client simply indicates support for WebTransport over HTTP/2. </ins> A client initiates a WebTransport session by sending an extended CONNECT request RFC8441.  If the server accepts the request, a

Discussion:
Remove SETTINGSENABLEWEBTRANSPORT in favor of SETTINGSWEBTRANSPORTMAX_SESSIONS.
I can't seem to remember or work out what the purpose of SETTINGSENABLEWEBTRANSPORT is now that we have SETTINGSWEBTRANSPORTMAXSESSIONS. This leads to the following questions: If the server sends SETTINGSWEBTRANSPORTMAXSESSIONS>0 but SETTINGSENABLEWEBTRANSPORT=0, what does that mean? If the client sends SETTINGSENABLEWEBTRANSPORT=0 but sends a WebTransport request, what is the purpose of having the server fail the request?
Yeah, I thought that we would remove SETTINGSENABLEWEBTRANSPORT when the session limit was added. If nothing else, it removes those awkward interactions.
Chair: discussed in editor's meeting, sounds like we should remove SETTINGSENABLEWEBTRANSPORT. We might add another setting to be removed by the RFC editor for versioning between drafts
IIRC, we discussed at IETF 115 and only the server needed to send MAX_SESSIONS, so we kept both. Can spell that either way though.
If we're doing this for H2, should we also do it for H3, since we have SETTINGSMAXWEBTRANSPORT_SESSIONS there, too?
h3 requires SETTINGSENABLEWEBTRANSPORT because it changes the format of server-initiated bidi streams h2 has no such requirement for a setting
Change:
not set a sector name in their registrations.  An RD can set a default sector name for registrations accepted under this policy, which is useful especially in a segmented setup where different <del> policies apply to different sectors. </del> <ins> policies apply to different sectors.  The configuration of such a behavior, as well as any other configuration applicable to such an RD (i.e. the set of recognized authorities) is out of scope for this document. </ins> 8.

Discussion:
See-Also: URL Apart from pointing out the scope, this also comprehensively lists the few configuration options that are there for such an RD. Hi, Thank you for this document. I'm glad that the shepherd's writeup indicates that there are implementations since that indicates that there does appear to be value in standardizing this work, despite its long journey. My main comment (which I was considering raising as a discuss) is: Since this document is defining a new service, I think that this document would benefit on having a short later section on "Operations, Administration and Management". This document does seem to cover some management/administration considerations in various sections in a somewhat ad hoc way, but having a section highlighting those would potentially make it easier deploy.  Defining a common management model (or API) would potentially also make administration of the service easier, I don't know if that had been considered, and if useful could be done as a separate document. A few other comments: What happens if an endpoint is managing the registration and is upgraded to new hardware with a different certificate?  Would the updated endpoint expect to be able to update the registration?  Or would it have to wait for the existing registration to timeout (which could be a long time)? Nit: Perhaps reword the second sentence.  Otherwise it seems to conflict with the last sentence of the prior paragraph. The "SHOULD NOT" feels a bit strong to me, and I would prefer to see this as "MAY NOT".  In many cases, if the configuration is not too big then providing the full configuration makes it easy to guarantee that the receiver has exactly the correct configuration.  I appreciate that there are many cases where from an endpoint perspective it may want to keep the update small, but if I was doing this from a CT, I think that I would rather just resend the entire configuration, if it is not large. Just to check, is it correct that the anchor in the http link is also to coap://?  If this is wrong then there is a second example in the same section that also needs to be fixed.
Change:
An endpoint MUST NOT send a packet if it would cause bytes_in_flight (see vars-of-interest) to be larger than the congestion window, <del> unless the packet is sent on a PTO timer expiration; see pto. </del> <ins> unless the packet is sent on a PTO timer expiration (see pto) or when entering recovery (see recovery-period). </ins> 7.1.

Discussion:
We may want to revert this once lands
~ still allows you to reduce the cwnd on entering recovery, so I think this text is still good.~ Now that I've seen your changes to , reverting this makes sense.
It might pay to reconcile: {{vars-of-interest}}) to be larger than the congestion window, unless the packet is sent on a PTO timer expiration; see {{pto}}. And now exceeds the recently reduced congestion window. Now, you might implement the latter using PTO machinery, but that text doesn't really suggest that in any way.
Where does this second sentence come from? I'm pretty sure I haven't implemented anything like this in quic-go. Should I?
That sentence is the the definition of the . We haven't implemented that either, and I was wondering if it truly helps.
For TCP this second case if important because as long as you don't retransmit the lost packet you will not get any ACK that acknowledges new data. I guess we don't need that for QUIC.
The second sentence was added later in , and the MUST wasn't updated, so I'll fix that. Chromium currently implements PRR(RFC6937), which is a more complex variant of this which is designed to keep the ACK clock going. I thought we discussed adding an informative reference to PRR when we added this text, and I'm not sure why we didn't.
seems to be the wrong issue you are pointed to...
Good catch, it's
Thanks. Simple :)
Change:
steps: Verify that the ciphersuite and protocol version of the KeyPackage <del> match those in use in the group. </del> <ins> match those in the "GroupContext". </ins> Verify that the "leaf_node" of the KeyPackage is valid for a KeyPackage according to leaf-node-validation.

Discussion:
This will guarantee that all group members agree on the ciphersuite used. It gives more meaning to statements like "Each MLS session uses a single ciphersuite". Also, it prevents the following attack: the adversary (a malicious insider) invites someone and convinces them that the group uses a ciphersuite with say a signature scheme that is weaker but still compatible with the one actually used. Now the new member uses a weaker scheme and the adversary can impersonate them.
Interim 2022-06-02: Agreement that more binding is better
Change:
The type of 0-RTT handshake that this configuration is to be used for (see early-data-indication).  If "client_authentication" or <del> "client_authentication_and_data", then the client should select the certificate for future handshakes based on the CertificateRequest parameters supplied in this handshake.  The server MUST NOT send either of these two options unless it also requested a certificate on this handshake.  [[OPEN ISSUE: Should we relax this?]] </del> <ins> "client_authentication_and_data", then the client MUST select the certificate for future handshakes based on the CertificateRequest parameters supplied in this handshake.  The server MUST NOT send either of these two options unless it also requested a certificate on this handshake.  [[OPEN ISSUE: Should we relax this?]] </ins> This field is a placeholder for future extensions to the

Discussion:
This cleans up some of the text around EarlyDataIndication that was introduced previously.
The early data indication parameters are defined as clientauthentication(1), earlydata(2), and clientauthenticationanddata(3). A few paragraph after that, some text refers to them by what was probably an old name: If TLS client authentication is being used, then either "earlyhandshake" or "earlyhandshakeand_data" MUST be indicated in order to send the client authentication data on the first flight. Easy fix...
See URL
This should now be fixed.
Change:
ensuring congestion protection and latency control for the above listed DetNet functions. <ins> [Note to Editors.  I am not convinced that the previous para adds value.  It certainly has the opportunity to add confusion.  I think it needs to be deleted - SB] </ins> The DetNet data plane allows for the aggregation of DetNet flows, e.g., via MPLS hierarchical LSPs, to improved scaling.  When DetNet flows are aggregated, transit nodes may have limited ability to

Discussion:
I have started to address the comments as agreed on the call 2nd May. Before I do a more significant edit next week I want to test out the pull mechanism,
Merged Stewart's first three commits to the master.
I wonder why we need to have/propose two approaches for the aggregation?
Change:
When an error occurs processing the capsule protocol, the receiver MUST treat the message as malformed or incomplete, according to the underlying transport protocol.  For HTTP/3, the handling of malformed <del> messages is described in Section 4.1.3 of H3.  For HTTP/2, the handling of malformed messages is described in Section 8.1.1 of H2. For HTTP/1.1, the handling of incomplete messages is described in Section 8 of H1. </del> <ins> messages is described in H3.  For HTTP/2, the handling of malformed messages is described in H2.  For HTTP/1.1, the handling of incomplete messages is described in H1. </ins> Each capsule's payload MUST contain exactly the fields identified in its description.  A capsule payload that contains additional bytes

Discussion:
It's shorter and apparently the tagging is what is now required later on in the RFC process anyway.
Change:
When the crypto retransmission timer is active, the probe timer (pto) is not active. <del> 6.2.1. A Retry or Version Negotiation packet causes a client to send another Initial packet, effectively restarting the connection process and resetting congestion control and loss recovery state, including resetting any pending timers.  Either packet indicates that the Initial was received but not processed.  Neither packet can be treated as an acknowledgment for the Initial. The client MAY however compute an RTT estimate to the server as the time period from when the first Initial was sent to when a Retry or a Version Negotiation packet is received.  The client MAY use this value to seed the RTT estimator for a subsequent connection attempt to the server. </del> 6.3. A Probe Timeout (PTO) triggers a probe packet when ack-eliciting data

Discussion:
Moves the "Retry and Version Negotiation" out of the "Crypto Retransmission Timeout" section in preparation for a redo of
Change:
in RFC5888, Section 9.1.  The "mid" value MUST match that specified in the offer. <del> An "a=rtcp" line, as specified in RFC3605, Section 2.1, containing the dummy value "9 IN IP4 0.0.0.0", because no candidates have yet been gathered. </del> A direction attribute which is the same as that of the associated transceiver.

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:
Transport of external authorization data. EDHOC is designed to encrypt and integrity protect as much <del> information as possible, and all symmetric keys are derived using as much previous information as possible.  EDHOC is furthermore designed to be as compact and lightweight as possible, in terms of message sizes, processing, and the ability to reuse already existing CBOR, COSE, and CoAP libraries.  Like (D)TLS, authentication is the responsibility of the application, EDHOC identifies (and optionally transports) authentication credentials, and provides proof-of- possession of the private authentication key. </del> <ins> information as possible.  Symmetric keys and random material derived using EDHOC-KDF are derived with as much previous information as possible, see fig-edhoc-kdf.  EDHOC is furthermore designed to be as compact and lightweight as possible, in terms of message sizes, processing, and the ability to reuse already existing CBOR, COSE, and CoAP libraries.  Like (D)TLS, authentication is the responsibility of the application, EDHOC identifies (and optionally transports) authentication credentials, and provides proof-of-possession of the private authentication key. </ins> To simplify for implementors, the use of CBOR and COSE in EDHOC is summarized in CBORandCOSE.  Test vectors including CBOR diagnostic

Discussion:
Based on side comment in about "all symmetric keys are derived using as much previous information as possible"
Change:
A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI. Just as the address of a traditional DNS nameserver cannot be <del> originally determined from that same server, a DOH client cannot use its DOH server to initially resolve the server's host name into an address.  Alternative strategies a client might employ include making the initial resolution part of the configuration, IP based URIs and corresponding IP based certificates for HTTPS, or resolving the DNS API server's hostname via traditional DNS or another DOH server while still authenticating the resulting connection via HTTPS. </del> <ins> originally determined from that same server, a DNS API client cannot use its DNS API server to initially resolve the server's host name into an address.  Alternative strategies a client might employ include making the initial resolution part of the configuration, IP based URIs and corresponding IP based certificates for HTTPS, or resolving the DNS API server's hostname via traditional DNS or another DNS API server while still authenticating the resulting connection via HTTPS. </ins> HTTP RFC7230 is a stateless application level protocol and therefore DOH implementations do not provide stateful ordering guarantees

Discussion:
Yipes, I thought I had found these in the last round. Thanks!
Even though the Terminology section contains "DNS API client" and "DNS API server" respectively, the -04 version of the draft still contains a few instances of "DOH client" and "DOH server". Not sure that's intended.
As well as one instance of "DOH API client" in Section 6.1
Change:
As above, the impact of undesirable links depends on the extent to which the lookup client relies on the RD.  To avoid the limitations, <del> RD applications should consider prescribe that lookup clients only </del> <ins> RD applications should consider prescribing that lookup clients only </ins> use the discovered information as hints, and describe which pieces of information need to be verified with the server because they impact the application's security.

Discussion:
Thanks, merged. (If questions come up around the normative-language RECOMMENDED: I agere that from the capitals NOT before it, this was already intended to be normative.)
Change:
or the rate at which validation can be requested within a given subtree of the DNS. <del> 10.5. </del> <ins> 10.4. </ins> The controls on issuance enabled by ACME are focused on validating that a certificate applicant controls the identifier he claims.

Discussion:
We already removed token-based account recovery; this PR removes contact-based recovery. It was already almost entirely unspecified, due to it being a process that primarily takes place outside of ACME. Removing account recovery from ACME simplifies both the protocol and the security considerations. As an alternative, this PR adds an field to the dictionary in the directory, which the CA can use to expose account management functions such as recovery. But you can also imagine using this for more sophisticated account management functions, like associating an ACME account with some other account in a different system.
(Also threw in some editorial corrections, sorry)
The editorial corrections are good and IMO should be taken in any circumstances. I agree this change does what it says it does, so r+. One concern, which I will cross-post to the list, is that the placement of this URL in the directory means that it is not customizable; It could be a useful thing to, after a signed request, give back a URI that contains a one-time value that would help tie a browser session to a given account key. I don't see a good endpoint for such a thing at present, so the hour is probably too late for such a change.
NAME I agree that could be useful, but I can think of other, simpler ways to provide it (e.g., a link relation from a registration URI). If you think it's important, please file a follow-on issue.
NAME See my feedback on the ACME list. I disagree that this should be merged now. Could you please submit a revert and seek further discussion?
Sorry, I misunderstood. Will revert.