Question: 7.2. <ins> ESNI requires encrypted DNS to be an effective privacy protection mechanism.  However, verifying the server's identity from the Certificate message, particularly when using the X509 CertificateType, may result in additional network traffic that may reveal the server identity.  Examples of this traffic may include requests for revocation information, such as OCSP or CRL traffic, or requests for repository information, such as authorityInformationAccess.  It may also include implementation- specific traffic for additional information sources as part of verification. Implementations SHOULD avoid leaking information that may identify the server.  Even when sent over an encrypted transport, such requests may result in indirect exposure of the server's identity, such as indicating a specific CA or service being used.  To mitigate this risk, servers SHOULD deliver such information in-band when possible, such as through the use of OCSP stapling, and clients SHOULD take steps to minimize or protect such requests during certificate validation. 7.3. </ins> I-D.ietf-tls-sni-encryption lists several requirements for SNI encryption.  In this section, we re-iterate these requirements and assess the ESNI design against them. <del> 7.2.1. </del> <ins> 7.3.1. </ins> Since the SNI encryption key is derived from a (EC)DH operation between the client's ephemeral and server's semi-static ESNI key, the

Since OCSP is the server name, ESNI should probably enforce OCSP stapling (similar to ) or any other way of encrypted OCSP checks. Ignoring OCSP status checks entirely makes it hard to revoke a certificate, even if it's only valid for a few months.
NAME what behavior do you expect here? Would clients fail hard if server don't send stapled responses? It's good to view ESNI as part of the leaky boat problem. It plugs one hole, but not all of them. Implementations probably should do something about cleartext OCSP if they want all holes plugged.
Thank you for the changes. LGTM.


Question: Coding is a reliability mechanism that is distinct and separated from the loss detection of congestion controls.  Using coding can be a useful way to better deal with tail losses or with networks with non- <del> congestion losses.  However, coding mechanisms could hide congestion signals to the server.  This memo proposes a discussion on how coding and congestion signals could interact and proposes best current practice. </del> <ins> congestion losses.  However, coding mechanisms should not hide congestion signals.  This memo offers a discussion of how coding and congestion control interact. </ins> 1.

This proposes a complete re-vamp of the document. I would also suggest to completely remove sections 6 and 7, but rather than doing this yet, I inserted comments that explain why.
Le 17/01/2020 à 09:28, mwelzl a écrit : Yes ! Definitely agree.
Le 17/01/2020 à 13:50, francoismichel a écrit : OK for me.


Question: receiver sends acknowledgments determines how long it takes for losses to be detected at the sender. <del> 8.2. </del> <ins> 9.2. </ins> Many congestion control algorithms have a startup mechanism during the beginning phases of a connection.  It is typical that in this

by adding a one byte IMMEDIATE_ACK frame.
editorial nit: my preference would be for frame diagrams to use the notation in QUIC transport. I see that ACK_FREQUENCY is defined using ASCII art, so perhaps you want to consider a separate follow up PR to switch styles after this lands.
Thanks Lucas, I filed to update them.
They currently use ascii art. Will write this up once is merged.
sgtm, thanks!
When sending a PTO packet, a sender wants to induce an immediate ACK. The only trick I know to induce such an ACK is intentionally skip the packet number. However, the problem of that approach is that it relies on the receiver not ignoring reorders. When an ACKFREQUENCY frame previously sent had set the bit, then it become impossible for a sender to induce an immediate ACK when sending a PTO packet. At the moment, the only solution is to bundle an ACK_FREQUENCY packet in each PTO packet, but that seems like a bit of unnecessary overhead to me. Should we have a dedicated frame for inducing immediate ACKs instead?
That's an option. Another option is to revisit the max_reordering idea discussed in . If the max reordering was 5, then you could skip 5 PNs. I do feel like it'd be nice to allow specifying an int for max reordering, since that matches up with adaptive packet threshold loss detection, but as I expressed in , I think getting the details right are deceptively difficult, so I'm torn.
This does seem like a real problem. I like the idea of a single "ELICIT_ACK" type frame. With one byte a sender could effectively mark its PTOs ensuring they get an ACK without relying on the trick. An explicit frame is also easier to implement for the sender than the packet number skipping.
There's quite a bit of discussion on this on the tcpm mailing list at the moment, ie: URL I'm increasingly thinking it's worth using an unused protected bit in the header for this. It'd end up competing with the 2-bit packet loss measurements, but given those are experimental and may never be widely deployed, I think it might be worth it. For example, I believe this could allow an implementation to not include maxackdelay in PTO if it set the "ACK-pull"(or whatever it's called) bit on the final packet.


Question: receiver sends acknowledgments determines how long it takes for losses to be detected at the sender. <del> 8.2. </del> <ins> 9.2. </ins> Many congestion control algorithms have a startup mechanism during the beginning phases of a connection.  It is typical that in this

That already seems possible if more than the threshold number of ack-eliciting packets are outstanding.
I've thought more about this, and I think most of the time a 1-byte frame would be acceptable, but it definitely adds some implementation complexity, so I'd be curious which design others prefer? If we can decide, then I'll be happy to write a PR(or NAME can). Besides PTO, a use case would be making the last packet before becoming app-limited elicit an immediate ACK. This could allow skipping maxackdelay for all PTOs(see ), though always doing it could be a bit much in some cases. For example, browsers commonly send a series of requests, but to the transport it seems app-limited between them, because it doesn't know the browser has another request to send. It might be useful for 'chirping' as well, but I've never tried that, so it's mostly speculation.
We don't currently have any intention of deploying them either, and I think that's unlikely to change. I haven't seen a lot of good evidence that they are terribly helpful, and content providers don't seem to have a good incentive for implementing it. For us at least, the difference in complexity for a frame versus a bit in the header is negligible. A frame is actually be slightly easier to implement and losing a byte here and there isn't so bad.
I strongly prefer using the header bit. Although it will be a bit more work to implement, the fact that I won't end up with a 1-byte STREAM frame that I have to split off at the end of the packet will be worth the effort.
Is testimony of network operators not taken as evidence? I remember a line of people, from different companies -- BT, ATT, and so on, at IETF 101 practically begging for some information in QUIC packets to be exposed for monitoring and troubleshooting.
I do not see anyone propose a 1-byte STREAM frame. I believe what is meant is a new frame type. If anything, using a new frame type to elicit an ACK is easier than using a header bit, as it involves fewer parts of the code to change.
Nobody is proposing a 1-byte STREAM frame (you can't just make up stream data anyway). The problem is that a new frame would consume bytes (or probably one byte) in the packet payload.


Question: receiver sends acknowledgments determines how long it takes for losses to be detected at the sender. <del> 8.2. </del> <ins> 9.2. </ins> Many congestion control algorithms have a startup mechanism during the beginning phases of a connection.  It is typical that in this

Given that you set this signal on a PTO, and PTOs are often retransmissions of packets, this would require you to repackage (and, most likely, cut off a single byte from a STREAM frame). Using a header bit would solve that problem.
NAME and I discussed this and there are number of ways to fix this, but given this issue of not being able to elicit an immediate ACK by skipping packet numbers is introduced by the draft, we feel it's important it be fixed in some way. One more option is new STREAM frame codepoints that elicit an immediate ACK.
I'm ready to write a PR, but I'd appreciate thoughts on whether the existing PING frame should be repurposed or we should add a new frame(ACK, PONG, etc). I lean towards a new frame, since there are enough code-points and I believe there are use cases for the existing PING frame that does not elicit an immediate ACK.
+1. While I would not be opposed to repurposing the existing PING frame, I do not see the necessity of doing that. Let's simply consume one code point of the remaining 33.
Thanks, now for bikeshedding time. Some possible names: ACKME ACKPULL (from TCP) FAST_ACK PONG
Putting on my bikeshedding hat: I don't think we should prefix the frame name with ACK since that almost makes it looks like yet another variant of the ACK frame. The "pull" TCP terminology is fine (e.g. PULLACK) but we could also be more explicit with something like SOLICIT_ACK.
SCTP has something similar and calls it SACK-IMMEDIATELY (RFC 7053).
Thanks, I'd be happy with ACKIMMEDIATELY or IMMEDIATEACK
For those two options I'd prefer IMMEDIATE_ACK for the same reasoning as above -- so it appears less like an ACK variant.
IMMEDIATEACK sounds good to me. Alternatively, I'd be also fine with something like ACKNOW.
IMMEDIATE_ACK it is, PR coming.


Question: 9. Security issues are discussed throughout this memo, especially in <del> Appendices B, C, and D. </del> <ins> implementation-notes, backward-compatibility, and security-analysis. </ins> 10.

Just noticed that the MTI suites section didn't link to the suites, so here's a minor PR with some reference fiddling for this section: Add a link in MTI suites to the suites section, now that they're defined in this document. Nitpick ordering of extensions in MTI extensions to have them in same order as sections (so numbers in links are consistient). Change plaintext reference to appendices in Security Considerations to actual references.


Question: 5.1.1. HPKE public keys are opaque values in a format defined by the <del> underlying protocol (see the Cryptographic Dependencies section of the HPKE specification for more information). </del> <ins> underlying protocol (see Section 4 of RFC9180 for more information). </ins> Signature public keys are likewise represented as opaque values in a format defined by the ciphersuite's signature scheme.

URL This definition of a handshake message is being defined in terms of a Proposal or Commit object, neither of which are defined in this session. Furthermore, PublicMessage or PrivateMessage aren’t defined either as this point in the text. To improve clarity, consider defining these key terms. The use of "respectively" in the text is suggesting that PrivateMessages don’t have integrity protection which is not accurate. (see the Cryptographic Dependencies section of the HPKE specification for more information). Is this Section 4 of RFC9180?  If so, why not say that? What would be the circumstance where the application_id extension would be treated with equal standing as something from the AS?  Why can’t this be a "MUST"? Unsaid is what to do if the proposal list is not valid.  Please clarify. Is this normative behavior required, or could it be left up to application?  The mixing of updates/removes on the same node and the SHOULD guidance already means that this "recovery from an invalid node" may not be consistent across clients/DS-es. Same observation on recovering from ReInit with any other proposals. Is there any additional retry mechanism?  Let’s say the sender of the proposal doesn’t see it reflect in the epoch after it sent proposal.  And then not in the next epoch.  Does it try resending indefinitely? This setup seems a little simplistic. If the application data is encrypted to begin with, how does the adversary know the question being posed by Alice?


Question: TLDs as well, but only Iran has acted by blocking all Israeli (.il) domains Albert-2011. <del> 4.4. </del> <ins> 4.5. </ins> Distributed Denial of Service attacks are a common attack mechanism used by "hacktivists" and black-hat hackers, but censors have used

s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:


Question: acknowledgments will cause undesirable bursts of data into the network. <del> 9. </del> <ins> 10. </ins> TBD. <del> 10. </del> <ins> 11. </ins> TBD. <del> 11.  References </del> <ins> 12.  References </ins> <del> 11.1.  URIs </del> <ins> 12.1.  URIs </ins> [1] https://mailarchive.ietf.org/arch/search/?email_list=quic


Question: acknowledgments will cause undesirable bursts of data into the network. <del> 9. </del> <ins> 10. </ins> TBD. <del> 10. </del> <ins> 11. </ins> TBD. <del> 11.  References </del> <ins> 12.  References </ins> <del> 11.1.  URIs </del> <ins> 12.1.  URIs </ins> [1] https://mailarchive.ietf.org/arch/search/?email_list=quic


Question: acknowledgments will cause undesirable bursts of data into the network. <del> 9. </del> <ins> 10. </ins> TBD. <del> 10. </del> <ins> 11. </ins> TBD. <del> 11.  References </del> <ins> 12.  References </ins> <del> 11.1.  URIs </del> <ins> 12.1.  URIs </ins> [1] https://mailarchive.ietf.org/arch/search/?email_list=quic


Question: contain frames. QUIC payloads MUST contain at least one frame, and MAY contain <del> multiple frames and multiple frame types. </del> <ins> multiple frames and multiple frame types.  Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC packet boundary. </ins> <del> Frames MUST fit within a single QUIC packet and MUST NOT span a QUIC packet boundary.  Each frame begins with a Frame Type, indicating its type, followed by additional type-dependent fields: </del> <ins> Each frame begins with a Frame Type, indicating its type, followed by additional type-dependent fields: </ins> The frame types defined in this specification are listed in frame- types.  The Frame Type in ACK, STREAM, MAX_STREAMS, STREAMS_BLOCKED,

This was always intended (and also written in the description of FRAMEENCODINGERROR), but didn't show up in the text somehow.
I agree with NAME about the MUSTs that you shuffled around are statements of fact, not interoperability requirements, but the addition is fine.


Question: 6.3.2. <ins> The server MAY require a value to be present for the "external- account-binding" field.  This can be used to an ACME account with an existing account in a non-ACME system, such as a CA customer database. To enable ACME account binding, a CA needs to provision the ACME client with a MAC key and a key identifier.  The key identifier MUST be an ASCII string.  The MAC key SHOULD be provided in base64url- encoded form, to maximize compatibility between provisioning systems and ACME clients. The ACME client then computes a binding JWS to indicate the external account's approval of the ACME account key.  The payload of this JWS is the account key being registered, in JWK form.  The protected header of the JWS MUST meet the following criteria: The "alg" field MUST indicate a MAC-based algorithm The "kid" field MUST contain the key identifier provided by the CA The "nonce" field MUST NOT be present The "url" field MUST be set to the same value as the outer JWS The "signature" field of the JWS will contain the MAC value computed with the MAC key provided by the CA. When a CA receives a new-registration request containing an "external-account-binding" field, it must decide whether or not to verify the binding.  If the CA does not verify the binding, then it MUST NOT reflect the "external-account-binding" field in the resulting account object (if any).  To verify the account binding, the CA MUST take the following steps: Verify that the value of the field is a well-formed JWS Verify that the JWS protected meets the above criteria Retrieve the MAC key corresponding to the key identifier in the "kid" field Verify that the MAC on the JWS verifies using that MAC key Verify that the payload of the JWS represents the same key as was used to verify the outer JWS (i.e., the "jwk" field of the outer JWS) If all of these checks pass and the CA creates a new account, then the CA may consider the new account associated with the external account corresponding to the MAC key, and MUST reflect value of the "external-account-binding" field in the resulting account object.  If any of these checks fail, then the CA MUST reject the new- registration request. 6.3.3. </ins> A client may wish to change the public key that is associated with a account in order to recover from a key compromise or proactively mitigate the impact of an unnoticed key compromise.

This is a variant of that uses a MAC key to perform the account binding instead of a bearer token. Thanks to NAME for pointing out the need for this on the ACME mailing list.
Question: will you require a CA that doesn't use external account bindings to reject a request if it contains an external-account-binding member? nit: s/field/member/g, consistent with RFC 7159.
StartCom plan to use ACME protocol for StartEncrypt, we need to identify the client's validation level, so the subscriber administration can generate a special token in the URL account that send this token to the email address used in the registration. At the registration, user need to enter email and this token with the certificate to let the CA system know this customer's validation level. After the CA system receive the email, the token and signing certificate, CA system know what type of certificate we can issue to this client; if this client account is class 4 validated, then the client can get EV SSL certificate, not DV SSL. please add this a parameter to the ACME protocol, thanks.
This request should be sent to the ACME mailing list (EMAIL) for further discussion, it would also be very useful to know what your EV (or OV) validation flow would look like using ACME as most likely the current certificate application object would need to be changed to identify those requirements to the server.
This was fixed by
Minor editorial comments.


Question: IPv4 - "all CoRE resource directories" address MCD2 (suggestion: 224.0.1.189), from the "IPv4 Multicast Address Space Registry".  As the address is used for discovery that may span beyond a single <del> network, it has come from the Internetwork Control Block (224.0.1.x, RFC 5771). </del> <ins> network, it has come from the Internetwork Control Block (224.0.1.x) RFC5771. </ins> IPv6 - "all CoRE resource directories" address MCD1 (suggestions FF0X::FE), from the "IPv6 Multicast Address Space Registry", in the

All expected to be uncontroversial; to be merged soon.
Commit 3809be46013e9708a6584c4fb730e7cfecab5f22 should have been part of this as well, and is already applied to master.


Question: The authors thank Benjamin Kaduk for providing the content related to TLS certificate validation of the API server. <ins> The authors thank Michael Richardson for providing wording requiring DNSSEC and TLS to operate without the user adding exceptions. </ins> The authors thank various individuals for their feedback on the mailing list and during the IETF98 hackathon: David Bird, Erik Kline, Alexis La Goulette, Alex Roscoe, Darshak Thakore, and Vincent van

Attempting to fix issue . I attempted to reword the principles, adding more prose for the rationale. Also upgraded some SHOULD NOT to MUST NOT because it seems some people thought the SHOULD NOT says the existing approach is OK. These are just some ideas. I won't be offended if rejected.
I believe I addressed all comments. You'll probably want to review the complete diff again.
Benjamin writes in his review: Michael replied with this suggested text: This seems reasonable, as I mentioned in the reply. We should go with it, unless anyone has an objection. Also, attribute it to Michael Richardson.
S. Moonesamy writes
One approach I suggested in my reply to the feedback:
This is good. Thanks for sorting through this; it's important that this is right, and you have cleared it up a lot.Much clearer. Thanks!


Question: curves, they SHOULD perform the additional checks specified in Section 7 of <del> 6.1.1. </del> <ins> 6.1.2. </ins> This ciphersuite uses the following primitives:

Here's the Weekly Digest for : - - Last week 2 issues were created. Of these, 0 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by - - Last week, 8 pull requests were created, updated or merged. Last week, 1 pull request was opened. :greenheart: , by Last week, 5 pull requests were updated. :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by :yellowheart: , by Last week, 2 pull requests were merged. :purpleheart: , by :purpleheart: , by - - Last week there were 2 commits. :hammerandwrench: by :hammerandwrench: by - - Last week there was 1 contributor. :bustinsilhouette: - - Last week there was 1 stargazer. :star: You are the star! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .


Question: their peer.  This update changes the suggestion to assume support for SHA-256 instead, due to MD5 and SHA-1 being deprecated. <ins> In Section 7.4.1.4.1: the text should be revised from: </ins> OLD: <del> In Section 7.4.1.4.1: the text should be revised from " Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." </del> <ins> "Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." </ins> NEW:

Addressing Roman's AD comments.
has 2 conflicts, not sure how to resolve, the updates look fine. Please merge.
There was a conflict with the 8174 reference being in the other branch. I added it in because it's now part of the terminology paragraph.
Please address the following IDNits: -- The document seems to lack an IANA Considerations section. (See Section 2.2 of URL for how to handle the case when there are no actions for IANA.) -- The draft header indicates that this document updates RFC5246, but the abstract doesn't seem to mention this, which it should. -- The draft header indicates that this document updates RFC7525, but the abstract doesn't seem to mention this, which it should. Section 1. Editorial. -- s/RFC 5246 [RFC5246]/[RFC5246]/ -- s/RFC 6151 [RFC6151]/[RFC6151]/ -- s/RFC7525 [RFC7525]/[RFC7525]/ Section 1. Editorial. For symmetry with the rest of the text: OLD RFC 6151 [RFC6151] details the security considerations, including collision attacks for MD5, published in 2011. NEW In 2011, [RFC6151] detailed the security considerations, including collision attacks for MD5. Section 1. Please provide a reference for "Wang, et al". Is there a reference to provide for the "the potential for brute-force attack" Section 6. Editorial Nit. s/RFC5246 [RFC5246]/[RFC5246]/ Section 6. Move the text "In Section 7.4.1.4.1: the text should be revised from" out of the "OLD" block of text to be its own intro paragraph so that the OLD vs. NEW is a clear cut-and-paste. Section 7. Editorial. s/ RFC7525 [RFC7525]/[RFC7525]/ Section 7. SHA-1 is also not mentioned in RFC7525. Recommend: OLD The prior text did not explicitly include MD5 and this text adds it to ensure it is understood as having been deprecated.


Question: their peer.  This update changes the suggestion to assume support for SHA-256 instead, due to MD5 and SHA-1 being deprecated. <ins> In Section 7.4.1.4.1: the text should be revised from: </ins> OLD: <del> In Section 7.4.1.4.1: the text should be revised from " Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." </del> <ins> "Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." </ins> NEW:

NEW The prior text did not explicitly include MD5 or SHA-1; and this text adds guidance to ensure that these algorithms have been deprecated. Section 7. Editorial. Grammar. OLD In addition, the use of the SHA-256 hash algorithm is RECOMMENDED, SHA-1 or MD5 MUST NOT be used NEW In addition, the use of the SHA-256 hash algorithm is RECOMMENDED; and SHA-1 or MD5 MUST NOT be used Section 10.2 Please make RFC5246 a normative reference.


Question: The transmission of QUIC packets on a regular QUIC connection is regulated by the arrival of data from the application and the <del> congestion control scheme.  QUIC packets can only be sent when the congestion window of at least one path is open. Multipath QUIC implementations also need to include a packet </del> <ins> congestion control scheme.  QUIC packets that increase the number of bytes in flight can only be sent when the congestion window allows it.  Multipath QUIC implementations also need to include a packet </ins> scheduler that decides, among the paths whose congestion window is <del> open, the path over which the next QUIC packet will be sent.  Many factors can influence the definition of these algorithms and their precise definition is outside the scope of this document.  Various packet schedulers have been proposed and implemented, notably for Multipath TCP.  A companion draft I-D.bonaventure-iccrg-schedulers provides several general-purpose packet schedulers depending on the application goals. Note that the receiver could use a different scheduling strategy to send ACK(_MP) frames.  The recommended default behaviour consists in sending ACK(_MP) frames on the path they acknowledge packets.  Other scheduling strategies, such as sending ACK(_MP) frames on the lowest latency path, might be considered, but they could impact the sender with side effects on, e.g., the RTT estimation or the congestion control scheme.  When adopting such asymetrical acknowledgment scheduling, the receiver should at least ensure that the sender negotiated one-way delay calculation mechanism (e.g., QUIC- Timestamp). </del> <ins> open, the path over which the next QUIC packet will be sent.  Most frames, including control frames (PATH_CHALLENGE and PATH_RESPONSE being the notable exceptions), can be sent and received on any active path.  The scheduling is a local decision, based on the preferences of the application and the implementation. Note that this implies that an endpoint may send and receive ACK_MP frames on a path different from the one that carried the acknowledged packets.  A reasonable default consists in sending ACK_MP frames on the path they acknowledge packets, but the receiver must not assume its peer will do so. </ins> 7.5.

Let's give the facts to the implementers, without providing too specific guidance neither. and may also address .
Just to not forget this, but this is mostly editorial. Probably present first the ACKMP frame, and then PATHABANDON and PATHSTATUS Drop reference to I-D.liu-multipath-quic as the PATHSTATUS frame is now integrated in the draft. Based on and , and If we agree on , we could also drop the text in PATh_ABANDON stating that on any path, not only the path on which the referenced Destination Connection ID is used.
We probably need to add some text in the scheduling considerations where control frames (PATHSTATUS, PATHABANDON, but also MAX_DATA,...) should be sent on a good working path, ideally with low latency.
I would say the same applies to ACK_MP
For ACK we recommend (SHOULD) to send it on the same path because of RTT calculations and I believe the scheduling text discusses at already.
Thinking about this some more. I believe we should say NOTHING. The point of the standard is to specify expected behavior when a node receives protocol messages from its peer. The basic statement is that most frames, including control frames, can be sent on any path -- the only exception being PATH CHALLENGE frames and PATH_RESPONSE frames. So my preference would be: 1) say nothing, because the purpose of standards is to specify requirements for Interop, not provide guidance to implementors. 2) if we do say something, just say that these frames can be sent on any valid path, based on preferences of the application and the implementation.
As for ACKMP frames, the text says "ACKMP frame (defined in ) SHOULD be sent on the same path as identified by the Path Identifier. However, an ACKMP frame can be returned via a different path, based on different strategies of sending ACKMP frames." That's an OK compromise, leaving open the possibility for implementations to use any strategy they want.
Alternatively, spell out the considerations to make when picking a path? Does it matter, if so, why? This would be useful to know when new frames come along in the future and need to think for themselves how multipath might affect them.
Sure, but at this stage we have preciously little experience. For example, I have a user request to specify affinity between a stream and a path.


Question: The transmission of QUIC packets on a regular QUIC connection is regulated by the arrival of data from the application and the <del> congestion control scheme.  QUIC packets can only be sent when the congestion window of at least one path is open. Multipath QUIC implementations also need to include a packet </del> <ins> congestion control scheme.  QUIC packets that increase the number of bytes in flight can only be sent when the congestion window allows it.  Multipath QUIC implementations also need to include a packet </ins> scheduler that decides, among the paths whose congestion window is <del> open, the path over which the next QUIC packet will be sent.  Many factors can influence the definition of these algorithms and their precise definition is outside the scope of this document.  Various packet schedulers have been proposed and implemented, notably for Multipath TCP.  A companion draft I-D.bonaventure-iccrg-schedulers provides several general-purpose packet schedulers depending on the application goals. Note that the receiver could use a different scheduling strategy to send ACK(_MP) frames.  The recommended default behaviour consists in sending ACK(_MP) frames on the path they acknowledge packets.  Other scheduling strategies, such as sending ACK(_MP) frames on the lowest latency path, might be considered, but they could impact the sender with side effects on, e.g., the RTT estimation or the congestion control scheme.  When adopting such asymetrical acknowledgment scheduling, the receiver should at least ensure that the sender negotiated one-way delay calculation mechanism (e.g., QUIC- Timestamp). </del> <ins> open, the path over which the next QUIC packet will be sent.  Most frames, including control frames (PATH_CHALLENGE and PATH_RESPONSE being the notable exceptions), can be sent and received on any active path.  The scheduling is a local decision, based on the preferences of the application and the implementation. Note that this implies that an endpoint may send and receive ACK_MP frames on a path different from the one that carried the acknowledged packets.  A reasonable default consists in sending ACK_MP frames on the path they acknowledge packets, but the receiver must not assume its peer will do so. </ins> 7.5.

I can certainly provide them an API to do that, but this is basically research. And then, affinity applies to stream frames, but whether it should be applied to control frames is debatable. I am concerned that the guidance that we provide will be so generic as not to be useful, while still requiring long debates and delaying the publication of the draft. I think guidance is best provided in research papers, and possibly in text books.
I agree we shoukd avoid the potential time sink. I wasn't suggesting guidance but rather a fairly succinct statement like "The path that frames are sent on is a local choice, which could effect the behavior or performance of the QUIC transport or delivery of application data. There is no guidance provided by this document on strategies for path selection for frames beyond the control frames for the multipath extension itself." And perhaps gathering consensus on that now avoids people asking the question in later review rounds.
NAME I agree. Your proposal is basically equivalent to my suggestion that "if we do say something, just say that these frames can be sent on any valid path, based on preferences of the application and the implementation." Your text is good.
Sorry, I did read your comment and immediately paged it out. Credit to you for proposing that option earlier
Looks good, but the description of congestion is imprecise. Either drop it or fix it.


Question: Supported Versions ("supported_versions"; supported-versions) <ins> Cookie ("cookie"; cookie) </ins> Signature Algorithms ("signature_algorithms"; signature- algorithms)


Question: connections.  Servers MAY discard any Initial packet that does not carry the expected token. <ins> A token SHOULD be constructed for the server to easily distinguish it from tokens that are sent in Retry packets as they are carried in the same field. The token MUST NOT include information that would allow it to be linked by an on-path observer to the connection on which it was issued.  For example, it cannot include the connection ID or addressing information unless the values are encrypted. </ins> Unlike the token that is created for a Retry packet, there might be some time between when the token is created and when the token is <del> subsequently used.  Thus, a token SHOULD include an expiration time. The server MAY include either an explicit expiration time or an issued timestamp and dynamically calculate the expiration time.  It is also unlikely that the client port number is the same on two </del> <ins> subsequently used.  Thus, a token SHOULD have an expiration time, which could be either an explicit expiration time or an issued timestamp that can be used to dynamically calculate the expiration time.  A server can store the expiration time or include it in an encrypted form in the token. It is unlikely that the client port number is the same on two </ins> different connections; validating the port is therefore unlikely to be successful. <del> A token SHOULD be constructed for the server to easily distinguish it from tokens that are sent in Retry packets as they are carried in the same field. </del> If the client has a token received in a NEW_TOKEN frame on a previous connection to what it believes to be the same server, it SHOULD include that value in the Token field of its Initial packet.

…are: require unlinkability by stating: "SHOULD NOT expose linkability" suggest use of encryption when embedding expiration time in the token
Thanks NAME !
My understanding is that tokens provided by NEW_TOKEN frames should not leak information that allows observers correlate the newly established connection with the previous connection. Such information include the time when the token was issued, RTT, server name (when SNI is not used or Encrypted SNI is used), or even the size of the token. However, the draft seems to be vague about the requirement. I think it might be worth clarifying the principle in the draft. "a token SHOULD include an expiration time" (section 8.1.2) - I think we should change this to "a token SHOULD be associated an expiration time", considering the fact that we are talking about "stateful" design (stateless design is mentioned briefly in one of the following paragraphs). In a stateful design, an opaque identifier is the only thing that a server should be allowed to send. "In a stateless design, a server can use encrypted and authenticated tokens to pass information to clients" - I think we might prefer using "SHOULD" rather than "can".
I think the current text is fine: "include" translates to "put into the token and encrypt" in my mind. Reading that a token is "associated" with an expiration time would give me pause.
Would you mind clarifying where the "and encrypt" comes from? My point is that that is the way it should be, however the text does not seem to clarify that.
I don't recall how I arrived at it -- perhaps some common sense. Now that I have implemented it, it seems only natural. Perhaps we should simply add "and encrypt" to the text instead of changing to "associated with," which is less clear?
I'm happy to know that we share the common sense :+1: As stated in the opening comment, my "editorial" preference goes to stating the principle that any information in an NEW_TOKEN token (other than the opaque lookup key used in a stateful design) SHOULD be encrypted. If that is to be met, I think adding "and encrypt" would be fine.
I agree with NAME -- I think stating this explicitly as a SHOULD is sensible.
(For the chairs, and triage purposes).


Question: connections.  Servers MAY discard any Initial packet that does not carry the expected token. <ins> A token SHOULD be constructed for the server to easily distinguish it from tokens that are sent in Retry packets as they are carried in the same field. The token MUST NOT include information that would allow it to be linked by an on-path observer to the connection on which it was issued.  For example, it cannot include the connection ID or addressing information unless the values are encrypted. </ins> Unlike the token that is created for a Retry packet, there might be some time between when the token is created and when the token is <del> subsequently used.  Thus, a token SHOULD include an expiration time. The server MAY include either an explicit expiration time or an issued timestamp and dynamically calculate the expiration time.  It is also unlikely that the client port number is the same on two </del> <ins> subsequently used.  Thus, a token SHOULD have an expiration time, which could be either an explicit expiration time or an issued timestamp that can be used to dynamically calculate the expiration time.  A server can store the expiration time or include it in an encrypted form in the token. It is unlikely that the client port number is the same on two </ins> different connections; validating the port is therefore unlikely to be successful. <del> A token SHOULD be constructed for the server to easily distinguish it from tokens that are sent in Retry packets as they are carried in the same field. </del> If the client has a token received in a NEW_TOKEN frame on a previous connection to what it believes to be the same server, it SHOULD include that value in the Token field of its Initial packet.

This suggests a normative requirement that I don't think that we need, or that is already implied by existing text. There would be new normative text. I believe that is still editorial on the basis that the requirement is already implied, but will defer to your judgment.
FWIW, what I am shooting for is a change like URL
NAME and others, is kazuhoNAME kind of the change you were envisioning?
I was asked to move here. I miss the point, that the server SHOULD NOT construct the same token multiple times because this leads to additional scenarios where tracking by a network observer becomes feasible. The referenced PR does not fix this problem.
NAME I think we are in agreement that unlinkability between tokens is required. IMO the phrase "SHOULD NOT expose linkability" in the proposed text captures the concept, though I might agree that "i.e., ..." needs improvement.
NAME NAME change would be adequate, and I agree with NAME that this is effectively editorial. Do the chairs want to mark this issue as ?
NAME Yes, I agree with you on the phrase "Should NOT expose likability". To address my concern, I suggest to include "This includes that the server constructs each time a different token when issuing tokens to clients from the same source address." after line 1560 of #kazuho/base-draftsNAME
Marking this as editorial
Looks good, modulo the minor suggestions.


Question: resolvers frequently support a local "hosts file" that preempts query forwarding, and most DNS forwarders and full resolvers can also serve responses from a local zone file.  Other standardized hybrid <del> resolution behaviors include Local Root RFC8806, mDNS RFC6762, and NXDOMAIN synthesis for .onion RFC7686. </del> <ins> resolution behaviors include RFC8806, RFC6762, and RFC7686. </ins> In many network environments, the network offers clients a DNS server (e.g.  DHCP OFFER, IPv6 Router Advertisement).  Although this server

Includes: Text adjustments for grammar and clarity Replacing "public" resolver with "external" Changes to references and blockquotes Made diagrams narrower
NAME NAME Please review
Changes look good to me.


Question: DNS: Provision DNS resource records for the domain <del> Proof of possession of a prior key: Sign using the private key specified by the server </del> There are several ways that these assumptions can be violated, both by misconfiguration and by attack.  For example, on a web server that allows non-administrative users to write to .well-known, any user can

There has been no implementer interest in the proof-of-possession challenge, and it makes the document more complex by having a completely different structure than the other challenges. If it is decided later that such a challenge is necessary, it can be added in a follow-on extension specificiation.
Generally this seems fine, and I wholeheartedly agree with the purpose of the removal (for now). One problem I can't open a comment for: Line 2099, the last paragraph before "Preventing Authorization Hijacking", still refers to the PoP Challenge. Without the PoP Challenge wording, a new reader may take that this to be referring to the implicit Proof of Possession of the ACME Account Key and thus be confused. Since it's non-normative, perhaps you could simply modify that paragraph into something more like:


Question: The User Equipment accesses the network until conditions Expire. <del> 3.2. </del> <ins> 4.2. </ins> This section describes a possible work-flow when conditions expire and the user visits the portal again (e.g., low quota, or time

We need to discuss what information will be used to identify the UE from the perspective of the various components in the system. This updates the draft to discuss this concept, including desired properties of the identifier and some examples. This aims to address issue 5 (URL)


Question: sequence number fields in the DTLSCiphertext structure have been reduced from those in previous versions. <ins> The DTLS epoch serialized in DTLSPlaintext is 2 octets long for compatibility with DTLS 1.2.  However, this value is set as the least significant 2 octets of the connection epoch, which is an 8 octet counter incremented on every KeyUpdate.  See seq-and-epoch for details.  The sequence number is set to be the low order 48 bits of the 64 bit sequence number.  Plaintext records MUST NOT be sent with sequence numbers that would exceed 2^48-1, so the upper 16 bits will always be 0. </ins> The DTLSCiphertext structure has a variable length header. DTLSPlaintext records are used to send unprotected records and

Yet another attempt to This builds on Chris's PR but just omits the epoch entirely from the AEAD nonce calculation. This is more consistent with TLS and doesn't require special case reasoning about why we only need to build in the bottom 16 bits. This relies entirely on the keys being different. Needs analysis.
This seems promising.
NAME this LGTM, but there's a conflict. Can you resolve prior to merging? NAME are you OK with the new rationale, and text that allows it to be relaxed in the future?
If I have understood and calculated correctly DTLS 1.3 limits the number of packets in a AES-GCM connection to 2^40.5 compared to 2^64 in DTLS 1.2. This is quite a severe limitation that is not mentioned explicitly. The AEAD limits in themselves are not a problem, but the combination of AEAD limits (2^24.5) and a small epoch (2^16) is a problem. I think this is major problem in some use cases of DTLS. E.g. most 3GPP 5G use cases where DTLS or DTLS/SCTP is used for semi-permanent connections (lasting years) and where the terminating the connection cause severe disturbances. I did not find any discussion about this problem (but I could easily have missed it) It is known that the limit of 2^48 packets in SRTP can be reached and 2^40.5 is significantly smaller than this... If the document was not in such a late stage, I would have suggested to increase the size of the epoch to 32 bits..... I think this and the other problems DTLS 1.3 has with semi-permanent connections has to be solved sooner than later.
NAME thanks for filing this. I hear you about the late stage, but IIRC we never represent the entire epoch on the wire in any case, so it seems like just changing it to 32 bits would be pretty easy, so why not do it now?
How do the chacha20 numbers compare to the AES-GCM ones?


Question: sequence number fields in the DTLSCiphertext structure have been reduced from those in previous versions. <ins> The DTLS epoch serialized in DTLSPlaintext is 2 octets long for compatibility with DTLS 1.2.  However, this value is set as the least significant 2 octets of the connection epoch, which is an 8 octet counter incremented on every KeyUpdate.  See seq-and-epoch for details.  The sequence number is set to be the low order 48 bits of the 64 bit sequence number.  Plaintext records MUST NOT be sent with sequence numbers that would exceed 2^48-1, so the upper 16 bits will always be 0. </ins> The DTLSCiphertext structure has a variable length header. DTLSPlaintext records are used to send unprotected records and

NAME I don't think (D)TLS 1.3 puts any limits on ChaCha20 so my understanding is understanding is that the total number of packets can be protected in the current drafts is ChaCha20 2^64 (2^48 2^16) AES-GCM 2^40.5 (2^24.5 2^16) AES-GCM 2^39 (2^23 * 2^16)
NAME I am all for changing this now. I made a PR that change epoch from uint16 to uint32. As you say, it seems like a pretty easy change to do. Is uint32 the right size?
Unless you think we should do uint64. NAME NAME what would we have to do to make this change?
URL Magnus Westerlund thinks uint64 would be a safer bet.Michael Tüxen suggest to wrap the uint16 epoch instead. That might be an easier solution. I don't see a direct problem in DTLSPlaintext, ACK message, or recordsequencenumber with a uint16 epoch that is allowed to wrap like: 4, 5, ... 2^16-1, 4, 5, ... 2^16-1, 4, 5, ...
NAME NAME NAME since it's through the IESG we would need to at least raise that this change was made after they had approved it. I suspect that doing some kind of 2-week heads up to the WG/IESG that we want to make the change before landing it. But, if we do that or something more drastic that's really up to NAME
I want to point out that allowing wrapping per may not be the best solution if one considers to use the DTLS epoch as part of the input to the TLS exporter as suggested in . Then one want an input that doesn't wrap, and then to ensure that one doesn't practically run into any limits, then an uint64 would be better. An unit32 appears to be sufficient for a quite extreme use case with minimal messages size (which is one DTLS record with 4 byte user message) and high bandwidth (10 Gbps) sustained over a period of more than 5 years before the epoch would wrap.


Question: sequence number fields in the DTLSCiphertext structure have been reduced from those in previous versions. <ins> The DTLS epoch serialized in DTLSPlaintext is 2 octets long for compatibility with DTLS 1.2.  However, this value is set as the least significant 2 octets of the connection epoch, which is an 8 octet counter incremented on every KeyUpdate.  See seq-and-epoch for details.  The sequence number is set to be the low order 48 bits of the 64 bit sequence number.  Plaintext records MUST NOT be sent with sequence numbers that would exceed 2^48-1, so the upper 16 bits will always be 0. </ins> The DTLSCiphertext structure has a variable length header. DTLSPlaintext records are used to send unprotected records and

However, to my understanding the full epoch value are so rarely included in transmitted DTLS messages that its size have minimal implication on the overhead that it is not worth saving 4-bytes to be certain to have eliminated any practical limitation.
I think a 2-week WGLC and notifying the IESG will suffice.
FYI. We have now run into quite many problems with the interworking of semi-permanent DTLS/SCTP connections (lasting years) and DTLS 1.3: No Diffie-Hellman rekeying No post-handshake server authentication No rekeying of the exporter_secret 2^40.5 packets limit 2 minute MSL requirement 2^38.5 byte SCTP user message size limit Our initial plan was to just replace DTLS 1.2 with DTLS 1.3, leave DTLS/SCTP as is, but as the problems keep adding up we are now startnig to consider quite big changes to DTLS/SCTP 1.3 to make this work: URL Using new DTLS connections instead of KeyUpdate could potentially address the first five, but is a significant change.
Hi, Based on the problems long-lived DTLS/SCTP had with DTLS 1.3 (as well as DTLS 1.2 without renegotiation and respecting AEAD limits) we restructured DTLS/SCTP (RFC6083bis) to use parallel connections instead of relying on renegotiation and post-handshake messages. We think this quite easily solves all the problems we had without requiring any updates of DTLS 1.3. It also makes DTLS/SCTP less dependant on version specific DTLS mechanisms. It will hopefully work without changes with any future DTLS 1.4. URL We can now firmly RECOMMEND DTLS 1.3 which I think is very important. 5G is to a large degree replacing or complementing IPsec with TLS, DTLS, and DTLS/SCTP. I will do my best to transition 3GPP to DTLS 1.3 asap. FYI, 3GPP DTLS/SCTP associations have very long lifetimes (can be years), strive for five nines (99.999%) availability and cannot be teared down without causing major disruptions.


Question: sequence number fields in the DTLSCiphertext structure have been reduced from those in previous versions. <ins> The DTLS epoch serialized in DTLSPlaintext is 2 octets long for compatibility with DTLS 1.2.  However, this value is set as the least significant 2 octets of the connection epoch, which is an 8 octet counter incremented on every KeyUpdate.  See seq-and-epoch for details.  The sequence number is set to be the low order 48 bits of the 64 bit sequence number.  Plaintext records MUST NOT be sent with sequence numbers that would exceed 2^48-1, so the upper 16 bits will always be 0. </ins> The DTLSCiphertext structure has a variable length header. DTLSPlaintext records are used to send unprotected records and

With such long lifetimes we think mutual reauthentication, rekeying of the SCTP-AUTH key, and forcing attackers to dynamic key exfiltration [RFC7624] are required features. I still think should be done. 2^40.5 packets is quite limiting.
Seems OK.Thanks -- this LGTM. We'll need to do a brief consensus call given the type of change.


Question: algorithms (AEAD, hash) in the selected cipher suite (see cs) and the application can make use of the established connection identifiers C_I and C_R (see ci).  EDHOC may be used with the media type <del> application/edhoc defined in media-type. </del> <ins> application/edhoc+cbor-seq defined in media-type. </ins> The Initiator can derive symmetric application keys after creating EDHOC message_3, see exporter.  Protected application data can

Signed-off-by: David Navarro
NAME NAME and others: Any response to John's comment?
NAME I included John's suggestion in the PR.
Looks good to me. Other opinions?
As specified in section , the payload in some CoAP messages can be an EDHOC message prepended by either a C_x identifier or "true". The draft states: However, the payload is actually a CBOR Sequence as defined by . Thus, we could define and use a new media type "application/edhoc+cbor-seq". Note that the usage of the Content-Format option is optional.
Makes sense to me. NAME NAME others: Comments? Good that you bring up the optionality of Content-Format, we should stress that in this text. The discussion in Hackathon also reminded me about the common-option-compression which NAME presented in the May 12 interim 2021 - how to replace the Uri-Path: "/.well-known/edhoc" with a, say, integer valued CoAP option.
Makes a lot of sense to me, too.
I find this distinction good and the solution consequential, still open for comments.


Question: first string compares less than the remainder of the second string. <del> Note that comparisons using the operator "<" yield false if either value being compared is an object, array, boolean, or "null". </del> "!=", "<=", ">", and ">=" are defined in terms of the other comparison operators.  For any "a" and "b":

NAME Deleting the text should have addressed your original editorial issue. This PR also adds the missing cross-reference. If you're happy, please approve.


Question: "task": The PA task. <del> "helper_urls": The helpers' endpoint URLs. </del> <ins> "helper_url": The helpers endpoint URL. </ins> "collector_config": The HPKE configuration of the collector (described in hpke-config).  [OPEN ISSUE: Maybe the collector's

Partially addresses . (We also need to decide if/how to allow a particular PA protocol to use multiple helpers for privacy.) Right now, multiple helpers are used for redundancy in case one of the helpers dropped out. This removes this mechanism from the core protocol.
Squashed and rebased.
That's a good idea,
Hmm... Do we need to decide. Per our discussion on Wednesday, if the clients learn this out of band then we won't need this field at all because clients will get it separately and helpers don't need to know what the other helpers are, right?
My takeaway is that the parameters must contain all input needed to run the protocol, including the helpers. And all of this is configured out of band. You could punt everything except for the cryptographic goop out of the parameters structure, forcing clients to know the leader and helper and get their public keys out of band as well, which would be fine. It's just different. I think both work just fine, but I lean towards having params specify everything. It just seems simpler to me. That said... making public key discovery part of the client upload protocol here is more complex, I think. So, .
Squashed.
LGTM. Multiple helpers "for privacy" seems like it's inherently a per-protocol thing (Prio supports it, Hits does not). If and when we decide to address that, should we move this to the protocol-specific slot in PAParam?


Question: An application server requests the delivery of a push message as described in I-D.ietf-webpush-protocol.  If the application server wishes to self-identify, it includes an Authorization header field <del> with credentials that use the "WebPush" authentication scheme auth and a Crypto-Key header field that includes its public key key. </del> <ins> with credentials that use the "WebPush" authentication scheme (auth) and a Crypto-Key header field that includes its public key (key). </ins> Note that the header fields shown in ex-push don't include line wrapping.  Extra whitespace is added to meet formatting constraints.

Found some minor stuff in the draft, and had two questions (below). If I should send those to the list instead, let me know :) Does an application server have to have a unique keypair? E.g lets say I have multiple application servers sitting behind a load balancer, could I just share the keys used for vapid between them? In 5.2: Why is a MAY? If I, as a UA, create a restricted subscription my assumption would be that that is actually checked, right? If the Push Service is not planning to check it anyway, wouldn't it make sense to tell the UA directly by responding w/ an error at restricted subscription creation time?
The concept of an application server does not define the quantity— it's fine for multiple servers to share a single key. Martin added text allowing additional claims () which further clarifies that it's fine to include more specific information, for example which server created the message, which is useful if the push service has means for dealing with this. (E.g. QoS or analytics.) I don't recall why that's a MAY. We certainly shouldn't forward unauthorized messages for restricted subscriptions to the user. /cc NAME The changes themselves look good, thanks! :)
Thanks for the explanation NAME Should I open an issue regarding the ?


Question: Data is protected using a number of encryption levels: <del> Plaintext </del> <ins> Initial Keys </ins> Early Data (0-RTT) Keys

I suspect these are uncontroversial.
All three Mart[ie]ns now agree, no further objections allowed.
LGTM, with the one change altered.


Question: "vdaf_verify_param": The aggregator's VDAF verification parameter output by the setup algorithm computed jointly by the aggregators <del> before the start of the PPM protocol I-D.draft-cfrg-patton-vdaf). [OPEN ISSUE: This is yet to be specified.  See issue#161.] </del> <ins> before the start of the PPM protocol VDAF).  [OPEN ISSUE: This is yet to be specified.  See issue#161.] </ins> Finally, the collector is configured with the HPKE secret key corresponding to "collector_hpke_config".

Would be helpful to readers if this reference was fixed in the Editor's Copy: [I-D.draft-cfrg-patton-vdaf] " BROKEN REFERENCE ".
Maybe change each reference to ? That way it'll render like in the text, which reads a bit nicer.


Question: The verifier MUST validate the signature against the expected key of the signer. <del> 7.3.6. </del> <ins> 7.3.5. </ins> This method is indicated by "oauthpop" in the "proof" field.  The signer creates an HTTP Authorization PoP header as described in I-

remove OAuth DPoP binding. Described why on IETF mailing list: only works for asymmetric keys, requires key be presented in the header (duplicating information from GNAP messages). It was never meant to be a general purpose signing mechanism, though the FAPI group in OIDF is considering it as an option in current proposed work.
:heavycheckmark: Deploy Preview for gnap-core-protocol-editors-draft ready! Built :hammer: Explore the source changes: c380eb747945a8002c19de9784e86bee713951a0 :mag: Inspect the deploy log: :sunglasses: Browse the preview:
Ok that's weird (just removed some lines...), will have a look
Ok that was due to my rust analyser in vscode, fixed it now


Question: a context that has a different origin than the top-level browsing context), or a private browsing context. <del> 6.5. </del> <ins> 6.7. </ins> Even when local IP addresses are not exposed, the number of mDNS hostname candidates can still provide a fingerprinting dimension.

I think this is good to go, will plan to land at EOD.
Does it obfuscate, conceal, or obscure local IP addresses? My vote is for conceal.
Conceal/concealment sgtm.
As noted in , we don't need to use the same term in every case, but the terms should have the same meaning. conceal and hide are fairly synonymous, but conceal and obfuscate have slightly different meanings.
This section is largely normative, so it might make more sense to put some parts from it immediately after Principle, namely the various adjustments to the technique that need to be considered (TURN, IPv6, stats) Things where we merely provide discussion (e.g., session monitoring) rather than normative guidance could remain in the privacy section.
Due to their different sensitivity and lifetime.
If we add this indication, do we also need to clarify the use case for lite ICE agents?
What did you have in mind?
{{#gathering}} starts with "For any host candidate gathered by an ICE agent as part of {{RFC8445}} section 5.1.1," it seems the place we need to revise to resolve this issue. I was thinking of allowing ICE lite implementation to skip the mDNS wrapping, since lite agents only use host candidates (8445, section 2.5). The lite implementation is however not required restricted to ICE agents that always have public IPs from my reading of that section, but rather an alternative to simplify the implementation when possible. So I am still not sure if it makes sense to say lite ICE can be exempted from wrapping; or instead indicating mDNS wrapping can be skipped if host candidates are equivalent to srflx candidates, and automatically the intended use of lite ICE satisfies this condition.
Right, the public IPs exception probably covers this. also indicates that this is really for web browsers, which are not allowed to implement ICE Lite.
Started writing this up today, but realized it's not totally clear how this should work. The idea would be to use STUN to figure out if an IP is public or not, but... Should we wait to hand out the mDNS candidate until we determine if the IP is private (i.e., STUN finishes)? Should we not hand out the mDNS candidate if we get a srflx candidate that shows the IP is not private?


Question: a context that has a different origin than the top-level browsing context), or a private browsing context. <del> 6.5. </del> <ins> 6.7. </ins> Even when local IP addresses are not exposed, the number of mDNS hostname candidates can still provide a fingerprinting dimension.

If we hand out the mDNS candidate and then get a srflx candidate that matches the local IP, should we make that a host candidate? Once we learn an IP is not public, should we cache that for future ICE gathering sessions (i.e., not give out mDNS candidates?) The easiest thing would probably be to recommend handing out the mDNS and srflx candidates as usual, but allow implementations to skip mDNS for IPs it has learned are public. (Except for RFC1918 addresses, which would always be treated as private.)
Partially addressed in , will probably include some additional clarifying text once it lands
The rest LGTM


Question: implementation should not aggressively close connections in these scenarios. <del> If the Protocol Stack includes a transport protocol that also supports multipath connectivity with migration support, the Transport Services implementation should also inform the Protocol Instance of potentially new paths that become permissible based on the Selection Properties passed by the application.  A protocol can then establish new subflows over new paths while an active path is still available or, if migration is supported, also after a break has been detected, and should attempt to tear down subflows over paths that are no longer used.  The Transport Services API provides an interface to set a multipath policy that indicates when and how different paths should </del> <ins> If the Protocol Stack includes a transport protocol that supports multipath connectivity, the Transport Services implementation should also inform the Protocol Instance of potentially new paths that become permissible based on the "multipath" Selection Property and the "multipath-policy" Connection Property choices made by the application.  A protocol can then establish new subflows over new paths while an active path is still available or, if migration is supported, also after a break has been detected, and should attempt to tear down subflows over paths that are no longer used.  The Transport Services API's Connection Property "multipath-policy" allows an application to indicate when and how different paths should </ins> be used.  However, detailed handling of these policies is still <del> implementation-specific.  The decision about when to create a new </del> <ins> implementation-specific.  For example, if the "multipath" Selection Property is set to "active", the decision about when to create a new </ins> path or to announce a new path or set of paths to the remote endpoint, e.g., in the form of additional IP addresses, is <del> implementation-specific or could be be supported by future API extensions.  If the Protocol Stack includes a transport protocol that does not support multipath, but does support migrating between paths, the update to the set of available paths can trigger the connection to be migrated. In case of Pooled Connections pooled-connections, the transport system may add connections over new paths or different protocols to the pool if permissible based on the multipath policy and Selection </del> <ins> implementation-specific.  If the Protocol Stack includes a transport protocol that does not support multipath, but does support migrating between paths, the update to the set of available paths can trigger the connection to be migrated. In case of Pooled Connections pooled-connections, the Transport Services implementation may add connections over new paths to the pool if permissible based on the multipath policy and Selection </ins> Properties.  In case a previously used path becomes unavailable, the transport system may disconnect all connections that require this path, but should not disconnect the pooled connection object exposed

Note, the change to the API draft here is a purely editorial detail that I fixed here in passing: the multipath selection property was renamed and this fixes the text referring to it.
"what we discussed" - you mean in , where I say that I stumbled over a sentence? This PR does update that sentence (simply removing "with migration support" from it because any multipath protocol can do that).
no, i meant what we discussed at the interim about using the handover, interactive, aggregate terminology. but i saw that this was not so easily done and we are all happy with your solution, so all good :)
Before distinguishing between protocols that do "multipath" and "migrating between paths", it might help to define these terms. This is tripping is up in QUIC, and IIRC the original "Multipath TCP" was pretty much the migration case. Something like, "In this section we distinguish between 'multipath' protocols and protocols that allow migration between paths. The first means ..."
This is in section 7.2 of taps-impl.
We define multipath (by policy in section 6.1.7 handover, interactive, aggregate) in the API doc. Section 4.2 in Implementation should use these definitions.
I wanted to fix this now, but stumbled over the following sentence in the implementation draft: This talks about the protocol below the transport services system; do multipath-supporting protocols with no migration support exist? I struggle to imagine a scheduler that wouldn't make this happen... e.g. lowest latency scheduling, but with the exception: if a path becomes completely unavailable, keep going? :-) Looking at the three policies in section 6.1.7 of our API, clearly, migration should work with all of them (and "Handover" is limited in that it doesn't do anything else, but it's gotta be a subset of the others anyway, I'd say). Am I missing something? Just checking...
I think the example of no migration support would be a multipath protocol that is not able to add new paths, so SCTP without support for the ADD_ADDR extension perhaps?


Question: implementation should not aggressively close connections in these scenarios. <del> If the Protocol Stack includes a transport protocol that also supports multipath connectivity with migration support, the Transport Services implementation should also inform the Protocol Instance of potentially new paths that become permissible based on the Selection Properties passed by the application.  A protocol can then establish new subflows over new paths while an active path is still available or, if migration is supported, also after a break has been detected, and should attempt to tear down subflows over paths that are no longer used.  The Transport Services API provides an interface to set a multipath policy that indicates when and how different paths should </del> <ins> If the Protocol Stack includes a transport protocol that supports multipath connectivity, the Transport Services implementation should also inform the Protocol Instance of potentially new paths that become permissible based on the "multipath" Selection Property and the "multipath-policy" Connection Property choices made by the application.  A protocol can then establish new subflows over new paths while an active path is still available or, if migration is supported, also after a break has been detected, and should attempt to tear down subflows over paths that are no longer used.  The Transport Services API's Connection Property "multipath-policy" allows an application to indicate when and how different paths should </ins> be used.  However, detailed handling of these policies is still <del> implementation-specific.  The decision about when to create a new </del> <ins> implementation-specific.  For example, if the "multipath" Selection Property is set to "active", the decision about when to create a new </ins> path or to announce a new path or set of paths to the remote endpoint, e.g., in the form of additional IP addresses, is <del> implementation-specific or could be be supported by future API extensions.  If the Protocol Stack includes a transport protocol that does not support multipath, but does support migrating between paths, the update to the set of available paths can trigger the connection to be migrated. In case of Pooled Connections pooled-connections, the transport system may add connections over new paths or different protocols to the pool if permissible based on the multipath policy and Selection </del> <ins> implementation-specific.  If the Protocol Stack includes a transport protocol that does not support multipath, but does support migrating between paths, the update to the set of available paths can trigger the connection to be migrated. In case of Pooled Connections pooled-connections, the Transport Services implementation may add connections over new paths to the pool if permissible based on the multipath policy and Selection </ins> Properties.  In case a previously used path becomes unavailable, the transport system may disconnect all connections that require this path, but should not disconnect the pooled connection object exposed

Not sure this is a case we need to worry about though...
Ah, a multipath protocol that doesn't do multipath :-)
Well, it can do multipath with the paths you give it from the beginning :) Possibly something else was intended with the text from the beginning, but this is what I could think of...
Looks good to me!Thanks for fixing the nits!


Question: A Captive Portal API needs to present information to clients that is unique to that client.  To do this, some systems use information from the context of a request, such as the source address, to identify the <del> UE. </del> <ins> User Equipment. </ins> Using information from context rather than information from the URI allows the same URI to be used for different clients.  However, it also means that the resource is unable to provide relevant <del> information if the UE makes a request using a different network path. This might happen when UE has multiple network interfaces.  It might also happen if the address of the API provided by DNS depends on where the query originates (as in split DNS RFC8499). </del> <ins> information if the User Equipment makes a request using a different network path.  This might happen when User Equipment has multiple network interfaces.  It might also happen if the address of the API provided by DNS depends on where the query originates (as in split DNS RFC8499). </ins> Accessing the API MAY depend on contextual information.  However, the <del> URIs provided in the API SHOULD be unique to the UE and not dependent on contextual information to function correctly. Though a URI might still correctly resolve when the UE makes the request from a different network, it is possible that some functions could be limited to when the UE makes requests using the captive network.  For example, payment options could be absent or a warning could be displayed to indicate the payment is not for the current connection. </del> <ins> URIs provided in the API SHOULD be unique to the User Equipment and not dependent on contextual information to function correctly. Though a URI might still correctly resolve when the User Equipment makes the request from a different network, it is possible that some functions could be limited to when the User Equipment makes requests using the captive network.  For example, payment options could be absent or a warning could be displayed to indicate the payment is not for the current connection. </ins> URIs could include some means of identifying the User Equipment in the URIs.  However, including unauthenticated User Equipment

We only use UE in one section. Everywhere else we use User Equipment. Expand UE in that section so we are consistent with our use of it.
It was pointed out that we sometimes use UE rather than user equipment (e.g. section 3.5.). Let's be consistent, perhaps shortening all references to UE other than where it is defined.


Question: epochs until an honest update from the compromised client happens. Note that under this compromise scenario, the attacker can perform <del> all operations which are available to an legitimate client even </del> <ins> all operations which are available to a legitimate client even </ins> without access to the actual value of the signature key. Without access to the group secrets, the adversary will not have the

For the authors' consideration: Section 3 A member with a valid credential authenticates its MLS messages by signing them with the s/its/it's/ mechanisms for a user to monitor and control which keys are associated to their identity. s/to their/with their/ Operational Requirements A extension can help maintain interoperability s/A extension/An extension/ Whether there should be a extension in groups. s/a extension/an extension/ Forward and Post-Compromise Security MLS partially defend against this problem by active member including freshness, however not s/defend/defends/ s/member/members/ Mandate a key updates from clients that are not otherwise sending messages s/a key/key/ Compromise of AEAD key material authentication is not affected in neither of these s/neither/either/ Compromise of the Group Secrets of a single group for one or more group epochs of the compromised party with no ability to an honest group to recover message secrecy. s/to an/for an/ Compromise by an active adversary with the ability to sign messages the attacker can perform all operations which are available to an legitimate client s/an legitmate/a legitimate/ Compromise of the authentication with access to a signature key Beware that in both oracle and private key access, an active adaptive attacker, can follow th s/attacker, can/attacker can/ Security consideration in the context of a full state compromise They also are providing the strong authentication guarantees to other clients s/providing the strong/providing strong/ hence we consider that their protection by additional security mechanism should be a priority. s/mechanism/mechanisms/ Overall there is no way to detect or prevent these compromise, as discussed s/compromise/compromises/ Privacy of delivery and push notifications For secure messaging systems, push notification are often sent real-time s/notification/notifications/ Authentication Service Compromise MLS client (which is under the control of the user) have often the ability s/have often/often have/
Approved with nits.These changes look good to me.


Question: given QUIC connection, HTTP datagrams contain two layers of multiplexing.  First, the QUIC DATAGRAM frame payload starts with an encoded stream identifier that associates the datagram with a given <del> QUIC stream.  Second, datagrams carry a context identifier (see datagram-contexts) that allows multiplexing multiple datagram </del> <ins> QUIC stream.  Second, datagrams optionally carry a context identifier (see datagram-contexts) that allows multiplexing multiple datagram </ins> contexts related to a given HTTP request.  Conceptually, the first layer of multiplexing is per-hop, while the second is end-to-end.

This change allows clients to disable contexts for a given stream. This uses a new REGISTERDATAGRAMNO_CONTEXT capsule for negotiation. The important property here is that it requires capsule support even when contexts are not required. This is critical to the health of the ecosystem as it will ensure that intermediaries that support datagrams but not capsules cannot be deployed, as that would prevent future extensibility.
Editorial comments aside, I support the protocol feature of an optional DATAGRAM Context ID. Using a registration capsule, as proposed in this PR, is a very logical way of achieving that. I plan to implement this in my WIP code.
Looks like there's support for merging this. Some additional editorial work is needed, but we'll do that in followups.
This issue assumes that decide to go with the two-layer design described in . Given that design, some applications might not need the multiplexing provided by context IDs. We have multiple options here: Make context ID mandatory Applications that don't need it waste a byte per datagram Negotiate the presence of context IDs using an HTTP header Context IDs would still be mandatory to implement on servers because the client might send that header Have the method determine whether context IDs are present or not This would prevent extensibility on those methods Create a REGISTERNOCONTEXT message This assumes we use the Message design from We add a register message that means that this stream does not use context IDs This allows avoiding the byte overhead without sacrificing extensibility
Making the context ID mandatory is simple, although slightly wasteful. For the variations where it is optional, I prefer the one that uses a header. It could work with a variant of where we do Header + Message, and the Header determines whether or not you have contexts, and whether or not they can be dynamic.
What are the benefits of message over header to make it optional? To me it seems like header is sufficient, because the context IDs are end-to-end, and should not affect intermediaries, making the header a natural place to put it. I think having the context ID be the default behavior and the header is to opt-out is the right decision if we were to allow removing it.
This is a bit of a bike-shed, but why would it default to having context-IDs instead of not having them?


Question: given QUIC connection, HTTP datagrams contain two layers of multiplexing.  First, the QUIC DATAGRAM frame payload starts with an encoded stream identifier that associates the datagram with a given <del> QUIC stream.  Second, datagrams carry a context identifier (see datagram-contexts) that allows multiplexing multiple datagram </del> <ins> QUIC stream.  Second, datagrams optionally carry a context identifier (see datagram-contexts) that allows multiplexing multiple datagram </ins> contexts related to a given HTTP request.  Conceptually, the first layer of multiplexing is per-hop, while the second is end-to-end.

I think the second option "Negotiate the presence of context IDs using an HTTP header" is the best personally. In terms of: "Context IDs would still be mandatory to implement on servers because the client might send that header", I assume server in this context is the final application server, not a proxy? Even so, I'd argue it's applications which decide if they need this functionality, so if a server only implemented one application and it didn't use Context-IDs, then I don't see why it would need to implement it.
Ian, in your comment, are you talking about an intermediary when you say "proxy"? If so, then an intermediary need not implement anything based on the payload of than H3 DATAGRAM, it only has to pass the data along. That may be worth a clarification.
Having context ID optional has a nice future-proof property - other uses of datagrams in HTTP/3 can decide if they want the second layer or not. I wouldn't even state it as application needing multiplexing or not. Other applications might find it very useful to include a second ((third, fourth, fifth) layer of frame header. I think its fine for us to state as much in this in the spec, while also defining an explicit second layer for multiplexing.
Yes, by proxy I meant intermediary. And I agree about what intermediaries need to do, I just wanted to ensure I understood what server meant when David used it above. Yup, whenever all this gets written up, we can make it clear that intermediaries can ignore much of this.
The method defines the semantics of datagrams for a particular request, thus I think the third option makes most sense. I don't see a point in using explicit negotiation, since in the two cases I can think of the top of the head, the answer is always clear from the method (CONNECT-IP seems to always want context IDs, WebTransport does not ever want context IDs). If some method starts out without context, but wants to add context later, it can add its own negotiation.
One set of use cases for which the method approach(3) is best are those where there are multiple context IDs but they're predefined by the method and don't need negotiation. My strawman is WebRTC.
Looks good overall.


Question: 3.2. <del> The document focuses on end-to-end coding, i.e. in cases where coding is added at the server and client end points.  The discussions should </del> <ins> The document focuses on end-to-end coding, i.e. cases where coding is added at the server and client end points.  The discussions should </ins> then consider fairness with non-coding solutions. 4. <del> The solution can be described as follows: </del> <ins> The solution can be described as follows: [MICHAEL: So far, it hasn't been clear that we're going to describe a "solution".  A solution to which problem?  I thought we're only discussing how FEC and CC relate.] </ins> <del> The client MUST indicate to the server that one or multiple packets have been repaired using a coding scheme.  The "repaired packet" signal does not guarantee that the packet actually needed to be repaired, since it could have been delayed but not lost. </del> <ins> The client indicates to the server that one or multiple packets have been repaired using a coding scheme.  The "repaired packet" signal does not guarantee that the packet actually needed to be repaired, since it could have been delayed but not lost. </ins> <del> The server MUST be able to detect the "repaired packet" signal. </del> <ins> The server must be able to detect the "repaired packet" signal. </ins> The base solution does not describe how the congestion control reacts to such signal. The rationale behind this solution is the following: the server has more information on the congestion status and the application <del> characteristics.  Moreover, congestion control should not be splitted between multiple entities otherwise non-optimized decisions may be taken. </del> <ins> characteristics.  Moreover, congestion control should not be split between multiple entities, as otherwise non-optimized decisions may be taken. </ins> The proposed solution applies for coding in the transport and <del> application layers.  The proposed approach is inline with the one in </del> <ins> application layers.  The proposed approach is in-line with the one in </ins> I-D.swett-nwcrg-coding-for-quic.  The proposed solution does not <del> applies for the interaction between coding under the transport layer </del> <ins> apply for the interaction between coding under the transport layer </ins> (i.e. not end-to-end), such as coding for tunnels. 5.

This proposes a complete re-vamp of the document. I would also suggest to completely remove sections 6 and 7, but rather than doing this yet, I inserted comments that explain why.
Le 17/01/2020 à 09:28, mwelzl a écrit : Yes ! Definitely agree.
Le 17/01/2020 à 13:50, francoismichel a écrit : OK for me.


Question: can be physically seized or the hosting provider can be required to prevent access Anderson-2011. <ins> 6.4. In some countries, legal mechanisms exist where an individual can issue a legal request to a content host that requires the host to take down content.  Examples include the voluntary systems employed by companies like Google to comply with "Right to be Forgotten" policies in the European Union Google-RTBF and the copyright-oriented notice and takedown regime of the United States Digital Millennium Copyright Act (DMCA) Section 512 DMLP-512. </ins> 7. This document benefited from discussions with Stephane Bortzmeyer,

s/prevention/interference/ ... Censors can degrade performance to a particular site, or for a particular service, effectively making performance so bad for a site that users opt to use a different site or service. China is known to do this. Censors can try to have content removed via takedown requests, under the guise of laws that forbid certain content (e.g., hate speech or whatnot). The ANC is .za has been accused of using the laws in this fashion.
Will Scott also noted in feedback to me that throttling should get more of a call out than it currently does:


Question: 6.3. <del> For performance reasons, an endpoint can receive incoming packets from the underlying platform in a batch of multiple packets.  This batch can contain enough packets to cause multiple acknowledgements to be sent. </del> To avoid sending multiple acknowledgements in rapid succession, an endpoint can process all packets in a batch before determining whether to send an ACK frame in response, as stated in Section 13.2.2

Defer to RFC9000.
The text says: "For performance reasons, an endpoint can receive incoming packets from the underlying platform in a batch of multiple packets." is this the network layer... or something else?
It could be the OS or the hardware.
I think the sentence needs some work - I can believe the network; interface; operating system; etc. Are examples of reasons why there is bunching of packets so that a batch of packets arrive at the receiver. The current text doesn't really say quite what I'd expect.


Question: Padding is a capability provided by binary HTTP messages; see BINARY. If the encapsulation method described in this document is used to protect a different message type (see repurposing), that message <del> format might need to include padding support. </del> <ins> format might need to include padding support.  can also use padding for the same reason, but need to operate at the HTTP layer since they cannot manipulate binary HTTP messages; for example, see HTTP2 or HTTP3). </ins> 6.3.

This came out of , where we realized that the relay padding is useful, but needs to employ different methods than client or gateway. The relay can't use binary HTTP padding; it has to insert stuff at the HTTP layer. Include citations for padding in those documents. Note that these citations are slightly misleading. Most relays won't have access at the level necessary to add that padding. More likely, the relay will need to do as NAME originally suggested, namely adding fields of an appropriate size. But we don't have good citations for that, so I'm cheaping out. (Note that RFC 9112, Section 7.1.1 talks about using chunk extensions for padding, but I'm going to pretend that doesn't exist; it's even less usable than the HTTP/2 and HTTP/3 options.)
Take it or leave it!


Question: UDP-blocking firewalls without using a TURN server. If TCP connections are used, RTP framing according to RFC4571 MUST be <del> used, both for the RTP packets and for the DTLS packets used to carry data channels. </del> <ins> used for all packets.  This includes the RTP packets, DTLS packets used to carry data channels, and STUN connectivity check packets. </ins> The ALTERNATE-SERVER mechanism specified in RFC5389 (STUN) section 11 (300 Try Alternate) MUST be supported.

NAME please review
From Magnus Westerlund in IETF LC review: Section 3.4: If TCP connections are used, RTP framing according to [RFC4571] MUST be used, both for the RTP packets and for the DTLS packets used to carry data channels. I think the last part of this sentence, unintentionally excludes the DTLS handshake packets. The ICE TCP spec also specifies that the STUN connectivity checks are using RFC4571 framing. Thus, I think some reformulation of this sentence is in order.


Question: client validates the server certificate against the public name before retrying. <del> 7.2.8. </del> <ins> 7.3.8. </ins> This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and client certificate verification.  Thus, it is compatible with multiple protocols. <del> 7.3. </del> <ins> 7.4. </ins> Note that the backend server has no way of knowing what the SNI was, but that does not lead to additional privacy exposure because the

Since OCSP is the server name, ESNI should probably enforce OCSP stapling (similar to ) or any other way of encrypted OCSP checks. Ignoring OCSP status checks entirely makes it hard to revoke a certificate, even if it's only valid for a few months.
NAME what behavior do you expect here? Would clients fail hard if server don't send stapled responses? It's good to view ESNI as part of the leaky boat problem. It plugs one hole, but not all of them. Implementations probably should do something about cleartext OCSP if they want all holes plugged.
Thank you for the changes. LGTM.


Question: any given time.  The Issuer public key MUST be made available to all Clients in such a way that key rotations and other updates are publicly visible.  The key material and protocol configuration that <del> an Issuer uses to produce tokens corresponds to a number of different pieces of information. </del> <ins> an Issuer uses to produce tokens corresponds to two different pieces of information. </ins> The issuance protocol in use; and

Supercede's .
Section 6 states: But there's just one subsection. :smiley: More importantly, it's not clear that the Clients are the malicious ones in the examples provided for token exhaustion.
Resolved in by removing the section header.
The security considerations section starts: But only one item, Token Exhaustion, is listed. Should there be more items listed here? Or should the section be collapsed to not have a subsection?
Resolved in by collapsing.


Question: the security and congestion-control properties of QUIC.  However, QUIC DATAGRAM frames do not provide a means to demultiplex application contexts.  This document describes how to use QUIC <del> DATAGRAM frames when the application protocol running over QUIC is HTTP/3.  It associates datagrams with client-initiated bidirectional streams.  Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </del> <ins> DATAGRAM frames with HTTP/3 by association with HTTP requests. Additionally, this document defines the Capsule Protocol that can convey datagrams over prior versions of HTTP. </ins> 1.

In Section 2 we start with the statement So let's just use that clearer description in the abstract and introduction too,


Question: currently open and currently used streams to the application to make the mapping of data to streams dependent on this information. <del> Further, streams have a maximum number of bytes that can be sent on one stream.  This number is high enough (2^64) that this will usually not be reached with current applications.  Applications that send chunks of data over a very long period of time (such as days, months, or years), should rather utilize the 0-RTT session resumption ability provided by QUIC, than trying to maintain one connection open. </del> <ins> While a QUIC implementation must necessarily provide a way for an application to send data on separate streams, it does not necessarily expose stream identifiers to the application (see e.g.  QUIC-HTTP section 6) either at the sender or receiver end, so applications should not assume access to these identifiers. </ins> 4.1.

This document should mention unidirectional streams Some words about the meaning of an abort signal vs. a clean close would be useful, both ingress and egress. Maximum stream bytes = 2^62-1. Saying "there are special streams for QUIC" is inaccurate (it's just one stream now, conceptually), and I would not bother to describe the CRYPTO frames this way.
Also: stream aborts are always unidirectional. what can/should applications assume about stream IDs? are they accessible, and does the app have any control over them?


Question: 5. <del> This section documents the considerations advised in Section 15.3.3 </del> <ins> This section documents the considerations advised in Section 16.3.3 </ins> of SEMANTICS. An intermediary that is not part of the originating service

uses http-core semantics fixes Sections refs cc: NAME
I'll wait for the new i-d-template image, but will do.
Please use either [RFCxxxx], Section yyy or Section yyy of [RFCxxxx]
Addressed by now.
If you start using the new kramdown-rcf2629 section ref syntax, you may want to do that consistently...


Question: connection if servers make reasonable selections when generating new IDs for that connection. <ins> 10.3. A simple deployment of QUIC-LB in a cloud provider might use the same global QUIC-LB configuration across all its load balancers that route to customer servers.  An attacker could then simply become a customer, obtain the configuration, and then extract server IDs of other customers' connections at will. To avoid this, the configuration agent SHOULD issue QUIC-LB configurations to mutually distrustful servers that have different keys (for the block cipher or stream cipher algorithms) or routing masks and divisors (for the obfuscated algorithm).  The load balancers can distinguish these configurations by external IP address, or by assigning different values to the config rotation bits (config-rotation).  Note that either of these techniques exposes information to outside observers, as traffic destined for each server set can be easily distinguished. These techniques are not necessary for the plaintext algorithm, as it does not attempt to conceal the server ID. 10.4. Section 21.9 of QUIC-TRANSPORT discusses the Stateless Reset Oracle attack.  For a server deployment to be vulnerable, an attacking client must be able to cause two packets with the same Destination CID to arrive at two different servers that share the same cryptographic context for Stateless Reset tokens.  As QUIC-LB requires deterministic routing of DCIDs over the life of a connection, it is a sufficient means of avoiding an Oracle without additional measures. </ins> 11. There are no IANA requirements.

Added two sections to Security Considerations (Stateless Reset Oracle and Local Configurations Only). and .
Can you speak a little about your reasoning for the recent changes? If this attack is limited to extracting the identity of server instances for other co-hosted entities, that's probably OK, but I'm having trouble connecting the SHOULD here with the preceding text.
Sure. If an attacker has the same QUIC-LB config as the victim, then it can extract the server mapping, which defeats the whole point of the spec. Obviously, an LB must have the QUIC-LB config for servers it routes to. If I'm an attacker within that group of servers I may already see the packet headers that give away the server mapping, so there's little added linkability here (though there is a little). The moment I share configuration among multiple server pools, I'm expanding the number of entities with access to the config, for no operational benefit except to make the administrator's life easier. In the absurd limit, all of AWS has the same QUIC-LB config, and essentially everyone can extract the server mapping from any CID that goes to AWS.
Add a security consideration to avoid the following scenario: MyCloudProvider has a single QUIC-LB config for all its load balancers. It rotates keys periodically, etc, but everyone gets the same config. Obviously, all the attacker has to do is open an account with MyCloudProvider and it is able to recover all the server IDs. Configs ought to be restricted to load balancers serving a finite set of servers. It is possible another MyCloudProvider customer is in the pool behind that load balancer, but that's already a privileged position as already described in the draft. Obviously, this will require some wordsmithing, as the statement above isn't very precise.
As server clusters increase in size, the need to reallocate server identifiers becomes more acute. In one model, the configuration ID is used to indicate a stable routing configuration. Server identifiers for a given configuration ID are routed to the same server, no matter how many other instances are added or removed. In order to allow for changes in the cluster, the configuration ID is used so that old servers can be removed from consideration and new ones added. If these changes happen frequently enough, the number of bits allocated to identifying a configuration might be insufficient. Why not make the length of the identifier flexible?