jiebi/CodeConvo huggingface dataset:
Change:
in deployments where no protected application data is sent from R to I. <del> A key material exporter and a key update function enabling frequent forward secrecy. </del> <ins> A key material exporter and a key update function enabling forward secrecy. </ins> Verification of a common preferred cipher suite:

Discussion:
Comment by Robert Moskowitz
I think the forward secrecy could use some more text. Right know we are using the definition according to the IETF security dictionary, but as the security dictionary states, a lot of different definitions is used. The draft that the KeyUpdate gives much better security than using a single key, but that the KeyUpdate method gives a lower security level than frequently running ephemeral diffie-hellman
Change:
Sending different payloads each time reduces the chances of spurious retransmission. <del> 5.2.5. Delivery or loss of packets in flight is established when an ACK frame is received that newly acknowledges one or more packets. A PTO timer expiration event does not indicate packet loss and MUST NOT cause prior unacknowledged packets to be marked as lost.  When an acknowledgement is received that newly acknowledges packets, loss detection proceeds as dictated by packet and time threshold mechanisms; see ack-loss-detection. </del> 5.3. A Retry packet causes a client to send another Initial packet,

Discussion:
The fact that PTO doesn't declare losses when it expires is quite important. It at the very end of the section, so I moved it to the first part. Also removed a section heading(pto-loss) which was never referenced.
A reasonable simplification.
Change:
messages directly, while in reality they would be sent encapsulated in MLSPlaintext or MLSCiphertext objects. <del> Before the initialization of a group, clients publish InitKeys (as KeyPackage objects) to a directory provided by the Service Provider. </del> <ins> Before the initialization of a group, clients publish KeyPackages to a directory provided by the Service Provider. </ins> When a client A wants to establish a group with B and C, it first initializes a group state containing only itself and downloads

Discussion:
Complete the renaming of InitKeys -> KeyPackages; and GroupInfo -> PublicGroupState
Comment by NAME Hmmm :P
Cf. RFC 8446 We could provide some more citations to the analyses that are now in the literature if you think that would help.
CC NAME NAME NAME for citations
They are also in this architecture document PR: URL
Oh good, I'll just add a citation over to mls-architecture.
Change:
In one example, if a media server overestimates the available bandwidth to the media player, <del> the transport protocol detects loss due to congestion and reduces its sending window size per round trip, </del> <ins> the transport protocol may detect loss due to congestion and reduce its sending window size per round trip, </ins> the media server adapts to application-level feedback from the media player and reduces its own sending rate,

Discussion:
From NAME -
NAME - after thinking about this comment, I think two things need to happen - your observation about bottlenecks at different nodes/hops/layers of the protocol stack belongs at the beginning of this section, because we're drilling down on ONE layer of the protocol stack in the rest of section 3.2, and as you say, the reference to "link" is not helpful here. Please let me know if URL is responsive to this comment.
Change:
components MUST be in the I-JSON range of exact values, see synsem- overview. <ins> 3.5.9.3. JSON document: Queries: </ins> 3.6. A Normalized Path is a JSONPath with restricted syntax that

Discussion:
Ref: URL
we need to discuss the descendant selector's behavior by including itself to the node list.
Yes. Let's do that in a PR for URL
yes ... it's illustratively shown, what a good thing inline examples are ...
Considering the following input: would evaluate to (in this case the values of the object): I would expect the descendant version: to evaluate to: Yet the example says: Considering the following pseudo logic: In the case of the would be an index wildcard selector. I would expect the descendant selector to (starting by selecting itself) walk through the json structure and select all the results by applying the child selector (dot-member-name, index-selector, index-wild-selector, or wildcard) on each traversed value. Am I misunderstanding something here or is this the intended behavior?
Thanks for raising this. When I was writing the example, I noticed that only a few implementations included the node itself. But the descendant selector semantics currently say: and so I included the "starting" node itself. This is why I included the following text in the commit message: The semantics section needs improving anyway to clarify the semantics of the various forms of the descendants selector. I agree with the semantics proposed above, providing there is a consensus for this in the WG.
In my understanding descendant selector simply extends the single-level operating of child selector , in that it further recursively operates on all other descendant levels. So I agree to Bram's traversal algorithm above. A node is not considered a descendant of itself. Obviously I have not been aware of this behavior.
Change:
On sending an update to the peer's "max_ack_delay", an endpoint can use this new value in later computations of its Probe Timeout (PTO) <del> period; see Section 5.2.1 of QUIC-RECOVERY.  The endpoint MUST however wait until the ACK_FREQUENCY frame that carries this new value is acknowledged by the peer. </del> <ins> period; see Section 5.2.1 of QUIC-RECOVERY. </ins> Until the frame is acknowledged, the endpoint MUST use the greater of the current "max_ack_delay" and the value that is in flight when

Discussion:
Not sure I fully understand why this is unnecessary.
The following paragraph has a MUST that I believe makes this one redundant. Thoughts?
Ah, maybe.
The text says: /The endpoint MUST however wait until the ACKFREQUENCY frame that carries this new value is acknowledged by the peer./ I found this a little hard on the reader, could this be easier to read as: /The endpoint MUST however wait for an acknowledgment by the peer of the ACKFREQUENCY frame that carries this new value./ and then I ask what does MUST mean here as a requirement to wait? I suspect it would be covered by saying /The endpoint needs to wait.../, because I suspect the required action is specified in the next para.
Yes, actually there is a mother MUST in the next sentence: So I think it would probably be better to remove the normative language in this sentence. As we are taking about changing normative language, I will label this as design now, but I think it otherwise mostly editorial.
Change:
complete, perhaps by timing out. In cases where the domain of the A or AAAA records being resolved do <del> not match the SNI Server Name, such as when RFC7838 is being used, the SNI domain should be used for querying the ESNI record. </del> <ins> not match the SNI Server Name, such as when RFC7838 Section 2.3 is being used, the SNI domain should be used for querying the ESNI record. </ins> Servers operating in Split Mode SHOULD have DNS configured to return the same A (or AAAA) record for all ESNI-enabled servers they

Discussion:
The draft currently states: I'm confused about what this means. From reading RFC 7838, I'm not sure the SNI and DNS names do not match when you're querying an alternate name. In particular, RFC 7838 states: Which means, if I understand it correctly, the client will send "URL" in the SNI when trying to query resources from it - the requirement is only that the certificate for "URL" also cover "URL".
Agreed. I'm parsing RFC 7838 the same way. I think we should drop this text.
The problem the text presents is real (though the resolution is arbitrary). no.. that's a misread. See section 2.3 of 7838 The alternate is essentially just a cname for the origin. If host b is an alternate for origin a, in order to use the alternate you look up the DNS a/aaaa of b, do a TCP connect to b, and then use sni=a and expect a certificate valid for a. (indeed the point of the SNI is to tell the server what certificate you expect to see) With esni you would continue to do all of those things, except of course sni=encrypted(a).. and the question becomes where do you find the key used for the encryption. Is it the ESNI DNS record of a (the origin) or b (the alternate host). That's the question the text is trying to resolve - it says to use a (the origin). I could make a case for either choice but I think the text needs to decide
NAME Would you mind suggesting some text with an example to clear this up?
NAME thanks for the clarification and pointer to s2.3 of 7838. After reading that I think the text in the ESNI draft looks fine. (I'd just add a pointer to s2.3 of 7838 instead of just 7838 to help prevent the confusion I had)
Change:
4.1. <del> There are two types of cryptographic state at the core of MLS: A _key schedule_ that represents the shared secret state of the group and its evolution from one epoch to the next. </del> <ins> The cryptographic state at the core of MLS is divided into three areas of responsibility: </ins> A _ratchet tree_ that represents the membership of the group, providing group members a way to authenticate each other and efficiently encrypt messages to subsets of the group.  Each epoch <del> has a distinct ratchet tree. </del> <ins> has a distinct ratchet tree.  It seeds the _key schedule_. A _key schedule_ that describes the chain of key derivations used to progress from epoch to epoch (mainly using the _init_secret_ and _epoch_secret_); and to derive a variety of other secrets (see epoch-derived-secrets) used during the current epoch.  One of these (the _encryption_secret_) is the root of _secret_tree_. </ins> A _secret tree_ derived from the key schedule that represents shared secrets used by the members of the group to provide

Discussion:
Note that is currently under , so that should probably move or the top level section should be renamed. I ran out of imagination for today.
Change:
IANA [SHALL add/has added] the following note: <ins> The role of the designature expert is described in [this-RFC]. The designated expert RFC8126 ensures that the specification is publicly available.  An Internet Draft that is posted and never published or a standard in another standards body, industry consortium, university site, etc. suffices.  The expert may provide more in depth reviews, but their approval should not be taken as an endorsement of the certificate type. The designated expert RFC8126 only ensures that the specification is publicly available.  An Internet Draft that is posted and never published or a standard in another standards body, industry consortium, university site, etc. suffices. </ins> Certificate Types marked as "Yes" are those allocated via Standards Track RFCs.  Certificate Types marked as "No" are not.

Discussion:
This change aligns the DE text and adds more info about what the DE does and doesn't do. It also capitalizes "Recommended" so that it's more clear that we're referring to the column. NAME PTAL
LGTM, thanks for unifying the DE language.
Change:
types of participants, underlying cryptographic constructions used when issuing tokens, and even privacy properties. <del> Clients initiate the Token issuance protocol using the challenge, a randomly generated nonce, and public key for the Issuer.  The Token issuance protocol itself can be any interactive protocol between </del> <ins> Clients initiate the issuance protocol using the challenge, a randomly generated nonce, and public key for the Issuer, all of which are the Client's private input to the protocol and ultimately bound to an output Token; see Section 2.2. of HTTP-Authentication for details.  Future specifications may change or extend the Client's input to the issuance protocol to produce Tokens with a different structure. The issuance protocol itself can be any interactive protocol between </ins> Client, Issuer, or other parties that produces a valid authenticator <del> over the Client's input, subject to the following security </del> <ins> over the Client's private input, subject to the following security </ins> requirements. Unconditional input secrecy.  The issuance protocol MUST NOT

Discussion:
This clarifies the inputs to the issuance protocol as constrained by the current HTTP authentication document. It also notes that these inputs may change in the future to accommodate different issuance protocols and Token formats. cc NAME NAME
The input secrecy requirement suggests that client private input would include the nonce, challenge, but doesn't give any ideas what else might be part of the private input: Why is it important to have a client nonce? Is this something that needs to be spelled out in the architecture document or left to the particular issuance protocol specifications?
The issuance protocol only takes as input the TokenChallenge and client-generated nonce, both of which are considered private. It doesn't take anything else as input. We should just say that directly. A client nonce is a required part of the Token structure.
Change:
This section defines the encoding of documents in the CoRAL binary format. <del> A document in the binary format is encoded in RFC8949.  The encoding MUST satisfy the Core Deterministic Encoding Requirements specified in RFC8949. </del> <ins> A document in the binary format is encoded in RFC8949. </ins> The CBOR structure of a document is presented in the RFC8610.  All CDDL rules not defined in this document are defined in RFC8610.

Discussion:
The requirement was probably a left-over from when CRIs where specified in here; the current document has no use for the properties obtainable from this. Closes: URL
The current text says: I think this is a remnant from when CoRAL and CRI were a single document; I don't see any reason to prescribe this for CoRAL. Any objections to removing that?
Change:
8. <del> [[ Editor's Note: Should we create a registry for tokens that go into the various JSON objects used by this protocol, i.e., the field names in the JSON objects? ]] </del> 8.1. The "Well-Known URIs" registry should be updated with the following

Discussion:
As discussed at IETF 97, this PR creates specification-required registries of fields in ACME objects, so that they can be extended in an orderly fashion. Currently only applies to account and order objects, not authorizations. Not for any ideological reason -- I would be happy to add that for symmetry if people think there might be a need..
Change:
The authorization and consent gathering process in GNAP is left deliberately flexible to allow for a wide variety of different deployments, interactions, and methodologies.  In this process, the <del> AS can gather consent from the RO as necessitated by the access that has been requested.  The AS can sometimes determine which RO needs to consent based on what has been requested by the client instance, such as a specific RS record, an identified user, or a request requiring specific access such as approval by an administrator.  If the AS has a means of contacting the RO directly, it could do so without involving the client instance in its consent gathering process.  For example, the AS could push a notification to a known RO and have the RO approve the pending request asynchronously.  These interactions can be through an interface of the AS itself (such as a hosted web page), through another application (such as something installed on the RO's device), through a messaging fabric, or any other means. When interacting with an RO, the AS can do anything it needs to determine the authorization of the requested grant, including: </del> <ins> AS can gather consent from the RO or apply the RO's policy as necessitated by the access that has been requested.  The AS can sometimes determine which RO needs to consent based on what has been requested by the client instance, such as a specific RS record, an identified user, or a request requiring specific access such as approval by an administrator.  If the AS has a means of contacting the RO directly, it could do so without involving the client instance in its consent gathering process.  For example, the AS could push a notification to a known RO and have the RO approve the pending request asynchronously.  These interactions can be through an interface of the AS itself (such as a hosted web page), through another application (such as something installed on the RO's device), through a messaging fabric, or any other means.  When interacting with an RO, the AS can do anything it needs to determine the authorization of the requested grant, including: </ins> authenticate the RO, through a local account or some other means such as federated login

Discussion:
to update section 4 to provide an additional use case (RO's policy). I don't think we need to update the definitions or URL
To edit notification comments on pull requests, go to your .
NAME please run on this PR to clean up the line end spaces, otherwise looks good to me. Thanks!
will do ! (btw, I added that to the wiki)
Following the discussion on the mailing list, will plan a rewording to clarify URL Thanks for the feedback. There was a rewrite of section 4 (gathering consent and authorization) that sought to update this, so if that’s still not entirely clear that definitely needs another pass. — Justin >
Change:
when appraising it at time(RA) by checking "time(RA) - time(RG) < Threshold", where the Relying Party's threshold is large enough to account for the maximum permitted clock skew between the Relying <del> Party and the Verifier. The result might then be used for some time (e.g., throughout the lifetime of a connection established at time(RA)).  The Relying Party must be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain fresh enough.  Thus, it might allow use (at time(OP)) as long as "time(OP) - time(RG) < Threshold".  However, if the Attestation Result contains an expiry time time(RX) then it could explicitly check "time(OP) < time(RX)". </del> <ins> Party and the Verifier.  The result might then be used for some time (e.g., throughout the lifetime of a connection established at time(RA)).  The Relying Party must be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain fresh enough.  Thus, it might allow use (at time(OP)) as long as "time(OP) - time(RG) < Threshold".  However, if the Attestation Result contains an expiry time time(RX) then it could explicitly check "time(OP) < time(RX)". </ins> 14.2.

Discussion:
replace pull request with one we can edit. This attempts to establish the architectural basis for implicit trust as a result of links.
new text from requires some new Security Considerations text.
Change:
This alert is sent by the client to indicate that all 0-RTT application_data messages have been transmitted (or none will be <del> sent at all) and that this is the end of the flight.  This alert MUST be at the warning level.  Servers MUST NOT send this alert and clients receiving it MUST terminate the connection with an "unexpected_message" alert. </del> <ins> sent at all) and that the following records are protected under handshake traffic keys.  This alert MUST be at the warning level. Servers MUST NOT send this alert and clients receiving it MUST terminate the connection with an "unexpected_message" alert. </ins> This alert notifies the recipient that the sender is canceling the handshake for some reason unrelated to a protocol failure.  If a

Discussion:
The alert is described as being part of the first flight, but it is really sent when the server Finished is received, per the processing order section. Notably, servers MUST NOT wait for endofearlydata before sending ServerHello through Finished. Group it with the client Finished flight, and fix the text about it terminating the first flight. (The division between the first and second client flight isn't especially well-defined because early data may flow in parallel with the ServerHello flight. But if there is to be a division, endofearlydata certainly falls into the second one.)
Yes, this should help avoid one of the most common mistakes in 0-RTT implementations.
LGTM.
Change:
The example in sec.detailed-example shows a more involved case of "LS" group generation. <del> The next step is to generate "m=" sections for each "m=" section that is present in the remote offer, as specified in RFC3264.  For the purposes of this discussion, any session-level attributes in the </del> <ins> The next step is to generate a "m=" section for each "m=" section that is present in the remote offer, as specified in RFC3264.  For the purposes of this discussion, any session-level attributes in the </ins> offer that are also valid as media-level attributes are considered to be present in each "m=" section.  Each offered "m=" section will have an associated RtpTransceiver, as described in sec.applying-a-remote-

Discussion:
This includes Removing my postal address. Mozilla closed that office. small editorial changes Removing bogus whitespace.
NAME PTAL
NAME I think I've got your changes and we are ready to land?
LGTM
Change:
functionality for the session (functionality that is supported but not desired by default may be omitted); for each SDP line, the generation of the SDP will follow the process defined for generating <del> an initial offer from the document that specifies the given SDP line. The exact handling of initial offer generation is detailed in </del> <ins> an initial offer from the specification that defines the given SDP line.  The exact handling of initial offer generation is detailed in </ins> sec.initial-offers below. In the event createOffer is called after the session is established,

Discussion:
…or already fixed. NAME Change in normative text (previous ART AD requested it), please review.
LGTM, approved.
eom
LGTMOne minor comment.
Change:
parse first flight packets but not enough to fully establish a connection using that version. <del> 3.1. </del> <ins> 4.1. </ins> QUIC connections are shared state between a client and a server INV. The compatible version negotiation mechanism defined in this document

Discussion:
This PR simplifies the document's design. The new simplified design was by NAME . It removes the indication of server versions that everyone seemed to think was useless, but apart from that has very similar properties to the previous design. One important difference is that it is now the client's responsibility to detect VN-packet-based downgrade attacks instead of the server's. .
In , NAME points out that the backticks don't render nicely in the TXT version, so let's remove them
In , NAME mentioned that having the client communicate preference ordering between compatible versions isn't absolutely necessary. This issue tracks whether we want to keep this ordering or not.
During the IETF QUIC WG meeting there was (weak-ish) consensus that this useful to keep.
The strongest argument against this was that it doesn't give the server a full ordering, because it doesn't tell the server where the offered version falls in the preference list. There's a possible answer to that, which is that the client should only offer compatible versions which are more preferred than the currently offered version. However, we should explicitly state that the server makes the actual decision and MAY factor client preferences into that. I suspect most won't.
NAME that's incorrect. The offered version is present in the list.
Ah, thanks for correcting me. Then we're spending bytes to repeat the version number, which we don't expect servers will typically use. Not the end of the world either way.
Consensus established. Closing this issue with no action.
Almost there, but I think we need clarity on the clients verification-and-drop requirements.