Question: TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two PSKs, one for HKDF-SHA256 and another for HKDF-SHA384.  In contrast, if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are <del> supported, only one derived key is necessary. </del> <ins> supported, only one derived key is necessary.  Each ciphersuite uniquely identifies the target KDF.  Future specifications that change the way the KDF is negotiated will need to update this specification to make clear how target KDFs are determined for the import process. </ins> EPSKs MAY be imported before the start of a connection if the target KDFs, protocols, and context string(s) are known a priori.  EPSKs MAY <del> also be imported for early data use if they are bound to protocol settings and configurations that would otherwise be required for early data with normal (ticket-based PSK) resumption.  Minimally, that means Application-Layer Protocol Negotiation RFC7301, QUIC transport parameters (if used for QUIC), and any other relevant parameters that are negotiated for early data MUST be provisioned alongside these EPSKs. </del> <ins> also be imported for early data use if they are bound to the protocol settings and configuration that are required for sending early data. Minimally, that means Application-Layer Protocol Negotiation value RFC7301, QUIC transport parameters (if used for QUIC), and any other relevant parameters that are negotiated for early data MUST be provisioned alongside these EPSKs. </ins> 4.2.

Minimally, that means Application-Layer Protocol Negotiation [RFC7301], QUIC RFC 8446 does not limit 0-RTT data to resumption, so I think we just want "if they are bound to the protocol settings and configuration that are required for sending early data". Also, nit: I think we usually refer to the "ALPN value" instead of just "ALPN" being configured. Section 5 If a client or server wish to deprecate a hash function and no longer use it for TLS 1.3, they remove the corresponding KDF from the set of target KDFs used for importing keys. This does not affect the KDF operation used to derive Imported PSKs. Should we also include a paragraph about how to deprecate the Hash used in deriving Imported PSKs? (It's fixed per EPSK, so, "configure a new EPSK", basically.) Section 6 Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK. Thus, an EPSK may be used with the same KDF (and underlying HMAC hash algorithm) as TLS 1.3 with importers. However, critically, the derived PSK will not be the same since the importer differentiates the PSK via the identity and target KDF and protocol. Thus, PSKs imported for TLS 1.3 are distinct from those used in TLS 1.2, and thereby avoid cross-protocol collisions. [...] As I read this I recalled that up in Section 1 we say that applications "SHOULD provision separate PSKs for TLS 1.3 and prior versions". The scenario being described here sounds like it can only occur if that SHOULD is ignored, which might be worth reiterating. We also say in § 4.1 that "external PSKs MUST NOT be imported for (D)TLS or prior versions". In light of these two observations, my best interpretation of the quoted text is that it should be equivalent to: NEW: Recall that TLS 1.2 permits computing the TLS PRF with any hash algorithm and PSK.


Question: TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two PSKs, one for HKDF-SHA256 and another for HKDF-SHA384.  In contrast, if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are <del> supported, only one derived key is necessary. </del> <ins> supported, only one derived key is necessary.  Each ciphersuite uniquely identifies the target KDF.  Future specifications that change the way the KDF is negotiated will need to update this specification to make clear how target KDFs are determined for the import process. </ins> EPSKs MAY be imported before the start of a connection if the target KDFs, protocols, and context string(s) are known a priori.  EPSKs MAY <del> also be imported for early data use if they are bound to protocol settings and configurations that would otherwise be required for early data with normal (ticket-based PSK) resumption.  Minimally, that means Application-Layer Protocol Negotiation RFC7301, QUIC transport parameters (if used for QUIC), and any other relevant parameters that are negotiated for early data MUST be provisioned alongside these EPSKs. </del> <ins> also be imported for early data use if they are bound to the protocol settings and configuration that are required for sending early data. Minimally, that means Application-Layer Protocol Negotiation value RFC7301, QUIC transport parameters (if used for QUIC), and any other relevant parameters that are negotiated for early data MUST be provisioned alongside these EPSKs. </ins> 4.2.

Accordingly, a given EPSK might be both used directly as a TLS 1.2 PSK and used with TLS 1.3 via the importer mechanism (noting that this configuration is not recommended, per Section 1), using the same KDF algorithm. However, because the TLS 1.3 importer mechanism includes an additional key-derivation step, the actual PSK used in the TLS 1.3 key schedule will be distinct from the one used in the TLS 1.2 key schedule, so there are no cross-protocol collisions possible. Note that this does not preclude endpoints from using non-imported PSKs for TLS 1.2. For some reason this line implies to me that endpoints might use imported PSKs for TLS 1.2, but this is forbidden by Section 4.1 (as quoted above). Perhaps "does not preclude endpoints from continuing to use TLS 1.2 and the non-imported PSKs it requires"? Section 7 We should probably note that any information placed in ImportedIdentity.context will be visible on the wire in cleartext, and thus that confidential identifiers from other protocols should either not be used or should be protected (e.g., by hashing) prior to use. Externally provisioned PSKs imported into a TLS connection achieve compound authentication of the provisioning process and connection. Context-free PSKs only achieve authentication within the context of a single connection. Do we need to use pskdhke to get the strong compound authentication property, or is it attainable with pskke as well? Section 10.1 I'm not sure why [QUIC] and RFC 5246 are listed as normative references. Appendix B The Selfie attack [Selfie] relies on a misuse of the PSK interface. The PSK interface makes the implicit assumption that each PSK is known only to one client and one server. If multiple clients or multiple servers with distinct roles share a PSK, TLS only authenticates the entire group. A node successfully authenticates its peer as being in the group whether the peer is another node or itself.


Question: TLS_AES_128_GCM_SHA256 and TLS_AES_256_GCM_SHA384 would yield two PSKs, one for HKDF-SHA256 and another for HKDF-SHA384.  In contrast, if TLS_AES_128_GCM_SHA256 and TLS_CHACHA20_POLY1305_SHA256 are <del> supported, only one derived key is necessary. </del> <ins> supported, only one derived key is necessary.  Each ciphersuite uniquely identifies the target KDF.  Future specifications that change the way the KDF is negotiated will need to update this specification to make clear how target KDFs are determined for the import process. </ins> EPSKs MAY be imported before the start of a connection if the target KDFs, protocols, and context string(s) are known a priori.  EPSKs MAY <del> also be imported for early data use if they are bound to protocol settings and configurations that would otherwise be required for early data with normal (ticket-based PSK) resumption.  Minimally, that means Application-Layer Protocol Negotiation RFC7301, QUIC transport parameters (if used for QUIC), and any other relevant parameters that are negotiated for early data MUST be provisioned alongside these EPSKs. </del> <ins> also be imported for early data use if they are bound to the protocol settings and configuration that are required for sending early data. Minimally, that means Application-Layer Protocol Negotiation value RFC7301, QUIC transport parameters (if used for QUIC), and any other relevant parameters that are negotiated for early data MUST be provisioned alongside these EPSKs. </ins> 4.2.

I think it may be useful to call out that the "multiple clients" and "multiple servers" case can occur even when there are only two endpoints that know the key (that is, when they do not have predetermined client/server roles). struct { opaque clientmac; opaque server_mac; } Context; We may not need the whole 16k to hold a MAC address, especially since this is just an example. If an attacker then redirects a ClientHello intended for one node to a different node, the receiver will compute a different context string and the handshake will not complete. Similarly to the above, this could be "a different node (including the node that generated the ClientHello)".


Question: 6.6. During the handshake, some packet protection keys might not be <del> available when a packet arrives.  In particular, Handshake and 0-RTT packets cannot be processed until the Initial packets arrive, and 1-RTT packets cannot be processed until the handshake completes. Endpoints MAY ignore the loss of Handshake, 0-RTT, and 1-RTT packets that might arrive before the peer has packet protection keys to process those packets. </del> <ins> available when a packet arrives and the receiver can choose to drop the packet.  In particular, Handshake and 0-RTT packets cannot be processed until the Initial packets arrive and 1-RTT packets cannot be processed until the handshake completes.  Endpoints MAY ignore the loss of Handshake, 0-RTT, and 1-RTT packets that might have arrived before the peer had packet protection keys to process those packets. Endpoints MUST NOT ignore the loss of packets that were sent after the earliest acknowledged packet in a given packet number space. </ins> 6.7.

Currently, the "Ignoring Loss of Undecryptable Packets" section indicates that some loss can be ignored, but now that we have multiple packet number spaces, I think we can constrain the set of ignorable losses to those below the smallest acknowledged packet in a packet number space. Ignoring the loss of a subsequently sent packet was not the intent.
I might have to put in a lint for HTAB...


Question: Connection racing: Happy Eyeballs V2 RFC8305 describes techniques for performing connection racing.  The Transport Services <del> Architecture implementation from I-D.ietf-taps-impl also describes how connections may race across interfaces and address families. In cases where clients have early data to send and want to minimize or avoid ticket re-use, unique tickets for each unique connection attempt are useful.  Moreover, as some servers may implement single-use tickets (and even session ticket encryption keys), distinct tickets will be needed to prevent premature ticket </del> <ins> Architecture implementation from TAPS also describes how connections may race across interfaces and address families.  In cases where clients have early data to send and want to minimize or avoid ticket re-use, unique tickets for each unique connection attempt are useful.  Moreover, as some servers may implement single-use tickets (and even session ticket encryption keys), distinct tickets will be needed to prevent premature ticket </ins> invalidation by racing. Connection priming: In some systems, connections may be primed or

Good catch -- will fix. Good suggestion! We can certainly add this. As the extension is merely a hint to servers when deciding how many tickets to vend, I think this is out of scope for the document. It's intended to be once per session, and we'll add that. Also a good catch. Like other extensions that are not affected by the possibly updated ClientHello, it must not change. We need to specify the server side behavior, too. That seems reasonable to me.
Thanks! Approved pending


Question: Verify the signature on the GroupInfo object.  The signature input comprises all of the fields in the GroupInfo object except the signature field.  The public key and algorithm are taken from the <del> credential in the leaf node of the member with LeafNodeRef "signer".  If there is no matching leaf node, or if signature verification fails, return an error. </del> <ins> credential in the leaf node of the ratchet tree with leaf index "signer".  If the node is blank or if signature verification fails, return an error. </ins> Verify the integrity of the ratchet tree.

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: Issuer portrayed in fig-overview can be instantiated and deployed in a number of ways.  This section covers some expected deployment models and their corresponding security and privacy considerations. <del> The discussion below assumes non-collusion between entities when operated by separate parties.  Mechanisms for enforcing non-collusion are out of scope for this architecture. </del> <ins> The discussion below assumes non-collusion between entities that have access to the attestation context and entities that have access to the redemption context, as collusion between such entities would enable linking of these contexts.  Generally, this means that entities operated by separate parties do not collude.  Mechanisms for enforcing non-collusion are out of scope for this architecture. </ins> 4.1.

This doesn't go overboard and clarify non-collusion assumptions for all models. It simply states the requirement that entities with access to the attestation context and redemption context do not collude, and then generalizes somewhat for simplicity. cc NAME NAME
The architecture assumes that any two parties do not collude with each other. I think this is too strong an assumption. In particular, if the Origin does not collude with anyone else, what is the point of unlinkability of the issuance and redemption flows? Looking at the use cases, it seems that where the Attester and Issuer are distinct there is a needed non-collusion assumption between them to achieve desirable privacy, but I think the origin colluding with one of the Issuer or Attester should be fine and would be worth considering in scope. Also, in addition to the non-collusion assumption, are there any other assumptions made on the parties, such as honest-but-curious, or do we consider them to be potentially fully malicious? It would be nice to spell this out.
If the Origin colluded with the Issuer it would learn the client's identity (presumably), which would be bad. Ultimately, the desired property is that any sort of collusion that would allow the redemption context to be linked to the attestation context is prohibited. I'll try to clarify.


Question: by applications, not the core protocol.  The table below is intended only to show the column layout of the registry. <del> 17.8. </del> <ins> 17.9. </ins> Specification Required RFC8126 registry requests are registered after a three-week review period on the MLS DEs' mailing list: mls-reg-

As discussed in the virtual interim 2022-12-16, it is possible that extensions might be tempted to re-use HPKE public keys created for MLS. Even within MLS, we have two different public-key encryption cases, Welcome and Commit (though these currently use different keys). Currently, for Commit encryption, the HPKE parameter is set to the group context. The content of is actually undefined for Welcome encryption (!) This PR makes the following changes: Define general and functions that populte the HPKE parameter with an encoded label and context Apply these to Commit and Welcome encryption: Commit: label="UpdatePathNode", context= Welcome: label="Welcome", context= Add an IANA registry of public-key encryption labels (as for signing) There is also a bit of reorganization of the Ciphersuites section to split it into three subsections.
Note that any previous analysis of MLS had to take this particular reuse into account. This can't be the case for any arbitrary extensions reusing the key. So if MLS uses an extension that reuses the key, none of the existing analysis applies, which is a much bigger issue. This said, this reuse did decrease security -- it weakened FS in that a joiner had to hold on to their HPKE leaf key, which also allowed to decrypt the init secret from the welcome message, long after joining.
I think this captures what we discussed during the interim. FWIW, I'm wondering if we didn't have a domain separation issue in the past when we only had one HPKE public key in KeyPackages and used it for both the Welcome subsequently for UpdatePath as well. Either way, I think this is a good defense-in-depth mechanism.


Question: 1. <del> The Datagram Transport Layer Security (DTLS) protocol was designed for securing connection-less transports, like UDP.  DTLS, like TLS, starts with a handshake, which can be computationally demanding (particularly when public key cryptography is used).  After a successful handshake, symmetric key cryptography is used to apply </del> <ins> The Datagram Transport Layer Security (DTLS) RFC6347 protocol was designed for securing connection-less transports, like UDP.  DTLS, like TLS, starts with a handshake, which can be computationally demanding (particularly when public key cryptography is used).  After a successful handshake, symmetric key cryptography is used to apply </ins> data origin authentication, integrity and confidentiality protection. This two-step approach allows endpoints to amortize the cost of the initial handshake across subsequent application data protection. Ideally, the second phase where application data is protected lasts <del> over a longer period of time since the established keys will only need to be updated once the key lifetime expires. </del> <ins> over a long period of time since the established keys will only need to be updated once the key lifetime expires. </ins> <del> In the current version of DTLS, the IP address and port of the peer </del> <ins> In DTLS as specified in RFC 6347, the IP address and port of the peer </ins> are used to identify the DTLS association.  Unfortunately, in some cases, such as NAT rebinding, these values are insufficient.  This is a particular issue in the Internet of Things when devices enter

This is supposed to all be editorial stuff, and I split a couple changes out into separate commits in case they're not actually desired.


Question: can send a CoAP Ping Signaling message (see sec-ping) to test the connection and verify that the CoAP server is responsive. <ins> When the underlying TCP connection is closed or reset, the signaling state and any observation state (see observe-cancel) associated with the reliable connection are removed.  In flight messages may or may not be lost. </ins> 4. CoAP over WebSockets is intentionally similar to CoAP over TCP;

1: It is not clear how the protocol reacts the errors from transport layers (e.g. connection failure). The protocol will just inform apps of the events and the app will decide what to do or the protocol itself will do something? The WebSockets case is addressed by RFC6455: -and- After review with the authors, we'll append a clarification for CoAP over TCP in its Connection Health section.


Question: migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. <del> 6.3. </del> <ins> 7.3. </ins> QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new

hopefully addresses issue
I don't think "the same port number as would be used for the same application over TCP" is necessary general-purpose guidance. I would argue for something more like:
Copying from URL There's no requirement that servers use a particular UDP port for HTTP/QUIC or any other QUIC traffic. Using Alt-Svc, the server is able to pick and advertise any port number and a compliant client will handle it just fine. That's already the case, and isn't part of this issue. updates the HTTP draft to highlight this, increasing the odds that implementations will test and support that case. This issue is to track that it might actually be desirable from a privacy standpoint for servers to pick arbitrary port numbers and perhaps even rotate them periodically (though that requires coordination with their Alt-Svc advertisements and lifetimes, which could be challenging) in order to make it more difficult for a network observer to classify traffic (and therefore more difficult to ossify). On the other hand, as we're wrestling with in each of these privacy/manageability debates, removing easy network visibility into the likely protocol by using arbitrary port numbers means that middleboxes will probably resort to other means of attempting to identify protocols and potentially doing it badly, which could result in even worse ossification. (E.g. indexing into the TLS ClientHello to find the ALPN list, then panicking on a different handshake protocol.) There's further discussion on the original issue, but this belongs in the ops drafts, not the protocol drafts.
this kind-of-but-not-really-duplicates , which I'll go ahead and close.
Actually, it's an exact duplicate, given that it points to the same issue. ;-) My bad.
NAME can you check if PR addresses this issue sufficiently? At least for the applicability doc...
Now also PR for the manageability statement.
and are a (ready for -03) treatment of this; however, we should consider if we want to say more, e.g. such as general guidance / recommendations for using ALPN in QUIC mappings, for instance? Keeping this open to track.
created new issue for ALPN


Question: connection SHOULD fail to allow the application to explicitly handle fallback to a less-secure alternative.  See fallback. <del> 10. </del> <ins> 11. </ins> This work is partially supported by the European Commission under Horizon 2020 grant agreement no. 688421 Measurement and Architecture


Question: the future and private curves can be used as well. contains the x coordinate for the EC point.  The integer is <del> converted to an octet string as defined in SEC1.  Zero octets MUST NOT be removed from the front of the octet string.  [CREF21] contains either the sign bit or the value of y coordinate for the EC point.  For the value, the integer is converted to an octet string as defined in SEC1.  Zero octets MUST NOT be removed from the front of the octet string.  For the sign bit, the value is true if the value of y is positive. </del> <ins> converted to an octet string use ???.  Note that the octet string represents a little-endian encoding of x.  [CREF21] </ins> contains the private key.

MTI Algorithm requirements Expand RSASSA-PSS section Correct one coordinate EC for endian Hint to get binary versions of examples Correct kid to binary in the examples (except for static public key one).


Question: during Connection establishment.  This Message can potentially be received multiple times (i.e., multiple copies of the message data may be passed to the Remote Endpoint).  See also msg- <del> safelyreplayable.  Note that disabling this property has no effect for protocols that are not connection-oriented and do not protect against duplicated messages, e.g., UDP. </del> <ins> safelyreplayable. </ins> 4.2.6.

The text says What does disabling mean? Does this mean mean that it is valid to set this property to "Prohibit" but still set "safelyReplayable" to "Require" on the PreConnection. Should that not be an error? This is also related to . The use of safelyReplayable for both reliable and unreliable services makes the text a bit confusing. Would it not be sufficient to state that if you do not Require Reliable Data Transfer you have to be prepared to deal with duplication?
We should remove this sentence in 4.2.5:


Question: provided.  Endpoints MUST NOT have more than one NewConnectionId message outstanding. <del> If the client and server have negotiated use of the "connection_id" extension, either side can request a new CID using the RequestConnectionId message.  In general, implementations SHOULD use a new CID whenever sending on a new path, and SHOULD request new CIDs for this purpose if path changes are anticipated. </del> <ins> Implementations which either did not negotiate the "connection_id" extension or which have negotiated receiving an empty CID MUST NOT send NewConnectionId.  Implementations MUST NOT send RequestConnectionId when sending an empty connection ID. Implementations which detect a violation of these rules MUST terminate the connection with an "unexpected_message" alert. Implementations SHOULD use a new CID whenever sending on a new path, and SHOULD request new CIDs for this purpose if path changes are anticipated. </ins> The number of CIDs desired.

It's possible to negotiate the CID extension but that you want to receive an empty CID (this is how you get asymmetrical CID lengths). The current text says: CID. If an implementation receives these messages when CIDs were not negotiated, it MUST abort the connection with an unexpected_message alert. But does this mean that (for instance) you can negotiate receiving an empty CID and then switch to a non-empty? I am tempted to say "no" as I recall QUIC did.
Doing what QUIC did seems prudent ... and if I didn't know what QUIC did I think I would also lean towards disallowing switching between empty and non-empty on a live connection.


Question: On receiving a PATH_CHALLENGE frame, an endpoint MUST respond by echoing the data contained in the PATH_CHALLENGE frame in a <del> PATH_RESPONSE frame.  An endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE frame unless constrained by congestion control. </del> <ins> PATH_RESPONSE frame.  A PATH_RESPONSE frame does not need to be sent on the network path where the PATH_CHALLENGE was received; a PATH_RESPONSE can be sent on any network path.  An endpoint MUST NOT delay transmission of a packet containing a PATH_RESPONSE frame unless constrained by congestion control. </ins> An endpoint MUST NOT send more than one PATH_RESPONSE frame in response to one PATH_CHALLENGE frame; see retransmission-of-

The original design for path validation attempted to validate return reachability by requiring that PATHRESPONSE followed the same path as PATHCHALLENGE. We removed that long ago, but the text retained echoes of that choice.
Currently, does not specify which path a PATHRESPONSE needs to be sent over. That was somewhat surprising to me, as I had expected it to be scoped to the path that PATHCHALLENGE was received on. If it isn't, could we add a sentence to the Path Validation Responses subsection to explicitly state that a PATH_RESPONSE is not scoped to a given path (and ideally explaining why it isn't)?
So I thought we were really crisp about this, but we were not. PATHRESPONSE does not need to follow the path on which PATHCHALLENGE was received. We're clear about this when it comes to preferred address handling, but there is some vestigial text that contradicts this. That should be fixed.
For the record, I personally believe that adequately resolves this issue while remaining purely editorial.
Thanks for being so prompt David. I will leave this for a bit to allow others a chance to spot errors, but I plan to merge this before we publish -30 (real soon now, I hope).
Yes, the requirement was removed but the inverse statement was never explicitly added. corrects that.
Thanks for writing this up, tiny wording suggestions, but looking great! Thanks for writing this up, I think this adequately resolves my concerns from .


Question: Cut and paste the CSR into a CA's web page. <del> Prove ownership of the domain by one of the following methods: </del> <ins> Prove ownership of the domain(s) in the CSR by one of the following methods: </ins> Put a CA-provided challenge at a specific place on the web server.

Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:


Question: appearing in cleartext in a ClientHello.  As a result, a passive adversary can link two or more connections together that use the same external PSK on the wire.  Applications should take precautions when <del> using external PSKs if these risks are a concern. </del> <ins> using external PSKs if these risks. </ins> In addition to linkability in the network, external PSKs are intrinsically linkable by PSK receivers.  Specifically, servers can

Changes to comments from Russ Housley on 03-Mar-2020
Section 3.1.1: The text says: C responds with to A. I think that C responds with a ServerHello to A. Section 3.1.2: The text says: A sends a ClientHello to B, without including a key share. It would be helpful to say "without including a key share extension." Section 3.1.3: I think a bit more explanation is needed here. Nonces can make the keys different, why doesn't the nonce from the uncompromised party help in this example? Section 4: I would like to see a bit more context here. I agree with the recommendations for the intended environment, but they are overkill in the environment suggested by draft-ietf-tls-tls13-cert-with-extern-psk. In fact, they are overkill if (EC)DH is combined with the PSK at all. So, maybe we just need to say that the PSK is not combined with a pairwise key that these rules apply.
Fixed by .
LGTM -- thanks, Russ!


Question: Let the group of peers who know the key be "A", "B", and "C".  The attack proceeds as follows: <del> "A" sends a "ClientHello" to "B", without including a key share. </del> <ins> "A" sends a "ClientHello" to "B", without including a key share extension. </ins> The handshake completes as expected.


Question: MUST be in the same order.  The leader's endpoint MUST be the first in the list.  The order of the "encrypted_input_shares" in a "Report" (see uploading-reports) MUST be the same as the order in <del> which aggregators appear in this list. </del> <ins> which aggregators appear in this list.  Aggregators MAY use the same endpoint for multiple tasks. </ins> "max_batch_lifetime": The maximum number of times a batch of reports may be used in collect requests.

All protocol request messages contain a field, which allows aggregators to service multiple tasks from a single set of endpoints. The exception is : since it is an HTTP GET request, there is no body, and thus no place for the client to indicate the desired to the aggregator. We don't want to introduce a request body to , because then it would have to be a POST instead of a GET, and that would make it harder for implementations to cache HPKE config values. So instead we have clients encode the task ID in RFC 4648 Base16 (a.k.a. hexadecimal) and provide it as a query parameter. See issue
My goal here is to enable our aggregator implementations in the interop target to use one HPKE config per task. The alternative to this would be for us to use aggregator endpoints that somehow incorporate the task ID, as I described , which is already permitted by the spec as written.
The Base64 alphabet includes , and , which means you have to URL encode (a.k.a. percent encode) Base64 strings before you can use them in a URL, which is a chore and yields less readable URLs (not that 64 character hex strings is especially user-friendly). An alternative would be to use RFC 4648's , omitting the padding characters as suggested in since task IDs are of a known length.
Gotcha. I think the main thing is to be consistent. I would either: Change this PR to use base64url; or Tack on a commit that makes all encodings of the taskID (except those that appear in the body, of course) the same (i.e., hexadecimal). I think (2.) would be my preference.
I agree with the consistency argument. I'm leaning towards using everywhere because it's more compact than Base16/hex, and also I think implementations are less likely to be surprised by case requirements in base64url (i.e., it's obvious that base64 is case sensitive, but you have to read RFC 4648 attentively to notice that it mandates uppercase hex strings).
Base64Url sounds good to me. I took a quick look and it appears that most standard base64 libraries also support the URL encoding.
I will clean this up and merge it once I have implemented it in Janus and convinced myself it's sound.
SGTM, but why not base64 encode the taskID for consistency with URL


Question: 17.6. <del> The "SignWithLabel" function defined in ciphersuites avoids the risk of confusion between signatures in different contexts.  Each context is assigned a distinct label that is incorporated into the signature. </del> <ins> The "SignWithLabel" function defined in signing avoids the risk of confusion between signatures in different contexts.  Each context is assigned a distinct label that is incorporated into the signature. </ins> This registry records the labels defined in this document, and allows additional labels to be registered in case extensions add other types of signature using the same signature keys used elsewhere in MLS.


Question: Media servers can provide media streams at various bitrates because the media has been encoded at various bitrates.  This is a so-called "ladder" of bitrates that can be offered to media players as part of <del> the manifest that describes the media being requested by the media player, so that the media player can select among the available </del> <ins> the manifest, so that the media player can select among the available </ins> bitrate choices. The media server may also choose to alter which bitrates are made

looks good.
From NAME
NAME and NAME - I'm not sure who wrote this text, except I don't think it was me. >And as with other parts of the ecosystem, new technology brings new challenges. For example, with the emergence of ultra-low-latency streaming, responses have to start streaming to the end user while still being transmitted to the cache, and while the cache does not yet know the size of the object. Some of the popular caching systems were designed around cache footprint and had deeply ingrained assumptions about knowing the size of objects that are being stored, so the change in design requirements in long-established systems caused some errors in production. Incidents occurred where a transmission error in the connection from the upstream source to the cache could result in the cache holding a truncated segment and transmitting it to the end user's device. In this case, players rendering the stream often had the video freeze until the player was reset. In some cases the truncated object was even cached that way and served later to other players as well, causing continued stalls at the same spot in the video for all players playing the segment delivered from that cache node. NAME was curious if there's a reasonable reference that we could provide for this.
Yeah, that was me. There was not a public reference for this, alas, just a word of mouth anecdote.
NAME - I agree with you about your comment on Section 3.6. It happens that I got comments that Section 3.6 and 3.7 didn't need to be nearly as detailed as they were, so they were heavily rewritten. The text where "throttled" was used is now in Section 3.6.1, and the emphasis is now on the cause of unexpected traffic profile changes, rather than the ISP response to the unexpected traffic profile changes in this specific incident, so the text that included "throttled" has been removed.
NAME - I agree with your comment on Section 4.4, that some description or reference should be provided for the word "manifest". The next occurrence of "manifest" is in Section 5.2, which does provide a description. I don't think that's quite right - I'd say So I'm changing this definition, and moving it to the first occurrence of "manifest" in Section 4.4. Thanks for helping us fix problems you didn't even tell us about. :upsidedownface:
lgtm


Question: lacking a "server_name" extension with a fatal "missing_extension" alert. <del> Some of these extensions exist only for the client to provide additional data to the server in a backwards-compatible way and thus have no meaning when sent from a server.  The client-only extensions defined in this document are: "signature_algorithms" & "supported_groups".  Servers MUST NOT send these extensions.  Clients receiving any of these extensions MUST respond with a fatal </del> <ins> Servers MUST NOT send the "signature_algorithms" extension; if a client receives this extension it MUST respond with a fatal </ins> "unsupported_extension" alert and close the connection. 9.

You'll also need to update the last paragraph of the MTI Extensions section (currently section 8.2). Now that we're going to be down to only one client-only extension defined in this document, that whole paragraph can probably be cut in favor of a one-off note in the remaining extension's section (signature_algorithms will be the last).
So that the clients can learn about what groups a server supports. The idea here is to allow a client to offer P256 but then learn that a server supports 25519 for next time without the server having to reject.


Question: below). The client specifies the cryptographic configuration for the 0-RTT <del> data using the "configuration", "cipher_suite", and "extensions" </del> <ins> data using the "configuration_id", "cipher_suite", and "extensions" </ins> values.  For configurations received in-band (in a previous TLS connection) the client MUST:

The text & struct have different names for the config ID. Use the one in the struct.


Question: Any identifier of type "dns" in a new-order request MAY have a wildcard domain name as its value.  A wildcard domain name consists of a single asterisk character followed by a single full stop <del> character ("_.") followed by a domain name as defined for use in the Subject Alternate Name Extension by RFC 5280 . An authorization returned by the server for a wildcard domain name identifier MUST NOT include the asterisk and full stop ("_RFC5280.") prefix in the authorization identifier value. </del> <ins> character ("*.") followed by a domain name as defined for use in the Subject Alternate Name Extension by RFC 5280 RFC5280.  An authorization returned by the server for a wildcard domain name identifier MUST NOT include the asterisk and full stop ("*.") prefix in the authorization identifier value. </ins> The elements of the "authorizations" and "identifiers" array are immutable once set.  The server MUST NOT change the contents either

Prior to this commit the literal string "." was being rendered as the start of italics in the generated HTML doc. This commit updates the markup to escape the "*."` in the generated document. Originally reported by Joel Sing - thanks!


Question: the fact that there are applications using HTTP/3 datagrams enabled on this endpoint. <del> 10. 10.1. This document will request IANA to register the following entry in the "HTTP/3 Frames" registry: </del> <ins> 9. </ins> <del> 10.2. </del> <ins> 9.1. </ins> This document will request IANA to register the following entry in the "HTTP/3 Settings" registry: <del> 10.3. </del> <ins> 9.2. </ins> This document establishes a registry for HTTP capsule type codes. The "HTTP Capsule Types" registry governs a 62-bit space.

Had offline conversation with Lucas, conclusion was that this is good enough to merge to allow interop - we'll have plenty of time to figure out details in subsequent issues and PRs.


Question: e.g., public key cryptographic operations, avoiding waste is desirable. <ins> Decline resumption: Clients may indicate they have no intention of resuming connections by sending a ticket request with count of zero. </ins> 3. <del> Clients may indicate to servers their desired number of tickets via the following "ticket_request" extension: </del> <ins> Clients may indicate to servers their desired number of tickets for a single connection via the following "ticket_request" extension: </ins> Clients may send this extension in ClientHello.  It contains the following structure:

Good catch -- will fix. Good suggestion! We can certainly add this. As the extension is merely a hint to servers when deciding how many tickets to vend, I think this is out of scope for the document. It's intended to be once per session, and we'll add that. Also a good catch. Like other extensions that are not affected by the possibly updated ClientHello, it must not change. We need to specify the server side behavior, too. That seems reasonable to me.
Thanks! Approved pending


Question: for detailing what kinds of information are disclosed, and to whom they are exposed. <del> 10. </del> 11. <ins> 12. </ins> This document does not require any actions by IANA. <del> 12. </del> <ins> 13. </ins> Special thanks go to David Wooten, Joerg Borchert, Hannes Tschofenig, Laurence Lundblade, Diego Lopez, Jessica Fitzgerald-McKay, Frank Xia,

Here's a first attempt to combine terminology sections, and trust model. Includes new terms Endorser and Appraisal Policy per recent discussion. Signed-off-by: Dave Thaler
Done
Done. (But if you have feedback on a sentence like this in the future, please attach the comment directly to the code line under the "Files changed" tab, to make it easy to find which phrase you're referring to.)
Done
Updated. How about now?
I would like to discuss the possibility of combining the terms "Endorsement" and "Attestation Result". Just like we have an Appraisal Policy for a verifier and an Appraisal Policy for a relying party, some might view an Attestation Result as an Endorsement for use by the relying party. I'm ok either way, but wanted to discuss this in our next call to see if others think it would help or confuse things.
I still believe my original definition of Attestation is good, I haven't seen any comments here about what the problem was. For comparison, URL says it's "The process of validating the integrity of a computing device such as a server needed for trusted computing.". I'm also ok with that definition.
I’m OK with that wording for introducing the concept. It may break down if the terminology for ‘device’ and ‘trusted computing’ become overly specified / specific.
The word 'health' is generally being used where other words such as 'trustworthiness', or 'state' could be used. I'm concerned that 'health' might not easily be synonymous with 'trust'. It also seems to bias the architecture toward NEA (RFC5209) which IMO does not define attestation.


Question: elapsed time between the acknowledgements for specific TCP segments from a TCP receiver since TCP octet sequence numbers and acknowledgements for those sequence numbers are carried in the clear, <del> even if the TCP payload itself is encrypted.  See tcp-behavior for more information. </del> <ins> even if the TCP payload itself is encrypted.  See reliable-behavior for more information. </ins> As transport protocols evolve to encrypt their transport header fields, one side effect of increasing encryption is the kind of passive monitoring, or even "performance enhancement" (RFC3135) that was possible with the older transport protocols (UDP, described in <del> udp-behavior and TCP, described in tcp-behavior) is no longer possible with newer transport protocols such as QUIC (described in quic-behavior).  The IETF has specified a "latency spin bit" mechanism in Section 17.4 of RFC9000 to allow passive latency </del> <ins> unreliable-behavior and TCP, described in reliable-behavior) is no longer possible with newer transport protocols such as QUIC (described in quic-behavior).  The IETF has specified a "latency spin bit" mechanism in Section 17.4 of RFC9000 to allow passive latency </ins> monitoring from observation points on the network path throughout the duration of a connection, but currently chartered work in the IETF is focusing on endpoint monitoring and reporting, rather than on passive

…transport protocols Also tighten up description of the assumed protocol stack in (what is now) Section 6.1. Note that the UDP and TCP sections have been flipped in order, to improve section flow and clarity.
NAME - If you have a moment before our call on Friday to take a look at this PR, I'd appreciate it. I think it's important to to get that right, in order to address both the INTDIR and TSVART reviews.
From NAME As a bit of transport commentary, I don't find the setup of Section 6 compelling. While UDP is a transport in a technical sense, for the purpose of media, it is almost always a layer upon which the protocol doing the congestion control work runs. To that end, QUIC is just another more standardized case of this, just like SCTP over UDP. Rather than talking about "UDP's behavior" vs "TCP's behavior", I suggest talking about how applications over UDP for media behave vs applications over TCP for media behave.
NAME - I need to look at this more closely. I understand your point about UDP, but (because UDP is not a real transport layer, while TCP and QUIC are), I suspect (without looking closely yet) I'm going to be making sure that I explain this more clearly, without trying to explain the behavior(s) of applications running over TCP and QUIC. As an aside, I'm trying to make this clearer in drafts I'm targeting forwards Media Over QUIC/MOQ, so I actually DO believe you ... Please await results.
A +1 from NAME 's review (URL): Section 6. Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. TCP vs. QUIC is actually the relevant distinction. What may actually matter are the transport services provided by the protocol stack (e.g., RFC 8095). I fully agree to a related comment in the INTDIR review.
After looking at this issue. I agree with both NAME and NAME that the emphasis should be on the interaction between (see new section describing this) media transport protocols and the transport services provided by underlying transport protocols. I'm moving the formerly-UDP section below the formerly-TCP section, because it's easier to describe what UDP is NOT doing after describing what TCP IS doing.


Question: elapsed time between the acknowledgements for specific TCP segments from a TCP receiver since TCP octet sequence numbers and acknowledgements for those sequence numbers are carried in the clear, <del> even if the TCP payload itself is encrypted.  See tcp-behavior for more information. </del> <ins> even if the TCP payload itself is encrypted.  See reliable-behavior for more information. </ins> As transport protocols evolve to encrypt their transport header fields, one side effect of increasing encryption is the kind of passive monitoring, or even "performance enhancement" (RFC3135) that was possible with the older transport protocols (UDP, described in <del> udp-behavior and TCP, described in tcp-behavior) is no longer possible with newer transport protocols such as QUIC (described in quic-behavior).  The IETF has specified a "latency spin bit" mechanism in Section 17.4 of RFC9000 to allow passive latency </del> <ins> unreliable-behavior and TCP, described in reliable-behavior) is no longer possible with newer transport protocols such as QUIC (described in quic-behavior).  The IETF has specified a "latency spin bit" mechanism in Section 17.4 of RFC9000 to allow passive latency </ins> monitoring from observation points on the network path throughout the duration of a connection, but currently chartered work in the IETF is focusing on endpoint monitoring and reporting, rather than on passive

I'm also moving one paragraph into the formerly-TCP section from Section 6, because it is specific to ABR strategies that assume a reliable transport. More news to come, when I create a PR for this issue ...
We think is now mergrable. Reviewer: Michael Scharf Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC EMAIL if you reply to or forward this review. This informational document surveys network and transport protocol issues that affect quality of experience for streaming applications, in particular video. The overview covers many topics across different technologies. Readers may only be familiar with a subset of these topics and could therefore learn quite a bit from this kind of tutorial. Nonetheless, it remains somewhat unclear what the actual objective of some of the text is. For some topics, quite a bit of technical background is provided, but the discussion is not really comprehensive. In many sections, the document neither derives technical challenges, nor system/protocol requirements, nor practical usage guidance. It is just a kind of tutorial. Quite a bit of text also presents ongoing IETF work, and an RFC with this scope may thus get outdated soon. Section 6.2 deals with topics owned by TCPM. In similar past documents, I have asked for a TCPM presentation prior to an IETF last call in order to ensure that owners of running code are in the loop. I believe this strategy has worked well in the past. Having said this, as TSV-ART reviewer I don't strongly disagree with a publication. All these issues may just be OK for an informational RFC. Some more specific comments: Section 3.2.1. Recognizing Changes from an Expected Baseline This section apparently assumes relatively static path properties, e.g., fixed network connectivity. It would be more useful to analyze the impact of Wifi and 4G/5G networks in one place.


Question: elapsed time between the acknowledgements for specific TCP segments from a TCP receiver since TCP octet sequence numbers and acknowledgements for those sequence numbers are carried in the clear, <del> even if the TCP payload itself is encrypted.  See tcp-behavior for more information. </del> <ins> even if the TCP payload itself is encrypted.  See reliable-behavior for more information. </ins> As transport protocols evolve to encrypt their transport header fields, one side effect of increasing encryption is the kind of passive monitoring, or even "performance enhancement" (RFC3135) that was possible with the older transport protocols (UDP, described in <del> udp-behavior and TCP, described in tcp-behavior) is no longer possible with newer transport protocols such as QUIC (described in quic-behavior).  The IETF has specified a "latency spin bit" mechanism in Section 17.4 of RFC9000 to allow passive latency </del> <ins> unreliable-behavior and TCP, described in reliable-behavior) is no longer possible with newer transport protocols such as QUIC (described in quic-behavior).  The IETF has specified a "latency spin bit" mechanism in Section 17.4 of RFC9000 to allow passive latency </ins> monitoring from observation points on the network path throughout the duration of a connection, but currently chartered work in the IETF is focusing on endpoint monitoring and reporting, rather than on passive

Some of this follows later in sections 3.2.1 and Yet, the split between these three sections is unclear. Having a discussion about today's Internet path characteristics and the dynamics at one place could be more useful. The text could also better distinguish between what matters to endpoints and considerations relevant only for middleboxes (such as passive monitors). Section 3.3 Path Requirements The statement "to find the bandwidth requirements for a router on the delivery path" may assume that the bottleneck on the path will be routers. Yet, on a path the bottlenecks could also be a link layer device (e.g., an Ethernet Switch, a Wifi access point, etc.). RFC 6077 (specifically Section 3.1.3) also explains that issue. A better wording may be "to find the bandwidth requirements for a delivery path". Section 3.6. Unpredictable Usage Profiles / Section 3.7. Extremely Unpredictable Usage Profiles I am not fully convinced by the distinction between "unpredictable" and "extremely unpredictable". To me, these two sections could be merged and maybe also be shortened. More specifically, Section 3.7 lists a lot of statistics from the past. What is IMHO a bit missing in Section 3.7 are actual operational considerations. For instance, are there any lessons learnt for the future? Note that Section 3.6 has a reasonable conclusion at the end. Section 4. Latency Considerations and Section 4.1. Ultra Low-Latency I am surprised by the definition "ultra low-latency (less than 1 second)", as well as some of the other numbers. For other real-time communication use cases, "ultra low-latency" would probably imply a latency requirement of the order of one millisecond. For instance, isochronous traffic for motion control in industrial networks may require a latency of 1 ms, and such "ultra-low latency" requirements are discussed elsewhere, e.g., in the DetNet WG. The terminology in this section should be better explained to readers dealing with networked systems with much harder latency requirements. And a reference should be added for these definitions in the context of video streaming.


Question: elapsed time between the acknowledgements for specific TCP segments from a TCP receiver since TCP octet sequence numbers and acknowledgements for those sequence numbers are carried in the clear, <del> even if the TCP payload itself is encrypted.  See tcp-behavior for more information. </del> <ins> even if the TCP payload itself is encrypted.  See reliable-behavior for more information. </ins> As transport protocols evolve to encrypt their transport header fields, one side effect of increasing encryption is the kind of passive monitoring, or even "performance enhancement" (RFC3135) that was possible with the older transport protocols (UDP, described in <del> udp-behavior and TCP, described in tcp-behavior) is no longer possible with newer transport protocols such as QUIC (described in quic-behavior).  The IETF has specified a "latency spin bit" mechanism in Section 17.4 of RFC9000 to allow passive latency </del> <ins> unreliable-behavior and TCP, described in reliable-behavior) is no longer possible with newer transport protocols such as QUIC (described in quic-behavior).  The IETF has specified a "latency spin bit" mechanism in Section 17.4 of RFC9000 to allow passive latency </ins> monitoring from observation points on the network path throughout the duration of a connection, but currently chartered work in the IETF is focusing on endpoint monitoring and reporting, rather than on passive

Section 5.5.2 Head-of-Line Blocking If Head-of-Line Blocking is indeed a relevant operational problem, it would be useful to add a corresponding reference (e.g., with measurements). Section 5.5.3. Wide and Rapid Variation in Path Capacity The statement "As many end devices have moved to wireless connectivity for the final hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have emerged from radio interference and signal strength effects." could be moved to earlier parts of the document. Quite a bit of new computers apparently only have Wifi connectivity and no Ethernet port, i.e., Wifi may just be their default. Also, wireless may not only be used on the last hop, for instance in meshed setups. This may make the problem even harder. Section 6. Evolution of Transport Protocols and Transport Protocol Behaviors I really wonder whether UDP vs. TCP vs. QUIC is actually the relevant distinction. What may actually matter are the transport services provided by the protocol stack (e.g., RFC 8095). I fully agree to a related comment in the INTDIR review. Section 6.1. UDP and Its Behavior UDP is also used for encrypted tunnels (OpenVPN, Wireguard, etc.). Does encrypted tunneling really have no operational impact on streaming apps other than circuit breakers? (I am thinking about 4K streaming over OpenVPN and the like.) Section 6.2. TCP and Its Behavior This text should IMHO be presented and be discussed in TCPM. Personally, I am not convinced that this document is a good place for discussing the long history of TCP congestion control. If the objective of the document is to provide a tutorial, IMHO it would be more useful to briefly explain the state-of-the-art in year 2022. Some further specific comments on TCP congestion control: It is surprising that RFC 5681 is not referenced.793bis has normative statements regarding congestion control, and most stacks are compatible to what is written in 793bis. Several operating systems use CUBIC by default and support standard Reno. Another general good reference for TCP standards is RFC 7414.Does ECN, DCTCP, etc. really not matter at all, for instance, if a data center hosts video playout servers?


Question: elapsed time between the acknowledgements for specific TCP segments from a TCP receiver since TCP octet sequence numbers and acknowledgements for those sequence numbers are carried in the clear, <del> even if the TCP payload itself is encrypted.  See tcp-behavior for more information. </del> <ins> even if the TCP payload itself is encrypted.  See reliable-behavior for more information. </ins> As transport protocols evolve to encrypt their transport header fields, one side effect of increasing encryption is the kind of passive monitoring, or even "performance enhancement" (RFC3135) that was possible with the older transport protocols (UDP, described in <del> udp-behavior and TCP, described in tcp-behavior) is no longer possible with newer transport protocols such as QUIC (described in quic-behavior).  The IETF has specified a "latency spin bit" mechanism in Section 17.4 of RFC9000 to allow passive latency </del> <ins> unreliable-behavior and TCP, described in reliable-behavior) is no longer possible with newer transport protocols such as QUIC (described in quic-behavior).  The IETF has specified a "latency spin bit" mechanism in Section 17.4 of RFC9000 to allow passive latency </ins> monitoring from observation points on the network path throughout the duration of a connection, but currently chartered work in the IETF is focusing on endpoint monitoring and reporting, rather than on passive

Section 6.3. QUIC and Its Behavior As already noted, the discussion about head-of-line-blocking would really benefit from backing by a reference. Section 7. Streaming Encrypted Media As far as I know, streaming users sometimes use encrypted tunnels such as OpenVPN or WireGuard (or IPsec) to access video content. I may miss something, but it is unclear to me how that fits into the categories presented in Section


Question: Add "post_handshake_auth" extension to negotiate post-handshake authentication (*). <ins> Shorten labels for HKDF-Expand-Label so that we can fit within one compression block (*). </ins> draft-19 Hash context_value input to Exporters (*)

Per mailing list discussion, this allows us to have every HKDF-Expand just have one hash block of info. NAME would love your feedback.
Shouldn't "TLS 1.3, " be shortened to "tls13 "? Without that, several of the labels would seem to blow blocks. Also, "derived secret" seems unchanged, and is too long to fit into a block, even with "tls13 " prefix.
Oops. Good catch. Script fail.
NAME fixed?
Yeah, I'll add a note. I still have an issue for the ChangeLog so I will add this as well
Also, minimum label size looks to be still 10, presumably should be 7 with 6-byte prefix (as it 10 with 9-byte prefix).


Question: Non-exportable: CurveCP <del> 5.3. Record interfaces are the points of interaction between a record protocol and the application, handshake protocol, and transport once in use. Pre-Shared Key Import Either the handshake protocol or the application directly can supply pre-shared keys for the record protocol use for encryption/ decryption and authentication.  If the application can supply keys directly, this is considered explicit import; if the handshake protocol traditionally provides the keys directly, it is considered direct import; if the keys can only be shared by the handshake, they are considered non-importable. Explict import: QUIC, ESP Direct import: TLS, DTLS, MinimalT, tcpcrypt, WireGuard Non-importable: CurveCP Encrypt application data The application can send data to the record protocol to encrypt it into a format that can be sent on the underlying transport.  The encryption step may require that the application data is treated as a stream or as datagrams, and that the transport to send the encrypted records present a stream or datagram interface. Stream-to-Stream Protocols: TLS, tcpcrypt Datagram-to-Datagram Protocols: DTLS, ESP, SRTP, WireGuard Stream-to-Datagram Protocols: QUIC ((Editor's Note: This depends on the interface QUIC exposes to applications.)) Decrypt application data The application can receive data from its transport to be decrypted using record protocol.  The decryption step may require that the incoming transport data is presented as a stream or as datagrams, and that the resulting application data is a stream or datagrams. Stream-to-Stream Protocols: TLS, tcpcrypt Datagram-to-Datagram Protocols: DTLS, ESP, SRTP, WireGuard Datagram-to-Stream Protocols: QUIC ((Editor's Note: This depends on the interface QUIC exposes to applications.)) </del> Key Expiration The record protocol can signal that its keys are expiring due to reaching a time-based deadline, or a use-based deadline (number of

…/security and security/transport dependencies.
NAME can you please take a look before Wednesday?
Yep, I will review Monday morning.
I think this is fine. We can do further tweaks in subsequent PRs.


Question: This document will request IANA to register "connect-udp" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <ins> 8.2. This document will request IANA to register "masque/udp" in the Well- Known URIs Registry maintained at <<https://www.iana.org/assignments/ well-known-uris/well-known-uris.xhtml>>. </ins>

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: This document will request IANA to register "connect-udp" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <ins> 8.2. This document will request IANA to register "masque/udp" in the Well- Known URIs Registry maintained at <<https://www.iana.org/assignments/ well-known-uris/well-known-uris.xhtml>>. </ins>

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: This document will request IANA to register "connect-udp" in the HTTP Upgrade Token Registry maintained at <<https://www.iana.org/assignments/http-upgrade-tokens>>. <ins> 8.2. This document will request IANA to register "masque/udp" in the Well- Known URIs Registry maintained at <<https://www.iana.org/assignments/ well-known-uris/well-known-uris.xhtml>>. </ins>

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: The QUIC transport protocol (QUIC-TRANSPORT) is designed to support HTTP semantics, and its design subsumes many of the features of <del> HTTP/2 (RFC7540).  HTTP/2 uses HPACK (RFC7541) for compression of the header and trailer sections.  If HPACK were used for HTTP/3 (HTTP3), it would induce head-of-line blocking for field sections due to built-in assumptions of a total ordering across frames on all </del> <ins> HTTP/2 (RFC9113).  HTTP/2 uses HPACK (RFC7541) for compression of the header and trailer sections.  If HPACK were used for HTTP/3 (RFC9114), it would induce head-of-line blocking for field sections due to built-in assumptions of a total ordering across frames on all </ins> streams. QPACK reuses core concepts from HPACK, but is redesigned to allow

These track corrections I've asked the RFC Editor to make directly in their copy prior to publication. It appears that some http-core sections moved since the last time we did a full sweep of our references.


Question: it describes what is and is not possible with the QUIC transport protocol as defined. <ins> This document focuses solely on network management practices that observe traffic on the wire.  Replacement of troubleshooting based on observation with active measurement techniques, for example, is therefore out of scope.  A more generalized treatment of network management operations on encrypted transports is given in RFC9065. </ins> QUIC-specific terminology used in this document is defined in QUIC- TRANSPORT.

hi NAME NAME NAME PTAnotherL, reviewed the thread and I do think an additional 9065 ref here would be helpful.


Question: 4.2.3. <del> The ROUTE_ADVERTISEMENT capsule allows an endpoint to communicate to its peer that it is willing to route traffic to a given prefix.  This indicates that the sender has an existing route to the prefix, and notifies its peer that if the receiver of the ROUTE_ADVERTISEMENT capsule sends IP packets for this prefix in HTTP Datagrams, the sender of the capsule will forward them along its preexisting route. This capsule uses a Capsule Type of 0xfff102.  Its value uses the following format: </del> <ins> The ROUTE_ADVERTISEMENT capsule (see iana-types for the value of the capsule type) allows an endpoint to communicate to its peer that it is willing to route traffic to a set of IP address ranges.  This indicates that the sender has an existing route to each address range, and notifies its peer that if the receiver of the ROUTE_ADVERTISEMENT capsule sends IP packets for one of these ranges in HTTP Datagrams, the sender of the capsule will forward them along its preexisting route.  Any address which is in one of the address ranges can be used as the destination address on IP packets originated by the receiver of this capsule. </ins> <del> IP Version of this route advertisement.  MUST be either 4 or 6. </del> <ins> The ROUTE_ADVERTISEMENT capsule contains a sequence of IP Address Ranges. </ins> <del> IP address of the advertised route.  If the IP Version field has value 4, the IP Address field SHALL have a length of 32 bits.  If the IP Version field has value 6, the IP Address field SHALL have a length of 128 bits. </del> <ins> IP Version of this range.  MUST be either 4 or 6. </ins> <del> The number of bits in the IP Address that are used to define the prefix of the advertised route.  This MUST be lesser or equal to the length of the IP Address field, in bits.  If the prefix length is equal to the length of the IP Address, this route only allows sending packets to a single destination address.  If the prefix length is less than the length of the IP address, this route allows sending packets to any destination address that falls within the prefix. </del> <ins> Inclusive start and end IP address of the advertised range.  If the IP Version field has value 4, these fields SHALL have a length of 32 bits.  If the IP Version field has value 6, these fields SHALL have a length of 128 bits.  The Start IP Address MUST be strictly lesser than the End IP Address. </ins> The Internet Protocol Number for traffic that can be sent to this <del> prefix.  If the value is 0, all protocols are allowed. </del> <ins> range.  If the value is 0, all protocols are allowed. </ins> Upon receiving the ROUTE_ADVERTISEMENT capsule, an endpoint MAY start <del> routing IP packets in that prefix to its peer. If an endpoint receives multiple ROUTE_ADVERTISEMENT capsules, all of the advertised routes can be used.  For example, multiple ROUTE_ADVERTISEMENT capsules are necessary to provide routing to both IPv4 and IPv6 hosts.  Routes are removed using ROUTE_WITHDRAWAL capsules. </del> <ins> routing IP packets in these ranges to its peer. </ins> <del> 4.2.4. </del> <ins> Each ROUTE_ADVERTISEMENT contains the full list of address ranges. If multiple ROUTE_ADVERTISEMENT capsules are sent in one direction, each ROUTE_ADVERTISEMENT capsule supersedes prior ones.  In other words, if a given address range was present in a prior capsule but the most recently received ROUTE_ADVERTISEMENT capsule does not contain it, the receiver will consider that range withdrawn. </ins> <del> The ROUTE_WITHDRAWAL capsule allows an endpoint to communicate to its peer that it is not willing to route traffic to a given prefix.  This capsule uses a Capsule Type of 0xfff103.  Its value uses the following format: </del> <ins> If multiple ranges using the same IP protocol were to overlap, some routing table implementations might reject them.  To prevent overlap, the ranges are ordered; this places the burden on the sender and makes verification by the receiver much simpler.  If an IP Address Range A precedes an IP address range B in the same ROUTE_ADVERTISEMENT capsule, they MUST follow these requirements: </ins> <del> IP Version of this route withdrawal.  MUST be either 4 or 6. IP address of the withdrawn route.  If the IP Version field has value 4, the IP Address field SHALL have a length of 32 bits.  If the IP Version field has value 6, the IP Address field SHALL have a length of 128 bits. The number of bits in the IP Address that are used to define the prefix of the withdrawn route.  This MUST be lesser or equal to the length of the IP Address field, in bits. </del> <ins> IP Version of A MUST be lesser or equal than IP Version of B </ins> <del> The Internet Protocol Number for traffic for this route.  If the value is 0, all protocols are withdrawn for this prefix. </del> <ins> If the IP Version of A and B are equal, the IP Protocol of A MUST be lesser or equal than IP Protocol of B. </ins> <del> Upon receiving the ROUTE_WITHDRAWAL capsule, an endpoint MUST stop routing IP packets in that prefix to its peer.  Note that this capsule can be reordered with DATAGRAM frames, and therefore an endpoint that receives packets for routes it has rejected MUST NOT treat that as an error. </del> <ins> If the IP Version and IP Protocol of A and B are both equal, the End IP Address of A MUST be strictly lesser than the Start IP Address of B. </ins> <del> ROUTE_ADVERTISEMENT and ROUTE_WITHDRAWAL capsules are applied in order of receipt: if a prefix is covered by multiple received ROUTE_ADVERTISEMENT and/or ROUTE_WITHDRAWAL capsules, only the last received capsule applies as it supersedes prior ROUTE_ADVERTISEMENT and ROUTE_WITHDRAWAL capsules for this prefix. </del> <ins> If an endpoint received a ROUTE_ADVERTISEMENT capsule that does not meet these requirements, it MUST abort the stream. </ins> 5.

This PR is one potential way to It simplifies route exchanges by going with NAME 's suggestion of sending the entire routing table each time something changes. It could be somewhat inefficient in some cases, but it becomes easier to reason about than what's currently in the draft when overlapping prefixes are involved.
This is interesting, but I'd prefer to wait to do this until after we post a -00 version. NAME is that OK with you?
I'd prefer we figure this out before -00, because this would be a pretty significant non-compatible change and I'd like to implement -00
NAME you nearly convinced me in the call that we rather want to announce ranges separately but I forgot why. Can you outline your reasoning again?
NAME my argument was that we shouldn't have two different ways to set routes, one that gives a table and one that gives a single route. If we go to only have a table, then it's fine.
I know saw the discussion in and support this approach. Also if we agree on this approach, I also think we should merge it before we submit -00
NAME I think we're ready to merge this PR
As discussed in , turning a sequence of ROUTEADVERTISEMENT and ROUTEWITHDRAWAL capsules into a functional routing table isn't as simple as initially expected. This is because two separate capsules can describe prefixes that are distinct but overlap. We should simplify the design or better explain the caveats.
I think this looks good enough to include in the -00.


Question: This is necessary to allow the discovery of pledges by the registrar- agent using mDNS.  The list may be provided by administrative means or the registrar agent may get the information via an interaction <del> with the pledge, like scanning of product-serial-number information using a QR code or similar. </del> <ins> with the pledge.  For instance, RFC9238 describes scanning of a QR code, the product-serial-number would be initialized from the 12N B005 Product Serial Number. </ins> According to RFC8995 section 5.3, the domain registrar performs the pledge authorization for bootstrapping within his domain based on the

Included in the text. Maybe will include further text for
In 5.5.1: This kind of suggests that an Agent may also not know the serial number. But in creating the agent-signed-data, this number is required later on. Could we clarify perhaps the Agent MUST know the serial-number; e.g. in one of these ways: configured (as in quoted text above) discovered (in "standard" way using mDNS / DNS-SD first part of service instance name) discovered (in vendor-specific way e.g. RF beacons) other (in vendor-specific way, e.g. scan QR code of packaging) - maybe that's the same as category 1 from the Agent point of view.
Additional Note: figure 4 doesn't show the part where the Agent discovers the serial number of the Pledge. This was adding to the confusion. Maybe figure 4 can stay as is; this is just to clarify that at the start of Fig 4 the Agent MUST know the serial-number. So some small link is missing to get the complete picture.
I reopened as the initial point if the registrar-agent MUST know the serial number is not solved by the QR code reference. As the registrar-agent needs to know, which pledges he is bootstrapping, he needs the list of serial numbers in advance to be able to construct the agent signed data. Text proposed will be included into the pre-conditions described in section 5.5.1, In addition, the registrar-agent MUST know the product-serial-number(s) of the pledge(s) to be bootstrapped. The registrar-agent MAY be provided with the product-serial-number in different ways: configured, e.g., as a list of pledges to be bootstrapped via QR code scanning discovered by using standard approaches like mDNS as described in 5.4.2. discovered by using a vendor specific approach, e.g., RF beacons
Ok


Question: Secure Frame (SFrame) <del> draft-omara-sframe-01 </del> <ins> draft-ietf-sframe-enc-latest </ins> Abstract

This: Changes the name of the draft (I made something up, but you are free to suggest a different name) Adds venue information to the draft (working group, area, stream, github, etc...) Updates some of the boilerplate stuff (README, CONTRIBUTING, .gitignore, Makefile) Adds workflows for CI with GitHub Actions Cleans up trailing whitespace (with ) so that the build runs cleanly Updates the Gemfile (I don't use this, but I tried to make it functional for those that do) From here, you should be able to create a first submission of a draft-ietf-sframe-enc-00 by pushing a tag of draft-ietf-sframe-enc-00 (or making a new release with that name).
Spec changes look ok since they are editorial/ NAME is this ready to go?
You should be able to merge this and use it straight away, if that is what you want to do (the only thing that might need attention is the proposed filename, which I just made up).


Question: Upon receiving this event, a framer implementation is responsible for performing any necessary transformations and sending the resulting <del> data to the next protocol.  Implementations SHOULD ensure that there is a way to pass the original data through without copying to improve </del> <ins> data back to the Message Framer, which will in turn send it to the next protocol.  Implementations SHOULD ensure that there is a way to pass the original data through without copying to improve </ins> performance. To provide an example, a simple protocol that adds a length as a

Just some points about the new text on framers in the API draft: In 10.2 it is specified in which order multiple framers run on incoming and outgoing messages, it is however never specified what the order looks like on Start and Stop events. In 10.6, "MessageFramer.DeliverAndAdvanceReceiveCursor" appears to be missing the "Data" argument that is present in "MessageFramer.Deliver". Also in 10.6, in the second paragraph it says: When it is probably meant to say While the framer implementation is able to notify the Connection that it has finished handling a Start event (by calling MessageFramer.MakeConnectionReady), there is no such way for Stop events.
As notes for the responses to these points: If there are multiple framers, the "lowest" one (the one closest to the transport) would receive start first, and the next would get the start event when the lower one is ready. Similar for stop. Good calls on the missing data argument and the typo re application vs framer. I was thinking to use the failConnection call to complete a stop, potentially with no error?


Question: When a DTLS implementation receives a handshake message fragment corresponding to the next expected handshake message sequence number, <del> it MUST buffer it until it has the entire handshake message.  DTLS implementations MUST be able to handle overlapping fragment ranges. This allows senders to retransmit handshake messages with smaller fragment sizes if the PMTU estimate changes.  Senders MUST NOT change handshake message bytes upon retransmission.  Receivers MAY check that retransmitted bytes are identical and SHOULD abort the handshake with an "illegal_parameter" alert if the value of a byte changes. </del> <ins> it MUST process it, either by buffering it until it has the entire handshake message or by processing any in-order portions of the message.  DTLS implementations MUST be able to handle overlapping fragment ranges.  This allows senders to retransmit handshake messages with smaller fragment sizes if the PMTU estimate changes. Senders MUST NOT change handshake message bytes upon retransmission. Receivers MAY check that retransmitted bytes are identical and SHOULD abort the handshake with an "illegal_parameter" alert if the value of a byte changes. </ins> Note that as with TLS, multiple handshake messages may be placed in the same DTLS record, provided that there is room and that they are

NAME here is another try at this.
I did not realize that the intent of your text was to allow out of order processing. IMO that's off the fairway and we shouldn't allow that any more than we let you reach into the TCP stack and pull out forward messages.
NAME I don't think the comparison with TCP works - the handshake protocol is internal. We should not force a particular implementation unless there's good reason to. In this case, as explained on the list, there's potential merit of allowing out of order processing of very large handshake messages with known structure. NAME What's your opinion?
Again, this is a last minute change during Auth48, so the bar is much higher than "potential merit"
This isn't motivated by security-related reasons like , so I agree with NAME that this does not raise to the level of an AUTH48 change. I propose we land this PR and close out .
Thanks NAME NAME for considering this in the first place. As I understood NAME since this does not impact the wire-format, we can revisit once the RFC has been finalized?
Once the RFC is finalized, it's final. Changes can be requested via the , or via a new document that updates the RFC in question.
Ok, thank you. I was referring to NAME comment on the list
Yes. What I was saying is that you could just write an RFC that said "you can process out of order"
corresponding to the next expected handshake message sequence number, it MUST buffer it until it has the entire handshake message. As discussed in URL The spec mandates buffering all handshake fragments, but some implementations (e.g. GnuTLS) choose to implement simpler reassembly schemes. It has been argued by Ekr that such should be discouraged because they aren't efficient. On the other hand, as Rich Salz remarks, the choice of reassembly mechanism isn't something the peer could tell (the effects of poor reassembly performance are more retransmissions, which could also be due to poor network reliability), so it does feel like we're overspecifying things here. Weakening the MUST to a SHOULD isn't good either as it allows dropping fragments altogether. There's a tension between the desire for a concrete operational guidance, which the current text clearly provides, and a more abstract formulation along the line of "implementations MUST use a reassembly scheme ensuring forward progress".


Question: When a DTLS implementation receives a handshake message fragment corresponding to the next expected handshake message sequence number, <del> it MUST buffer it until it has the entire handshake message.  DTLS implementations MUST be able to handle overlapping fragment ranges. This allows senders to retransmit handshake messages with smaller fragment sizes if the PMTU estimate changes.  Senders MUST NOT change handshake message bytes upon retransmission.  Receivers MAY check that retransmitted bytes are identical and SHOULD abort the handshake with an "illegal_parameter" alert if the value of a byte changes. </del> <ins> it MUST process it, either by buffering it until it has the entire handshake message or by processing any in-order portions of the message.  DTLS implementations MUST be able to handle overlapping fragment ranges.  This allows senders to retransmit handshake messages with smaller fragment sizes if the PMTU estimate changes. Senders MUST NOT change handshake message bytes upon retransmission. Receivers MAY check that retransmitted bytes are identical and SHOULD abort the handshake with an "illegal_parameter" alert if the value of a byte changes. </ins> Note that as with TLS, multiple handshake messages may be placed in the same DTLS record, provided that there is room and that they are

As suggested by Ekr, taking this off the mailing list and continuing discussion here. To be clear: This has no bearing on the protocol itself, it's about how much implementation details the spec should enforce.
As mentioned on the list, I don't like the in-order qualification. I agree it's debatable whether there will be cases where it makes sense to process data out of order, but (see list again) it is not inconceivable, and I see no reason to exclude this here. I would therefore prefer to drop the in-order qualification. Hi all, Both DTLS 1.2 and DTLS 1.3 mandate: Can someone explain the underlying rationale? It seems that in the context of very large key material or certificate chains (think e.g. PQC), gradual processing of handshake messages (where possible) is useful to reduce RAM usage. Is there a security risk in doing this? It would also be useful for stateless handling of fragmented ClientHello messages. I'm sure this was discussed before but I don't remember where and who said it, but a server implementation could peek into the initial fragment of a ClientHello, check if it contains a valid cookie, and if so, allocate state for subsequent full reassembly. That wouldn't be compliant with the above MUST, though, as far as I understand it. Thanks! Hanno IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.


Question: service, defines the types of credentials which may be used in a deployment and provides methods for: <del> Issuing new credentials, </del> <ins> Issuing new credentials with a relevant credential lifetime, </ins> <del> Validating a credential against a reference identifier, and </del> <ins> Validating a credential against a reference identifier, </ins> Validating whether or not two credentials represent the same <del> client. </del> <ins> client, and Optionally revoking credentials which are no longer authorized. </ins> A *Delivery Service*, described fully in delivery-service, provides methods for:

WGLC comments on Operation Requirements section. Added several overlooked requirements
Discussed on 12/8 interim, and folks seemed fine with this. I.e., it's ready to merge.


Question: requires negotiation between the two endpoints using a new transport parameter, as specified in nego. <del> This proposal supports the negotiation of either the use of one packet number space for all paths or the use of separate packet number spaces per path.  While both approaches are supported by the specification in this version of the document, the intention for the final publication of a multipath extension for QUIC is to choose one option in order to avoid incompatibility.  More evaluation and implementation experience is needed to select one approach before final publication.  Some discussion about pros and cons can be found here: https://github.com/mirjak/draft-lmbdhk-quic- multipath/blob/master/presentations/PacketNumberSpace_s.pdf As currently defined in this version of the draft the use of multiple packet number spaces requires the use of connection IDs is both directions.  Today's deployments often only use destination connection ID when sending packets from the client to the server as this addresses the most important use cases for migration, like NAT rebinding or mobility events.  Further discussion and work is required to evaluate if the use of multiple packet number spaces could be supported as well when the connection ID is only present in one direction. </del> <ins> This extension uses multiple packet number spaces.  When multipath is negotiated, each destination connection ID is linked to a separate packet number space.  Using multiple packet number spaces enables direct use of the loss recovery and congestion control mechanisms defined in QUIC-RECOVERY. Some deployments of QUIC use zero-length connection IDs.  When a node selects to use zero-length connection IDs, it is not possible to use different connection IDs for distinguishing packets sent to that node over different paths.  This extension also specifies a way to use zero-length CID by using the same packet number space on all paths. However, when using the same packet number space on multiple paths, out of order delivery is likely.  This causes inflation of the number of acknowledgement ranges and therefore of the the size of ACK frames.  Senders that accept to use a single number space on multiple paths when sending to a node using zero-length CID need to take special care to minimize the impact of multipath delivery on loss detection, congestion control, and ECN handling.  This proposal specifies algorithms for controlling the size of acknowledgement packets and ECN handling in Section using-zero-length and ecn- handling. </ins> This proposal does not cover address discovery and management. Addresses and the actual decision process to setup or tear down paths

This derives from the discussions on issue
The commit applies the changes suggested in the previous reviews. With those changes, I think we have a good basis for discussing a unified solution in the working group.
Thanks NAME for the review. I have applied the editorial changes. You are asking for something more regarding the "specific logic" required when supporting zero-length CID. There are in fact two pieces to that: logic at the receiver, i.e., the node that chose to receive packets with zero-length CID; and logic at the sender, i.e., the node that accepts to send data on multiple paths towards a node that uses zero-length CID. This is explained in details in the section "Using Zero-Length connection ID", so I guess what we need is a reference to that section.
Comment by NAME (on PR ): I think we expand this section a bit as we found getting the delay right was non-trivial. QUIC time-stamp would work for sure. But if one decides not to use QUIC timestamp, we probably want to explain what is needed to be done here.
I have submitted PR for this one.
Closing as got merged.
In section 3.1, we wrote When the multipath option is negotiated, clients that want to use an additional path MUST first initiate the Address Validation procedure with PATHCHALLENGE and PATHRESPONSE frames described in of ]. After receiving packets from the client on the new paths, the servers MAY in turn attempt to validate these paths using the same mechanisms. With multipath, we cannot simply write that the server MAY validate the new path. There is a risk of a malicious client that operates as follows: client creates path from its own address, A. Path is validate by server client starts long download from server client creates a second path to server using a spoofed address, B client starts address validation for B but does not care about the response from the server client stops acknowledging packets over the first path to force the server to move packets to the second one and then opportunistically acknowledges packets that should have been sent by the server over that second packet (SPNS would probably make such an attack simpler than MPNS) We probably need to start working on the security considerations section of the draft.
This is already covered in the QUIC threat model. The server is supposed to validate new paths by sending a "path challenge" on that path, then waiting for a challenge response.