Question: Prior to receiving an ACK_FREQUENCY frame, endpoints send acknowledgements as specified in Section 13.2.1 of QUIC-TRANSPORT. <del> On receiving an ACK_FREQUENCY frame and updating its recorded "max_ack_delay" and "Ack-Eliciting Threshold" values (ack-frequency- frame), the endpoint MUST send an acknowledgement when one of the following conditions are met: </del> <ins> On receiving an ACK_FREQUENCY frame and updating its "max_ack_delay" and "Ack-Eliciting Threshold" values (ack-frequency-frame), the endpoint sends an acknowledgement when one of the following conditions are met: </ins> Since the last acknowledgement was sent, the number of received <del> ack-eliciting packets is greater than or equal to the recorded "Ack-Eliciting Threshold". </del> <ins> ack-eliciting packets is greater than the "Ack-Eliciting Threshold". </ins> Since the last acknowledgement was sent, "max_ack_delay" amount of time has passed.

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


Question: This document provides usage guidance for external Pre-Shared Keys (PSKs) in Transport Layer Security (TLS) 1.3 as defined in RFC 8446. <del> This document lists TLS security properties provided by PSKs under certain assumptions, and then demonstrates how violations of these assumptions lead to attacks.  This document discusses PSK use cases and provisioning processes.  This document provides advice for applications to help meet these assumptions.  This document also lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. </del> <ins> It lists TLS security properties provided by PSKs under certain assumptions, and then demonstrates how violations of these assumptions lead to attacks.  Advice for applications to help meet these assumptions is provided.  It also discusses PSK use cases and provisioning processes.  Finally, it lists the privacy and security properties that are not provided by TLS 1.3 when external PSKs are used. </ins> 1.

Address comments from IESG evaluation. Due to the holiday season, we may not get prompt confirmation that these changes fully resolve the comments.


Question: 4.2. TCP conflates transmission order at the sender with delivery order at <del> the receiver, which results in retransmissions of the same data carrying the same sequence number, and consequently leads to "retransmission ambiguity".  QUIC separates the two.  QUIC uses a packet number to indicate transmission order.  Application data is sent in one or more streams and delivery order is determined by stream offsets encoded within STREAM frames. </del> <ins> the receiver, resulting in the retransmission ambiguity problem (RETRANSMISSION).  QUIC separates transmission order from delivery order: packet numbers indicate transmission order, and delivery order is determined by the stream offsets in STREAM frames. </ins> QUIC's packet number is strictly increasing within a packet number space, and directly encodes transmission order.  A higher packet

In the Recovery genart review, Vijay Gurbani wrote:
Based on the proposed PR, I'm marking this as editorial.
In the Recovery genart review, Vijay Gurbani wrote:
Based on the proposed PR, I'm marking this as editorial.


Question: 2. The design goal is to be able to send simple sensor measurements in <del> small packets on mesh networks from large numbers of constrained devices.  Keeping the total size of payload under 80 bytes makes this easy to use on a wireless mesh network.  It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on a 8 bit microprocessor. Experience with power meters and other large scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request.  This "batch" upload capability allows the server side to efficiently support a large number of devices.  It also conveniently supports batch transfers from proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time.  The multiple measurements could be from multiple related sensors or from the same sensor but at different times. </del> <ins> small packets from large numbers of constrained devices.  Keeping the total size of payload small makes it easy to use SenML also in constrained networks, e.g., in a 6LoWPAN RFC4944.  It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on a 8 bit microprocessor.  Experience with power meters and other large scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request.  This "batch" upload capability allows the server side to efficiently support a large number of devices.  It also conveniently supports batch transfers from proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time.  The multiple measurements could be from multiple related sensors or from the same sensor but at different times. </ins> The basic design is an array with a series of measurements.  The following example shows two measurements made at different times.

100 bytes? (Here again I'd remove the text about mesh networks.) mesh networks result in about 80 bytes of usable payload per packet without fragmentation. How about we say keeping it small is good and quote examples of 802.15.4 has about 80 byte payload and that LoRa has 51 byte of applications payload in long range mode and just remove any reference to "mesh"
I'm fine with suggestion above. I'm also fine with just leaving draft as is.
Addressed by PR


Question: If the nodelist is empty, the conversion result is "LogicalFalse". <del> Extraction of a value from a nodelist can be performed in several ways, so an implicit conversion from "NodesType" to "ValueType" may be surprising and has therefore not been defined.  A function expression with a declared type of "NodesType" can indirectly be used as an argument for a parameter of declared type "ValueType" by wrapping the expression in a call to a function extension such as "value" (see value). </del> <ins> Notes: Extraction of a value from a nodelist can be performed in several ways, so an implicit conversion from "NodesType" to "ValueType" may be surprising and has therefore not been defined. A function expression with a declared type of "NodesType" can indirectly be used as an argument for a parameter of declared type "ValueType" by wrapping the expression in a call to a function extension, such as "value()" (see value), that takes a parameter of type "NodesType" and returns a result of type "ValueType". </ins> The well-typedness of function expressions can now be defined in terms of this type system.

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


Question: Section 8.2 of I-D.ietf-add-svcb-dns describes a second downgrade attack where an attacker can block connections to the encrypted DNS <del> server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed.  For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires, unless verification of the resolver fails. </del> <ins> server.  For DDR, clients need to validate a Designated Resolver using a connection to the server before trusting it, so attackers that can block these connections can prevent clients from switching to use encrypted DNS. </ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the

DISCUSS: CC NAME See my discuss on draft-ietf-add-ddr-11 for my generic ADD DNR/DDR concerns Resolver without some sort of validation Why not? What is the alternative? Using unencrypted DNS to the party that told you how and where to contact these (unvalidated) Designated Resolvers. Resolver that does not use a private or local IP address and can be verified using the mechanism described in Section 4.2, it MAY be used on different network connections so long as the subsequent connections over other networks can also be successfully verified using the mechanism described in Section 4.2. This seems to go against a lot of advise in the documents that networks must be treated independently. Also, the network wants you to use their designated resolver, so to say it is okay to use a totally different Designated Resolvers seems to violate the whole DNR/DDR architecture. This will also cause failure if there is split-DNS or internal-only data. Also, using "public IP" is not a good trustworthy method to prove that these IPs are truly the same Designated Resolver used by both networks. I can easily use an internal only zone with . IN A 8.8.8.8 and get a valid ACME'd certificate with SAN=. The user connecting to another network might now be switching from my private DNS on my stolen 8.8.8.8 IP to the real google DNS. address of the designating Unencrypted Resolver in a subjectAltName extension. How feasible is it to get a certificate with SAN=ip from one of the generally accepted root store CA's? Can you give me one example where I can get a certificate for with SAN=193.110.157.123 ? I do not think this is currently possible or easy. If I am right, that means all of Section 4.2 is wishful thinking and not realistic to get rolled out. (I know we can see the cert for 1.1.1.1, so it is possible, but I know of no ACME supported CA that issues these) discovered Designated Resolver. This creates a strange policy when compared to DNR where if you get a DHCP or RA for the Designated Resolver, which is also not validatable, that you do end up using it?


Question: Section 8.2 of I-D.ietf-add-svcb-dns describes a second downgrade attack where an attacker can block connections to the encrypted DNS <del> server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed.  For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires, unless verification of the resolver fails. </del> <ins> server.  For DDR, clients need to validate a Designated Resolver using a connection to the server before trusting it, so attackers that can block these connections can prevent clients from switching to use encrypted DNS. </ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the

And section 6.5 states DNR trumps DDR. address, clients MAY choose to opportunistically use the Designated Resolver even without this certificate check (Section 4.3). Why only when the IP is the same? Why not for when the IP is different? What's to lose, since the only fallback option is stick to using the unencrypted resolver? yields an IP address that was not presented in the Additional Answers section or ipv4hint or ipv6hint fields of the original SVCB query, the connection made to that IP address MUST pass the same TLS certificate checks before being allowed to replace a previously known and validated IP address for the same Designated Resolver name. How does the appearance of an (unsigned) Additional Answer entry convey any kind of real world trust/authentication? In other words, why should it not ALWAYS pass the same TLS certificate checks ? is to use unencrypted DNS, why not just use it anyway? use DDR to discover details about all supported encrypted DNS protocols. It's a little odd to mention this as the DNR draft really tries hard to say to only use the network's offered encrypted DNS servers, so this option is in conflict with the DNR draft. Unfortunately, all currently deployed software does not know this, so it will be very common that this happens. URL SHOULD treat URL as a locally served zone per [RFC6303] Why is this not a MUST ? queries being dropped either maliciously or unintentionally, clients can re-send their SVCB queries periodically. I don't see how this would improve security for the client. It also mixes up behaviour of proper DNS clients that have their own retransmit logic for if they get no answer. attack where an attacker can block connections to the encrypted DNS server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed. For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires I wonder which attacker can block encrypted DNS connections but not spoof (or block!) an unsigned SVCB record to the local client? And even if that is the case, this would be a denial of service attack if the DNS client cannot fallback to unencrypted DNS.


Question: Section 8.2 of I-D.ietf-add-svcb-dns describes a second downgrade attack where an attacker can block connections to the encrypted DNS <del> server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed.  For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires, unless verification of the resolver fails. </del> <ins> server.  For DDR, clients need to validate a Designated Resolver using a connection to the server before trusting it, so attackers that can block these connections can prevent clients from switching to use encrypted DNS. </ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the

Spoofing an SVCB to a bogus IP with an SVCB TTL of a few hours would be a very cheap 1 packet attack to keep the DNS client down for hours. This seems dangerous to implement. unencrypted DNS MUST NOT provide differentiated behavior based on the HTTP path alone, since an attacker could modify the "dohpath" parameter. For example, if a DoH resolver provides provides a filtering service for one URI path, and a non-filtered service for another URI path, [...] It seems likely that this advise will get ignored a lot, eg by people who have limited public IPs to use to spin up a DoH server, or who have to pay-per-IP. This advise seems more appropriate for local private IP DoH servers. So I would change this MUST NOT to SHOULD NOT for that reason. Unencrypted Resolver, clients applying Verified Discovery (Section 4.2) MUST validate that the IP address of the Unencrypted Resolver is covered by the SubjectAlternativeName of the Designated Resolver's TLS certificate. How would one obtain such a certificate via ACME? Since on the IP of the unencrypted resolver, there would be no HTTP server running? Additionally, if the client notices a failed verification of the Designated Resolver's TLS certificate, wouldn't it fallback to the Unencrypted Resolver? But now it may not? So this becomes a denial of service then ? to cases where the Unencrypted Resolver and Designated Resolver have the same IP address. Based on earlier text, this should read "the same non-public IP address". you use "unilateral probing" (draft-ietf-dprive-unilateral-probing) to just connect to the DoT or DoQ ports of the Unencrypted Resolver and see if you get anything back. It might be unauthenticated TLS but better than port 53? Special-Use Domain Names (SUDN) registry established by [RFC6761]. Why not pick URL As .local is already handled to not be forwarded by DNS forwarders. It would also not require an addition to SUDN. Even if someone was already using URL, it would not interfere with that usage because that usage would not be using SVCB records.


Question: Section 8.2 of I-D.ietf-add-svcb-dns describes a second downgrade attack where an attacker can block connections to the encrypted DNS <del> server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed.  For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires, unless verification of the resolver fails. </del> <ins> server.  For DDR, clients need to validate a Designated Resolver using a connection to the server before trusting it, so attackers that can block these connections can prevent clients from switching to use encrypted DNS. </ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the

To avoid name lookup deadlock, Designated Resolvers SHOULD follow the guidance in Section 10 of [RFC8484] regarding the avoidance of DNS- based references that block the completion of the TLS handshake. I find that reference to list more the issues than solutions that can be followed. The solution to use another DoH server is not really appropriate in most cases The client's other interface likely resides on other networks where its private DoH server cannot resolve the name of another network's private DoH server. It is also not easy to get an IP based certificate (eg SAN=ip) that is accepted by general webpki root stores. And things like OCSP stapling doesn't help if the target is malicious - they just would omit the stapling that proves against its malicious use. The only real advise usable from RFC8484 is "use the local unencrypted resolver to resolve the encrypted resolver". Might as well say that and remove the 8484 reference. as the protocol is mentioned throughout the document as interacting with this protocol. when accessing web content on a dual-stack network: A, AAAA, and HTTPS queries. Discovering a Designated Resolver as part of one of these queries, without having to add yet another query, minimizes the total number of queries clients send. I don't understand this paragraph. Once clients can send SVCB queries for web content, they already have had to do all the DDR/DNR related queries, so I don't understand the argument of "saving queries" ? Also, it is adding queries for a specific target, eg URL, and this cannot be "saved" either? What am I misunderstanding here? provides provides -> provides
We should reference Security Considerations, because if you don't have any validation, an attacker can point you to any server they want (someone other than the server you were configured with by DHCP, etc).
We can probably just remove this, not using it in implementations right now.
It's already done by the major public resolvers, and there is an RFC to support this (RFC 8738). The IP address validation is clearly important and a matter of WG consensus. Hopefully, this will push adoption of RFC 8738 by more ACME services.
We can reference the DNR section. The MUST NOT should only apply to DDR, but doesn't invalidate other ways of using the resolver.


Question: Section 8.2 of I-D.ietf-add-svcb-dns describes a second downgrade attack where an attacker can block connections to the encrypted DNS <del> server, and recommends that clients prevent it by switching to SVCB- reliant behavior once SVCB resolution does succeed.  For DDR, this means that once a client discovers a compatible Designated Resolver, it SHOULD NOT use unencrypted DNS until the SVCB record expires, unless verification of the resolver fails. </del> <ins> server.  For DDR, clients need to validate a Designated Resolver using a connection to the server before trusting it, so attackers that can block these connections can prevent clients from switching to use encrypted DNS. </ins> DoH resolvers that allow discovery using DNS SVCB answers over unencrypted DNS MUST NOT provide differentiated behavior based on the

If they are different, it can be a random attacker (see security considerations). The client may also have other better options to fall back to.
Agree, this should be simplified to say "even if you connect over a different IP address for any reason, still validate the original IP address"
There are definitely cases where the client can have directly selected their own resolver name, etc. We don't have to use the network resolver.
Correct, and that's why we need this document, and it was added to the IANA section.
Sure, we can make this a MUST.
It makes the attacker's job harder by requiring them to be persistent. Normal retransmission logic is fine too.
This is a direct outcome of the svcb-dns document. Spoofing SVCB shouldn't be enough to cause a DoS here, because we should continue to use the previously used encrypted DNS server while on this network (even if you get a bad SVCB packet).
For the security reasons, I think this needs to stay as a MUST NOT. However, if you differentiate based on hostname + path, you can still differentiate, it just isn't a differentiation that can be discovered by IP address queries.
Yes, you'd fall back to unencrypted resolution if you can't have a secure trusted connection for encrypted resolution.
Yes, but that part is SHOULD. Will fix.
I think that's just opportunistic DoT / DoQ. That's already specified.
.local is the SUDN for multicast DNS, but it is also squatted on by some internal networks. Following the patterns for URL, etc, .arpa is a much more appropriate name. This is what the group had consensus on years ago and has been deployed widely already.
I think we can say "as explained in RFC 8484, don't loop on the resolver name."
Sure, that's fine.
Yeah, this paragraph is old and can be removed.
Looks good! Just silly editorial nits


Question: param_value_definition : If for any one of the endpoints the parameter is absent or set to 0, <del> or if the two endpoints select incompatible values, one proposing 0x1 and the other proposing 0x2, the endpoints MUST fallback to QUIC- TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If an endpoint proposes the value 0x3, the value proposed by the other is accepted.  If both endpoints propose the value 0x3, the value 0x2 is negotiated. </del> <ins> the endpoints MUST fallback to QUIC-TRANSPORT with single active path and MUST NOT use any frame or mechanism defined in this document. </ins> If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type

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


Question: param_value_definition : If for any one of the endpoints the parameter is absent or set to 0, <del> or if the two endpoints select incompatible values, one proposing 0x1 and the other proposing 0x2, the endpoints MUST fallback to QUIC- TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If an endpoint proposes the value 0x3, the value proposed by the other is accepted.  If both endpoints propose the value 0x3, the value 0x2 is negotiated. </del> <ins> the endpoints MUST fallback to QUIC-TRANSPORT with single active path and MUST NOT use any frame or mechanism defined in this document. </ins> If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type

If the client spoofs a path, it will never receive the challenge, and thus the server will never receive the response and will not validate the path. See section 8.2 of RFC 9000, path validation. Security section 21.1.3. Connection Migration states that "Path validation () establishes that a peer is both willing and able to receive packets sent on a particular path."
So yes, the current text should be "the servers MUST in turn attempt to validate these paths using the same mechanisms, as specified in {{ Section 8.2 of RFC9000 }}."
No, this should not be a MUST. It is true that the path MUST be validated before it can be used. However, just because the serve receives a new packet on a path, that doesn't automatically mean that the server has to start path validation. It could e.g. also decide to simply withdraw that packet.
Actually, this is also not right. This is what RFC9000 says (section 9): So I guess we should maybe not use normative language here but refer to section 9 in RFC9000 instead...?
Just submitted PR for this issue.
This draft initially originates from a merging effort of previous Multipath proposals. While many points were found to be common between them, there remains one design point that still requires consensus: the number of packet number spaces that a Multipath QUIC connection should support (i.e., one for the whole connection vs. one per path). The current draft enables experimentation with both variants, but in the final version we will certainly need to choose between one of the versions.
The main issues mentioned so far: Efficiency. One number space per path should be more efficient, because implementations can directly reuse the loss-recovery logic specified for QUIC ACK size. Single space leads to lots of out of order delivery, which causes ACK sizes to grow Simplicity of code. Single space can be implemented without adding mane new code paths to uni-path QUIC Shorter header. Single space works well with NULL length CID The picoquic implementation shows that "efficiency" and "ack size" issues of single space implementations can be mitigated.


Question: param_value_definition : If for any one of the endpoints the parameter is absent or set to 0, <del> or if the two endpoints select incompatible values, one proposing 0x1 and the other proposing 0x2, the endpoints MUST fallback to QUIC- TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If an endpoint proposes the value 0x3, the value proposed by the other is accepted.  If both endpoints propose the value 0x3, the value 0x2 is negotiated. </del> <ins> the endpoints MUST fallback to QUIC-TRANSPORT with single active path and MUST NOT use any frame or mechanism defined in this document. </ins> If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type

However, that required significant improvements in the code: to obtain good loss efficiency, picoquic remembers not just the path on which a packet was sent, but also the order of the packet on this path, i.e. a "virtual sequence number". The loss detection logic then operates on that virtual sequence number. to contain ACK size, picoquic implements a prioritization logic to select the most important ranges in an ACK, avoid acking the same range more than 3 or 4 times, and keep knowledge of already acknowledged ranges so range coalescing works. I think these improvements are good in general, and I will keep them in the implementations whether we go for single space or not. The virtual sequence number is for example useful if the CID changes for reasons not related to path changes in multiple number space variants. It is also useful in unipath variants to avoid interference between sequence numbers used in probes and the RACK logic. The ACK size improvements do reduce the size of ACKs in presence of out of order delivery, e.g., if the network is doing some kind of internal load balancing. On the other hand, the improvements are somewhat complex, would need to be described in separate drafts, and pretty much contradicts the "simplicity of code" argument. So we are left with the "Null length CID" issue. I see for cases: Client CID Priority ----------------------- long Used by many implementations NULL Preferred configuration of many big deployments long Rarely used, server load balancing does not work NULL Only mentioned in some P2P deployments The point here is that it is somewhat hard to deploy a large server with NULL CID and use server load balancing. This configuration is mostly favored by planned P2P deployments.
The big debate is for the configuration with NULL CID on client, long CID on server. The packets from server to client do not carry a CID, and only the last bytes of the sequence number. The client will need some logic to infer the full sequence number before decrypting the packet. The client could maybe use the incoming 5 tuple as part of the logic, but it is not obvious. It is much simpler to assume a direct map from destination CID to number space. That means, if a peer uses a NULL CID, all packets sent to that peer are in the same number space.


Question: param_value_definition : If for any one of the endpoints the parameter is absent or set to 0, <del> or if the two endpoints select incompatible values, one proposing 0x1 and the other proposing 0x2, the endpoints MUST fallback to QUIC- TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If an endpoint proposes the value 0x3, the value proposed by the other is accepted.  If both endpoints propose the value 0x3, the value 0x2 is negotiated. </del> <ins> the endpoints MUST fallback to QUIC-TRANSPORT with single active path and MUST NOT use any frame or mechanism defined in this document. </ins> If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type

Revised table: Client CID What -- -- long Multiple number space NULL Multiple number spaces on client side (one per CID), single space on server side long Multiple number spaces on server side (one per CID), single space on client side NULL single number space on each side If a node advertises both NULL CID and multipath support, they SHOULD have logic to contain the size of ACK. If a node engages in multipath with a NULL CID peer, they SHOULD have special logic to make loss recovery work well.
I think the above points to a possible "unified solution": if multipath negotiated, tie number spaces to destination CID, use default (N=0) if NULL CID. use multipath ack; in multipath ACK, identify number space by sequence number of DCID in received packets. Default that number to zero if received with NULL CID. in ABANDON path, identify path either by DCID of received packets, SCID of sent packet, or "this path" (sending path) if CID is NULL.
I like the proposal of the "unified solution". I think the elegance lies in the fact that it allows us to automatically cover all four cases listed above. The previous dilemma for me was that on one hand we have some use cases where we need to support more than two paths and separate PN makes the job easier, but on the other hand, I think we should not ignore the NULL CID use cases as it is also important. Now, with this proposal, a big part of the problem is solved. The rest of challenge is to make sure single PN remains efficient in terms of ACK and loss recovery. On that part, we plan to do an A/B test and would love to share the results when we get them. There is one more problem as pointed in issue , when we want to take hardware offloads into account. In such a case, we may still need single PN for long server CID. However, if hardware supports nonce modification, this problem can be addressed with the proposed "unified solution".
If the APi does not support 96 bit sequence numbers, it should always be possible to create an encryption context per number space, using Key=current key and ID = current-ID + CID sequence number. Of course, that forces creation of multiple context, and that makes key rotation a bit harder to manage. But still, that should be possible.


Question: param_value_definition : If for any one of the endpoints the parameter is absent or set to 0, <del> or if the two endpoints select incompatible values, one proposing 0x1 and the other proposing 0x2, the endpoints MUST fallback to QUIC- TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If an endpoint proposes the value 0x3, the value proposed by the other is accepted.  If both endpoints propose the value 0x3, the value 0x2 is negotiated. </del> <ins> the endpoints MUST fallback to QUIC-TRANSPORT with single active path and MUST NOT use any frame or mechanism defined in this document. </ins> If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type

Thanks for the summary NAME I think one point is missing in your list which is related to issue . Use of a single packet number space might not support ECN. Regarding the unified solution: I think what you actually say is that we would specify both solutions and everybody would need to implement both logics. At least regarding the "simplicity of code" argument, that would be the worst choice. If we can make the multiple packet number spaces solution work with one-sided CIDs, I'm tending toward such an approach. Use of multiple packet number spaces avoids ambiguity/needed "smartness" in ACK handling and packet scheduling which, as you say above, can make the implementation more complex and, moreover, wrong decisions may have large impact on efficient (both local processing and on-the-wire). I don't think we want to leave these things to each implementation individually.
The summary Christian made above about design comparison sounds indeed quite accurate. Besides ECN, my other concern about single packet number is that it require cleverness from the receiver side if you want to be performant in some scenarios. At the sender-side, you need to consider a path-relative packet number threshold instead of an absolute one to avoid spurious losses. Just a point I think we did not mentioned yet is that there can be some interactions between Multipath out-of-order number delivery and incoming packet number duplicate detection. This requires maintaining some state at the receiver side, as described by URL With single packet number space, the receiver should take extra care when updating the "minimum packet number below which all packets are immediately dropped". Otherwise, in presence of paths with very different latencies, the receiver might end up discarding packets from a (slower) path. I'm also preferring the multiple packet number spaces solution for the above reasons. I'm not against thinking for a "unified" solution (the proposal sounds interesting), but I wonder how much complexity this would add compared to requiring end hosts to use one-byte CIDs.
I think the issue is not really so much "single vs multiple number space" as "support for multipath and NULL CID". As noted by Mirja, there is an implementation cost there. My take is: If a node uses NULL CID and proposes support of multipath, then that node MUST implement code to deal with size of acknowledgements.


Question: param_value_definition : If for any one of the endpoints the parameter is absent or set to 0, <del> or if the two endpoints select incompatible values, one proposing 0x1 and the other proposing 0x2, the endpoints MUST fallback to QUIC- TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If an endpoint proposes the value 0x3, the value proposed by the other is accepted.  If both endpoints propose the value 0x3, the value 0x2 is negotiated. </del> <ins> the endpoints MUST fallback to QUIC-TRANSPORT with single active path and MUST NOT use any frame or mechanism defined in this document. </ins> If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type

If a node sees a peer using NULL CID and supporting multipath, then that node MUST either use only one path at a time or implement code to deal with impact on loss detection due to out of order arrivals, and impact on congestion control including ambiguity of ECN signals. Then add sections on what it means to deal with the side of acknowledgements, out of order arrivals, and congestion control. I think this approach ends up with the correct compromises: It keeps the main case simple. Nodes that rely on multipath just use long CID and one number space per CID. Nodes that use long CID never have to implement the ACK length minimization algorithms. Nodes that see a peer using NULL CID have a variety of implementation choices, e.g., sending on just one path at a time, sending on mostly one path at a time in "make or break" transitions, or implementing sophisticated algorithms. If we do that, we can get rid of the single vs multiple space discussion, and end up with a single solution addressing all use cases.
Looking at all the discussions here and in other issues such as ECN, I think that we should try to write two different versions of section 7: one covering all the aspects of single packet number space (RTT estimation, retransmissions, ECN, handling of CIDs, ...) one covering all the aspects of multiple packet number space (RTT estimation, retransmissions, ECN, handling of CIDs, ...) There would be some overlap between these two sections and also some differences that would become clear as we specify them. At the end of this writing, we'll know whether it is possible to support/unify both or we need to recommend a single one. The other parts of the document are almost independent of that and can evolve in parallel with these two sections. However, I don't think that such a change would be possible by Monday
I don't think we should rush changes before we have agreed on the final vision.
It might be helpful to have these options as PRs (without merging) them, so people can understand all details of each approach.
I agree with NAME that supporting multi-path with null CIDs is a more fundamental issue than the efficiency comparison between single PN and separate PN, as it would ultimately impact the application scope of multipath QUIC. But indeed, we might want to implement proposed solution first and then decide if we want to adopt such a unified approach.


Question: param_value_definition : If for any one of the endpoints the parameter is absent or set to 0, <del> or if the two endpoints select incompatible values, one proposing 0x1 and the other proposing 0x2, the endpoints MUST fallback to QUIC- TRANSPORT with single path and MUST NOT use any frame or mechanism defined in this document. If an endpoint proposes the value 0x3, the value proposed by the other is accepted.  If both endpoints propose the value 0x3, the value 0x2 is negotiated. </del> <ins> the endpoints MUST fallback to QUIC-TRANSPORT with single active path and MUST NOT use any frame or mechanism defined in this document. </ins> If endpoint receives unexpected value for the transport parameter "enable_multipath", it MUST treat this as a connection error of type

Since NAME prodded me, we now have a PR for the "unified" proposal.
I totally agree with Christian that the issue is about "support for multipath and NULL CID", and the solution that Christian suggested looks really great! It both takes advantage of multiple spaces, and support NULL CID users without affect the efficiency of ACK arrangements. Besides, the solution is more convenient for implementations, because If both endpoints uses non-zero length cids, endpoints only need to support multiple spaces, and if one of the endpoints use NULL CID, it could use single pn space in one direction and could support NULL CID and multipath at the same time.
Very high level summary of IETF-113 discussion seems that there is interest and likely support for the unified solution (review minutes for further details).


Question: The helper handles well-formed requests as follows.  (As usual, malformed requests are handled as described in pa-error-common- aborts.)  It first looks for the PDA parameters "PDAParam" for which <del> "PDAAggregateReq.task_id" is equal to the task id derived from </del> <ins> "PDAAggregateReq.task_id" is equal to the task ID derived from </ins> "PDAParam". The response consists of the helper's updated state and a sequence of

I added a clarification that the nonce is random. IMO the question of who randomly generates the nonce goes with the question of how participants agree upon PDAParams, which is to say it's outside the protocol.
On the 2021/7/7 design call we decided that the ID should be derived deterministically from the serialized PAParam by, for example, hashing it. This solves a few problems simultaneously. This settles the question of whether there should be 1:1 correspondence between a task ID and the parameters used for that task. NAME brought up an interesting question, which is how to make the task ID unique when two different data collection tasks use the same parameters. Thoughts?
The consensus here is to do SHA-256 over the PDAParams structure and use that as the 32 byte PDATaskID. However, hashing a protocol message requires us to decide on a canonical representation of a protocol message, which I think forces us to decide how to encode messages on the wire. I filed for that question. I'll proceed with a PR for this issue on the assumption that we'll pick JSON.
As I mentioned there, the assumption would be that we're adopting TLS' binary encoding. If so, in TLS notation, you would write as the hash of , which itself is a serialized data structure.
All we require is that each PAParam have some unique value, right? A random nonce would probably suffice. r.e. the encoding, yes, let's stick with TLS's wire format as NAME suggests.
Yes, my thinking was that we would just stick 16 bytes of random data in (a UUID's worth). I agree that we should stick with TLS binary encoding.
Approved, with the following suggestion: Let's leave a [TODO: ...] comment under the definition of for clarifying how it should be chosen.


Question: handshake even though the Retry itself was sent using the original version. <del> 6.2. </del> <ins> 7.2. </ins> QUIC version 1 uses TLS 1.3, which supports session resumption by sending session tickets in one connection that can be used in a later

Can an ALPN label be used for multiple QUIC versions? I think that the text should say something like: NAME adds (and I wholly agree):
I'm merging into this one where NAME said "The point is that your ALPN offer when you offer QUICvX shouldn't be dependent on if you did VN or not."
LGTM


Question: for other control processes, and a short header that may be used for data transmission in an established connection.  While the long header always exposes some information (such as the version and <del> Connection IDs), the short header only optionally exposes a single Connection ID. Given that exposing this information may make it possible to associate multiple addresses with a single client during rebinding, which has privacy implications, an application may indicate to not support exposure of certain information after the handshake. Specifically, an application that has additional information that the client is not behind a NAT and the server is not behind a load balancer, and therefore it is unlikely that the addresses will be re- bound, may indicate to the transport that is wishes to not expose a </del> <ins> Connection IDs), the short header exposes at most only a single </ins> Connection ID. 6.1. QUIC supports a server-generated Connection ID, transmitted to the client during connection establishment (see Section 6.1 of QUIC). <del> Servers behind load balancers should propose a Connection ID during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support stateless load balancing.  Once the server generates a Connection ID that encodes its identity, every CDN load balancer would be able to forward the packets to that server without needing information about every specific flow it is forwarding. Server-generated Connection IDs must not encode any information other that that needed to route packets to the appropriate backend server(s): typically the identity of the backend server or pool of servers, if the data-center's load balancing system keeps "local" state of all flows itself.  Care must be exercised to ensure that the information encoded in the Connection ID is not sufficient to identify unique end users.  Note that by encoding routing information in the Connection ID, load balancers open up a new attack vector that allows bad actors to direct traffic at a specific backend server or pool.  It is therefore recommended that Server-Generated Connection ID includes a cryptographic MAC that the load balancer pool server is able to identify and discard packets featuring an invalid MAC. </del> <ins> Servers behind load balancers may need to propose a Connection ID during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support stateless load balancing.  Once the server generates a Connection ID that encodes its identity, every CDN load balancer would be able to forward the packets to that server without retaining connection state. Server-generated connection IDs should seek to obscure any encoding, of routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption. </ins> 6.2. <ins> While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection. Analysis of the lifetimes of six-tuples (source and destination addresses as well as the migrated CID) may expose these links anyway. In the limit where connection migration in a server pool is rare, it is trivial for an observer to associate two connection IDs. Conversely, in the opposite limit where every server handles multiple simultaneous migrations, even an exposed server mapping may be insufficient information. The most efficient mitigation for these attacks is operational, either by using a load balancing architecture that loads more flows onto a single server-side address, by coordinating the timing of migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. 6.3. </ins> QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new Connection ID in that packet and the client will retry by sending

Tries to I resisted the urge to reference the QUIC-LB draft, which isn't adopted. The major substantive change is that I removed the prohibition on non-routing information in the CID. I'm happy to discuss this if people have object.
LGTM. will go ahead and land this, then fix up the lint issues.
NAME missed this during the inconsistency, will fix in working copy
(this is done)
BTW, this was meant to address
Moving URL to the ops repo.
see also -- in any case the text that is there now is not great.
NAME can you please review the existing text (orginially provided by NAME and state what else is needed? Please have also a look at issue
This is a bit OBE, but I think there might still be value in discussing how a server implementer should think about connection IDs. Fortunately, NAME has been doing a bunch of work on this in his load balancer draft. I would suggest that we leave this issue open, and either point to the LB draft or use text from it.
fixed this
Write section to provide guidance; maybe in the same section than guidance in port selection in general


Question: Compute a COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm of the selected cipher suite, using the encryption key K_4, the <del> initialization vector IV_4, the plaintext P, and the following parameters as input (see COSE): </del> <ins> initialization vector IV_4, the plaintext PLAINTEXT_4, and the following parameters as input (see COSE): </ins> protected = h''

There has been a lot of suggestions and discussion regarding the key derivation latelely. Below is an attempt to summarize all the current suggstions that currently seems relatively likely to be done. This is not an issue in itself but I think it is good to have somewhere to discucess the complete changes to the key derivation. Suggested to permute the order of element in the TH2 sequence to be more resistant to any future collision attacks in hash functions. Exact order unclear but suggested to put the random and unpredictable GY first. Suggested to use PLAINTEXT instead of CIPHERTEXT in transcript hashes to simplify formal verification. Endpoints agree on that they received the same plaintext rather then the same cipertext.Suggested to use a salt derived from PRK in Extract to avoid usign the PRK keys directly in both Extract and ExpandSuggested to use unsigned integer instead of text string for label to save memory.Suggestion to add a final key derivation PRKout and use that in the exporter. Note that the exporter would also have uint labelsSuggestion to base Key-Update on Expand instead of extract. The label would need IANA registration. hashlength is a new variable that the implementation needs to keep track of. Should considered whether using Exporter for KeyUpdate has any disadvantages. Suggested that more info on how an application protocol is supposed to use KeyUpdate and Exporter together is needed.The EDHOC internal key derivations (i.e., not using the Exporter) would then be something like below. The exact labels should be discussed. Note that that only some of the derivations actually need a label to avoid collisionIncluding KeyUpdate, the IANA registered exporter labels could be:
Looks good. I had different naming in mind of the salts: PRK3e2m = Extract( SALT3e2m, GRX ) PRK3m = Extract( SALT3m, GIY ) where SALT3e2m = EDHOC-KDF( PRK2e, TH2, 0, h'', hashlength ) SALT3m = EDHOC-KDF( PRK3e2m, TH3, 0, h'', hashlength ) With this the salts are named by its use rather than from what key they are derived.
The labels was just to illustrate the fact that they don't need to be separate.


Question: Compute a COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm of the selected cipher suite, using the encryption key K_4, the <del> initialization vector IV_4, the plaintext P, and the following parameters as input (see COSE): </del> <ins> initialization vector IV_4, the plaintext PLAINTEXT_4, and the following parameters as input (see COSE): </ins> protected = h''

I think it is still better to just use 0-7. That makes it very easy for the reader to see that there are no collisions.
NAME Was this a comment on my proposed names of salts, or a separate comment? (I agree labels 0-7 is good.)
It was a separate comments. Your suggestion for salt naming is fine with me. Some other non-technical naming things that a hidden in my summary above I think keylength should use different terms in the derivation of K4 and OSCORE Master Secret. The current naming gives the idea that they are the same. I think the contexts in the MAC2 and MAC3 derivations should be given names. Should consider collection all the EDHOC-KDF derivations in a single place.
Might want to derive: K4 = EDHOC-KDF( PRK3m, TH4, 0, h'', keylength ) IV4 = EDHOC-KDF( PRK3m, TH4, 0, h'', ivlength ) to avoid that the applicaiton gets K4 and IV4. Another alternative is to use K4 = EDHOC-Exporter( 7, h'', keylength ) IV4 = EDHOC-Exporter( 8, h'', ivlength ) and forbid the application to use the labels for K4 and IV4
Editorial; should be: K4 = EDHOC-KDF( PRK3m, TH4, 1, h'', keylength ) IV4 = EDHOC-KDF( PRK3m, TH4, 2, h'', ivlength ) or, if we want all KDF labels distinct: K4 = EDHOC-KDF( PRK3m, TH4, 8, h'', keylength ) IV4 = EDHOC-KDF( PRK3m, TH4, 9, h'', ivlength ) Alternatively, application access to Exporter only allows uint with: K4 = EDHOC-Exporter( -1, h'', keylength ) IV4 = EDHOC-Exporter( -2, h'', ivlength )
Trying to compile the suggestions.


Question: Compute a COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm of the selected cipher suite, using the encryption key K_4, the <del> initialization vector IV_4, the plaintext P, and the following parameters as input (see COSE): </del> <ins> initialization vector IV_4, the plaintext PLAINTEXT_4, and the following parameters as input (see COSE): </ins> protected = h''

These have a PR: Suggested to permute the order of element in the TH2 sequence … Suggested to use PLAINTEXT instead of CIPHERTEXT in transcript hashes … Suggestion to add a final key derivation PRKout and use that in the exporter The following needs to be addressed: Suggested to use a salt derived from PRK in Extract define salt derive salt Suggested to use unsigned integer instead of text string for label to save memory suggestion to base Key-Update on Expand consider whether using Exporter for KeyUpdate has any disadvantages. more info on how an application protocol is supposed to use KeyUpdate and Exporter together distinguish keylength in K3/K_4 and OSCORE Master Secret define contexts explicitly table of KDF derivations
Trying to put things together. Let's call this variant A, part 1. where and (edit: depending on method) New salts to avoid double use of PRK, named by its use. Same construction for K4/IV4 as K3/IV3, motivating the renaming of 3m in as 4e3m. The label in the KDF, third argument, is an uint, all distinct for simplicity.
Variant A, part 2: Distinct "transcript hash" in KeyUpdate and Exporter. Exporter does not give access to EDHOC internal keys. OSCORE key length separate from key_length. Edit: Not clear that 'context' is needed in the EDHOC-Exporter. Also, to be strict in labelling we could continue enumeration. Here is variant B, part 2 (B.1 = A.1):
Variant C.2 (C.1 = A.1): (edited:) Same as B.2 but with different labels. With variant C we have essentially: the internal KDF labels with current list: 0, ..., 9; and the IANA EDHOC Exporter Registry with current list: 0, 1.
NAME NAME NAME and all: Any implementation considerations or other comments on variant C above? We'll start with the PR(s) soon.
The last posts here are confusing.... I don't agree. These are separate. We should definitly not try to keep them separate. I.e.


Question: Compute a COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm of the selected cipher suite, using the encryption key K_4, the <del> initialization vector IV_4, the plaintext P, and the following parameters as input (see COSE): </del> <ins> initialization vector IV_4, the plaintext PLAINTEXT_4, and the following parameters as input (see COSE): </ins> protected = h''

it should be Master Secret = EDHOC-Exporter( 0, h'', oscorekeylength ) Master Salt = EDHOC-Exporter( 1, h'', oscoresaltlength )
The above looks good to me with the following not so interesting options. order of the 0-9 labels use 10 or 0 label for Key-Update order of the h'00' and h'01' "transcripts"
I think we should maybe merge the "context" and "transcript hash" inputs. This simplifies things and avoids using h'00' and h''01' as "transcript hashes.
Alternatively
The latest version of the summary URL looks good.
Overview of main changes needed: Merge Rename PRK3m as PRK4e3m Section 4.1 update PRK definitions move section PRKout to 4.2 Section 4.2 Update EDHOC-KDF and info definition Update derivations Include derivations of salts and K4 / IV4 List EDHOC-KDF derivations with labels 0-9 Section 4.3 Update EDHOC-Exporter (use label 10 instead of 11) Remove derivation of K4 / IV4 Section 4.4 Update EDHOC-KeyUpdate (use label 11 instead of 10) Section 5.3.2 Define context2 Section 5.4.2 Define context3 Section 9.1 Update EDHOC Exporter labels Appendix A.1 Update Master Secret/Salt derivation
Additional updates: As noted in previous comment, a proposal to interchange labels 10 and 11 to enumerate labels in the order they appear in the specification. (Other proposal for assignment of integer labels is welcome.) Should we align / adapt definition of contextx and externalaad? Currently (for message2 and similar for message3): externalaad = > context2 = > Edit: Seems to be favourable to at least align this blobs, so changed context2 to > and similar for context_3, in 5464707a
PRKexporter is a key which we only introduce for simple distinction between different KDF applications. Perhaps an overkill? May open up for unnecessary discussion about properties of that key. Here is another variant: Edit: As commented before, Marco thinks a separate PRKExporter is preferred; less error prone etc.


Question: Compute a COSE_Encrypt0 as defined in Sections 5.2 and 5.3 of I- D.ietf-cose-rfc8152bis-struct, with the EDHOC AEAD algorithm of the selected cipher suite, using the encryption key K_4, the <del> initialization vector IV_4, the plaintext P, and the following parameters as input (see COSE): </del> <ins> initialization vector IV_4, the plaintext PLAINTEXT_4, and the following parameters as input (see COSE): </ins> protected = h''

Most old comments are now addressed, and there are quite a few changes, so it is a good time to merge PR . Remaining points: derivation of K4/ IV4 and text about key confirmation. Not clear if there is any difference in practice between K4 /IV4 being derived from PRK4e3m or PRKout, but the current text about explicit key confirmation is not valid in the former case. May alternatively tune down the key confirmation terminology. Suggested to make clearer distinction between key derivation for EDHOC processing, resulting in PRKout, and key derivation for application, i.e. making use of PRKout in EDHOC-Exporter and EDHOC-KeyUpdate. More guidance on the latter is also proposed.
Tried to address the remaining points in the previous comment with the latest two commits: 5d675ac and 95e35bb. More guidance on KeyUpdate may still be needed. Other points?
NAME What more guidance is needed on KeyUpdate?
Was a request from someone. Might be hard to understand how to use it. E.g. that you should alternate key update and exporter Exporter Key Update Exporter Key Update Exporter ...
Another guidance needed is how to manage overwrite of PRKout pending confirmation of the derived key from the other endpoint. When the Initiator is updating PRKout it needs both old and new derived keys to be able to communicate securely in lock-step the change to the new key.
Perhaps good to remark that the entire application contexts (including e.g. sequence numbers) need to be maintained before a transition is made.
see instead. The current discussion has very little to do with


Question: To avoid excessively small idle timeout periods, endpoints MUST increase the idle timeout period to be at least three times the <del> current Probe Timeout (PTO). </del> <ins> current Probe Timeout (PTO).  This allows for multiple PTOs to expire prior to idle timeout, ensuring the idle timeout does not expire as a result of a single packet loss. </ins> 10.1.1.

I believe these two cases are both 3*PTO to allow the PTO to expire at least once before declaring path validation failure and idle timeout.
Thanks for your suggestions, I'm quite happy with this now.
NAME says in : This is reasonable. I don't know which document needs the text though.
This looks like it should go into -recovery, since -transport mostly only refers to as a TP, except in Section 13.2.1 ("sending-acknowledgements"), but that text is very general.
I would suggest that this should go where a value of X PTOs is suggested for each specific timer.
Relabeling, since ended up being against -transport and not -recovery.


Question: 4.2.2. <del> The ADDRESS_REQUEST capsule allows an endpoint to request assignment of an IP address from its peer.  This capsule is not required for simple client/proxy communication where the client only expects to receive one address from the proxy.  The capsule allows the endpoint to optionally indicate a preference for which address it would get assigned.  This capsule uses a Capsule Type of 0xfff101.  Its value uses the following format: </del> <ins> The ADDRESS_REQUEST capsule (see iana-types for the value of the capsule type) allows an endpoint to request assignment of an IP address from its peer.  This capsule is not required for simple client/proxy communication where the client only expects to receive one address from the proxy.  The capsule allows the endpoint to optionally indicate a preference for which address it would get assigned. </ins> IP Version of this address request.  MUST be either 4 or 6.

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


Question: must instead match what was supplied in the offer, as described above. <del> Unless codec preferences have been set for the associated transceiver, the media formats on the m= line MUST be generated in the same order as in the current local description. </del> Each "a=ice-ufrag" and "a=ice-pwd" line MUST stay the same, unless the m= section is restarting, in which case new ICE credentials must be created as specified in RFC5245, Section 9.2.1.1.  If the

LGTM and if Justin wants to tie in the stuff from my comment a bit more that is great
NAME PTAL
seems like it's generally right,LGTM


Question: following restriction: The fields of the "o=" line MUST stay the same except for the <del> <session-version> field, which MUST increment if the session description changes in any way, including the addition of ICE candidates. </del> <ins> <session-version> field, which MUST increment by one on each call to createOffer if the offer might differ from the output of the previous call to createOffer; implementations MAY opt to increment <session-version> on every call.  The value of the generated <session-version> is independent of the <session-version> of the current local description; in particular, in the case where the current version is N, an offer is created with version N+1, and then that offer is rolled back so that the current version is again N, the next generated offer will still have version N+2. Note that if the application creates an offer by reading currentLocalDescription instead of calling createOffer, the returned SDP may be different than when setLocalDescription was originally called, due to the addition of gathered ICE candidates, but the <session-version> will not have changed.  There are no known scenarios in which this causes problems, but if this is a concern, the solution is simply to use createOffer to ensure a unique <session-version>. </ins> If the initial offer was applied using setLocalDescription, but an answer from the remote side has not yet been applied, meaning the

From meeting minutes "SDP o= line increment [] While the proposed solution on the slide was accepted, it was noted that the proposal on the slide goes against what was agreed at last meeting. Emil Ivov also commented that Trickle ICE for SIP does exactly what is described on the slide. Jonathan Lennox said that we should make sure this is compatible with whatever is done in trickle ICE SIP stacks."
This algorithm becomes correct once we decide to not allow o= modification. Editorial comments follow.
Discussion in-room: 1) add example to make it clear that there is a separate counter (other than current o=) which is what increments. 2) change text about <session-version> to be more of a "note that" for an edge case, as opposed to normative text about a mainline case.
Updated this branch. PTAL
LGTM
2349: "might differ" is creepy. "differs" perhaps. 2359: "N + 2" -> must be greater than N + 1 This is basically OK modulo the above


Question: provide a signature on a signature allowing for a proof that a signature existed at a given time (i.e., a timestamp). <ins> A CoSWID SHOULD be signed, using the above mechanism, to protect the integrity of the CoSWID tag.  See the security considerations (in sec-sec) for more information on why a signed CoSWID is valuable in most cases. </ins> 8. This specification allows for tagged and untagged CBOR data items

Addressed the following comments: [Per IETF 110] Add text on the order of native CDDL approach for handling version is used. If a future version of SWID is published which alters the semantics of exists fields, a future version of CoSWID SHOULD (MUST?) use a different tag to represent it. [daw: A new paragraph was added to section 2 detailing how index values are used to support revisions and extensions.] [Per IETF 110] see -16. Use ISO SWID reference for the IANA registry and if desired, used [SEMVER] as an informal reference in the text [daw: This has been done in section 4.1.] [daw: The FIXME markers have been replaced with actual text.] [daw: Section 7 now details the construction of a signed CoSWID. A SHOULD sign requirement was also added to section 7.] [Per IETF 110] We discussed adding language on the order of "This document specifies a data format and an associated integrity mechanism agnostic of a deployment. Application which choose to use CoSWID will need to specify explicit guidance which security properties are needed and under which circumstances." > ** [-15] Section 6. Per "When an authoritative tag is signed, the software [daw: Authenticating the signer is the software provider will require a match between a CoSWID entity and the signer. We are working out a means to do this.] 2 [daw: Not sure which tags this applies to? Signing? All of section 2?] [daw: done.] [daw: This confusing text has been removed.] [daw: done.] [daw: We added a note about this.] [daw: Done.] [daw: Added signature validation as a way.] Regards, Roman


Question: Before the client can upload its report to the leader, it must know the public key of each of the aggregators.  These are retrieved from <del> each aggregator by sending a request to "[aggregator]/hpke_config", where "[aggregator]" is the aggregator's endpoint URL, obtained from the task parameters.  The aggregator responds to well-formed requests with status 200 and an "HpkeConfig" value: </del> <ins> each aggregator by sending a request to "[aggregator]/hpke_config?task_id=[task-id]", where "[aggregator]" is the aggregator's endpoint URL, obtained from the task parameters, and "[task-id]" is the task ID obtained from the task parameters, encoded in Base 64 with URL and filename safe alphabet with no padding, as specified in sections 5 and 3.2 of RFC4648.  If the aggregator does not recognize the task ID, then it responds with HTTP error status 404 Not Found and an error of type "unrecognizedTask".  The aggregator responds to well-formed requests with status 200 and an "HpkeConfig" value: [TODO: Allow aggregators to return HTTP 403 Forbidden in deployments that use authentication to avoid leaking information about which tasks exist.] </ins> [OPEN ISSUE: Decide whether to expand the width of the id, or support multiple cipher suites (a la OHTTP/ECH).]

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


Question: Time-Sensitive Network. <del> 2.3. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. </del> 3. The basic approach defined in I-D.ietf-detnet-mpls supports the

ip-over-tsn (nits) mpls-over-tsn (nits) tsn-vpn-over-mpls (nits, ch5.2, ch5.3)


Question: match a value provided in the corresponding "ECHConfig.cipher_suites" list. <del> A cryptographic hash of the "ECHConfig" structure from which the ECH key was obtained, i.e., from the first byte of "version" to the end of the structure.  This hash is computed using the hash function associated with "cipher_suite", i.e., the corresponding HPKE KDF algorithm hash. </del> <ins> Equal to "Expand(Extract("", config), "ech_config_digest", Nh)", where "config" is the "ECHConfig" structure and "Extract", "Expand", and "Nh" are as specified by the cipher suite KDF. (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.) </ins> The HPKE encapsulated key, used by servers to decrypt the corresponding "encrypted_ch" field.

Per NAME suggestion, this replaces computations involving the "hash underlying the KDF" with evaluation of the KDF itself. This respects the API defined in the HPKE draft. This supersedes .
Hey NAME and NAME I rolled up your changes! Please have another look before merging.
Rebased and rolled up.
Thanks -- let's let this stew until Friday, at which point we can merge.
Rebased.
Field is computed as "digest of the complete ClientHelloInner" (including presumably, the "outer_extensions" extension). I don't understand the analytical value of this hash. Can anyone explain its reasoning?
The hash is intended to prevent the attacker from influencing the reconstructed CHInner by manipulating CHOuter. Consider the contrived example of an extension which is separately protected but only works for SNI-A and not SNI-B. E.g., it's constructed by doing E(K_sni, SNI). If that extension were included in CHOuter and then imported into CHInner via this mechanism, then an attacker could substitute it and use a reaction attack to determine whether the CH referred to A or B. However, with the hash (which may be not well-specified), this attack gets caught by the client-facing server and the handshake is rejected without leaking information.
My initial understanding of this mechanism was incorrect. What happens is that the hash is computed over the ClientHelloInner that is consumed by the backend server. This is intended to ensure that if ECH accepts, then the backend server consumes the CH intended by the client. (PR URL makes this more clear, I think.) I wonder if this mechanism is redundant. Agreement on the CH between the client and backend server is provided by the binding of the transcript hash to the handshake traffic secret, so any attempt to manipulate the ClientHelloInner by fiddling with the ClientHelloOuter should be detected. On the other hand, the binding of the outer extensions to ClientHelloInner ensures agreement on the CH prior to the backend server consuming it. This is a strictly stronger property, which may or may not be useful. I agree that the attack works, but the example seems really contrived :) I'd be interested if there are more natural extensions for which this extra layer of security would be useful.
From the interim meeting, the consensus seems to be that we should err on the conservative side.


Question: match a value provided in the corresponding "ECHConfig.cipher_suites" list. <del> A cryptographic hash of the "ECHConfig" structure from which the ECH key was obtained, i.e., from the first byte of "version" to the end of the structure.  This hash is computed using the hash function associated with "cipher_suite", i.e., the corresponding HPKE KDF algorithm hash. </del> <ins> Equal to "Expand(Extract("", config), "ech_config_digest", Nh)", where "config" is the "ECHConfig" structure and "Extract", "Expand", and "Nh" are as specified by the cipher suite KDF. (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.) </ins> The HPKE encapsulated key, used by servers to decrypt the corresponding "encrypted_ch" field.

Let's close this issue and leave the mechanism as is.
Hrm, before closing I think it might be worth noting, in the spec, the stronger security property this provides.
I think we should also consider binding the CHInner to a hash of the whole CHOuter (minus the ClientEncryptedCH extension). That would have the same size overhead, but would give us a stronger property: modifying anything in CHOuter (not just one of the copied extensions) invalidates the whole thing.
The point of hashing outer extensions is to provide integrity of the ClientHelloInner. What would be the point in hashing more of the ClientHelloOuter? (Not a rhetorical question :) It seems conceptually different, and I'm curious what the security benefit might be.)
If we authenticate the ClientHelloOuter, we'd be authenticating all the inputs that go into the ClientHelloInner, so I think that would also provide integrity. I expect Ben is suggesting this in the context of URL, where GREASE can additionally be made a little stronger if we did that. Getting that to interact well with any PSK binders in ClientHelloOuter is tricky though, unless we decide to ban resumption attempts in outer ClientHellos. (Probably best to keep the GREASE-related conversation in one place. Though I see I didn't help on that front because some discussion is also in . Ah, GitHub.)
Yep, I'm just echoing NAME observation. See also URL
Today, the only thing that gets copied into ClientHelloInner is extensions, so I don't see how it's an improvement in terms of our primary security goal. (Not sure about the "don't stick out" benefit.)
I don't understand how hashing all of CHOuter is going to work. In split mode, the server never sees any of CHOuter.
Yes, the hash would be checked when reconstructing the inner ClientHello (as here), and would not be present in the reconstructed ClientHello.
There's not much discussion here. Unless there's objection, shall we leave the mechanism as-is and close out this issue? cc/ NAME
Works for me.
From Section 6.1: This assumes that the KDF specifies some underlying hash function.


Question: match a value provided in the corresponding "ECHConfig.cipher_suites" list. <del> A cryptographic hash of the "ECHConfig" structure from which the ECH key was obtained, i.e., from the first byte of "version" to the end of the structure.  This hash is computed using the hash function associated with "cipher_suite", i.e., the corresponding HPKE KDF algorithm hash. </del> <ins> Equal to "Expand(Extract("", config), "ech_config_digest", Nh)", where "config" is the "ECHConfig" structure and "Extract", "Expand", and "Nh" are as specified by the cipher suite KDF. (Passing the literal """" as the salt is interpreted by "Extract" as no salt being provided.) </ins> The HPKE encapsulated key, used by servers to decrypt the corresponding "encrypted_ch" field.

From the HPKE spec, it seems like all that's required of the KDF is that it's an "extract-then-expand" KDF: URL In fact, the currently assigned code points are all for HKDF: URL But there's no requirement that the KDF always have some underlying hash function. As an alternative to HKDF, one can imagine a dedicated primitive that satisfies the extract-then-expand API but is not constructed from a hash function.
Impacted fields: ClientEncryptedCH.record_digest URL
We can probably replace with and be done with it.
Putting on my theorist hat, I'd say that the extract function is a "randomness extractor" and not a collision resistant hash function. We want the latter in this context. From a practical stand point, using the extract function is more hashing than we need. I'd suggest doing away with (see ) and figuring something else out for . Could we simply require HKDF be used with HPKE?
Sure, but in practice randomness extractors use a collision resistant hash or PRF (CBC) under the hood. I don't think we can require HKDF for HPKE. That seems too restrictive. We might just say that ECH requires HKDF-based HPKE ciphersuites, as HKDF is already paramount for TLS 1.3, and then just reference HKDF's hash function.
addresses this issue.
As I mentioned on the list, we can use the KDF in place of a hash.
I tend to agree. I'll create a new PR.
Have a look at , NAME
Resolved in . Closing.


Question: CertificateEntry. If the corresponding certificate type extension <del> ("server_certificate_type" or "client_certificate_type") was not used or the X.509 certificate type was negotiated, then each CertificateEntry contains an X.509 certificate.  The sender's certificate MUST come in the first CertificateEntry in the list. Each following certificate SHOULD directly certify one preceding it. Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </del> <ins> ("server_certificate_type" or "client_certificate_type") was not negotiated in Encrypted Extensions, or the X.509 certificate type was negotiated, then each CertificateEntry contains an X.509 certificate. The sender's certificate MUST come in the first CertificateEntry in the list.  Each following certificate SHOULD directly certify one preceding it.  Because certificate validation requires that trust anchors be distributed independently, a certificate that specifies a trust anchor MAY be omitted from the chain, provided that supported peers are known to possess any omitted certificates. </ins> Note: Prior to TLS 1.3, "certificate_list" ordering required each certificate to certify the one immediately preceding it; however,

the RFC 7250 semantics that both certificate types are globally negotiated. There is no support for mixed certificates.


Question: That the client controls the identifier in question. <del> This process may be repeated to associate multiple identifiers to a key pair (e.g., to request certificates with multiple identifiers) or to associate multiple accounts with an identifier (e.g., to allow </del> <ins> This process may be repeated to associate multiple identifiers with an account (e.g., to request certificates with multiple identifiers) or to associate multiple accounts with an identifier (e.g., to allow </ins> multiple entities to manage certificates). Authorization resources are created by the server in response to <del> certificate orders or authorization requests submitted by an account key holder; their URLs are provided to the client in the responses to </del> <ins> newOrder or newAuthorization requests submitted by an account key holder; their URLs are provided to the client in the responses to </ins> these requests.  The authorization object is implicitly tied to the account key used to sign the request. <del> When a client receives an order from the server in reply to a new order request, it downloads the authorization resources by sending </del> <ins> When a client receives an order from the server in reply to a newOrder request, it downloads the authorization resources by sending </ins> POST-as-GET requests to the indicated URLs.  If the client initiates authorization using a request to the newAuthz resource, it will have already received the pending authorization object in the response to

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


Question: involves sending a cookie exchange to avoid DoS attacks. Protocols: QUIC + TLS, DTLS, WireGuard <ins> 5.3. Connection Termination The security protocol may be instructed to tear down its connection and session information.  This is needed by some protocols to prevent application data truncation attacks. Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 </ins> Key Update The handshake protocol may be instructed to update its keying material, either by the application directly or by the record protocol sending a key expiration event. Protocols: TLS, DTLS, QUIC + TLS, MinimalT, tcpcrypt, IKEv2 <del> Pre-Shared Key Export The handshake protocol will generate one or more keys to be used for record encryption/decryption and authentication.  These may be explicitly exportable to the application, traditionally limited to direct export to the record protocol, or inherently non-exportable because the keys must be used directly in conjunction with the record protocol. </del> <ins> Pre-Shared Key Export The handshake protocol will generate one or more keys to be used for record encryption/decryption and authentication.  These may be explicitly exportable to the application, traditionally limited to direct export to the record protocol, or inherently non-exportable because the keys must be used directly in conjunction with the record protocol. </ins> Explict export: TLS (for QUIC), tcpcrypt, IKEv2, DTLS (for SRTP)

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


Question: Steps: <del> Run "(cfg, update) = PP_Server_Setup(id)". </del> <ins> Run "(cfg, update) = ServerSetup(id)". </ins> Construct a "config_update" message.

These functions do not need the "PP_" namespace prefix as it's implied from the specification. I also removed underscores in favor of normal camel case notation.


Question: Priority handling of retransmissions can be implemented by the sender in the transport layer.  QUIC recommends retransmitting lost data before new data, unless indicated differently by the application. <del> Currently, QUIC only provides fully reliable stream transmission, which means that prioritization of retransmissions will be beneficial in most cases, by filling in gaps and freeing up the flow control window.  For partially reliable or unreliable streams, priority scheduling of retransmissions over data of higher-priority streams might not be desirable.  For such streams, QUIC could either provide an explicit interface to control prioritization, or derive the prioritization decision from the reliability level of the stream. </del> <ins> When a QUIC endpoint uses fully reliable streams for transmission, prioritization of retransmissions will be beneficial in most cases, filling in gaps and freeing up the flow control window.  For partially reliable or unreliable streams, priority scheduling of retransmissions over data of higher-priority streams might not be desirable.  For such streams, QUIC could either provide an explicit interface to control prioritization, or derive the prioritization decision from the reliability level of the stream. </ins> 4.3.

From PR : I'd also like to see something like : /In this section, we discuss those aspects of the QUIC transport protocol that/This section discusses those aspects of the QUIC transport protocol that/ /Here, we are concerned primarily with the unencrypted part of QUIC's wire image {{WIRE-IMAGE}}, which we define as the information available in the packet/This section is concerned primarily with the unencrypted part of QUIC's wire image {{WIRE-IMAGE}}, defined as the information available in the packet/ and /least four datagrams we'll call "Client Initial",/least four datagrams, labelled "Client Initial",/ and / 0-RTT data may also be seen in the Client Initial datagram, as shown in /When the client uses 0-RTT connection resumption, the Client Initial datagram can also carry 0-RTT data, as shown in/ and /typically around 10 packets/typically to around 10 packets/ and /of a connection after one of one endpoint/of a connection after an endpoint/ I'd prefer more like: /Though the guidance there holds, a particularly unwise behavior admits a handful of UDP packets and then makes a decision as to whether or not to filter later packets in the same connection. QUIC applications are encouraged to fail over to TCP if early packets do/ ... and I'll close PR .
“QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established or because the information is intended to be used by the network.” Could this benefit form a cross-reference to manageability, where this topic is also discussed from a network perspective?
Three places where the text might avoid confusion when read in future years: 1) “Further downgrades to older TLS versions than used in QUIC, which is 1.3, “ … will it always be 1.3, or should this be “in QUIC [REF] is TLS 1.3” 2) “Currently, QUIC only provides fully reliable stream transmission, which means that prioritization of retransmissions will be beneficial in most cases, by filling in gaps and freeing up the flow control window.


Question: Priority handling of retransmissions can be implemented by the sender in the transport layer.  QUIC recommends retransmitting lost data before new data, unless indicated differently by the application. <del> Currently, QUIC only provides fully reliable stream transmission, which means that prioritization of retransmissions will be beneficial in most cases, by filling in gaps and freeing up the flow control window.  For partially reliable or unreliable streams, priority scheduling of retransmissions over data of higher-priority streams might not be desirable.  For such streams, QUIC could either provide an explicit interface to control prioritization, or derive the prioritization decision from the reliability level of the stream. </del> <ins> When a QUIC endpoint uses fully reliable streams for transmission, prioritization of retransmissions will be beneficial in most cases, filling in gaps and freeing up the flow control window.  For partially reliable or unreliable streams, priority scheduling of retransmissions over data of higher-priority streams might not be desirable.  For such streams, QUIC could either provide an explicit interface to control prioritization, or derive the prioritization decision from the reliability level of the stream. </ins> 4.3.

“ I'm not so happy with currently here: Is this the best way to say this, might it be better to say this rather than even hinting that future QUIC might only be reliable: “When a QUIC endpoint provides provides fully reliable stream transmission, prioritization of retransmissions will be beneficial in most cases, by filling in gaps and freeing up the flow control window. “ 3) I’d prefer to see a ref here, since this something that the WG might later decide to work upon: “Currently QUIC only supports failover cases [Quic-Transport].”
That mega paragraph has a bunch of good concepts, but it's all run together into a single blob, which makes it a bit hard to follow.


Question: ClientHello message in their first Initial packet. The TLS implementation does not need to ensure that the ClientHello <del> is sufficiently large.  QUIC PADDING frames are added to increase the size of the packet as necessary. </del> <ins> is large enough to meet the requirements for QUIC packets.  QUIC PADDING frames are added to increase the size of the packet as necessary; see Section 14.1 of QUIC-TRANSPORT. </ins> 4.4.

NAME I'll leave that in your hands.
NAME said:
Seems reasonable. I took the opportunity to reword a little.
Perhaps this PR should also fix the text in 8.1 to simply state and point to 14.1 in -transport. That text is redundant.


Question: Clients using Opportunistic Discovery (opportunistic) MUST be limited to cases where the Unencrypted DNS Resolver and Designated Resolver <del> have the same IP address.  Clients which do not follow Opportunistic Discovery (opportunistic) and instead try to connect without first checking for a designation run the possible risk of being intercepted by an attacker hosting an Encrypted DNS Resolver on an IP address of an Unencrypted DNS Resolver where the attacker has failed to gain </del> <ins> have the same IP address, which SHOULD be a private or local IP address.  Clients which do not follow Opportunistic Discovery (opportunistic) and instead try to connect without first checking for a designation run the possible risk of being intercepted by an attacker hosting an Encrypted DNS Resolver on an IP address of an Unencrypted DNS Resolver where the attacker has failed to gain </ins> control of the Unencrypted DNS Resolver. The constraints on the use of Designated Resolvers specified here

DISCUSS: CC NAME See my discuss on draft-ietf-add-ddr-11 for my generic ADD DNR/DDR concerns Resolver without some sort of validation Why not? What is the alternative? Using unencrypted DNS to the party that told you how and where to contact these (unvalidated) Designated Resolvers. Resolver that does not use a private or local IP address and can be verified using the mechanism described in Section 4.2, it MAY be used on different network connections so long as the subsequent connections over other networks can also be successfully verified using the mechanism described in Section 4.2. This seems to go against a lot of advise in the documents that networks must be treated independently. Also, the network wants you to use their designated resolver, so to say it is okay to use a totally different Designated Resolvers seems to violate the whole DNR/DDR architecture. This will also cause failure if there is split-DNS or internal-only data. Also, using "public IP" is not a good trustworthy method to prove that these IPs are truly the same Designated Resolver used by both networks. I can easily use an internal only zone with . IN A 8.8.8.8 and get a valid ACME'd certificate with SAN=. The user connecting to another network might now be switching from my private DNS on my stolen 8.8.8.8 IP to the real google DNS. address of the designating Unencrypted Resolver in a subjectAltName extension. How feasible is it to get a certificate with SAN=ip from one of the generally accepted root store CA's? Can you give me one example where I can get a certificate for with SAN=193.110.157.123 ? I do not think this is currently possible or easy. If I am right, that means all of Section 4.2 is wishful thinking and not realistic to get rolled out. (I know we can see the cert for 1.1.1.1, so it is possible, but I know of no ACME supported CA that issues these) discovered Designated Resolver. This creates a strange policy when compared to DNR where if you get a DHCP or RA for the Designated Resolver, which is also not validatable, that you do end up using it?