jiebi/CodeConvo huggingface dataset:
Change:
therefore compare the expected rate at which servers will generate CIDs with the lifetime of a configuration. <ins> 8.7. The Four Pass Encryption algorithm is structured as a 4-round Feistel network with non-bijective round function.  As such, it does not offer a very high security level against distinguishing attacks, as explained in Patarin2008.  Attackers can mount these attacks if they are in possession of O(SQRT(len/2)) pairs of ciphertext and known corresponding plain text, where "len" is the sum of the lengths of the Server ID and the Nonce. The authors considered increasing the number of passes from 4 to 12, which would definitely block these attacks.  However, this would require 12 round of AES decryption by load balancers accessing the CID, a cost deemed prohibitive in the planned deployments. The attacks described in Patarin2008 rely on known plain text.  In a normal deployment, the plain text is only known by the server that generates the ID and by the load balancer that decrypts the content of the CID.  Attackers would have to compensate by guesses about the allocation of server identifiers or the generation of nonces.  The these attacks are thus mitigated by making nonces hard to guess, as specified in cid-entropy, and by rules related to mixed deployments that use both clear text CID and encrypted CID, for example when transitioning from clear text to encryption.  Such deployments MUST use different server ID allocations for the clear text and the encrypted versions. These attacks cannot be mounted against the Single Pass Encryption algorithm. </ins> 9. There are no IANA requirements.

Discussion:
Discuss Distinguishing Attack in security section. Fix specification of Four Passes decryption Fix number of kramdown issues.
NAME I think this simple PR is ready.
Thank you, this is perfect.
We're awaiting more data to fully understand this, but we may need to allow 4, 6, or 12 passes as configuration options.
Fixed by , but we're instead going to go with in lieu of doing this.
The analysis in the second crypto review should be in the security considerations.
I believe there is an edge case where a partially chosen plaintext is possible. 1) The load balancer is supporting both an encrypted and unencrypted config, on different codepoints, that happen to use the same server ID mapping 2) The server is generating encrypted CIDs. 3) The attacker sends an initial packet sends an unencrypted CID. 4) Any server generated CID is therefore using the unencrypted server ID as plaintext. The random nonce should generally protect us, but maybe not? Anyway, security considerations could say something like "unencrypted and encrypted CIDs MUST NOT use the same server ID assignments because...".
Fixed by
Change:
designed to hide.  The use of registered mDNS hostnames SHOULD be scoped by origin, and SHOULD have the lifetime of the page. <del> 5.4. </del> <ins> 6.4. </ins> As noted in IPHandling, privacy may be breached if a web application running in two browsing contexts can determine whether it is running

Discussion:
Added new section on latency, as requested by NAME PTAL - will plan to merge at EOD if there are no outstanding comments.
Include experimental results, if we have them
LGTM
Change:
orderings in successive runs of the query. In what follows, the semantics of each segment are defined for each <del> type of input node. </del> <ins> kind of input node. </ins> 3.4.

Discussion:
JSON types are not used much in the JSON spec. It is debatable whether there really is a boolean type or simply the values and . Also, the JSONPath spec doesn't really benefit from this term.
I think this reads well without breaking any semantics.
Change:
called 'options'. CoAP supports application-layer fragmentation of the CoAP payloads <del> through blockwise transfers I-D.ietf-core-block.  However, this method does not allow the fragmentation of large CoAP options, therefore data encoded in options has to be kept small. </del> <ins> through blockwise transfers I-D.ietf-core-block.  However, block-wise transfer does not increase the size limits of CoAP options, therefore data encoded in options has to be kept small. </ins> Transport layer security for CoAP can be provided by DTLS 1.2 RFC6347 or TLS 1.2 RFC5246.  CoAP defines a number of proxy operations which

Discussion:
I went through the overview section and updated the text. The text is already good and only a few minor changes had to be made. I believe we may need to determine (some time in the future) whether it is worthwhile to combine the introduction with the text in the overview section since there is some overlap.
I spotted a few sentences that were missing a word to make sense. I'll go through and try to fix this on Monday, unless someone else manages before me. Otherwise the changes look fine.
Change:
None <del> 10.  References </del> <ins> 10.3. </ins> <del> 10.1.  URIs </del> <ins> IANA will register the following entry in the "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained at https://www.iana.org/assignments/http-fields [12]: WebTransport-Init None permanent This document None 11.  References 11.1.  URIs </ins> [1] mailto:webtransport@ietf.org

Discussion:
Chair: discussed during editors' call, plan is to go with Martin's simpler proposed encoding. We might want to discuss non-zero defaults later, but that'll be its own separate issue.
The document currently does not specify what the initial flow control windows are, nor how to change those. We have two options: Add WT_SETTINGS capsule Put those into headers
Discussed in editor's meeting, initial thinking is to put these values into the headers on the CONNECT message, rather than defining a new capsule or otherwise polluting HTTP/2's settings
Is there any reason that you want to avoid settings? The main thing that using settings would do is to provide the client with non-zero initial flow control limits on WT streams, so that it can send application data with zero latency. You can't get that without using settings. Functionally speaking, there is no real difference between a new capsule and a field, except that you can be a little more efficient with a capsule, modulo some issues regarding sequencing (do you allow it to appear anywhere? how do you manage changing values? etc...)
If we're talking about H2-connection level settings, then those are scoped to the entire connection. Using those would bring us closer to how H3 behaves (where connection-level stream configuration applies to WebTransport stream due to WT streams also being QUIC streams). On the other hand, we have designed WebTransport over HTTP/2 so that everything that happens within the CONNECT stream, so using headers/capsule instead of settings would be consistent with that. It would also mean you can transparently proxy WT-H2 to WT-H2 without parsing it (I do realize we currently say that you're not supposed to do that). Agreed. I have a mild preference for header fields since those are guaranteed to always arrive before any payload, making reasoning about their properties slightly easier.
The problem, as I see it, is that fields or capsules both lead to a situation where the client is unable to send any application data in its first flight (that is, along with the CONNECT-wossname request). What I want to avoid is the case where clients decide to improve performance by remembering initial values. I'm very much inclined to implement that caching, if only because it means that we can start using a session more quickly (for anything other than 0-RTT).

Perhaps the right answer is that we need some sort of way to encapsulate origin-wide per-resource configuration (that is, a baseline configuration that applies to all resources on the origin) and - until then - we stick with populating each resource with fields.
Chair: discussed during editors' call, see URL
Any reason why you did not do a single header field, like: Then at least the common repetitive stuff isn't repeated.
Change:
This document describes how the Messaging Layer Security (MLS) can be used in a federated environment where different MLS implementations <del> can interoperate by defining the message format for user key </del> <ins> can interoperate by defining the message format for client key </ins> retrieval.  The document also describes some use cases where federation could be useful.

Discussion:
Addressed SV's comments Remove the client fanout concept (because of TreeKEM's handshake ordering requirements) Rename UserInitKeys to ClientInitKeys Minor editorial edits
drop client fanout specify why (policy enforcement, metadata protection) incorporated comments from SV check if it is necessary to define server-to-server message formats only one domain is responsible for a group
I'm very interested in the details of this, but was unable to attend the interim meeting. Does this mean that we are explicitly ruling out client fanout entirely? What metadata are we trying to protect here? You could in theory protect all the metadata with client fanout over Tor for example. Does domain here mean domain name? Why is that relevant? (I'd expect MLS to be independent of DNS) The kind of federated delivery service I'm hoping to be able to use with MLS is logically an append only list of messages published by each member. Where each member can read any other members queue and pull messages they don't have into their own queue (they push their own messages to their own queue only). This allows for diverse P2P topologies, and bandwidth efficient routing. This would be compatible with both and .
TreeKEM has the requirement of total ordering of handshake messages which doesn't work with client fanout. Therefore we drop the idea of client fanout until we have a better proposal on how to solve this. is more conceptual, it doesn't have to be an actual domain name.
Addressed in .
Change:
The RS signs the request with its own key and sends the access token as the body of the request. <del> REQUIRED.  The access token value presented to the RS by the client instance. RECOMMENDED.  The proofing method used by the client instance to bind the token to the RS request. REQUIRED.  The identification used to authenticate the resource server making this call, either by value or by reference as described in authentication. OPTIONAL.  The minimum access rights required to fulfill the request.  This MUST be in the format described in the Resource Access Rights section of I-D.ietf-gnap-core-protocol. </del> The AS MUST validate the access token value and determine if the token is active.  An active access token is defined as a token that

Discussion:
Deploy Preview for gnap-resource-servers-editors-draft ready! Explore the source changes: 94d11a4362aaea79f357583969d87ec4955655a9 Inspect the deploy log: Browse the preview:
Change:
associated local MediaStreamTrack, the appropriate directionality attribute, as specified in RFC3264, Section 6.1.  If the offer was sendrecv, and the remote MediaStreamTrack is still "live", and <del> there a local MediaStreamTrack has been associated, the </del> <ins> there is a local MediaStreamTrack that has been associated, the </ins> directionality MUST be set as sendrecv.  If the offer was sendonly, and the remote MediaStreamTrack is still "live", the directionality MUST be set as recvonly.  If the offer was

Discussion:
LGTM
LGTM with nit above
URL Justin to respond on the list and the changes to be attached to this issue.
Editorial changes: Section 3.2, Paragraph 4 Should read "only after an offer". yep Section 3.4.2, Paragraph 1 "... the number of media streams for which to gather candidates." ok, not a fan of ending a sentence with a preposition, I see. I'll go along with this one. Section 3.5, Paragraph 1 Should say, "... the media plane that is relevant." yep Section 4.1.5, Paragraph 2 and 3 Maybe I'm alone on this but I prefer the following: "Calling this API changes the local media state." The API doesn't do anything on its own, but is a mechanism for calling some action. (Same issue as above) "The candidate gathering process is indirectly controlled through this API." Will think this over. Overall, want to be consistent in how the term 'API' is used. Section 5.2.1, Paragraph 4 "into which it is being bundled." ok Section 5.2.1, Paragraph 5 Space needed after RFC reference. yep Section 5.2.1, Paragraph 7, bullet 6 "of" yep Section 5.2.1, Paragraph 7, bullet 11 "specified" yep Section 5.3.1, Paragraph 7 "URL then be generated..." yep Section 5.3.1, Paragraph 7, bullet 4 "... and there is a local MediaStreamTrack that has been associated ..." indeed, not my best work Section 5.3.1, Paragraph 7, bullet 5 "... Section 3, MUST be supported." yep Section 5.3.1, Paragraph 7, bullet 6 "... the payload type of the primary..." yep Section 5.3.1, Paragraph 7, bullet 11 "... as specified in ..." yep
Change:
An "a=rtcp-mux" line, as specified in RFC5761, Section 5.1.1. <ins> An "a=rtcp-mux-only" line, as specified in I-D.ietf-mmusic-mux- exclusive Section 4, if and only if the RTP/RTCP multiplexing policy is "require". </ins> An "a=rtcp-rsize" line, as specified in RFC5506, Section 5. For each supported RTP header extension, an "a=extmap" line, as

Discussion:
Line 2589: "I don't think this is quite right. I imagine this should probably echo the above, e.g. MUST only be added if present in the most recent answer."
So re-review this one and see if you are OK with it as is.
This seems fine.
JSEP should probably point at the draft and include the attribute on every (applicable) media section.
Agreed
Change:
captive=true), it can still be allowed enough access for it to perform server authentication server-auth. <del> "user-portal-url" (required, string): provides the URL of a web </del> <ins> "user-portal-url" (optional, string): provides the URL of a web </ins> portal with which a user can interact. "vendor-info-url" (optional, string): provides the URL of a webpage or site on which the operator of the network has <del> information that it wishes to share with the user (e.g. store </del> <ins> information that it wishes to share with the user (e.g., store </ins> info, maps, flight status, or entertainment). "expire-date" (optional, string formatted as RFC3339 datetime):

Discussion:
As discussed in , define an IANA registry for extending JSON keys use for Captive Portal API.
NAME NAME thanks for the comments. Please take another pass!
Should we define an IANA registry for adding new keys?
Yes, yes we should.
and i already commented in the PR, but if possible it would be beneficial to have some distinction between IETF or a relevant organization (like WFA, WBA) requested keys vs from some individual organization
Would we want to suggest having a nested dictionary format for organization-specific extensions? Like "wba" as a key to a dictionary; or a sub-dictionary indicating that there are WISPr-related settings to be aware of?
i think it would be a good idea. We have seen WBA start to take active interest in the documents. Also there's work happening in WFA that could benefit from having an extension point
RFC 6648 might suggest otherwise. If there are things that a group wants to add that are truly unique to that group, this is probably fine.
Yes, I think that more than having per-group keys (with almost certain overlap), I'd imagine that compatibility with certain technologies would be handled via these sub-dictionaries, such as what I mentioned for WISPr. Not sure how critical mentioning this is in the document though.
Can we call this one done?
I'm assuming we will go down the path of defining an IANA registry with access technology specific extension ?
The description in "Captive Portal API Keys Registry" gives some guidance for prefixes, etc. I assume the experts once designated can work with WFA/WBA to define proper entries.
Change:
When using a COSE key for this algorithm, the following checks are made: <del> The 'kty' field MUST be present and it MUST be 'EC2'. </del> <ins> The 'kty' field MUST be present and it MUST be 'EC2' or 'OKP'. </ins> If the 'alg' field present, it MUST match the Key Agreement algorithm being used.

Discussion:
Deemed not used in enough locations - counter signatures suffer because of this but the group did not care.
Change:
are not authenticated.  Servers MUST NOT respond to GET requests for resources that might be considered sensitive. <ins> 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 "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. </ins> In the examples below, JWS objects are shown in the JSON or flattened JSON serialization, with the protected header and payload expressed as base64url(content) instead of the actual base64-encoded value, so

Discussion:
Also: Forbid the use of MAC-based JWS algorithms (in case this wasn't obvious) Sort error codes alphabetically
The server needs to support whatever the client sends. We should have an error code for this, and a way for the server to specify what algorithms it does support in the error message.
Change:
Fetch KeyPackages for the members to be added, and selects a version and ciphersuite according to the capabilities of the members.  To protect against downgrade attacks, the creator MUST <del> use the "supported_versions" and "supported_ciphersuites" fields in these KeyPackages to verify that the chosen version and ciphersuite is the best option supported by all members. </del> <ins> use the "capabilities" extensions in these KeyPackages to verify that the chosen version and ciphersuite is the best option supported by all members. </ins> Initialize a one-member group with the following initial values (where "0" represents an all-zero vector of size Hash.length):

Discussion:
This PR makes a few minor fixes to extensions: Coalesces and into a single extension Adds a list of supported extensions in parallel with the versions and ciphersuites Adds a missing value to the IANA table for the extension
Change:
1. <del> QUIC QUIC-TRANSPORT is a new transport protocol encapsulated in UDP and encrypted by default.  QUIC integrates TLS QUIC-TLS to encrypt all payload data and most control information.  The design focused on support of semantics for HTTP, which required changes to HTTP known as HTTP/3 QUIC-HTTP. </del> <ins> QUIC QUIC-TRANSPORT is a new transport protocol that is encapsulated in UDP.  QUIC integrates TLS QUIC-TLS to encrypt all payload data and most control information.  QUIC version 1 was designed primarily as a transport for HTTP, with the resulting protocol being known as HTTP/3 QUIC-HTTP. </ins> Given that QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is not

Discussion:
This didn't need to say encrypted twice. And it didn't really require changes to HTTP, just an adaptation. (I'm less happy about that part; it could probably use a tweak or two.)
Change:
the PTO expiry, subject to the address validation limits in Section 8.1 of QUIC-TRANSPORT. <del> Endpoints can also use coalesced packets to ensure that each datagram elicits at least one acknowledgement.  For example, a client can coalesce an Initial packet containing PING and PADDING frames with a 0-RTT data packet and a server can coalesce an Initial packet containing a PING frame with one or more packets in its first flight. </del> <ins> Endpoints can also use coalesced packets (see Section 12.2 of QUIC- TRANSPORT) to ensure that each datagram elicits at least one acknowledgement.  For example, a client can coalesce an Initial packet containing PING and PADDING frames with a 0-RTT data packet and a server can coalesce an Initial packet containing a PING frame with one or more packets in its first flight. </ins> 6.2.4.

Discussion:
This PR is also a good spot to comment on my accidental commit() to master. I can make any changes to that in this PR.
This was filed a while ago (before WGLC ended), didn't want to drop it.
Editorial, design?
There is a design issue here regarding the initial congestion window that I would like to see split out into a new issue (which can be marked design). The rest appear to be things we can address with editorial changes.
NAME I moved the IW text into , though I'm not sure I think it's worth revisiting.
Thanks :) I agree that it isn't worth re-opening, but we did sign on to at least discuss whether it is worth discussing.
Do we have a plan for this one?
So, is there a plan? (Is there even anything left to do?)
Some of these are addressed already, others are in an accidental commit(), and for some there's no need to address them in the text. The rest are in
Some suggestions only.One nit, but LGTM.
Change:
Verify the integrity of the ratchet tree. <ins> Verify that the tree hash of the ratchet tree matches the "tree_hash" field in the GroupInfo. </ins> For each non-empty parent node, verify that exactly one of the node's children are non-empty and have the hash of this node set as their "parent_hash" value (if the child is another

Discussion:
A couple of shortcomings to note on this PR: The joiner can't compute their private keys because they're not told where they are in the tree or how big the tree is. The former should be added to and the latter to . This approach assumes that the joiner gets the tree OOB before processing the Welcome, otherwise they can't verify the signature on the Welcome. (Since Welcome presumes they get the credential for the signer from the tree.) We could avoid the latter problem by including a credential for the signer and a "membership proof" comprising the hashes needed to tie that leaf to the tree hash in the Welcome. That could allow participants to remain "passive" (without a full tree, just their private keys) for longer, especially if such a proof could be provided on Commit as well. This might be a good candidate for an extension, though.
Discussion at the 2020-07-14 interim indicated that we should go ahead with this strategy, and just note the requirement that you have to get the tree before you process the Welcome.
I remember we discussed this in the past, but I don't think we ever spec'ed this out fully: Right now the whole tree is part of (which in turn is part of ). This can grow quite big in large groups (~17MB with 100k members with the MTI). The practical limitations are: The TLS representation of the tree is hard to parse efficiently (no skipping and no a priori information of how many nodes are in the tree) Out-of-band transmission (like server assist) is not possible Large messages like that are hard to handle on mobile devices, when they have to be downloaded in the background We should introduce an indirection, like a commit hash of the tree.
Change:
Retry as QUIC version 1.  After switching to a negotiated version after a Retry, the server MUST include the relevant transport parameters to validate that the server sent the Retry and the <del> connection IDs used in the exchange, as described in QUIC.  Note that the version of the first Initial and the subsequent Retry are not authenticated by transport parameters. </del> <ins> connection IDs used in the exchange, as described in QUIC. </ins> The server SHOULD start sending its Initial packets using the negotiated version as soon as it decides to change.  Before the

Discussion:
NAME verbally approved.
Draft currently states: Is this true? The client sends this as its Chosen Version right?
I don't think so? If the client receives a v1 Retry and then chooses to connect via v2 for some reason, that won't break the transcript.
The "for some reason" doesn't make sense to me here. If the client follows the normative language in this document and in QUIC VN, it won't magically switch to v2 after receiving a v1 retry - it will instead send a second v1 initial which will contain the retry token and also . Also, while we're at it, what is the "subsequent Retry" here? Can you write up a packet diagram to explain the flow you have in mind? (on this issue not in the draft)
Ah, I'd forgotten that in 4.1 we validate the version in the Retry token. I'll delete the sentence.