jiebi/CodeConvo huggingface dataset:
Change:
server SHOULD leave the order in the "ready" state, to allow the client to submit a new finalize request with an amended CSR. <del> A request to finalize an order will return the order to be finalized. The client should begin polling the order by sending a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take: </del> <ins> A request to finalize an order will result in error if the order is not in the "ready" state.  In such cases, the server MUST return a 403 (Forbidden) error with a problem document of type "badState". The client should then send a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take (see below). If a request to finalize an order is successful, the server will return a 200 (OK) with an updated order object.  The status of the order will indicate what action the client should take: </ins> "invalid": The certificate will not be issued.  Consider this order process abandoned.

Discussion:
draft-ietf-acme-acme-18 §7.4 has two conflicting statements regarding what an ACME server should do when it receives a request to finalize an order that is not in the "ready" state: 'If the order indicated does not have status "ready" ... the problem document returned by the server SHOULD use error code "badCSR"'. 'A request to finalize an order will return the order to be finalized. The client should begin polling the order by sending a POST-as-GET request to the order resource to obtain its current state. The status of the order will indicate what action the client should take:', where values other than "ready" are listed. This PR proposes to resolve this conflict by requiring servers to return a new 'badState' error in response to a request to finalize an order that is not in the "ready" state. The client should respond to a "badState" error by re-fetching the order object and examining the status field to determine what to do.
I think a better name for this very specific error would be badOrderState or orderNotReady. That avoids potential confusion with bad states for authzs or challenges. Posted a proposed change in URL
Thanks NAME - this clarification makes sense to me. I'm +1 to applying your diff with the other AUTH48 changes. cc NAME Not really just editorial, but okay.
Change:
In order to allow the same Welcome message to be sent to all new members, information describing the group is encrypted with a <del> symmetric key and nonce randomly chosen by the sender.  This key and nonce are then encrypted to each new member using HPKE.  In the same encrypted package, the committer transmits the path secret for the lowest node contained in the direct paths of both the committer and the new member.  This allows the new member to compute private keys for nodes in its direct path that are being reset by the corresponding Commit. </del> <ins> symmetric key and nonce derived from the "joiner_secret" for the new epoch.  The "joiner_secret" is then encrypted to each new member using HPKE.  In the same encrypted package, the committer transmits the path secret for the lowest node contained in the direct paths of both the committer and the new member.  This allows the new member to compute private keys for nodes in its direct path that are being reset by the corresponding Commit. </ins> If the sender of the Welcome message wants the receiving member to include a PSK in the derivation of the "epoch_secret", they can

Discussion:
use and instead of and , for consistency with the rest of the spec the key and nonce are now derived from the rather than randomly chosen
Change:
The presence of the Object-Security option, both in requests and responses, is expressed in an HTTP header field named Object-Security <del> in the mapped request or response.  The value of the field is the value of the Object-Security option obj-sec-value in base64url encoding (Section 5 of RFC4648) without padding (see RFC7515 Appendix C for implementation notes for this encoding).  The value of the payload is the OSCORE payload oscore-payl, also base64url-encoded without padding. </del> <ins> in the mapped request or response.  The value of the field is: "" (empty string) if the CoAP Object-Security option is empty, or the value of the CoAP Object-Security option obj-sec-value in base64url encoding (Section 5 of RFC4648) without padding (see RFC7515 Appendix C for implementation notes for this encoding). The value of the body is the OSCORE payload oscore-payl. </ins> Example:

Discussion:
As suggested in
Need to update example as well
Not on expert on HTPP header formats, but are single quotes '' correct? I think I have only seen double quotes "" in HTTP.
should be fixed now
"The value of the payload" It is called body in HTTP
Jim suggested to not have an empty HTTP header (legal but likely to create problems), instead use: ""
Change:
client.  Compromise of a member removed from a group does not affect the security of messages sent after their removal.  Messages sent during the client's membership are also secure as long as the client <del> has properly implemented the MLS deletion schedule. </del> <ins> has properly implemented the MLS deletion schedule, which calls for the secrets used to encrypt or decrypt a message to be deleted after use, along with any secrets that could be used to derive them. </ins> 5.2.

Discussion:
Comment by NAME Again I am confused there are users with expectations of the MLS protocol, which is still in a draft form only? Is this mixing MLS and non-MLS?
Comment by NAME Is this the equivalent of proprietary IM clients "auto delete" or "view once" type messaging? "MLS deletation schedule" has not been defined before it is mentioned here. What is this?
It is not the equivalent of "expiring messages" features. It's a forward security provision.
The is defined in the protocol document. Perhaps a pointer would be useful.
Comment by NAME This seems a bit of gloating about the MLS protocol/client. Why not just state why the attack is impossible and require that MLS clients do this? I don't see other features being compared to other/older/worse solutions?
Comment by NAME It feels a bit odd to think of a compromised user sending an honest Commit message. If the user doesn't know they are compromised, they will still be compromised and this new Commit message won't help. If the user did know they were compromised and undid that, then sure this honest Commit message helps. I think perhaps "honest Commit" should be expanded and say something about de-compromised client sending a Commit message. My issue with "honest" is that compromised user with a passive attacker is still "honest". Similarly confusing is:
I think these cases mean "formerly compromised".
Comment by NAME This "recall" is misplaced. It is not mentioned before until this point.
Comment by NAME Is this saying a protocol within MLS, eg some application protocol? Or is this saying in this case, do not use MLS but another protocol at the messaging layer?
I understand "a protocol" as "a transport protocol". Because MLS does not provide FEC, and its integrity checks will fail if the packet is corrupted.
Comment by NAME It states any "secure channel" can be used, but it is kinda says any insecure channel can be used too. It also feels a little odd to describe these properties of MLS in the Security Considerations section, and not like in the introduction.
This is no different from how you can run TLS over a bare TCP/IP connection or you can run it over IPsec, and you get better security properties in the latter case.

Comment by NAME Wouldn't this PSK that is the result of a membership be part of the "state lost or corrupted" ? What is the exact kind of failure mode one would address with this? Also, how often would such a PSK get updated as it needs to be known to add group members (and doing this too often would I assume lead to long dormant group members from losing access?) If one could remove once's old self without the PSK, than everyone could delete any member?
Change:
computation, e.g., public key cryptographic operations, avoiding waste is desirable. <del> Decline resumption: Clients can indicate they have no intention of resuming connections by sending a ticket request with count of </del> <ins> Decline resumption: Clients can indicate they do not intend to resume a connection by sending a ticket request with count of </ins> zero. 3.

Discussion:
From Ben: One nit that can be rolled in with any LC comments: in Section 3, we say "clients can send a resumption_count equal to the number of sessions they are attempting in parallel", and "connections" probably works better than "sessions" in that case.
Document: draft-ietf-tls-ticketrequests-06 Reviewer: Dale R. Worley Review Date: 2020-11-27 IETF LC End Date: 2020-12-03 IESG Telechat date: Not known Summary: This draft is ready for publication as a Standards Track RFC. Editorial comments: Use Cases Parallel HTTP connections: To minimize ticket reuse while still improving performance, it may be useful to use multiple, distinct tickets when opening parallel connections. To the naive reader, the ordering of the phrases doesn't seem to match the logical ordering of the concepts. Perhaps Parallel HTTP connections: To improve performance, a client may open parallel connections. To avoid ticket reuse, the client may use multiple, distinct tickets on each connection. Decline resumption: Clients can indicate they have no intention of resuming connections by sending a ticket request with count of zero. "have no intention" seems to me to suggest a decision that will not change. Since the future cannot be guaranteed, perhaps better wording is "do not intend to resume", suggesting a current state that might possibly change in the future. newsessioncount The number of tickets desired by the client when the server chooses to negotiate a new connection. resumptioncount The number of tickets desired by the client when the server is willing to resume using a ticket presented in this ClientHello. If I understand the processing which is suggested correctly, when the client sends a ClientHello, the server can choose to either negotiate a new connection, or (if a ticket is present in the ClientHello) the server can choose to resume the previous connection represented by the ticket. These two parameters provide the requested ticket count for the two situations. Assuming the above is correct, I would recommend changing the wording slightly, as "when" suggests a fact which is true over an extended period of time, whereas the provided counts are applicable in just this one instance: newsessioncount The number of tickets desired by the client if the server chooses to negotiate a new connection.

resumptioncount The number of tickets desired by the client if the server chooses to resume (using the ticket presented in this ClientHello). (Change "the" to "a" in the last sentence if the ClientHello can present more than one ticket among which the server can choose.)
Change:
The protocol is designed in a way that limits the server-side (AS and DS) metadata footprint.  The DS only persists data required for the <del> delivery of messages and avoid Personally Identifiable Information </del> <ins> delivery of messages and avoids Personally Identifiable Information </ins> (PII) or other sensitive metadata wherever possible.  A Messaging Service provider that has control over both the AS and the DS, will not be able to correlate encrypted messages forwarded by the DS, with

Discussion:
This PR aims to fix some odd formulations, whilst maintaining the intended meaning of the sentences.
Thanks NAME !
Change:
Credentials MAY also include information that allows a relying party to verify the identity / signing key binding. <del> The SignatureScheme type represents a signature algorithm.  Signature public keys are opaque values in a format defined by the signature scheme. </del> <ins> A BasicCredential is a raw, unauthenticated assertion of an identity/ key binding.  The format of the key in the "public_key" field is defined by the relevant ciphersuite: the group ciphersuite for a credential in a ratchet tree, the KeyPackage ciphersuite for a credential in a KeyPackage object. For ciphersuites using Ed25519 or Ed448 signature schemes, the public key is in the format specified RFC8032.  For ciphersuites using ECDSA with the NIST curves P-256 or P-521, the public key is the output of the uncompressed Elliptic-Curve-Point-to-Octet-String conversion according to SECG. </ins> Note that each new credential that has not already been validated by the application MUST be validated against the Authentication Service.

Discussion:
This started off just fixing , then grew a bit. Defines an IANA registry for ExtensionType values Defines an IANA registry for CredentialType values Updates the Ciphersuites registry to share formatting with the other two, and to be more explicit about its ties to HPKE algorithms Removes the unnecessary field from ... and as a result removes the definition of (which is used nowhere else)
Now that we have a more robust extension mechanism, we need to have an IANA registry to manage extensions, including: Registry structure Registry policy and (probably) designated experts Reserved vendor space
Change:
If the sender wants to elicit a faster acknowledgment on PTO, it can skip a packet number to eliminate the acknowledgment delay. <del> When the PTO timer expires, an ack-eliciting packet MUST be sent.  An endpoint SHOULD include new data in this packet.  Previously sent data MAY be sent if no new data can be sent.  Implementations MAY use alternative strategies for determining the content of probe packets, including sending new or retransmitted data based on the application's priorities. </del> <ins> An endpoint SHOULD include new data in packets that are sent on PTO expiration.  Previously sent data MAY be sent if no new data can be sent.  Implementations MAY use alternative strategies for determining the content of probe packets, including sending new or retransmitted data based on the application's priorities. </ins> It is possible the sender has no new or previously-sent data to send. As an example, consider the following sequence of events: new

Discussion:
Despite how the diff appears at first glance, I've only changed the first two sentences.
NAME said:
This changes the emphasis slightly, but in a good way.
Change:
3.2. Connection establishment uses Initial, Handshake, and Retry packets <del> containing a TLS handshake on Stream 0.  Connection establishment can therefore be detected using heuristics similar to those used to detect TLS over TCP.  A client using 0-RTT connection may also send data packets in 0-RTT Protected packets directly after the Initial packet containing the TLS Client Hello.  Since these packets may be reordered in the network, note that 0-RTT Protected data packets may be seen before the Initial packet.  Note that only clients send Initial packets, so the sides of a connection can be distinguished by QUIC packet type in the handshake. </del> <ins> containing a TLS handshake.  Connection establishment can therefore be detected using heuristics similar to those used to detect TLS over TCP.  A client using 0-RTT connection may also send data packets in 0-RTT Protected packets directly after the Initial packet containing the TLS Client Hello.  Since these packets may be reordered in the network, note that 0-RTT Protected data packets may be seen before the Initial packet.  Note that only clients send Initial packets, so the sides of a connection can be distinguished by QUIC packet type in the handshake. </ins> 3.3.

Discussion:
The manageability document should illustrate all the various packet sequences in a handshake, preferably with pretty pictures.
Now the transport draft has these illustrations as well. However, I think we should still at them in manageability as well. Actually I would like to try the SVG format here. Anybody in for that?
The handshake illustrations here should only concern themselves with the wire image, unlike those in the transport draft, but yes we should derive them from the transport draft. Happy to do these in ASCII as well as SVG.
The problem with examples is that they might be typical, but they rarely capture the breadth of options well. Maybe you should purposefully diverge from established practice in these to avoid certain illusions from being formed. For instance, put PADDING first.
Change:
6. <del> During the development of a document, individual revisions of a </del> <ins> During the development of a document, individual revisions of the </ins> document can be built and formally submitted as an Internet-Draft. This creates a stable snapshot and makes the content of the in- progress document available to a wider audience.  Documents submitted

Discussion:
Please pay special attention to b872e53 and e74ba45 when reviewing this.
LGTM with some proposed simplifying text.
Change:
discussed could even be combined into even more complex implementations. <del> Claims are collected from Target Environments.  That is, Attesting Environments collect the raw values and the information to be represented in claims, such as by doing some measurement of a Target Environment's code, memory, and/or registers.  Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  Examples of environments that can be used as Attesting Environments include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), or Hardware Security Modules (HSM). </del> <ins> Claims are collected from Target Environments, as shown in twotypes- env.  That is, Attesting Environments collect the raw values and the information to be represented in claims, such as by doing some measurement of a Target Environment's code, memory, and/or registers. Attesting Environments then format the claims appropriately, and typically use key material and cryptographic functions, such as signing or cipher algorithms, to create Evidence.  Places that Attesting Environments can exist include Trusted Execution Environments (TEE), embedded Secure Elements (eSE), and BIOS firmware.  An execution environment may not, by default, be capable of claims collection for a given Target Environment.  Attesting Environments are designed specifically with claims collection in mind. </ins> 4.2.

Discussion:
Signed-off-by: Dave Thaler
I don't understand the text Ned added. Suggest moving it to a separate PR.
The existing text listed HSM and TEE as examples of Attesting Environments. However, an HSM that only provides crypto acceleration and key storage wasn’t designed for claims collection. Therefore, it isn’t an Attesting Environment (necessarily). The text I added explains that the Attesting Environment is designed in such a way that it is capable of claims collection. For example, if the HSM was designed to have exposed a shared memory region that is shared with the Target Environment’s executable code pages.
Will fix broken kramdown after pull.
Approve of the changes. But also have an additional comment suggested change.
Change:
Interim transcript hash: 0 <del> Init secret: 0 </del> <ins> Init secret: a fresh random value of size "KDF.Nh" </ins> For each member, construct an Add proposal from the KeyPackage for that member (see add)

Discussion:
This suggestion is based on a discussion in the MLS mailing list . It prevents issues that currently arrise when the very first commit of a group is an "add-only" commit because both the and would be 0. Let me know if the wording or anything else should be changed. /cc NAME URL
I believe this change invalidates the last paragraph of the , as it is impossible to verify the group creation process for the joiner without knowing the random that the group creator used.
maybe one alternative is to keep the zero , but make it compulsory to populate the path for this group creation welcome/commit (so that isn't zero)?
That would also work NAME (I also suggested that as an alternative in my original report in the mailing list), to me it is a little bit less elegant though. Personally, I also wonder why it is necessary to verify that group creation just happened. (Moreover, this way of recognizing group creation would prevent any group from which all but one person left from continuing, which my be confusing to end-users)
lgtm with one minor thing fixed Hi Eric, Thanks for the analysis, and the detailed, clear writeup. I agree that there are some real issues here, and with the solution approach. Just to align on a couple of details: is clearly a problem. Good catch. is less clear to me. You lose me when you say ""add-only" commits allow new group members (ONLY) to learn the value at the root of the TreeKEM tree". How do you think this happens? As I understand the spec, this is not the case. New members are added to the "unmergedleaves" array at the root, but they are not told the root secret or root private key. In any case, I agree that we should change the initial initsecret from being zero to being random. I think I had set it to zero out of a general caution against requiring fresh entropy, and likely under the theory that the first commit would change it (before was optional). But it is clearly necessary now. If you would like to send a PR, I would be happy to review. Thanks, --Richard >
Change:
HTTP/2 stream flow control, which limits the data on a single HTTP/2 stream.  For a WebTransport session, this includes all <del> capsules, including those that are exempt from session-level flow control. </del> <ins> capsules, including those that are exempt from WebTransport session-level flow control. </ins> WebTransport session-level flow control, which limits the total amount of stream data that can be sent or received on streams <del> within the WebTransport session. </del> <ins> within the WebTransport session.  Note that this does not limit other types of capsules within a WebTransport session, such as control messages or datagrams. </ins> WebTransport stream flow control, which limits data on individual streams within a session.

Discussion:
Expand description of flow control and add additional notes NAME already wrote up a very nice overview of the layers we have, so added a little bit extra there and filled in the last little bit on limiting streams within a session to round everything out.
Document how MAXDATA interacts with the enclosing HTTP/2 flow control scheme Originally posted by NAME in URL
I tend to think we might want to have a section entirely on flow control since we've now got several layers: HTTP/2 connection level HTTP/2 stream for the CONNECT stream WTMAXDATA for the WT session Noting that this is different than the HTTP/2 layer's CONNECT stream, since we want to be able to indicate the sum of stream data separately from other control frames WTMAXSTREAMDATA for each WT stream And stream-count flow control HTTP/2 stream limits don't really apply once you've got the WT session up WTMAX_STREAMS limits stream counts within a WT session Just indicating the intended usage of each of these knobs would be helpful.
(From : Since QUIC's flow control credits work differently from H2, it may be worth explicitly stating how this works here.)
Chair notes from IETF 112 meeting: no one objected to proposal of resolving this by documenting how flow control works and pitfalls
Why do we need WTMAXDATA in first place? I thought that since we have flow control from the HTTP/2 side, we don't need it.
We want to be able to say "don't send me any more data on this stream" while still allowing control frames on that stream