Question: support removing a Message from its buffer, this property may be ignored. <del> Niceness: this represents the ability to de-prioritize a Message in favor of other Messages.  This can be implemented by the system re-ordering Messages that have yet to be handed to the Protocol Stack, or by giving relative priority hints to protocols that support priorities per Message.  For example, an implementation of HTTP/2 could choose to send Messages of different niceness on streams of different priority. </del> <ins> Priority: this represents the ability to prioritize a Message over other Messages.  This can be implemented by the system re-ordering Messages that have yet to be handed to the Protocol Stack, or by giving relative priority hints to protocols that support priorities per Message.  For example, an implementation of HTTP/2 could choose to send Messages of different Priority on streams of different priority. </ins> Ordered: when this is false, it disables the requirement of in- order-delivery for protocols that support configurable ordering.

Several small updates, mostly to clean things up a bit, and align property names and such.
NAME - I think you're wrong: my understanding (and also the way the text is written - otherwise we'd have to change it in the API draft) was that Connection Properties can (and should) also be set on Preconnections, to give as much input as possible for Connection establishment. In the API draft, the Selection Properties in Section 5.2 can only be used on Preconnections: you can't ask for congestion control after establishment. You can't say that you'd rather have multistreaming support after establishment. But that doesn't exclude Connection properties from being usable earlier. Required minimum checksum coverage could influence choosing UDP-Lite vs. UDP. Bounds on Send or Receive Rate could influence the interface choice. The capacity profile could influence various things (and no, there isn't a matching Selection Property now - there is a per-Message override). So... I think that either you're wrong, or I'm missing something and the API draft heavily lags behind a decision that was made. I hope not!
NAME The API drafts says: I interpret this as only the Selection Properties influence selection and the Connection properties are used to further configure the connections according to user preferences. Otherwise what is the difference between them?
If you interpret it as you do, I think the text isn't clear enough (indeed it isn't super clear - in particular, "eventually established" is misleading IMO). Though, note that it says that Connection properties can also be used later. Regarding the difference between them: Selection Properties only make sense for Preconnections.
NAME - sorry lost this thread. But I saw that you have started cleaning up some Connection properties that had mixed Connection and Selection properties up in the API draft. Does it mean that we are now in synch and agree that only Selection properties are used in the selection and Connection properties are used for configuration (both during establisment and also after the connection setup).
NAME the other PR means nothing about what I said here: it only tried to address issue which is about a wording inconsistency in a specific property. You say that Connection properties can also be used during establishment - if you agree with allowing this, then why not allow to configure them as early as possible and allow them to influence selection?


Question: support removing a Message from its buffer, this property may be ignored. <del> Niceness: this represents the ability to de-prioritize a Message in favor of other Messages.  This can be implemented by the system re-ordering Messages that have yet to be handed to the Protocol Stack, or by giving relative priority hints to protocols that support priorities per Message.  For example, an implementation of HTTP/2 could choose to send Messages of different niceness on streams of different priority. </del> <ins> Priority: this represents the ability to prioritize a Message over other Messages.  This can be implemented by the system re-ordering Messages that have yet to be handed to the Protocol Stack, or by giving relative priority hints to protocols that support priorities per Message.  For example, an implementation of HTTP/2 could choose to send Messages of different Priority on streams of different priority. </ins> Ordered: when this is false, it disables the requirement of in- order-delivery for protocols that support configurable ordering.

What's bad about having more information available that can guide the selection process?
NAME the problem is that the Connection properties are not expressed in a way suitable for selection. If they should also be used for Selection they would have to be reworked to be of type Preference. Otherwise I do not know what they mean for selection. What does it mean if I pick say a particular connection group transmission scheduler? Is it required or preferred? Most connection properties also do not look very useful to me for selection so in case there are some we need I think it would be simpler to just define a matching selection property.
NAME we're only discussing whether it's allowed to use them as additional input or not. I agree, some (like the scheduler choice) don't seem useful, but some do... generally we may not have good guidance on how they should be used by an implementation, but giving the system freedom to use as many inputs as possible is probably a good thing. Regarding the type, require/prefer//ignore/avoid/prohibit obviously works fine for a "wishlist" of boolean character: having something, or not having it. The selection properties are generally like that - except "Interface Instance or Type" and "Provisioning Domain Instance or Type" which are, well... wishlist-collections. Consider the capacity profile. Surely configuring this early can be useful input - e.g. if someone picks low latency / interactive, you may even want to put this traffic on a specific network interface! But if you'd want to make a copy of the capacity profile as a "proper" selection property, how would you do it? Apply require/prefer/ignore/avoid/prohibit for each of its values? Then I could say "prefer" low latency/non-interactive but "avoid" low latency/non-interactive, which would surely be odd. Apply the qualifier to the whole thing? Then it's about, e.g. "avoiding" to use a capacity profile at all. That's odd as well. I think it's in the nature of the current selection properties that they merely say "I want to be able to do this, and this is how important it is to me", which is different from configuring something. That's also why, as written, they simply wouldn't work for later connection configuration.


Question: support removing a Message from its buffer, this property may be ignored. <del> Niceness: this represents the ability to de-prioritize a Message in favor of other Messages.  This can be implemented by the system re-ordering Messages that have yet to be handed to the Protocol Stack, or by giving relative priority hints to protocols that support priorities per Message.  For example, an implementation of HTTP/2 could choose to send Messages of different niceness on streams of different priority. </del> <ins> Priority: this represents the ability to prioritize a Message over other Messages.  This can be implemented by the system re-ordering Messages that have yet to be handed to the Protocol Stack, or by giving relative priority hints to protocols that support priorities per Message.  For example, an implementation of HTTP/2 could choose to send Messages of different Priority on streams of different priority. </ins> Ordered: when this is false, it disables the requirement of in- order-delivery for protocols that support configurable ordering.

Connection properties really are about configuring something, but I still say that being able to use them as early input is good. I agree that the implementation isn't super clear as they don't come with a require/prefer/... etc. qualifier, but then we just offer some freedom to implementers.
NAME I just pushed a commit that updates the selection and connection properties text, removing "connection" almost everywhere, but adding a disclaimer in the beginning that says that connection properties should be configured as early as possible because they can influence decisions made by the implementation, and "In the remainder of this document, we only refer to Selection Properties because they are the more typical case." Frankly I'm not sure this is better... but it does remove most of the "selection and connection" double mentions that you pointed out.
Fixed up branch building and resolved merge conflicts. I'll merge this in later today before the posting deadline.
Cool thanks! Sorry if I messed something up
As discussed in
Thank you for updating this – looks good! just needs s/send-params/msg-properties/ and merging


Question: connection error of type "HTTP_QPACK_ENCODER_STREAM_ERROR". Reducing the dynamic table capacity can cause entries to be evicted <del> (see eviction).  This MUST NOT cause the eviction of entries with outstanding references (see reference-tracking).  Changing the capacity of the dynamic table is not acknowledged as this instruction does not insert an entry. </del> <ins> (see eviction).  This MUST NOT cause the eviction of blocking entries (see blocked-insertion).  Changing the capacity of the dynamic table is not acknowledged as this instruction does not insert an entry. </ins> 4.4.

A dynamic table entry that has not been acknowledged by the decoder must not be evicted by the encoder, even if there has never been any references to it. This is already alluded to in the current spec at URL by the phrase "acknowledged by the decoder", but since "acknowledged" is used interchangeably for acknowledging the insertion instruction and acknowledging references, a reader could understand this to mean "all references acknowledged". In addition, at three other places eviction of entries with unacknowledged references are banned, with unambigously no ban on eviction of unacknowledged entries with no references. I argue that more explicit language would be beneficial. This issue has already been discussed at URL and below. Note that avoiding this kind of corruption could also be achieved by banning an encoder from inserting entries that it does not immediately reference, but this is probably way too restrictive. For example, an encoder might wish to achieve best latency and speculatively improve future compression ratio at the expense of potentially wasting current bandwidth by encoding header fields as literals while inserting them at the same time for potiential future use. This is already alluded to in the spec at multiple places. Below is a specific scenario when this issue might cause corruption: Suppose MaxEntries is 5. Suppose that there is a fresh connection, with an empty dynamic table, and there is a header list to be sent that has two header fields which fit in the dynamic table together. Suppose one encoder implementation inserts these two header fields into the dynamic table, and encodes the header list using two Indexed Header Field instructions, referring to absolute indices 1 and 2. This header block will have an abstract Largest Reference value of 2, which is encoded as 3 on the wire. A spec compliant decoder should have no difficultly correctly decoding this header block. Suppose another encoder implementation starts by adding 10 unique entries, all different from the two header fields in the header list to be sent, to the dynamic table, but does not emit references to any of them. Of course in the end only the last couple will stay in the dynamic table, the rest will be evicted. This can be considered spec compliant depending on how one interprets the spec, see above.


Question: connection error of type "HTTP_QPACK_ENCODER_STREAM_ERROR". Reducing the dynamic table capacity can cause entries to be evicted <del> (see eviction).  This MUST NOT cause the eviction of entries with outstanding references (see reference-tracking).  Changing the capacity of the dynamic table is not acknowledged as this instruction does not insert an entry. </del> <ins> (see eviction).  This MUST NOT cause the eviction of blocking entries (see blocked-insertion).  Changing the capacity of the dynamic table is not acknowledged as this instruction does not insert an entry. </ins> 4.4.

Suppose that after this, this encoder implementation encodes our header list by inserting both header fields into the dynamic table, with absolute indices 11 and 12, and using two Indexed Header Field instructions on the request stream. The abstract Largest Reference value is 12, which is encoded as 3 on the wire since 2 * MaxEntries == 10. Now suppose that out of the 12 instructions on the encoder stream, only the first two arrive before all the request stream data are received. The remaining 10 instructions on the encoder stream are delayed on the wire. Now a spec compliant decoder sees the same header block on the request stream, bit by bit, as above, and two insertions on the encoder stream. It will emit dynamic table entires 1 and 2, which are different from the encoded header list.
You should really create a new issue for these things. Because this comment relates only to the issue, not the proposed fix. I haven't read the proposed changes, though I will if you think that there is a fix in there that is worth keeping after this. Anyhow, the example is invalid here: Because: And you can only ever fit 5 entries in that table.
That's exactly the issue: "it has first been acknowledged by the decoder" is ambigous. "Acknowledged" is being used throughout the text with two different meanings, most often to refer to references, not insertions. The ban on evicting an entry the insertion of which has not been acknowledged, that you are quoting, only occurs once out of four different locations talking about when an entry can be evicted. The other three places clearly only ban evicting an entry with unacknowledged references (note the use of the same word), giving the impression that acknowledgement of the insertion is not necessary before eviction. Since the design is correct if you read it right, but wording is not as clear as I think it should be, I consider this issue editorial. The change I propose in this PR is meant to be an improvement on clarity.
OK, having read the changes, I agree with them. They consolidate the fix by creating two conditions that cause an entry to be "blocking".
Rebased on . Please let me know if anybody can come up with a term better than "blocking" which is confusing given that streams can be "blocked".


Question: connection error of type "HTTP_QPACK_ENCODER_STREAM_ERROR". Reducing the dynamic table capacity can cause entries to be evicted <del> (see eviction).  This MUST NOT cause the eviction of entries with outstanding references (see reference-tracking).  Changing the capacity of the dynamic table is not acknowledged as this instruction does not insert an entry. </del> <ins> (see eviction).  This MUST NOT cause the eviction of blocking entries (see blocked-insertion).  Changing the capacity of the dynamic table is not acknowledged as this instruction does not insert an entry. </ins> 4.4.

NAME Thank you for your feedback.
Thanks for this. I don't have a better name for blocking entries right now, but I will keep thinking on it as I agree it could confuse people even more.
This looks reasonable.


Question: ratchet tree and the members' ClientInitKeys. The hash of a tree is the hash of its root node, which we define <del> recursively, starting with the leaves.  The hash of a leaf node is the hash of a "LeafNodeHashInput" object: </del> <ins> recursively, starting with the leaves. While hashes at the nodes are used to check the integrity of the subtrees, signatures are required to provide authentication and group agreement.  Siganatures are especially important in the case of newcomers and MUST be verified when joining.  All nodes in the tree MUST be signed to provide authentication and group agreement. </ins> <del> The content within the leaf of a ratchet tree is composed of a "ClientInitKey" when the leaf is populated.  The "info" field is equal to the null optional value when the leaf is blank (i.e., no member occupies that leaf). </del> <ins> Elements of the ratchet tree are called "RatchetNode" objects and contain optionally a "ClientInitKey" when at the leaves or an optional "ParentNode" above. </ins> <del> The intermediate nodes contain less information, the hash of a parent node (including the root) is the hash of a "ParentNodeHashInput" struct: </del> <ins> When computing the hash of a parent node AB the "ParentNodeHash" structure is used: </ins> The "left_hash" and "right_hash" fields hold the hashes of the node's <del> left and right children, respectively.  The "public_key" field holds the hash of the public key stored at this node, represented as an "optional<HPKEPublicKey>" object, which is null if and only if the node is blank. </del> <ins> left (A) and right (B) children, respectively.  The signature within the "ParentNode" is computed over the its prefix within the serialized "ParentNodeHash" struct to cover all information about the sub-tree.  The "committer_index" is required for a member to determine the signing key needed to perform the signature verification. To compute the hash of a leaf node is the hash of a "LeafNodeHash" object: Note that unlike a ParentNode, a ClientInitKey already contains a signature. </ins> 7.4.

It seems like there's a major thing missing here, namely how the sender of a Commit transmits the new node signatures to the other members of the group. We need something like that before this lands. The most obvious approach would be to add a field to DirectPathNode, as you have with RatchetNode.
It would also be handy to include in the intermediate node an indication of which leaf signed it. Otherwise you have to do "trial verifications" (cf. trial decryption), which is expensive.
Was this addressed? it's mentioned that the signature should be transmitted in "Synchronizing Views of the Tree" but there's no signature in the transmitted DirectPathNode
NAME changes the strategy for signing the tree, everything should be sorted out there.
Here's the Weekly Digest for : - - Last week 8 issues were created. Of these, 0 issues have been closed and 8 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :speaker: , by It received 1 comments. - - Last week, 6 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 3 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases.


Question: ratchet tree and the members' ClientInitKeys. The hash of a tree is the hash of its root node, which we define <del> recursively, starting with the leaves.  The hash of a leaf node is the hash of a "LeafNodeHashInput" object: </del> <ins> recursively, starting with the leaves. While hashes at the nodes are used to check the integrity of the subtrees, signatures are required to provide authentication and group agreement.  Siganatures are especially important in the case of newcomers and MUST be verified when joining.  All nodes in the tree MUST be signed to provide authentication and group agreement. </ins> <del> The content within the leaf of a ratchet tree is composed of a "ClientInitKey" when the leaf is populated.  The "info" field is equal to the null optional value when the leaf is blank (i.e., no member occupies that leaf). </del> <ins> Elements of the ratchet tree are called "RatchetNode" objects and contain optionally a "ClientInitKey" when at the leaves or an optional "ParentNode" above. </ins> <del> The intermediate nodes contain less information, the hash of a parent node (including the root) is the hash of a "ParentNodeHashInput" struct: </del> <ins> When computing the hash of a parent node AB the "ParentNodeHash" structure is used: </ins> The "left_hash" and "right_hash" fields hold the hashes of the node's <del> left and right children, respectively.  The "public_key" field holds the hash of the public key stored at this node, represented as an "optional<HPKEPublicKey>" object, which is null if and only if the node is blank. </del> <ins> left (A) and right (B) children, respectively.  The signature within the "ParentNode" is computed over the its prefix within the serialized "ParentNodeHash" struct to cover all information about the sub-tree.  The "committer_index" is required for a member to determine the signing key needed to perform the signature verification. To compute the hash of a leaf node is the hash of a "LeafNodeHash" object: Note that unlike a ParentNode, a ClientInitKey already contains a signature. </ins> 7.4.

- - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 4 issues were created. Of these, 0 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by - - Last week, 14 pull requests were created, updated or merged. Last week, 8 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 6 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 10 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 3 contributors. :bustinsilhouette: :bustinsilhouette: :bustinsilhouette: - - Last week there were no stargazers. - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .
Here's the Weekly Digest for : - - Last week 11 issues were created. Of these, 1 issues have been closed and 10 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by :speaker: , by It received 2 comments.


Question: ratchet tree and the members' ClientInitKeys. The hash of a tree is the hash of its root node, which we define <del> recursively, starting with the leaves.  The hash of a leaf node is the hash of a "LeafNodeHashInput" object: </del> <ins> recursively, starting with the leaves. While hashes at the nodes are used to check the integrity of the subtrees, signatures are required to provide authentication and group agreement.  Siganatures are especially important in the case of newcomers and MUST be verified when joining.  All nodes in the tree MUST be signed to provide authentication and group agreement. </ins> <del> The content within the leaf of a ratchet tree is composed of a "ClientInitKey" when the leaf is populated.  The "info" field is equal to the null optional value when the leaf is blank (i.e., no member occupies that leaf). </del> <ins> Elements of the ratchet tree are called "RatchetNode" objects and contain optionally a "ClientInitKey" when at the leaves or an optional "ParentNode" above. </ins> <del> The intermediate nodes contain less information, the hash of a parent node (including the root) is the hash of a "ParentNodeHashInput" struct: </del> <ins> When computing the hash of a parent node AB the "ParentNodeHash" structure is used: </ins> The "left_hash" and "right_hash" fields hold the hashes of the node's <del> left and right children, respectively.  The "public_key" field holds the hash of the public key stored at this node, represented as an "optional<HPKEPublicKey>" object, which is null if and only if the node is blank. </del> <ins> left (A) and right (B) children, respectively.  The signature within the "ParentNode" is computed over the its prefix within the serialized "ParentNodeHash" struct to cover all information about the sub-tree.  The "committer_index" is required for a member to determine the signing key needed to perform the signature verification. To compute the hash of a leaf node is the hash of a "LeafNodeHash" object: Note that unlike a ParentNode, a ClientInitKey already contains a signature. </ins> 7.4.

- - Last week, 11 pull requests were created, updated or merged. Last week, 6 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by Last week, 4 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 1 pull request was merged. :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :bustin_silhouette: - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .


Question: The step of gathering candidates involves identifying which paths, protocols, and endpoints may be used for a given Connection.  This list is determined by the requirements, prohibitions, and preferences <del> of the application as specified in the Path Selection Properties and Protocol Selection Properties. </del> <ins> of the application as specified in the Selection Properties. </ins> 4.1.1.


Question: The step of gathering candidates involves identifying which paths, protocols, and endpoints may be used for a given Connection.  This list is determined by the requirements, prohibitions, and preferences <del> of the application as specified in the Path Selection Properties and Protocol Selection Properties. </del> <ins> of the application as specified in the Selection Properties. </ins> 4.1.1.


Question: The step of gathering candidates involves identifying which paths, protocols, and endpoints may be used for a given Connection.  This list is determined by the requirements, prohibitions, and preferences <del> of the application as specified in the Path Selection Properties and Protocol Selection Properties. </del> <ins> of the application as specified in the Selection Properties. </ins> 4.1.1.


Question: suite it will use for encryption.  It MUST NOT choose a cipher suite not advertised by the configuration. <del> Next, the client constructs the ClientHelloOuter message just as it </del> <ins> Next, the client constructs the ClientHelloInner message just as it </ins> does a standard ClientHello, with the exception of the following rules: <del> It MUST offer to negotiate TLS 1.3 or above. It MUST include an "encrypted_client_hello" extension with a payload constructed as described below. </del> <ins> It MUST NOT offer to negotiate TLS 1.2 or below.  Note this is necessary to ensure the backend server does not negotiate a TLS version that is incompatible with ECH. </ins> <del> The value of "ECHConfig.public_name" MUST be placed in the "server_name" extension. </del> <ins> It MUST NOT offer to resume any session for TLS 1.2 and below. </ins> <del> It MUST NOT include the "pre_shared_key" extension.  (See flow- clienthello-malleability.) </del> <ins> It SHOULD contain TLS padding RFC7685 as described in padding. </ins> <del> The client then constructs the ClientHelloInner message just as it </del> <ins> The client then constructs the ClientHelloOuter message just as it </ins> does a standard ClientHello, with the exception of the following rules: <del> It MUST NOT offer to negotiate TLS 1.2 or below.  Note this is necessary to ensure the backend server does not negotiate a TLS version that is incompatible with ECH. It MUST NOT offer to resume any session for TLS 1.2 and below. </del> <ins> It MUST offer to negotiate TLS 1.3 or above. </ins> <del> It MAY offer any other extension in the ClientHelloOuter except those that have been incorporated into the ClientHelloInner as described in outer-extensions. </del> <ins> Any extensions compressed as described in outer-extensions must match the ClientHelloInner.  [[OPEN ISSUE: When #331 and compression ordering is resolved, be a bit more precise here.]] </ins> <del> It MAY copy any other field from the ClientHelloOuter except ClientHelloOuter.random.  Instead, It MUST generate a fresh ClientHelloInner.random using a secure random number generator. </del> <ins> It MAY copy any other field from the ClientHelloInner except ClientHelloInner.random.  Instead, It MUST generate a fresh ClientHelloOuter.random using a secure random number generator. </ins> (See flow-client-reaction.) <del> It SHOULD contain TLS padding RFC7685 as described in padding. </del> If implementing TLS 1.3's compatibility mode (see Appendix D.4 of RFC8446), it MUST copy the legacy_session_id field from <del> ClientHelloOuter.  This allows the server to echo the correct </del> <ins> ClientHelloInner.  This allows the server to echo the correct </ins> session ID when ECH is negotiated. <ins> It MUST include an "encrypted_client_hello" extension with a payload constructed as described below. The value of "ECHConfig.public_name" MUST be placed in the "server_name" extension. It MUST NOT include the "pre_shared_key" extension.  (See flow- clienthello-malleability.) </ins> The client might duplicate non-sensitive extensions in both messages. However, implementations need to take care to ensure that sensitive extensions are not offered in the ClientHelloOuter.  [[OPEN ISSUE: We

There are two ClientHelloInners, the actual one used in the handshake, and the encoded one with outerextensions substituted in. Both are described as ClientHelloInner, but this makes it slightly ambiguous which goes into, say, the handshake transcript. (It's late now, so I'll leave this as an issue without a PR. If we don't end up resolving this separately, I'll probably fix this as part of . If we decide to implicitly copy over legacysession_id, the encryption payload becomes less and less defensibly an actual ClientHelloInner.)
In my own implementation, I've been referring to the plaintext payload as CompressedClientHelloInner. Which is terrible, but unambiguous.
Works for me. I was thinking EncodedClientHelloInner because it's shorter and still works even if you choose not to compress anything. (A no-op encoding is still an encoding.)
+1 to EncodedClientHelloInner, given that compression is optional. NAME if you have time, could you whip up a PR?
I noticed this while drafting a PR for . We're a little inconsistent about whether the ClientHelloInner or ClientHelloOuter is constructed first. Section 4 says inner before outer: Section 5.1 implies inner before outer: But section 6.1 says outer before inner: I think inner before outer makes more sense. You certainly can't finish the outer one before you've computed the inner one. (Of course, an implementation can pick whatever order is most convenient, but I think the spec should be consistent with itself.)


Question: typically that which is not possible to infer from routing information in the lower layers. <ins> EDHOC messages might change in transit due to a noisy channel or through modification by an attacker.  Changes in message_1 and message_2 (except PAD_2) are detected when verifying Signature_or_MAC_2.  Changes to PAD_2 and message_3 are detected when verifying CIPHERTEXT_3.  Changes to message_4 are detected when verifying CIPHERTEXT_4. </ins> Compared to SIGMA, EDHOC adds an explicit method type and expands the message authentication coverage to additional elements such as algorithms, external authorization data, and previous plaintext

Further security considerations about how message content is protected against manipulation. Perhaps something like this: "Manipulations of message1 may not be detected at reception since there is no MAC but, since message1 is included in TH2, if I and R disagree on message1 then subsequent PRKs and MACs will be different. Manipulations of other messages are detected at reception through the MACs, except for manipulation of the encrypted padding of message2, since PAD2 is not integrity protected."
I made a PR for this
I merged to prepare for submission on -15. is just a simple clarification.
The selfie attack mitigation implies that an initiator is stopping the exchange if it receives its own identity. An active attacker can then use this behavior to test if an initiator identity is the same one as a responder identity. In turn, it implies that the initiator anonymity does not hold against an active attacker when this mitigation is enabled. To judge if this is an issue in practice, the following question should be answered: Are there scenarios where an identity is shared between an initiator and a receiver, but the initiator identity should still be protected? One could maybe think about the case where multiple initiators and receivers are on the same server, sometimes sharing public keys and using distinct ports, but it is expected that the initiators identities are still protected. Possible actions: mention privacy loss due to the selfie attack mitigation. update the selfie attack mitigation, by mentioning that initiators should conclude the exchange as usual, but can check at the end whether they are talking to themselves or not. remove the selfie attack mitigation. Classical selfie attacks are when there is a pre-shared key between an initiator and a receiver, and the initiator will be talking to itself while it believes to be talking to the receiver. When there are only public keys, as in EDHOC, it is unclear to me if what is currently called in the draft is indeed a selfie attack. An initiator talking to itself knows it and does not believe to be talking to some other identity. As such this is why it could be possible to either remove the mention of selfie attacks in the draft, or update it.
I and R are expected to stop the exchange it they receive any identity they do not want to talk to. This likely includes their own identity. Good point that this leaks information. I think that should be added, but I don't see that the own identity is special.


Question: typically that which is not possible to infer from routing information in the lower layers. <ins> EDHOC messages might change in transit due to a noisy channel or through modification by an attacker.  Changes in message_1 and message_2 (except PAD_2) are detected when verifying Signature_or_MAC_2.  Changes to PAD_2 and message_3 are detected when verifying CIPHERTEXT_3.  Changes to message_4 are detected when verifying CIPHERTEXT_4. </ins> Compared to SIGMA, EDHOC adds an explicit method type and expands the message authentication coverage to additional elements such as algorithms, external authorization data, and previous plaintext

>Classical selfie attacks are when there is a pre-shared key between an initiator and a receiver, >and the initiator will be talking to itself while it believes to be talking to the receiver. >When there are only public keys, as in EDHOC, it is unclear to me if what is currently >called in the draft is indeed a selfie attack. The selfie attack mitigation is intended for Trust On First Use (TOFU) use cases, where there is no authentication in the initial setup. I don't think an initiator talking to itself in a TOFU use case would not know it except if they checked R's public key. Do you some better suggestion than "Selfie attack". I agree that it is not perfect. "Selfie attacks" has in older papers been called reflection attacks, but the term reflection attacks has also been used for very different attacks. One option is to not give the attack any name and instead just describe the attack.
I think I like to not give any name, as it does not perfectly match the classical definition. Here, the property which is violated is "If an EDHOC exchange is completed, two distinct identities/computers/agents were active". Which is different to violating the authentication of the protocol as is the case in classical selfie attacks. Good point. So what we are talking about in this issue is a slightly different privacy leak, which happens when the set of parties you are willing to talk to is equal to all responders minus yourself. To be more concrete, let me try to put it in a kind of drafty formal description that could replace the existing formulation. First the existing formulation: Now a possible replacement:
Thanks for the input! This issue is related to the TOFU use case which is still to be detailed (Appendix D.5). We probably should wait with the update until we have progressed that.
Relates to
I made PR for this issue. This is also related to PR and PR . The suggested text in is largely based on the suggested text above but I made some changes. I did not think this fitted well with the rest of the draft. The sentence was also not really needed. This is only true in the case where the set of identifiers is a small finite set. In the general case the set of identifiers the Initiator is not willing to communicate with is infinite.


Question: typically that which is not possible to infer from routing information in the lower layers. <ins> EDHOC messages might change in transit due to a noisy channel or through modification by an attacker.  Changes in message_1 and message_2 (except PAD_2) are detected when verifying Signature_or_MAC_2.  Changes to PAD_2 and message_3 are detected when verifying CIPHERTEXT_3.  Changes to message_4 are detected when verifying CIPHERTEXT_4. </ins> Compared to SIGMA, EDHOC adds an explicit method type and expands the message authentication coverage to additional elements such as algorithms, external authorization data, and previous plaintext

I suggest to add the following recommendation for TOFU To not leak any long-term identifiers, it is recommended to use a freshly generated authentication key as identity in each initial TOFU exchange.
I merged the PR to master. Keeping the issue open for a while.


Question: [[OPEN ISSUE: Should we require standards action for all profile IDs that would fit in 2 octets.]] <ins> 6.2. This document requests that IANA open a new registry entitled "cTLS Template Keys", on the Transport Layer Security (TLS) Parameters page, with a "Specification Required" registration policy and the following initial contents: </ins>

This PR looks good to me.
cTLS enumerates keys in the template, but does not explain how templates can be extended. Suggestion: Clients must reject the whole template if it contains any key they do not understand. The “optional” key holds a map of optional extensions that are safe to ignore.
Thanks for addressing your own issue with a PR. Creating an IANA registry for the keys used in the configuration data makes sense. I would, however, like to point out (and maybe we need to make this explicit) that the configuration information is defined for convenience but is not a mandatory-to-implement functionality for a stack.
Sure, some use cases can pre-arrange, or even hardcode, a specific configuration through a nonstandard channel. Some use cases (where the client and server are developed separately) obviously cannot.


Question: 3.5.7.2. <del> The "descendant-selector" is inspired by ECMAScript for XML (E4X). It selects the node and all its descendants. </del> <ins> The "descendant-selector" selects the node and all its descendants. </ins> 3.5.8.

Thanks for merging. I had a small fix to the caption of table 1 which is now .
(This was original raised in and now being split out) (Michael Kay) want to confuse the JSONPath spec by going into detailed comparisons at the risk of contradicting the normative text. (Glyn Normington) (Michael Kay) It seemed to be important in 2007, while argumenting to have something like XPath for JSON. If nowadays the terminology used has changed significantly with XPath 2.0 and 3.0, we better leave that comparison table 2 out. I am quite passionless here. At the IETF 110 meeting consensus was raised that inclusion of XPath in the Appendix section would be the most appropriate way to reference to it.
Closed in
Great improvement!Additions / Replacements of high value ... thanks


Question: 1. <del> QUIC QUIC has numerous extension points, including the version number that occupies the second through fifth bytes of every long header (see QUIC-INVARIANTS).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes always being 0x00000001. </del> <ins> QUIC version 1QUIC has numerous extension points, including the version number that occupies the second through fifth bytes of every long header (see QUIC-INVARIANTS).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes always being 0x00000001. </ins> In QUIC version 1, Initial packets are encrypted with the version- specific salt as described in QUIC-TLS.  Protecting Initial packets

here (URL) it is better that we call it QUIC version 1 not just QUIC. As later it is referred as QUIC version 1.here (URL) I would add reference to VN draft instead of calling it "that document"here (URL) i would add "packet" after "Initial" just to be clear, as we have now a initial version in VN draft.
Thanks, fixed here URL


Question: The total length of time over which consecutive PTOs expire is limited by the idle timeout. <del> The probe timer MUST NOT be set if the time threshold (time- threshold) loss detection timer is set.  The time threshold loss detection timer is expected to both expire earlier than the PTO and be less likely to spuriously retransmit data. </del> <ins> The PTO timer MUST NOT be set if a timer is set for time threshold loss detection; see time-threshold.  A timer that is set for time threshold loss detection will expire earlier than the PTO timer in most cases and is less likely to spuriously retransmit data. </ins> 6.2.2.

That term doesn't appear above, so don't use it in the PTO section.
Thanks NAME I took your suggestions with one tweak.
Section 6.2.1: "The probe timer MUST NOT be set if the time threshold (Section 6.1.2) loss detection timer is set. The time threshold loss detection timer is expected to both expire earlier than the PTO and be less likely to spuriously retransmit data." What does "MUST NOT be set" means. The time threshold loss detection 6.1.2 only occurs if there is acknowledgement received by the sender sufficient late after the transmission. Thus, PTO timer needs to always be set. because even if Time Threshold timer fires it might not declare a loss.
It means if the time threshold timer is armed, you are not supposed to arm the PTO timer. If the Time Threshold timer fires and doesn't declare a loss, then I would consider that a bug.
So the above text about loss timer is only when one are under the condition created by this Section 6.1.2 sentence? "If packets sent prior to the largest acknowledged packet cannot yet be declared lost, then a timer SHOULD be set for the remaining time." Does the formulation in 6.1.2 need to be improved, possibly naming the timer?
I can see the confusion. This can either be a single timer or multiple, and sometimes we refer to it one way and sometimes as separately named timers, ie "The time threshold loss detection timer" We can either be more consistent about naming the timers or stop naming the timers entirely. Would you prefer the former?
Frankly I don't know which direction that is best. Could I ask you to take an editorial stab on your most preferred. I would guess when you sit down to do either you realize if it will work or not when you harmonize it.
NAME Does PR resolve this for you?
NAME we'd need a response, please
Yes, that simple tweak do make it clearer. So resolved.
The second suggestion is a little risky, but avoids a slightly awkward construction.Editorial suggestion. I'm fine with merging this, but NAME should probably see if it addresses his issue.


Question: Target KDF: The KDF for which a PSK is imported for use. <del> Imported PSK (IPSK): A PSK derived from an EPSK, external identity, optional context string, and target protocol and KDF. </del> <ins> Imported PSK (IPSK): A PSK derived from an EPSK, External Identity, optional context string, and target protocol and KDF. </ins> Imported Identity: A sequence of bytes used to identify an IPSK. 4. <del> A key importer diversifies an input EPSK into one or more PSKs advertised on the wire via a target protocol, KDF identifier, and optional context string.  Additionally, the resulting PSK binder key is modified with a new derivation label to prevent confusion with non-imported PSKs.  This section describes the diversification mechanism and binder key computation change. </del> <ins> This section describes the PSK Importer interface and its underlying diversification mechanism and binder key computation modification. </ins> 4.1. <del> A key importer takes as input an EPSK with external identity "external_identity" and base key "epsk", as defined in terminology, along with an optional context, and transforms it into a set of PSKs and imported identities for use in a connection based on supported (target) protocols and KDFs.  In particular, for each supported target protocol "target_protocol" and KDF "target_kdf", the importer </del> <ins> The PSK Importer interface takes as input an EPSK with External Identity "external_identity" and base key "epsk", as defined in terminology, along with an optional context, and transforms it into a set of PSKs and imported identities for use in a connection based on target protocols and KDFs.  In particular, for each supported target protocol "target_protocol" and KDF "target_kdf", the importer </ins> constructs an ImportedIdentity structure as follows: The list of "target_kdf" values is maintained by IANA as described in

This is mainly editorial, so there should be nothing surprising here. Please let me if that's not the case! It also includes clarifying text per NAME recommendation raised during WGLC. cc NAME NAME
From Rob Sayre: We should note the latter is a requirement from Section 4.2.11 of RFC8446. Let's also fix the typo "import external keys for TLS..."


Question: If information about the RO is requested and the AS grants the client instance access to that data, the AS returns the approved information <del> in the "subject" response field.  This field is an object with the following OPTIONAL properties. </del> <ins> in the "subject" response field.  The AS MUST return the "subject" field only in cases where the AS is sure that the RO and the end-user are the same party.  This can be accomplished through some forms of authorization. This field is an object with the following OPTIONAL properties. </ins> An array of subject identifiers for the RO, as defined by I- D.ietf-secevent-subject-identifiers.

Opaque identifiers provide a generic reference, so we can simplify the text. (mainly), and as a byproduct also and - removed userhandle from main response in section 3 changed title of section 3.4 (User -> Subject) and moved the text that requires RO = end-user at the top of the section, for clarity changed name (userhandle -> user) and wording in section 3.5. Maybe we could also simplify the title "Returning Dynamically-bound Reference Handles" into "Returning Reference Handles" (didn't do it yet).
Deploy Preview for gnap-core-protocol-editors-draft ready! Explore the source changes: 73de700ce82846ec5e09f8f60550fac7bee0dfb5 Inspect the deploy log: Browse the preview:
With the adoption of the subject identifier format, we no longer need to have a GNAP-specific value and can instead leverage this more standard field. Alternatively, we could have a GNAP-specific subject identifier format, instead of a separate field.
In section 2.4 (Requesting User Information), the first sentence starts with: If the client instance is requesting information about the RO from the AS, ... From the title, the acronym "RO" should be changed into "end-user". The case where the RO is also the end-user is a specific case. This leads to the following change: If the client instance is requesting information about the end-user from the AS, ... In the following sentences of this section, RO should be changed into end-user.
The current text really means RO, and generally considers the case end-user = RO. Any other case would even trigger an error: "If the identified end-user does not match the RO present at the AS during an interaction step, the AS SHOULD reject the request with an error." (section 2.4) Which makes sense because why would we return something about the RO to a potentially unknown end-user? (the only problem is that this wording is buried in the text, so it's hard to understand) Back to the general case: The RO is in control of policies at the AS. The end-user is in control of a client and a request to the AS. The end-user and client may or may not have any prior relationship with the AS.


Question: If information about the RO is requested and the AS grants the client instance access to that data, the AS returns the approved information <del> in the "subject" response field.  This field is an object with the following OPTIONAL properties. </del> <ins> in the "subject" response field.  The AS MUST return the "subject" field only in cases where the AS is sure that the RO and the end-user are the same party.  This can be accomplished through some forms of authorization. This field is an object with the following OPTIONAL properties. </ins> An array of subject identifiers for the RO, as defined by I- D.ietf-secevent-subject-identifiers.

The subject info is what is known by the AS (in theory could be RO and maybe end-user, but notice that in the terminology, we define the end-user as a natural person and the RO as a subject entity). I think we should clarify when we could have a remote RO too. Then do we even return a result if the AS knows something about the end-user? (different from RO in that case). Plus we need to keep in mind that we also use sub_ids for URL In general, we might want to avoid the term "user" as it is not specific enough.
The title has been changed into "Requesting Subject information". This title is incorrect as long as a subject can be also an organization or a device. An AS can hold information about an end-user or about RO when the RO is a human being. It does not hold information about organizations or devices. However, an end-user may belong to some organizations or/and use some devices. IMO, I would replace it by "Requesting end-user Information". If an AS holds information about an end-user, it seems logical that the end-user should have access to it. If it happens that the end-user has also a RO account on the AS, then it should also have access to it. In such a case, another section with the following title "Requesting RO Information" should be created. RO = end-user was a common case in OAuth. In GNAP and in the general case a RO is different from an end-user and an AS may have no relationship with any RO (e.g. when attributes only are being used).
I guess you refer to "2.2. Requesting Subject Information". We might have to harmonize a bit, but for instance "2.3. Identifying the Client Instance" might very well hold information about devices or at least the software running on it (that's the point of client software attestation to be discussed in ) We don't always know in advance whether it will be a RO or an end-user only, so the proposal isn't always applicable.
I was indeed referring to "2.2. Requesting Subject Information" which has no relationship with "2.3. Identifying the Client Instance".


Question: If information about the RO is requested and the AS grants the client instance access to that data, the AS returns the approved information <del> in the "subject" response field.  This field is an object with the following OPTIONAL properties. </del> <ins> in the "subject" response field.  The AS MUST return the "subject" field only in cases where the AS is sure that the RO and the end-user are the same party.  This can be accomplished through some forms of authorization. This field is an object with the following OPTIONAL properties. </ins> An array of subject identifiers for the RO, as defined by I- D.ietf-secevent-subject-identifiers.

This means that your arguments do not apply to section 2.2. and, by implication, that my argumentation currently remains valid.
Well, I take the point in consideration but I don't think we should base our reasoning on the structure of sections, which can change
Identifying the User by Reference: Editor's note: We might be able to fold this function into an unstructured user assertion reference issued by the AS to the RC. We could put it in as an assertion type of "gnap_reference" or something like that. Downside: it's more verbose and potentially confusing to the client developer to have an assertion-like thing that's internal to the AS and not an assertion.
Why an assertion? Is that reference supposed to be linked to a session (cf "represent the same end-user to the AS over subsequent requests") or can it be persistent? I would see that more as an opaque identifier, rather than an assertion. Something like: asref seems a bit specific to GNAP (reference managed by the AS) but it could always be read "as a reference" in a more general setting. There's a variety of generic names that we could choose if needed, localuid, internal_uid, etc. But that really asks what additional types we could define as part of secevents (section 7.1.2). Beyond the case mentioned here, it would be most useful as an opaque identifier when RO != end-user, to avoid leaking private info about the RO (although currently we don't seem to cover that case yet) It's indeed more verbose than "user": "XUT2MFM1XBIKJKSDU8QM" but at least it's always the same structure (doesn't depend whether it's a reference or not), and it also makes the type more explicit.
A subject identifier makes sense here, and I agree that it should be a new value to let us constrain it to the GNAP context.
Fixed by SECEVENT opaque identifiers
I don't think this goes far enough -- I am thinking that with the opaque identifiers we can now simply return a with a format of that the client can be allowed to send in a follow-up request if it wants to. This way they all get treated equally, there's no special field anymore.


Question: result is "Nothing". Note: a singular query may be used anywhere where a ValueType is <del> expected, so there is no need to use the "value" function extension </del> <ins> expected, so there is no need to use the "value()" function extension </ins> with a singular query. 2.4.9.

Use parentheses as an indication that something is a function. Also, don't confuse the reader by alluding to potential future alternatives to value(). Reviewers: is this an improvement? It's a draft PR for now until we decide the change is worthwhile.
I think we'll need to explain the () notation, which should be familiar to C programmers but not necessarily to people who grew up on other languages. I also think we have a few more examples that point to hypothetical functions, such as , , .
I don't think there's a great point at which to explain that notation and, based on your observation, I'm going off the idea.
NAME Let's see how pans out before taking the current PR any further. Once I remove the function parentheses, the two PRs are changing the same text.
would be the place.
NAME As you suggested, I introduced this in 1.1, but near the start since it's notation rather than terminology. I did a regexp search to find and fix the remaining examples (your list was complete). In doing so, I found the strange markup and removed the backticks since there was no good reason for them.
We could do the fun() explanation and completeness search in a separate PR.


Question: 7.1. <del> This document will request IANA to register "masque-udp" in the HTTP </del> <ins> This document will request IANA to register "connect-udp" in the HTTP </ins> Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <del> masque-udp </del> <ins> connect-udp </ins> Proxying of UDP Payloads.

Should the upgrade token be "connect-udp" or "masque-udp" ? (issue based on by NAME
I vote for or something along those lines. "MASQUE" is good as a working group name, but I don't think it's helpful in the protocol to help people understand what the variant of CONNECT does.


Question: clients using some identifier.  MLS clients have a few types of identifiers, with different operational properties. <del> The Credentials presented by the clients in a group authenticate application-level identifiers for the clients.  These identifiers may not uniquely identify clients.  For example, if a user has multiple devices that are all present in an MLS group, then those devices' clients could all present the user's application-layer identifiers. </del> Internally to the protocol, group members are uniquely identified by <del> their leaves, expressed as LeafNodeRef objects.  These identifiers are unstable: They change whenever the member sends a Commit, or whenever an Update proposal from the member is committed. MLS provides two unique client identifiers that are stable across epochs: </del> <ins> their leaf index.  However, a leaf index is only valid for referring to members in a given epoch.  The same leaf index may represent a different member, or no member at all, in a subsequent epoch. </ins> <del> The index of a client among the leaves of the tree The "epoch_id" field in the key package The application may also provide application-specific unique identifiers in the "extensions" field of KeyPackage or LeafNode </del> <ins> The Credentials presented by the clients in a group authenticate application-level identifiers for the clients.  However, these identifiers may not uniquely identify clients.  For example, if a user has multiple devices that are all present in an MLS group, then those devices' clients could all present the user's application-layer identifiers. If needed, applications may add application-specific unique identifiers to the "extensions" field of KeyPackage or LeafNode </ins> objects. 7.

This seems to be a layer of indirection that doesn't add any value to implementation.
The Credentials section claims there is an epoch id field in key packages. I don't think that actually exists. My apologies if this is a duplicate issue.
Addressed in but may need to be pulled out depending on the fate of that PR
contains all of the Proposals that were previously sent within the same epoch. This seems unnecessary, since all members should have them anyway. The list of in the actual message should be enough for members to parse and validate a message. We should discuss if we can de-duplicate this, since the list of Proposals might be quite long.
The current definition of is as follows; Maybe this issue is obsolete?
Seems it is now obsolete indeed.
I don't have a strong opinion on this question, but this change seems sensible to me. The use of LeafNodeRef requires either (a) a linear scan through the tree, which is time-expensive in large trees, or (b) keeping an index that maps LeafNodeRef values to indices, which is storage-intensive in large trees. IIRC, the change to LeafNodeRef was made in the context of NAME work to make the tree description less tied to the array representation. In general, that is the right thing to do, and it's good that we did it. But we still have leaf indices anyway, for . Since we still have the concept, we might as well use it where it makes sense. And it certainly seems to me like and make sense, since they are internal to the protocol. In case folks are worried about the application-facing API -- MLS stacks can certainly be more intelligent, e.g., exposing or or . But they can do that regardless of this PR.


Question: the Sequence Number value in the frame is not greater than the largest processed thus far. <del> An endpoint will have committed a "max_ack_delay" value to the peer, which specifies the maximum amount of time by which the endpoint will delay sending acknowledgments.  When the endpoint receives an ACK_FREQUENCY frame, it MUST update this maximum time to the value proposed by the peer in the Request Max Ack Delay field. </del> 5. A sender can use an ACK_FREQUENCY frame to reduce the number of

We have inconsistent definitions for Ack-Eliciting Threshold, which probably has people implementing this differently. In Section 4: In Section 7: The intended definition is the one in Section 4, so fixes and makes this consistent.
The document uses MUST in multiple places, however, as discussed in the new proposed text for the security considerations (see PR ) the requester cannot enforce any ACK strategy and there might be reason like practical limitation or an overload situation where the ACK sender simply decides to send less ACKs. So the question is really can to requirements be MUSTs or is SHOULD more realistic and correct?


Question: where: <del> master_secret is defined above </del> <ins> salt is the Master Salt as defined above </ins> <del> salt is a string of zeros of the length of the hash function output in octets </del> <ins> IKM is the Master Secret is defined above </ins> info is a serialized CBOR array consisting of: <del> output_length is the size of the AEAD key/IV in bytes encoded as an 8-bit unsigned integer </del> <ins> L is the key/IV size of the AEAD algorithm in octets without leading zeroes. </ins> For example, if the algorithm AES-CCM-64-64-128 (see Section 10.2 in <del> I-D.ietf-cose-msg) is used, output_length for the keys is 128 bits and output_length for the IVs is 56 bits. </del> <ins> I-D.ietf-cose-msg) is used, L is 16 bytes for keys and 7 bytes for IVs. </ins> 3.2.2.

, and
This goes against Jim's wish to have things in bits rather than bytes... But HKDF uses octets and to combine the two parameters as wanted by Ludwig, they need the same unit.
Fixed in branch v-02
OSCOAP refers to HKDF [RFC5869], but it not clearly defined how the parameters map to HKDF-Extract and HKDF-Expand. E.g. IKM. Salt should be made optional.
In section 3.2.1. outlen is defined as "the key/IV size of the AEAD algorithm" and outputlength as "is the size of the AEAD key/IV in bytes encoded as an 8-bit unsigned integer" Isn't that essentially the same?
I just created a v-02 branch for the next update. I'll make an update as soon as possible trying to address this.
Fixed in brach v-02


Question: this limit even applies when no connection ID is exposed in the QUIC header. <ins> This extension does not change the definition of any transport parameter defined in Section 18.2. of QUIC-TRANSPORT.  Inline with the definition in QUIC-TRANSPORT disable_active_migration also disables multipath support, except "after a client has acted on a preferred_address transport parameter" Section 18.2. of QUIC- TRANSPORT.  Further, it is out of scope for this document to specify if the old address can also be used for multipath after a client has migrated to the address provided in the preferred_address transport parameter.  However, it SHOULD NOT be assumed that it is possible to use both addresses simultaneously without further confirmation from the other host. </ins> 3. After completing the handshake, endpoints have agreed to enable

NAME you wrote: That sounds like you want to restrict the multipath extension to only one server address (but potentially different paths from different clients address)...? I think this restriction is unnecessary. Yes we don't specify a way to learn server addresses but that doesn't means that the client doesn't know (e.g. based on higher layer information) multiple addresses of the server. What should we restrict that?
However, can we maybe merge this PR as it is for now and you open a separate issue for your additional point NAME ?
Mirja, That was my understanding of the sentences in the PR. Maybe I got it wrong. I think that we should discuss the role of preferred address in section 3 where we explain how paths can be opened.
Fine, let's do it this way.
RFC9000 defines a list of transport parameters. 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10 [QUICWG] These transport parameters apply to all the paths that compose a Multipath QUIC connection. We should probably confirm this in the mpquic draft to avoid any misinterpretation (e.g. for maxidletimeout or ack delays). There are two transport parameters that could warrant some discussion: disableactivemigration : This transport parameter is incompatible with enablemultipath. An endpoint that receives both this transport parameter and a non zero enablemultipath parameter MUST treat this as a connection error of type MPCONNECTIONERROR and close the connection. preferredaddress: RFC9000, section 9.2.1 contains the following: Once the handshake is confirmed, the client SHOULD select one of the two addresses provided by the server and initiate path validation (see Section 8.2). A client constructs packets using any previously unused active connection ID, taken from either the preferredaddress transport parameter or a NEWCONNECTION_ID frame. As soon as path validation succeeds, the client SHOULD begin sending all future packets to the new server address using the new connection ID and discontinue use of the old server address. If path validation fails, the client MUST continue sending all future packets to the server's original IP address.


Question: this limit even applies when no connection ID is exposed in the QUIC header. <ins> This extension does not change the definition of any transport parameter defined in Section 18.2. of QUIC-TRANSPORT.  Inline with the definition in QUIC-TRANSPORT disable_active_migration also disables multipath support, except "after a client has acted on a preferred_address transport parameter" Section 18.2. of QUIC- TRANSPORT.  Further, it is out of scope for this document to specify if the old address can also be used for multipath after a client has migrated to the address provided in the preferred_address transport parameter.  However, it SHOULD NOT be assumed that it is possible to use both addresses simultaneously without further confirmation from the other host. </ins> 3. After completing the handshake, endpoints have agreed to enable

For multipath, do we want to be stronger than SHOULD select one ? Can a client create news paths towards the initial address or only to one of the preferred addresses ? Should the client use both addresses (IPv4 and IPv6) if non-empty ?
Good point about "disableactivemigration". I would read it as also disabling multipath. We do not need to say that "transport parameters apply to all the paths that compose a Multipath QUIC connection". We are already inheriting that property from compatibility with path migration in RFC 9000. Multipath support is an extension to QUIC v1, not a new protocol, so we do not need to specify all the defaults. Same goes for the preferred address -- meaning does not change just because the nodes negotiate multipath. I would avoid debating "which server addresses the client can try" in the base multipath document. If we want the server to signal plausible addresses to the client, let's have a specific document for that.
I would maybe add a sentence that this draft does not change the meaning of preferred_address and if that address could also be used for multipath is out of scope for this extension.
Regarding disableactivemigration: this cannot be a connection error, as you can also send preferred address and after migration to the preferred address you can still use migration or multipath (if negotiated). I think the definition in RFC9000 is still valid; it means you can't send any packets from another address than the one used in the handshake. Which effectively means disabling multipath as well as Christian noted (if not moved to another preferred address). I guess we could explicitly note that this draft does not change the definition of disableactivemigration. For your reference this is what RFC9000 says:
I created a PR in . Is this sufficient to address this issue or do we need to say more? NAME ?
The proposed PR sounds good to me, with the slight addition I mentioned.


Question: attacker injected packets in order to influence the version negotiation process, see downgrade. <ins> Only servers can start incompatible version negotiation: clients MUST NOT send Version Negotiation packets and servers MUST ignore all received Version Negotiation packets. </ins> 2.2. If A and B are two distinct versions of QUIC, A is said to be

This was raised during the Reviewer: Qin Wu Review result: Has Issues I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. This document describes a version negotiation mechanism that allows a client and server to select a mutually supported version. The mechanism can be further broke down into incompatible Version Negotiation and compatible Version Negotiation. I believe this document is on the right track and but worth further polished with the following editorial comments. Major Issues: No Minor Issues: 1. Section 4 introduce verson downgrade term [Qin]What the version downgrade is? I feel confused, does it mean when I currently use new version, I should not fall back to the old version? Can you explain how version downgrade is different from version incompatible? It will be great to give a definition of version downgrade in the first place or provide an example to explain it? 2. Section 9 said: " The requirement that versions not be assumed compatible mitigates the possibility of cross-protocol attacks, but more analysis is still needed here." [Qin] It looks this paragraph is incomplete, what else analysis should we provide to make this paragraph complete? 3. Section 10 [Qin]: I am not clear why not request permanent allocation of a codepoint in the 0-63 range directly in this document. In my understanding, provisional codepoint can be requested without any dependent document? e.g., Each vendor can request IANA for Vendor specific range. Secondly, if replacing provisional codepoint with permanent allocation, requires make bis for this document, I don't think it is reasonable. Nits: 1. Section 2 said: " For instance, if the client initiates a connection with version A and the server starts incompatible version negotiation and the client then initiates a new connection with .... " [Qin]Can the client starts incompatible version negotiation? if not, I think we should call this out, e.g., using RFC2119 language. 2.


Question: attacker injected packets in order to influence the version negotiation process, see downgrade. <ins> Only servers can start incompatible version negotiation: clients MUST NOT send Version Negotiation packets and servers MUST ignore all received Version Negotiation packets. </ins> 2.2. If A and B are two distinct versions of QUIC, A is said to be

Section 2, last paragraph [Qin] This paragraph is a little bit vague to me, how do we define not fully support? e.g., the server can interpret version A, B,C, but the server only fully implements version A,B, regarding version C, the server can read this version, but can not use this version, in other words, it is partially implemented, is my understanding correct? 3.Section 2.1 the new term "offered version" [Qin] Can you add one definition of offered versions in section 1.2, terminology section? To be honest, I still not clear how offered version is different from negotiated version? Also I suggest to add definitions of accepted version, deployed version as well in section 1.2? Too many terminologies, hard to track them in the first place. 4. Section 6 said: " it is possible for some application layer protocols to not be able to run over some of the offered compatible versions. " [Qin]I believe compatible versions is not pertaining to any application layer protocol, if yes, s/compatible versions/compatible QUIC versions 7.1 said: "For example, that could be accomplished by having the server send a Retry packet in the original version first thereby validating the client's IP address before" [Qin] Is Version first Version 1? If the answer is yes, please be consistent and keep using either of them instead of inter-exchange to use them. s/version first/version 1


Question: to configure the proxy host and the proxy port.  Client implementations of this specification that are constrained by such limitations MUST use the default template which is defined as: <del> "https://$PROXY_HOST:$PROXY_PORT/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT are the configured host and port of the proxy respectively.  Proxy deployments SHOULD use the default template to facilitate interoperability with such clients. </del> <ins> "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/ udp/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT are the configured host and port of the proxy respectively.  Proxy deployments SHOULD use the default template to facilitate interoperability with such clients. </ins> 3.

The default template's purpose is to enable compatibility with origin-only proxy configuration schemes. This is a worthwhile goal, but the default template is not a suitable solution: It violates RFC 8615's definition of .well-known/ as the location for metadata about an origin. A MASQUE service is not metadata. It is not representable as a .well-known "URI suffix" as required by the .well-known registry (unless we register all (2^128 + 2^32)2^16 distinct paths). It conflicts with better discovery mechanisms, like the one in the MASQUE development process. It is not compatible with the use of HTTPS records. (In the targeted legacy context, the client has no other DNS server that can be used when a proxy is in use.) This is somewhat ironic, as HTTPS records allow bootstrapping QUIC connections, and proxying for QUIC is the primary motivation for CONNECT-UDP. We should defer this problem to a subsequent draft, and provide a cohesive proxy setup flow, presumably with a standardized configuration object that could be served from .well-known/ and extended to cover CONNECT-IP, DoH and other relevant capabilities.
Fundamentally I disagree with your assessment that this solution isn't good and should be removed. This serves a real purpose. Let's go into the issues individually: Those points are not an argument to remove the default template, they are an argument to revert PR and switch back to a non-well-known prefix. Let's set those aside for now. I don't see a conflict here: the default template doesn't preclude using other templates that have been discovered through other means. Can you clarify what the conflict is? Can you clarify what the incompatibility is here? I don't understand what the relationship between the default template and HTTPS records is. Clients are welcome to query their own HTTPS records before using CONNECT or CONNECT-UDP. The way that the client picks its template has no impact on its DNS settings.
... This is called "squatting on the HTTP namespace", and it would violate the in RFC 7320. It's also messy to implement, as it would require mixing MASQUE-specific "routing" rules with the user's application-specific routing rules. It doesn't prevent better discovery mechanisms, but it doesn't encourage them either.


Question: to configure the proxy host and the proxy port.  Client implementations of this specification that are constrained by such limitations MUST use the default template which is defined as: <del> "https://$PROXY_HOST:$PROXY_PORT/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT are the configured host and port of the proxy respectively.  Proxy deployments SHOULD use the default template to facilitate interoperability with such clients. </del> <ins> "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/ udp/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT are the configured host and port of the proxy respectively.  Proxy deployments SHOULD use the default template to facilitate interoperability with such clients. </ins> 3.

From the server side, there would be no way to "opt out" of the default path, due to the potential for clients that have implemented this specification but not a later, better discovery mechanism. Servers that would prefer a different path would still have to operate the default path for backwards-compatibility. The relationship is that the default template cannot express the existence of a DNS server affiliated with the MASQUE server. No, they are not, as this would violate the privacy guarantees implicit in the legacy proxy settings UI that this feature is trying to preserve.
You're conflating two types of proxies here: traditional enterprise proxies that speak CONNECT today and can be updated to speak CONNECT-UDP privacy proxies designed to protect a user's privacy from the network Folks won't ever be deploying both of these use cases on the same proxy. Your concerns are valid but they only apply to (2). (2) would never use the default template. The default template only applies to (1).
Client software generally can't tell why a proxy is being used. It just knows that an HTTP CONNECT proxy has been configured with a particular protocol, domain, and port. Its behavior has to be correct for any existing use case. I don't see why privacy proxies wouldn't use the default template. Privacy proxies that are configured via the existing Secure Web Proxy configuration mechanisms (e.g. browser extensions, system settings) would have no other way to use MASQUE. Also, I think this distinction is false. Enterprises are free to use HTTP CONNECT proxies to conceal certain information from the network (e.g. using an employees-only browser extension), and enterprises are often opinionated about which DNS server ought to be used (not controllable via a browser extension).
For completeness, here's how I think this ought to look: URL
Your discovery draft sounds great - however the default template doesn't get in the way of that. I don't think it's reasonable to remove a useful feature because we might have a more complete solution later when the useful feature doesn't get in the way of the future complete solution.
Should the default URI template have a /.well-known prefix? For example, ? (issue based on by NAME
While you are at it..., how about something simpler? would put the host and port in query parameters AND it would have smaller, shorter names.


Question: to configure the proxy host and the proxy port.  Client implementations of this specification that are constrained by such limitations MUST use the default template which is defined as: <del> "https://$PROXY_HOST:$PROXY_PORT/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT are the configured host and port of the proxy respectively.  Proxy deployments SHOULD use the default template to facilitate interoperability with such clients. </del> <ins> "https://$PROXY_HOST:$PROXY_PORT/.well-known/masque/ udp/{target_host}/{target_port}/" where $PROXY_HOST and $PROXY_PORT are the configured host and port of the proxy respectively.  Proxy deployments SHOULD use the default template to facilitate interoperability with such clients. </ins> 3.

Having implemented this, placing the variables in the path is easier to parse on the proxy than placing them in query parameters
From the discussion in the room at IETF 113, it appeared folks were OK with . I'm going to pick that to close this issue, and we can open another issue during WGLC if we really want to bikeshed this further
It sound like you're writing your own URL parser? Any reasonable URL library will handle this for you.
I don't think placing these things in path components by default is reasonable.


Question: 8.1. <del> Several of the challenges in this document make use of a key </del> <ins> All challenges defined in this document make use of a key </ins> authorization string.  A key authorization is a string that expresses a domain holder's authorization for a specified key to satisfy a specified challenge, by concatenating the token for the challenge with a key fingerprint, separated by a "." character: The "JWK_Thumbprint" step indicates the computation specified in <del> RFC7638, using the SHA-256 digest FIPS180-4.  As noted in JWA RFC7518 any prepended zero octets in the fields of a JWK object MUST be stripped before doing the computation. </del> <ins> RFC7638, using the SHA-256 digest FIPS180-4.  As noted in RFC7518 any prepended zero octets in the fields of a JWK object MUST be stripped before doing the computation. </ins> As specified in the individual challenges below, the token for a challenge is a string comprised entirely of characters in the URL-

I think without OOB all challenges use key-authorization "JWA" is not defined in this document. I think it can just be omitted
NAME Thank you for the change! :smile:
Thanks again NAME I really appreciate your editing & the accompanying PRs! :-)


Question: certain that it has not processed another packet with the same packet number from the same packet number space.  Duplicate suppression MUST happen after removing packet protection for the reasons described in <del> Section 9.3 of QUIC-TLS. </del> <ins> Section 9.5 of QUIC-TLS. </ins> Endpoints that track all individual packets for the purposes of detecting duplicates are at risk of accumulating excessive state.

There are three places which refer to "Section 9.3 of QUIC-TLS". I think they should refer to "Section 9.5 of QUIC-TLS".
Thanks!


Question: in the cookie, rather than requiring it to export the entire intermediate hash state (see cookie). <ins> For concreteness, the transcript hash is always taken from the following sequence of handshake messages, starting at the first ClientHello and including only those messages that were sent: ClientHello, HelloRetryRequest, ClientHello, ServerHello, EncryptedExtensions, Server CertificateRequest, Server Certificate, Server CertificateVerify, Server Finished, EndOfEarlyData, Client Certificate, Client CertificateVerify, Client Finished. </ins> In general, implementations can implement the transcript by keeping a running transcript hash value based on the negotiated hash.  Note, however, that subsequent post-handshake authentications do not

Move the list to the new transcript hash section. Note that EndOfEarlyData goes in the client Handshake Context.
lgtm


Question: RFC4566 is the base SDP specification and MUST be implemented. RFC5764 MUST be supported for signaling the UDP/TLS/RTP/SAVPF <del> RFC5764, TCP/DTLS/RTP/SAVPF I-D.nandakumar-mmusic-proto-iana- registration, "UDP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp, and "TCP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp RTP profiles. </del> <ins> RFC5764, TCP/DTLS/RTP/SAVPF RFC7850, "UDP/DTLS/SCTP" I-D.ietf- mmusic-sctp-sdp, and "TCP/DTLS/SCTP" I-D.ietf-mmusic-sctp-sdp RTP profiles. </ins> RFC5245 MUST be implemented for signaling the ICE credentials and candidate lines corresponding to each media stream.  The ICE

Originally raised by Magnus: Section 5.1.1: R-2 [RFC5764] MUST be supported for signaling the UDP/TLS/RTP/SAVPF [RFC5764], TCP/DTLS/RTP/SAVPF [I-D.nandakumar-mmusic-proto-iana-registration], "UDP/DTLS/ SCTP" [I-D.ietf-mmusic-sctp-sdp], and "TCP/DTLS/SCTP" [I-D.ietf-mmusic-sctp-sdp] RTP profiles. I would note that [I-D.nandakumar-mmusic-proto-iana-registration] is actually published as RFC 7850. Section 5.1.1: R-12 [RFC5761] MUST be implemented to signal multiplexing of RTP and RTCP. This should include the updated as ref also.


Question: 3. QUIC version 2 endpoints MUST implement the QUIC version 1 <del> specification as described in QUIC, QUIC-TLS, and RFC9002, with the following changes. </del> <ins> specification as described in QUIC, QUIC-TLS, and RFC9002.  However, the following differences apply in version 2. </ins> 3.1. <del> The version field of long headers is 0x709a50c4. </del> <ins> The Version field of long headers is 0x709a50c4. </ins> 3.2. <del> Initial packets use a packet type field of 0b01. 0-RTT packets use a packet type field of 0b10.  Handshake packets use a packet type field of 0b11.  Retry packets use a packet type field of 0b00. </del> <ins> All version 2 long header packet types are different.  The Type field values are: Initial: 0b01 0-RTT: 0b10 Handshake: 0b11 Retry: 0b00 </ins> 3.3.

, , , , , .
Just a style thing (and something we should try an capture in a QUIC style guide).
There a bit of inconsistency through the document. Personally I prefer the QUIC version N style.
is there a missing word here?
Nope, extra word, thanks
I find this awkward to read in isolation, it requires converting the RFC 9000 types definition format into a different encoding to realize there is a change. A clearer alternative could be "All version 2 Long Packet Types are different: Initial: 0b01 0-RTT: 0b10 Handshake 0b11 Retry: 0b00
Starting with This might be a matter of style but to me the term "changes" imply that you're modifying the original, not creating something new. How about we term these as differences instead? The the opening paragraph of Section 3 could be something like "QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in ], ], and ]. However, the following differences apply in version 2."
This might have been important earlier in the document lifetime but it seems to stick out now.
This could be misread to imply the salt is universally known and universally applicable, which I don't think is your intention. In fact, I find the construction of this entire paragraph a bit awkward. Can we rephrase this for better clarity? Something like "In QUIC version 1, Initial packets are encrypted with the version-specific salt as described in Section 5.2 of [QUIC-TLS]. Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Clent Hello or Server Hello messages. Again, there is the potential for middleboxes to ossify on the 1 key derivation and packet formats."
Couple of nits but otherwise LGTM


Question: "encrypted_server_name" extension.  If the client does not retry in either scenario, it MUST report an error to the calling application. <ins> If the server sends a HelloRetryRequest in response to the ClientHello and the client can send a second updated ClientHello per the rules in RFC8446, the "encrypted_server_name" extension values which do not depend on the (possibly updated) ClientHello.KeyShareClientHello, i.e,, ClientEncryptedSNI.suite, ClientEncryptedSNI.key_share, and ClientEncryptedSNI.record_digest, MUST NOT change across ClientHello messages.  Moreover, ClientESNIInner.nonce and ClientESNIInner.realSNI MUST not change across ClientHello messages.  Informally, the values of all unencrypted extension information, as well as the inner extension plaintext, must be consistent between the first and second ClientHello messages. </ins> 5.1.3. When the server cannot decrypt or does not process the

NAME NAME please have a look.
We also need to specify server-side HRR behavior, right? Specifically, the server MUST recheck the second ClientHello's ESNI extension before sending the server certificate, otherwise putting the key share into the AD field doesn't really mean anything. The attacker would be able to do a cut-and-paste thing. (We could also incorporate the nonce into key schedule, but that upsets the document's split mode use case.)
Yep! Thanks for bringing that up. I'll prepare text.
Thank you for the text. LGTM.


Question: extension and MUST NOT use the retry keys. Offering a GREASE extension is not considered offering an encrypted <del> ClientHello for purposes of requirements in client-behavior.  In particular, the client MAY offer to resume sessions established without ECH. </del> <ins> ClientHello for purposes of requirements in real-ech.  In particular, the client MAY offer to resume sessions established without ECH. </ins> 7.

The overview was a bit long, and slightly inaccurate. The ClientHelloInner is encrypted after (most) of the ClientHelloOuter is constructed. I've also merged the ECH-naive server case with the ECH rejection case. This is more consistent with the client text, and most other TLS extensions, where we do not distinguish between reasons why the extension could not be negotiated. I've also generally tightened up the wording to make it shorter. As part of that, I'm trimmed the repeated list of sensitive ClientHello extensions. ECH itself is (mostly) agnostic to which extensions you believe are sensitive, and we already gave examples in the introduction.


Question: the "..[*]" and "..*" forms select all the descendants. <del> The resultant nodelist is ordered as if: </del> <ins> An </ins> <del> nodes are visited before their children, and </del> <ins> of the descendants of a node is a sequence of all the descendants in which: </ins> <del> nodes of an array are visited in array order. </del> <ins> nodes of any array appear in array order, </ins> <del> Children of an object may be visited in any order, since JSON objects are unordered. </del> <ins> nodes appear immediately before all their descendants. </ins> <del> Implementations may visit descendants in any way providing the resultant nodelist could have been produced by visiting descendants as above. </del> <ins> This definition does not stipulate the order in which the children of an object appear, since JSON objects are unordered. The resultant nodelist of a "descendant-selector" applied to a node must be a sub-sequence of an array-sequenced preorder of the descendants of the node. </ins> 3.5.7.3.

This is probably a bit too wordy, but is a starting point for a sharper definition of the nodelist orders which can be produced by the descendant selector. Ref: URL
I'm not sure of the context. Please could you point out particular lines. (The usual way to do this is to enter your review by clicking a "+" which appears when you hover the mouse pointer just to the left of a line in the "Files changed" tab of the PR. You can comment on a block of lines by clicking on the line number of the first line of the block and then shift-clicking on the line number of the last line of the block.) Meta comment: thanks for your review. I'm afraid it's non-binding. See on the mailing list.
I created local comments as requested per NAME Well, let us keep that discussion in that list maybe? Actually, Stefan Hagen's kind approvals are not binding, so I will await your approval, Carsten, or someone else's with the appropriate privileges. (I could give Stefan those privileges, but that seems wrong!) In fact, I'm puzzled over who can approve PRs (in a binding way). The repository settings list four people with direct access to the repo (see the attached screenshot), but then there are cabo, timbray, and probably some other users with binding PR approval privileges. I'm not sure how we arrived at this set of people. Maybe someone will remember... On Tue, 12 Jul 2022 at 20:16, Glyn Normington wrote:


Question: For example: <del> 3.8. </del> <ins> 3.9. </ins> TLS defines two generic alerts (see alert-protocol) to use upon failure to parse a message.  Peers which receive a message which

Variants is not a subsection of Constants; just have them all be subsections of same depth within Presentation Language URL


Question: 3. <del> Key importers mirror the concept of key exporters in TLS in that they diversify a key based on some contextual information before use in a connection.  In contrast to key exporters, wherein differentiation is done via an explicit label and context string, the key importer defined herein diversifies external one PSK into one or more PSKs for use via a target protocol, KDF identifier, and optional context string.  Additionally, the resulting PSK binder key is modified with a new derivation label to prevent confusion with non-imported PSKs. Imported keys do not require negotiation for use, as a client and server will not agree upon identities if not imported correctly. Endpoints may incrementally deploy PSK importer support by offering </del> <ins> The PSK Importer interface mirrors that of the TLS Exporters interface in that it diversifies a key based on some contextual information.  In contrast to the Exporters interface, wherein differentiation is done via an explicit label and context string, the PSK Importer interface defined herein takes an external PSK and identity and "imports" it into TLS, creating a set of "derived" PSKs and identities.  Each of these derived PSKs are bound a target protocol, KDF identifier, and optional context string.  Additionally, the resulting PSK binder keys are modified with a new derivation label to prevent confusion with non-imported PSKs. Imported keys do not require negotiation for use since a client and server will not agree upon identities if imported incorrectly. Endpoints may incrementally deploy PSK Importer support by offering </ins> non-imported keys for TLS versions prior to TLS 1.3.  Non-imported and imported PSKs are distinct since their identities are different on the wire.  See rollout for more details. <del> Clients which import external keys TLS MUST NOT use these keys for any other purpose.  Moreover, each external PSK MUST be associated with at most one hash function. </del> <ins> Clients which import external keys MUST NOT use either the external keys or the derived keys for any other purpose.  Moreover, each external PSK MUST be associated with at most one hash function, as per the rules in Section 4.2.11 from RFC8446.  See security- considerations for more discussion. </ins> 3.1.

This is mainly editorial, so there should be nothing surprising here. Please let me if that's not the case! It also includes clarifying text per NAME recommendation raised during WGLC. cc NAME NAME
From Rob Sayre: We should note the latter is a requirement from Section 4.2.11 of RFC8446. Let's also fix the typo "import external keys for TLS..."


Question: negotiating-connection-ids describes the use of this field in more detail. <ins> The remainder of the packet, if any, is type-specific. </ins> In this version of QUIC, the following packet types with the long header are defined:

Minor nit while looking at ; the definition of generic "Long-Header Packets" won't actually match any real packet types, because it ends after the CIDs. This modifies the definition to add a final "Type-Specific Payload" section to the figure.
While the transport draft talks a lot about "1-RTT packets", the term is not defined. We also have a sentence that seem to imply that a long-header variant of 1-RTT packets might exist (URL). We refer to the packet less frequently as "short header packets" or "packet with a short header." As a resolution, I think we might want to change the title of section 17.3 from "Short Header Packets" to "1-RTT Packets". Rest of the text can remain the same, as the first sentence of that section says that it is the only type of short header packet that we define.


Question: 4. <del> As discussed above, frames are carried on QUIC streams and used on control streams, request streams, and push streams.  This section describes HTTP framing in QUIC.  For a comparison with HTTP/2 frames, see h2-frames. </del> <ins> HTTP frames are carried on QUIC streams, as described in stream- mapping.  HTTP/3 defines three stream types: control stream, request stream, and push stream.  This section describes HTTP/3 frame formats and the streams types on which they are permitted; see stream-frame- mapping for an overiew.  A comparison between HTTP/2 and HTTP/3 frames is provided in h2-frames. </ins> 4.1.

So a friendly pointer to detail that could be easily misinterpreted or missed? It seems like a table footnote is required but I'm not sure how to do that in Markdown.
While each frame's description indicates the stream type(s) on which it is allowed, there isn't one unified place to indicate which frames are expected on which streams. QPACK subdivides the instruction space per stream, which has the nice property that you can't put something on the wrong stream. While that's overkill for H3 (too dramatic a departure from H2, multiple IANA registries, etc.), having a table to indicate which frames are permitted on which streams would be helpful.
I like the table idea for both. Want a PR?
Text always welcome.
I'll submit two PRs in next day or so.
Minor nit; otherwise good. Given that we have two frames that fall into this camp, might it be worth doing something like "(*) = only as the first frame"?