Question: certainly as examining decrypted traffic. Because HTTPS has historically layered HTTP on top of TLS, which is <del> in turn layered on top of TCP, intermediaries do have access to unencrypted TCP-level transport information, such as retransmissions, and some carriers exploited this information in attempts to improve transport-layer performance RFC3135.  The most recent standardized version of HTTPS, HTTP/3 I-D.ietf-quic-http, uses the QUIC protocol RFC9000 as its transport layer.  QUIC relies on the TLS 1.3 initial handshake RFC8446 only for key exchange RFC9001, and encrypts almost all transport parameters itself except for a few invariant header fields.  In the QUIC short header, the only transport-level parameter which is sent "in the clear" is the Destination Connection ID RFC8999, and even in the QUIC long header, the only transport-level parameters sent "in the clear" are the Version, Destination </del> <ins> in turn layered on top of TCP, intermediaries have historically had access to unencrypted TCP-level transport information, such as retransmissions, and some carriers exploited this information in attempts to improve transport-layer performance RFC3135.  The most recent standardized version of HTTPS, HTTP/3 RFC9114, uses the QUIC protocol RFC9000 as its transport layer.  QUIC relies on the TLS 1.3 initial handshake RFC8446 only for key exchange RFC9001, and encrypts almost all transport parameters itself except for a few invariant header fields.  In the QUIC short header, the only transport-level parameter which is sent "in the clear" is the Destination Connection ID RFC8999, and even in the QUIC long header, the only transport- level parameters sent "in the clear" are the Version, Destination </ins> Connection ID, and Source Connection ID.  For these reasons, HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2.

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


Question: certainly as examining decrypted traffic. Because HTTPS has historically layered HTTP on top of TLS, which is <del> in turn layered on top of TCP, intermediaries do have access to unencrypted TCP-level transport information, such as retransmissions, and some carriers exploited this information in attempts to improve transport-layer performance RFC3135.  The most recent standardized version of HTTPS, HTTP/3 I-D.ietf-quic-http, uses the QUIC protocol RFC9000 as its transport layer.  QUIC relies on the TLS 1.3 initial handshake RFC8446 only for key exchange RFC9001, and encrypts almost all transport parameters itself except for a few invariant header fields.  In the QUIC short header, the only transport-level parameter which is sent "in the clear" is the Destination Connection ID RFC8999, and even in the QUIC long header, the only transport-level parameters sent "in the clear" are the Version, Destination </del> <ins> in turn layered on top of TCP, intermediaries have historically had access to unencrypted TCP-level transport information, such as retransmissions, and some carriers exploited this information in attempts to improve transport-layer performance RFC3135.  The most recent standardized version of HTTPS, HTTP/3 RFC9114, uses the QUIC protocol RFC9000 as its transport layer.  QUIC relies on the TLS 1.3 initial handshake RFC8446 only for key exchange RFC9001, and encrypts almost all transport parameters itself except for a few invariant header fields.  In the QUIC short header, the only transport-level parameter which is sent "in the clear" is the Destination Connection ID RFC8999, and even in the QUIC long header, the only transport- level parameters sent "in the clear" are the Version, Destination </ins> Connection ID, and Source Connection ID.  For these reasons, HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2.

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


Question: certainly as examining decrypted traffic. Because HTTPS has historically layered HTTP on top of TLS, which is <del> in turn layered on top of TCP, intermediaries do have access to unencrypted TCP-level transport information, such as retransmissions, and some carriers exploited this information in attempts to improve transport-layer performance RFC3135.  The most recent standardized version of HTTPS, HTTP/3 I-D.ietf-quic-http, uses the QUIC protocol RFC9000 as its transport layer.  QUIC relies on the TLS 1.3 initial handshake RFC8446 only for key exchange RFC9001, and encrypts almost all transport parameters itself except for a few invariant header fields.  In the QUIC short header, the only transport-level parameter which is sent "in the clear" is the Destination Connection ID RFC8999, and even in the QUIC long header, the only transport-level parameters sent "in the clear" are the Version, Destination </del> <ins> in turn layered on top of TCP, intermediaries have historically had access to unencrypted TCP-level transport information, such as retransmissions, and some carriers exploited this information in attempts to improve transport-layer performance RFC3135.  The most recent standardized version of HTTPS, HTTP/3 RFC9114, uses the QUIC protocol RFC9000 as its transport layer.  QUIC relies on the TLS 1.3 initial handshake RFC8446 only for key exchange RFC9001, and encrypts almost all transport parameters itself except for a few invariant header fields.  In the QUIC short header, the only transport-level parameter which is sent "in the clear" is the Destination Connection ID RFC8999, and even in the QUIC long header, the only transport- level parameters sent "in the clear" are the Version, Destination </ins> Connection ID, and Source Connection ID.  For these reasons, HTTP/3 is significantly more "opaque" than HTTPS with HTTP/1 or HTTP/2.

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


Question: The length of the Certificate message once it is uncompressed.  If after decompression the specified length does not match the actual length, the party receiving the invalid message MUST abort the <del> connection with the "bad_certificate" alert. </del> <ins> connection with the "bad_certificate" alert.  The presence of this field allows the receiver to pre-allocate the buffer for the uncompressed Certificate message and to enforce limits on the message size before performing decompression. </ins> The compressed body of the Certificate message, in the same format as it would normally be expressed in.  The compression algorithm

State explicitly that we do not define any compression dictionaries. Explain the rationale behind the uncompressed_length field. Addresses comments from John Mattsson on the list.
Actually, I have a small nit.


Question: If not populating the "path" field: Set the "path" field in the Commit to the null optional.  Define "commit_secret" as the all- <del> zero vector of the same length as a "path_secret" value would be. In this case, the new ratchet tree is the same as the provisional ratchet tree. </del> <ins> zero vector of length "KDF.Nh" (the same length as a "path_secret" value would be).  In this case, the new ratchet tree is the same as the provisional ratchet tree. </ins> Derive the "psk_secret" as specified in pre-shared-keys, where the order of PSKs in the derivation corresponds to the order of

Right now, the vector is described in a couple of ways. This PR standardizes on "of length ".


Question: 2.4. New QUIC connections are established using a handshake, which is <del> distinguishable on the wire and contains some information that can be passively observed. </del> <ins> distinguishable on the wire (see sec-identifying for details), and contains some information that can be passively observed. </ins> To illustrate the information visible in the QUIC wire image during the handshake, we first show the general communication pattern

Could the first 1200-byte QUIC packet be used to suspect a QUIC connection establishment ? [MK] Yes, I think if you look at the first packet as a whole you can be reasonably sure that you look at a quic packet. I guess this is an assumption throughout the whole document, as section 2.4 says: "New QUIC connections are established using a handshake, which is distinguishable on the wire and contains some information that can be passively observed." [MK] Do we need to say more? EV> hummm I guess not even if the text in 2.4 is rather generic while the point in 3.1 is really specific. Perhaps adding which handshake properties are 'distinguishable' already in section 2.4 ?
proposes to fix this with a forward reference.


Question: empty redemption contexts must be stored and shared across all requests until token-key expiration or rotation. <ins> Origins that share redemption contexts, i.e., by using the same redemption context, choosing the same issuer, and providing the same origin_info field in the TokenChallenge, must necessarily share state required to enforce double spend prevention.  Origins should consider the operational complexity of this shared state before choosing to share redemption contexts.  Failure to successfully synchronize this state and use it for double spend prevention can allow Clients to redeem tokens to one Origin that were issued after an interaction with another Origin that shares the context. </ins> 2.1.2. Clients can generate multiple tokens from a single TokenChallenge,

The section references seem to be breaking the build, so I'll fix that later before we land this.
Origins currently choose whether their challenges are per-origin or cross-origin. For cross-origin, double-spend prevention is only as good as the coordination between origins and the Issuer. Per-origin allows double-spend prevention to be isolated to a single origin; also prevents the cache of tokens being take up by some other origin.
Write this as "any origins that share a redemption context must also share double spend state for that context."


Question: 5. A DNS client that already knows the name of an Encrypted Resolver can <del> use DEER to discover details about all supported encrypted DNS </del> <ins> use DDR to discover details about all supported encrypted DNS </ins> protocols.  This situation can arise if a client has been configured to use a given Encrypted Resolver, or if a network provisioning protocol (such as DHCP or IPv6 Router Advertisements) provides a name

Changed 2 instances of DEER to DDR
I was so focused on finding "equivalent" that I missed a couple deer apparently. Thank you!


Question: server has selected for the negotiated key exchange.  Servers MUST NOT send a KeyShareEntry for any group not indicated in the "supported_groups" extension and MUST NOT send a KeyShareEntry when <del> using the "psk_ke" PskKeyExchangeMode.  If a HelloRetryRequest was received by the client, the client MUST verify that the selected NamedGroup in the ServerHello is the same as that in the </del> <ins> using the "psk_ke" PskKeyExchangeMode.  If using (EC)DHE key establishment, and a HelloRetryRequest containing a "key_share" extension was received by the client, the client MUST verify that the selected NamedGroup in the ServerHello is the same as that in the </ins> HelloRetryRequest.  If this check fails, the client MUST abort the handshake with an "illegal_parameter" alert.

This clarifies two items relevant to stateless HelloRetryRequests: 1) If a HelloRetryRequest does not contain a keyshare extension, the negotiated group does not have to match the non-existent selected group in the HRR. 2) If a HelloRetryRequest does select a group, the server can still choose to use pskke key exchange. When sending a stateless HelloRetryRequest, the server may not know if it will accept a PSK yet. This allows the server to still select a group in the HelloRetryRequest which it would need for a full handshake, but later decide to accept the PSK with psk_ke mode.
Seems reasonable to me.


Question: message MUST be compressed with the ZLIB compression algorithm, as defined in RFC1950.  If the specified compression algorithm is brotli, the Certificate message MUST be compressed with the Brotli <del> compression algorithm as defined in RFC7932. </del> <ins> compression algorithm as defined in RFC7932.  If the specified compression algorithm is zstd, the Certificate message MUST be compressed with the Zstandard compression algorithm as defined in RFC8478. </ins> It is possible to define a certificate compression algorithm that uses a pre-shared dictionary to achieve higher compression ratio.

Parking this here; if we have a consensus on the list to add it, we should merge this.


Question: to match the protocol version that is negotiated by the client and server. <del> The credential's public key, a DER-encoded SubjectPublicKeyInfo as defined in RFC5280. </del> <ins> The credential's public key, a DER-encoded X690 SubjectPublicKeyInfo as defined in RFC5280. </ins> The delegated credential has the following structure:

Just some nits.
The public key name and type have been changed in , as NAME suggested on the mailing list.
NAME beat me to it!
oh looks like the travis build is failing for some reason
NAME I have no idea why pushing that worked ...
awesomesauce. it's probably some temporary failure while trying to fetch the new references or something


Question: including the signature algorithm identifier in the data to be signed. <ins> 9.2. The RSASSA-PSS signature algorithm is defined in RFC3447. The RSASSA-PSS signature algorithm is parametized with a hash function, a mask generation function and a salt length (sLen).  For this specification, the mask generation function is fixed to be MGF1 as defined in RFC3447.  It has been recommended that the same hash function be used for hashing the data as well as in the mask generation function, for this specification we following this recommendation.  The salt length is the same length as the hash function output. Three algorithms are defined in this document.  These algorithms are: This uses the hash algorithm SHA-256 for signature processing. The value used for this algorithm is -10.  The key type used for this algorithm is 'RSA'. This uses the hash algorithm SHA-384 for signature processing. The value used for this algorithm is "PS384".  The key type used for this algorithm is 'RSA'. This uses the hash algorithm SHA-512 for signature processing. The value used for this algorithm is -11.  The key type used for this algorithm is 'RSA'. There are no algorithm parameters defined for these signature algorithms.  A summary of the algorithm definitions can be found in table-rsa-algs. 9.2.1. Key size.  is there a MUST for 2048? or do we need to specify a minimum here? </ins> 10. Message Authentication Codes (MACs) provide data authentication and

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


Question: needs to initialize a GroupContext object that can be updated to the current state using the Add message.  This information is encrypted for the new member using HPKE.  The recipient key pair for the HPKE <del> encryption is the one included in the indicated ClientInitKey, corresponding to the indicated ciphersuite.  The "add_key_nonce" field contains the key and nonce used to encrypt the corresponding Add message; if it is not encrypted, then this field MUST be set to the null optional value. </del> <ins> encryption is the one included in the indicated ClientInitKey.  The "add_key_nonce" field contains the key and nonce used to encrypt the corresponding Add message; if it is not encrypted, then this field MUST be set to the null optional value. </ins> In the description of the tree as a list of nodes, the "credential" field for a node MUST be populated if and only if that node is a leaf

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


Question: needs to initialize a GroupContext object that can be updated to the current state using the Add message.  This information is encrypted for the new member using HPKE.  The recipient key pair for the HPKE <del> encryption is the one included in the indicated ClientInitKey, corresponding to the indicated ciphersuite.  The "add_key_nonce" field contains the key and nonce used to encrypt the corresponding Add message; if it is not encrypted, then this field MUST be set to the null optional value. </del> <ins> encryption is the one included in the indicated ClientInitKey.  The "add_key_nonce" field contains the key and nonce used to encrypt the corresponding Add message; if it is not encrypted, then this field MUST be set to the null optional value. </ins> In the description of the tree as a list of nodes, the "credential" field for a node MUST be populated if and only if that node is a leaf

Of these, 0 issues have been closed and 2 issues are still open. :greenheart: , by :greenheart: , by - - Last week, 2 pull requests were created, updated or merged. Last week, 2 pull requests were opened. :greenheart: , by :greenheart: , by - - Last week there were no commits. - - Last week there were no contributors. - - Last week there were 2 stagazers. :star: :star: You all are the stars! :star2: - - Last week there were no releases. - - That's all for last week, please :eyes: Watch and :star: Star the repository to receive next weekly updates. :smiley: You can also .


Question: Certain characters are escaped in Normalized Paths, in one and only one way; all other characters are unescaped. <del> Note: Normalized Paths are Singular Queries, but not all Singular Queries are Normalized Paths.  For example, "$[-3]" is a singular </del> <ins> Note: Normalized Paths are singular queries, but not all singular queries are Normalized Paths.  For example, "$[-3]" is a singular </ins> query, but is not a Normalized Path.  The Normalized Path equivalent to "$[-3]" would have an index equal to the array length minus "3". (The array length must be at least "3" if "$[-3]" is to identify a

Sometimes the spec uses "Singular Query" and sometimes "singular query". We should be consistent. (If we decide to use lower case, it's probably best to address this issue after PR has been merged, since that PR adds some usages of "Singular Query".) Also, there is one instance of "Logical context", which I think would be better uncapitalised ("logical context").
After merging in my changes from main, it appears some Singular Queries still need fixing.


Question: can be mounted using spoofed source addresses.  In determining this limit, servers only count the size of successfully processed packets. <del> Clients MUST pad UDP datagrams that contain only Initial packets to at least 1200 bytes.  Once a client has received an acknowledgment </del> <ins> Clients MUST ensure that UDP datagrams containing Initial packets are sized to at least 1200 bytes, adding padding to packets in the datagram as necessary.  Once a client has received an acknowledgment </ins> for a Handshake packet it MAY send smaller datagrams.  Sending padded datagrams ensures that the server is not overly constrained by the amplification restriction.

This change does two things: Clarify that if UDP datagram contains Initial packets, it must be at least 1200 bytes in size; and Rule out padding the UDP datagram with junk (the "padding packets" part) as NAME suggested earlier. Issue is only about (1). Not that I am against (2), but this is just so that we are clear.
I think that the reinterpretation of the text here has introduced the second problem NAME mentions. This also has the unfortunate consequence of disallowing small acknowledgment datagrams (for HelloRetryRequest in particular). This might need to be more carefully phrased.
As NAME said, this is an editorial change, so I'm going to merge. The substantive one is in NAME
NAME -- you're right, but I think this was unintentional earlier. I think if we want to make a case for allowing junk, that should be discussed separately. The proposed text captures what I believe our intent was.
states: This seemingly says that the first UDP datagram that has two coalesced packets, Initial and 0-RTT, can be smaller than 1200 bytes. I don't believe that's the intention.
Agreed, I believe the "only" needs to removed unless I'm missing some other intent.
I don't think that is sufficient. The intent of this was to allow the client to send Initial packets that acknowledge server Initial packets without padding to 1200.
Given PADDING is supposed to count towards bytes in flight, but it's not ack-eliciting, a special case for ACK-only packets makes sense. I'd be inclined to specify ACK-only packets as the exception, opposed to basing it on receiving an ACK of Handshake packets or some other mechanism.
As stated in URL, I prefer to stop requiring the use of full-sized packets once the client observes a response from server. Reasons: QUIC stacks would have the logic to change rules based on if the peer's address has been validated due to the 3-packet rule on the server side. It's just about using the same logic for padding on the client side. Implementations that prefer to pad all the Initial packets it sends can do so anyways. Regardless of what we decide, the server side logic would be indifferent; i.e. create new connection context only when observing a full-sized Initial packet.


Question: can be mounted using spoofed source addresses.  In determining this limit, servers only count the size of successfully processed packets. <del> Clients MUST pad UDP datagrams that contain only Initial packets to at least 1200 bytes.  Once a client has received an acknowledgment </del> <ins> Clients MUST ensure that UDP datagrams containing Initial packets are sized to at least 1200 bytes, adding padding to packets in the datagram as necessary.  Once a client has received an acknowledgment </ins> for a Handshake packet it MAY send smaller datagrams.  Sending padded datagrams ensures that the server is not overly constrained by the amplification restriction.

tl;dr: we should always pad to 1200 for UDP datagrams that contain Initial packets. The reason we pad to 1200 is to provide a server with plenty of inbound bytes so that it can send outbound bytes prior to path validation. Padding to 1200 has sub-optimal performance in certain cases. In particular, it makes datagrams containing a simple ACK enormous. So the original thought was to try to find a case where we could allow for smaller datagrams to be sent. I think that in both alternative designs we have a problem with the interaction with our DoS defense. And while those problems might only exist in the abstract for now, I think that the best answer is to pad to 1200 always. (I will suggest rewording the text separately.) An ACK-only Initial packet is sent at the tail of the Initial phase. That is the obvious candidate for consideration here. But there are other cases where small Initial packets might be sent. The looser requirement NAME suggests is less than ideal for HelloRetryRequest. A client can receive a HelloRetryRequest and be forced to send another ClientHello. We can't assume here that the server is using the HelloRetryRequest to validate the client address (though it certainly can). If the ClientHello message is small, the number of bytes that a server can send is still limited. If the client doesn't pad, the server can still count the original ClientHello toward its budget, but it doesn't get significant additional budget from the client. And that budget doesn't increase when packets are lost. So it could be that the server is stuck with 3x whatever it gets in ACKs, which is not a lot. It's worse if you consider the possibility of the ServerHello being enormous (hello PQ crypto). At this point, the server won't have validated the client address and so is still limited in what it can send. Ideally, we want the packets to be big so that the server gets more budget for sending and isn't limited to sending tiny packets. But if all the client sends is small ACK-only packets (under either proposed amendment, either what NAME or NAME describe), the increased allowance is very small. Based on this, I would suggest that we reluctantly say that all Initial-carrying datagrams need to be 1200 bytes or more.


Question: can be mounted using spoofed source addresses.  In determining this limit, servers only count the size of successfully processed packets. <del> Clients MUST pad UDP datagrams that contain only Initial packets to at least 1200 bytes.  Once a client has received an acknowledgment </del> <ins> Clients MUST ensure that UDP datagrams containing Initial packets are sized to at least 1200 bytes, adding padding to packets in the datagram as necessary.  Once a client has received an acknowledgment </ins> for a Handshake packet it MAY send smaller datagrams.  Sending padded datagrams ensures that the server is not overly constrained by the amplification restriction.

For the case of the ACK at the tail, most of the designs proposed for key discard will result in that packet not being sent. If it is sent, there are plenty of cases where it will be a packet with Initial (ACK), Handshake (ACK + ...Finished) and 1-RTT data, so the requirement is met without wasting bytes at all. But for ACK of big ServerHello messages or HelloRetryRequest, the overhead is regrettably necessary.
SGTM. I agree this greatly incentivizes good coalescing, but otherwise I don't see any downsides. And simple is good. Even when suggesting the special case for ACK-only packets, it felt like a premature optimization.
Works for me. It's a corner case anyways. Unless HRR is involved, client will not send an Initial in response to the server's Initial, assuming we decide to continue dropping the Initial keys when the client receives a handshake packet.
A potential friendly amendment, but then we should proceed. I would say after confirming with chairs, because there was a pretty strong design decision involved here, but technically this is only an editorial change.


Question: the sender will not have the keys necessary to construct an MLSCiphertext object. <del> 13.1.9.1. </del> <ins> 13.1.8.1. </ins> The "external_senders" extension is a group context extension that contains credentials of senders that are permitted to send external

The way the spec is written now, clients need to implement all proposal types, and they must react to appropriately to all valid proposals, including AppAck. AppAck in a large, busy group could result in a situation where clients with longer latency connections to the DS (perhaps in a different country, using satellite, or using some wireless networks) might be effectively prevented from sending any messages, or worse could be prevented from sending AppAcks because their proposals are always a few hundred milliseconds late. I think AppAcks still have a place is relatively small groups with low message volumes, but I have a few suggestions: 1) Describe this issue either in the AppAck proposal section or in the security considerations section 2) I think it is reasonable for a group to consider some proposal types invalid. If there is consensus with this position, I'd like to make this clear with an extra sentence or two. If that is not the consensus, then I will propose that only Add, Remove, and Update are assumed to be supported by each group, and other proposal types have to be explicitly added.
My team had similar comments. I agree that this shouldn't be a 100% necessary thing to support.
I would differentiate between "support" in the sense of "if you receive one, do something sensible with it" vs. "send this under some circumstances". My understanding was that the requirement here was the former, and even that the definition of "sensible" was up to the implementation. The thinking being that if an application wanted to get some anti-suppression properties, it could send and verify these on some schedule, but when exactly they would be sent would be up to the application. Does that alleviate some of the concern here? If so, I would totally be open to clarifying that. To NAME point about latency, it seems like we could add an parameter to AppAck so that you could report on past epochs' messages in a future epoch. On considering proposal types invalid -- I think there has always been a notion that applications might have policies on which proposals are acceptable. Not just at the proposal type level, but at even finer granularities. Think about things like groups where only certain members are allowed to add/remove participants. I would also be fine laying this out more explicitly, though maybe it would be a more natural fit in the architecture document.


Question: the sender will not have the keys necessary to construct an MLSCiphertext object. <del> 13.1.9.1. </del> <ins> 13.1.8.1. </ins> The "external_senders" extension is a group context extension that contains credentials of senders that are permitted to send external

Sorry, meant to delete a comment, closed the issue instead.
In the past I've expressed reservations about AppAck being included in the spec. I don't think it's sufficiently general (it only handles a one specific pattern of message loss and won't work for others, per NAME comment), and I don't like that we don't specify how to handle dropped messages in any way. The AppAck functionality is likely to just be re-invented at the application-level because of this. For example, AppAck can't be used to implement read receipts It doesn't help detect the suppression of handshake messages It doesn't handle cases where some messages must be delivered and others may be dropped So instead I would propose removing AppAck from the spec.
I've opened a PR to that effect in .
Virtual interim 2022-05-19 Agreement that the bar for support is quite low ... but you don't get a security property unless members actually do something more than the minimum That sort of implies that you want the group to opt in to this mechanism So we should have a new proposal type in a separate I-D
(To be clear, AppAck should move from the main spec here to its own I-D.)
One comment that renumbering the groupcontextextensions proposal was probably a bad idea from a process perspective which we should avoid doing in the future. In this case it seems unlikely that many people have implemented it who could not make a breaking change.


Question: This document uses the Augmented BNF defined in RFC5234 and updated by RFC7405. <del> 1.2. The OpenAPI Specification Media Types convey OpenAPI Specification (OAS) files as defined in oas for version 3.0.0 and above. Those files can be serialized in JSON or yaml.  Since there are multiple OpenAPI Specification Specifications versions, those media- types support the "version" parameter. The following examples conveys the desire of a client to receive an OpenAPI Specification resource preferably in the following order: openapi 3.1 in yaml openapi 3.0 in yaml any openapi version in json </del> 2. <del> Security requirements for both media type and media type suffix registrations are discussed in Section 4.6 of MEDIATYPE. </del> <ins> This section describes the information required to register the above media types. </ins> <del> 3. </del> <ins> 2.1. </ins> <del> This specification defines the following new Internet media types MEDIATYPE. 3.1. </del> <ins> The following information serves as the registration form for the "application/yaml" media type. </ins> Type name: application

introduce numbered sections for YAML NAME since each media type is defined in its IANA consideration, would it be ok for you if we just add a section for YAML? Feel free to PR with another proposal.
NAME could you PTAL ? :)
to be honest, i prefer definitions to have URIs and not just registrations. but if we have URIs, that's already a lot better than not having URIs! thanks!
it's maybe just OCD (and because it's very useful for URL to have linkable references) but i think it's nice to have numbered sections for everything that's being defined in the spec. in this case, i suggest to have a numbered section for each of the four media types, and to have a brief explanation of what it identifies. that way, each definition is self-contained and can be easily referenced when necessary. NAME NAME


Question: If Host A does not receive a TCP RST in reply to its MP_FASTCLOSE after one retransmission timeout (RTO) (the RTO of the subflow <del> where the MPTCP_RST has been sent), it SHOULD retransmit the </del> <ins> where the MP_FASTCLOSE has been sent), it SHOULD retransmit the </ins> MP_FASTCLOSE.  The number of retransmissions SHOULD be limited to avoid this connection from being retained for a long time, but this limit is implementation specific.  A RECOMMENDED number is 3. If no TCP RST is received in response, Host A SHOULD send a TCP <del> RST itself when it releases state in order to clear any remaining state at middleboxes. </del> <ins> RST with the MP_FASTCLOSE option itself when it releases state in order to clear any remaining state at middleboxes. Upon receipt of a RST with MP_FASTCLOSE, containing the valid key, Host B tears down all subflows.  Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state). </ins> 3.6.

Adding Olivier's proposed text about the Fast-Close (cfr., URL) and integrated a shorter version of URL Hello, Sorry for being late with this, but the beginning of the fall semester is always too busy for me. During the summer, there was a discussion on the FASTCLOSE option that was triggered by Francois. The current text of RFC6824bis uses the FASTCLOSE option inside ACK packets, but deployment experience has shown that this results in additional complexity since the ACK must be retransmitted to ensure its reliable delivery. Here is a proposed update for section 3.5 that allows a sender to either send FASTCLOSE inside ACK or RST while a receiver must be ready to process both. Changes are marked with Fast Close Regular TCP has the means of sending a reset (RST) signal to abruptly close a connection. With MPTCP, a reguler RST only has the scope of the subflow and will only close the concerned subflow but not affect the remaining subflows. MPTCP's connection will stay alive at the data level, in order to permit break-before-make handover between subflows. It is therefore necessary to provide an MPTCP-level "reset" to allow the abrupt closure of the whole MPTCP connection, and this is the MPFASTCLOSE option. MPFASTCLOSE is used to indicate to the peer that the connection will be abruptly closed and no data will be accepted anymore. The reasons for triggering an MPFASTCLOSE are implementation specific. Regular TCP does not allow sending a RST while the connection is in a synchronized state [RFC0793]. Nevertheless, implementations allow the sending of a RST in this state, if, for example, the operating system is running out of resources. In these cases, MPTCP should send the MPFASTCLOSE. This option is illustrated in Figure 14.


Question: If Host A does not receive a TCP RST in reply to its MP_FASTCLOSE after one retransmission timeout (RTO) (the RTO of the subflow <del> where the MPTCP_RST has been sent), it SHOULD retransmit the </del> <ins> where the MP_FASTCLOSE has been sent), it SHOULD retransmit the </ins> MP_FASTCLOSE.  The number of retransmissions SHOULD be limited to avoid this connection from being retained for a long time, but this limit is implementation specific.  A RECOMMENDED number is 3. If no TCP RST is received in response, Host A SHOULD send a TCP <del> RST itself when it releases state in order to clear any remaining state at middleboxes. </del> <ins> RST with the MP_FASTCLOSE option itself when it releases state in order to clear any remaining state at middleboxes. Upon receipt of a RST with MP_FASTCLOSE, containing the valid key, Host B tears down all subflows.  Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state). </ins> 3.6.

1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+-----------------------+ +---------------+---------------+-------+-----------------------+ +---------------------------------------------------------------+ Figure 14: Fast Close (MPFASTCLOSE) Option If Host A wants to force the closure of an MPTCP connection, it has two different options : Option A (ACK) : Host A sends an ACK containing the MPFASTCLOSE option on one subflow, containing the key of Host B as declared in the initial connection handshake. On all the other subflows, Host A sends a regular TCP RST to close these subflows, and tears them down. Host A now enters FASTCLOSEWAIT state. Option R (RST) : Host A sends a RST containing the MPFASTCLOSE option on all subflows, containing the key of Host B as declared in the initial connection handshake. Host A can tear the subflows and the connection down immediately. If a host receives a packet with a valid MPFASTCLOSE option, it shall process it as follows : o Upon receipt of an ACK with MPFASTCLOSE, containing the valid key, Host B answers on the same subflow with a TCP RST and tears down all subflows. Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state). o As soon as Host A has received the TCP RST on the remaining subflow, it can close this subflow and tear down the whole connection (transition from FASTCLOSEWAIT to CLOSED states). If Host A receives an MPFASTCLOSE instead of a TCP RST, both hosts attempted fast closure simultaneously. Host A should reply with a TCP RST and tear down the connection. o If Host A does not receive a TCP RST in reply to its MPFASTCLOSE after one retransmission timeout (RTO) (the RTO of the subflow where the MPTCPRST has been sent), it SHOULD retransmit the MPFASTCLOSE.


Question: If Host A does not receive a TCP RST in reply to its MP_FASTCLOSE after one retransmission timeout (RTO) (the RTO of the subflow <del> where the MPTCP_RST has been sent), it SHOULD retransmit the </del> <ins> where the MP_FASTCLOSE has been sent), it SHOULD retransmit the </ins> MP_FASTCLOSE.  The number of retransmissions SHOULD be limited to avoid this connection from being retained for a long time, but this limit is implementation specific.  A RECOMMENDED number is 3. If no TCP RST is received in response, Host A SHOULD send a TCP <del> RST itself when it releases state in order to clear any remaining state at middleboxes. </del> <ins> RST with the MP_FASTCLOSE option itself when it releases state in order to clear any remaining state at middleboxes. Upon receipt of a RST with MP_FASTCLOSE, containing the valid key, Host B tears down all subflows.  Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state). </ins> 3.6.

The number of retransmissions SHOULD be limited to avoid this connection from being retained for a long time, but this limit is implementation specific. A RECOMMENDED number is 3. If no TCP RST is received in response, Host A SHOULD send a TCP RST with the MPFASTCLOSE option itself when it releases state in order to clear any remaining state at middleboxes. o Upon receipt of a RST with MPFASTCLOSE, containing the valid key, Host B tears down all subflows. Host B can now close the whole MPTCP connection (it transitions directly to CLOSED state). The burden of the MP_FASTCLOSE is on the host that decides to close the connection (typically the server, but not necessarily). The text above allows it to opt for either ACK or RST without adding complexity to the other side. Another point that might be discussed in RFC6824bis is how a host should react when there are all the subflows associates to a Multipath TCP connection are in the CLOSED state, but the connection is still alive. At this point, it is impossible to send or receive data over the connection. It should attempt to reestablish one subflow to keep the connection alive. Olivier


Question: 6. <del> For protocols where 4-tuple load balancing is sufficient, it is straightforward to deliver ICMP packets from the network to the correct server, by reading the echoed IP and transport-layer headers to obtain the 4-tuple.  When routing is based on connection ID, further measures are required, as most QUIC packets that trigger ICMP responses will only contain a client-generated connection ID that contains no routing information. To solve this problem, load balancers MAY maintain a mapping of Client IP and port to server ID based on recently observed packets. Alternatively, servers MAY implement the technique described in Section 14.4.1 of RFC9000 to increase the likelihood a Source Connection ID is included in ICMP responses to Path Maximum Transmission Unit (PMTU) probes.  Load balancers MAY parse the echoed packet to extract the Source Connection ID, if it contains a QUIC long header, and extract the Server ID as if it were in a Destination CID. </del> <ins> QUIC-LB requires no per-connection state at the load balancer.  The load balancer can extract the server ID from the connection ID of each incoming packet and route that packet accordingly. However, once the routing decision has been made, the load balancer MAY associate the 4-tuple with the decision.  This has two advantages: The load balancer only extracts the server ID once per incoming 4-tuple.  When the CID is encrypted, this substantially reduces computational load. Incoming Stateless Reset packets and ICMP messages are easily routed to the correct origin server. In addition to the increased state requirements, however, load balancers cannot detect the CONNECTION_CLOSE frame to indicate the end of the connection, so they rely on a timeout to delete connection state.  There are numerous considerations around setting such a timeout. In the event a connection ends, freeing an IP and port, and a different connection migrates to that IP and port before the timeout, the load balancer will misroute the different connection's packets to the original server.  A short timeout limits the likelihood of such a misrouting. Furthermore, if a short timeout causes premature deletion of state, the routing is easily recoverable by decoding an incoming Connection ID.  However, a short timeout also reduces the chance that an incoming Stateless Reset is correctly routed. Servers MAY implement the technique described in Section 14.4.1 of RFC9000 in case the load balancer is stateless, to increase the likelihood a Source Connection ID is included in ICMP responses to Path Maximum Transmission Unit (PMTU) probes.  Load balancers MAY parse the echoed packet to extract the Source Connection ID, if it contains a QUIC long header, and extract the Server ID as if it were in a Destination CID. </ins> 7.

Definitely an edge case, but the LB will spray stateless resets everywhere because the CID is random. If the LB tracks fourtuples, though, it shouldn't be a problem.
Maybe make this part of a thing about stateless LBs.
So, what's the plan ?
NAME raises an interesting point about stateless LBs in .


Question: The sn_key is computed as follows: [sender] denotes the sending side.  The Secret value to be used is <del> described in Section 7.3 of TLS13. </del> <ins> described in Section 7.3 of TLS13.  Note that a new key is used for each epoch: because the epoch is in the clear, this does not result in ambiguity. </ins> The encrypted sequence number is computed by XORing the leading bytes <del> of the Mask with the sequence number.  Decryption is accomplished by the same process. </del> <ins> of the Mask with the on-the-wire representation of the sequence number.  Decryption is accomplished by the same process. </ins> This procedure requires the ciphertext length be at least 16 bytes. Receivers MUST reject shorter records as if they had failed

Thanks for this document -- badly needed and easy to read. Thanks also to Bernard Adoba for his recent tsvart review. I support his comments. COMMENTS: Sec 2. It might be useful to introduce the term "epoch" in the glossary, for those who read this front to back. Sec 4.2.3: "The encrypted sequence number is computed by XORing the leading bytes of the Mask with the sequence number. Decryption is accomplished by the same process." The text is unclear if the XOR is applied to the expanded sequence number or merely the 1-2 octets on the wire. I presume it's the latter, but this should be clarified. Sec 4.2.3: It's implied here that the snkey rotates with the epoch. As this is different from QUIC, it's probably worth spelling out. Sec 5.1 is a bit vague about the amplification limit; why not at least RECOMMEND 3, as we've converged on this elsewhere? Sec 5.1. Reading between the lines, it's clear that the cookie can't be used as address verification across connections in the way that a NEWTOKEN token is. It would be good to spell this out for clients -- use the resumption token or whatever instead. Sec 7.2 "As noted above, the receipt of any record responding to a given flight MUST be taken as an implicit acknowledgement for the entire flight." I think this should be s/entire flight/entire previous flight? Sec 7.2 "Upon receipt of an ACK that leaves it with only some messages from a flight having been acknowledged an implementation SHOULD retransmit the unacknowledged messages or fragments." This language appears inconsistent with Figure 12, where Record 1 has not been acknowledged but is also not retransmitted. It appears there is an implied handling of empty ACKs that isn't written down anywhere in Sec 7.2 Sec 9. Should there be any flow control limits on newconnectionid? Or should receivers be free to simply drop CIDs they can't handle? It might be good to specify. Finally, a really weird one. Reading this document and references to connection ID prompted to me to think how QUIC-LB could apply to DTLS.


Question: The sn_key is computed as follows: [sender] denotes the sending side.  The Secret value to be used is <del> described in Section 7.3 of TLS13. </del> <ins> described in Section 7.3 of TLS13.  Note that a new key is used for each epoch: because the epoch is in the clear, this does not result in ambiguity. </ins> The encrypted sequence number is computed by XORing the leading bytes <del> of the Mask with the sequence number.  Decryption is accomplished by the same process. </del> <ins> of the Mask with the on-the-wire representation of the sequence number.  Decryption is accomplished by the same process. </ins> This procedure requires the ciphertext length be at least 16 bytes. Receivers MUST reject shorter records as if they had failed

The result is here: URL Please note the rather unfortunate third-to-last paragraph. I'm happy to take the answer that this use case doesn't matter, since I made it up today. But if it does, it would be very helpful if (1) DTLS 1.3 clients MUST include a connectionid extension in their ClientHello, even if zero length, and/or (2) this draft updated 4.1.4 of 8446 to allow the server to include connectionid in HelloRetryRequest even if the client didn't offer it. Thoughts? NITS: s/select(HandshakeType)/select(msg_type). Though with pseudocode your mileage may vary as to what's clearer. s/consitute/constitute Sec 5.7 In table 1, why include one ACK in the diagram but not the other? It's clear from the note, but the figure is a weird omission.
Addressed in URL


Question: do this, CoSWID tags can be created by any party and the CoSWID tags collected from an endpoint could contain a mixture of vendor and non- vendor created tags.  For this reason, a CoSWID tag might contain <del> potentially malicious content.  Input sanitization and loop detection are two ways that implementations can address this concern. </del> <ins> potentially malicious content.  Input sanitization, loop detection, and signature verification are ways that implementations can address this concern. </ins> 10.

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: a solution to this problem.  However, hiding information about the change of the IP address or port conceals important and security- relevant information from QUIC endpoints and as such would facilitate <del> amplification attacks (see section 9 of QUIC-TRANSPORT).  An NAT </del> <ins> amplification attacks (see Section 9 of QUIC-TRANSPORT).  A NAT </ins> function that hides peer address changes prevents the other end from detecting and mitigating attacks as the endpoint cannot verify connectivity to the new address using QUIC PATH_CHALLENGE and

Some section refs weren't linked to the sections; some objects were defined multiple ways; one reference wasn't actually cited in the text.
Thanks a lot!


Question: are independent and fully compatible protocols, each solving different problems.  The use of one does not diminish the need nor the usefulness of the other.  It is the choice of a client to either <del> perform full DNSSEC validation of answers or to treat answers from a DNS API server as DNSSEC-authenticated, and this choice may be affected by the response media type. </del> <ins> perform full DNSSEC validation of answers or to trust the DNS API server to do DNSSEC validation and inspect the AD (Authentic Data) bit in the returned message to determine whether an answer was authentic or not.  As noted in http-response, different response media types will provide more or less information from a DNS response so this choice may be affected by the response media type. </ins> caching describes the interaction of this protocol with HTTP caching. An adversary that can control the cache used by the client can affect

…raft-ietf-doh-dns-over-https/commit/3f74bd6e0760f96717ffd3e667a37e13b45839c4#commitcomment-28865666 and URL that this wording is much clearer.
Sara, making this pr was on my todo list - thanks for the time saver. Paul sent me an IM about it, so I'll ga and merge.


Question: QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established or <del> because the information is intended to be used by the network.  QUIC has a long header that exposes some additional information (the version and the source connection ID), while the short header exposes only the destination connection ID.  In QUIC version 1, the long header is used during connection establishment, while the short header is used for data transmission in an established connection. </del> <ins> because the information is intended to be used by the network.  For more information on manageability of QUIC see also I-D.ietf-quic- manageability.  QUIC has a long header that exposes some additional information (the version and the source connection ID), while the short header exposes only the destination connection ID.  In QUIC version 1, the long header is used during connection establishment, while the short header is used for data transmission in an established connection. </ins> The connection ID can be zero length.  Zero length connection IDs can be chosen on each endpoint individually, on any packet except the

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: QUIC exposes some information to the network in the unencrypted part of the header, either before the encryption context is established or <del> because the information is intended to be used by the network.  QUIC has a long header that exposes some additional information (the version and the source connection ID), while the short header exposes only the destination connection ID.  In QUIC version 1, the long header is used during connection establishment, while the short header is used for data transmission in an established connection. </del> <ins> because the information is intended to be used by the network.  For more information on manageability of QUIC see also I-D.ietf-quic- manageability.  QUIC has a long header that exposes some additional information (the version and the source connection ID), while the short header exposes only the destination connection ID.  In QUIC version 1, the long header is used during connection establishment, while the short header is used for data transmission in an established connection. </ins> The connection ID can be zero length.  Zero length connection IDs can be chosen on each endpoint individually, on any packet except the

“ 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: until a gathering phase occurs, and so any necessary filtering can still be done on any pooled candidates. <del> Any changes to the ICE candidate pool size take effect </del> <ins> The ICE candidate pool size MUST NOT be changed after applying a local description.  If a local description has not yet been applied, any changes to the ICE candidate pool size take effect </ins> immediately; if increased, additional candidates are pre-gathered; if decreased, the now-superfluous candidates are discarded.

The pool is only used in the first offer/answer exchange. After applying a local description, the pool size is frozen and changing the ICE servers will not result in new candidates being pooled. After an answer is applied, any leftover candidates are discarded. This only happens when applying an answer so that candidates aren't prematurely discarded for use cases that involve pranswer, or multiple offers.
I can live with this as is. Want to read again if we end up making changes to address EKR comments
Updated PR and its description based on our discussion.


Question: unblock the server until it is certain that the server has finished its address validation (see Section 8 of QUIC-TRANSPORT).  That is, the client MUST set the probe timer if the client has not received an <del> acknowledgement for one of its Handshake or 1-RTT packets. </del> <ins> acknowledgement for one of its Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame. </ins> Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to

Having non-overlapping conditions makes sense; adjusted wording.
The recovery draft : This is consistent with the pseudocode, in particular . When the server receives the client's final handshake flight, it discards handshake keys and hence cannot acknowledge it. When the client receives the resulting , the handshake is confirmed, but no Handshake or 1-RTT acknowledgements have necessarily been received. This results in a PTO being set even though the client's address has certainly been verified and there are no ack-eliciting packets in flight. As written, the pseudocode would in fact set a PTO for the Initial space at a garbage time. I think this could be corrected by appending "and has not discarded handshake keys" or "and has not confirmed the handshake" to the language, and adding the analogous clause to the conditions checked in the final statement of .
I thought that was implied, but implications are bad, so I agree it's best to explicitly state it. I'm happy to review a PR if you have time to write one, or I'll fix this fairly soon ideally.
When a reverse proxy forwards a HTTP response to the client, sometimes it sees the upstream server terminate the response early. For example, a HTTP/1.1 connection being closed prior to transmitting number of bytes specified by the field. Or a chunked response being closed abruptly. The only way of delegating such a condition to the client in HTTP/2 was to send a RSTSTREAM frame with . However, use of the error code is awkward in this case, considering the fact that the error did not happen within the communication between the endpoints using the particular HTTP/2 connection. I think it makes sense to have an error code that better designates the case. One way to address the issue in H3 would be to change to , and let the server use the error code (as an argument of the RESET_STREAM frame) to indicate that the response has been "cancelled". Originally proposed in URL
What if you do not want to admit to being a proxy? (who does?)
HTTPMESSAGECANCELLED would simply mean that the transfer of the response is cancelled, regardless of the server being an origin or a reverse proxy.
I can get behind this.


Question: unblock the server until it is certain that the server has finished its address validation (see Section 8 of QUIC-TRANSPORT).  That is, the client MUST set the probe timer if the client has not received an <del> acknowledgement for one of its Handshake or 1-RTT packets. </del> <ins> acknowledgement for one of its Handshake or 1-RTT packets, and has not received a HANDSHAKE_DONE frame. </ins> Prior to handshake completion, when few to none RTT samples have been generated, it is possible that the probe timer expiration is due to

As long as we're not looking for a byte-by-byte reproduction of the bytes the intermediary received (as was once requested and rejected, I think at the Seattle interim), then it makes sense to signal that the message was killed.
This is basically an expansion of the CANCELLED/REJECTED codes to allow a server to do either. WFM.
NAME Yes. And thank you for the PR.


Question: _mandatory_ <del> A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. _mandatory_ </del> A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Claims included in Evidence.

Signed-off-by: Michael Eckel
Based on URL Previous section says “Attester Identity” is about “a distinguishable Attesting Environment”, and here says it’s about “a distinguishable Attester”.
How to understand “without accompanying evidence about its validity”?
I think it means that there is no certificate conveyed along with it which proves its validity.
I think this is related to and should be fixed.
Based on URL The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity?
The TPM’s AIK certificate is one kind of Attester Identity, right?
"The TPM’s AIK certificate is one kind of Attester Identity, right?": Correct.
"The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity?" I see the point, too, and agree. So, perhaps it should be renamed to "Attesting Environment identity"!? The Attester Identity then should be something different. It may be the TPM AK/AIK of one of the Attesting Environments, but not necessarily.
As discussed, polish can happen later Hi Henk, I've reviewed the reference interaction models I-D recently, I hope the comments below can help improve the draft before the IETF110 draft submission cut-off. Section 3 Disambiguation Comment > This section is talking about the disambiguation of terminology, so I suggest making it a sub-section of Section 2 Terminology. Examples of these types of co-located environments include: a Trusted Execution Environment (TEE), Baseboard Management Controllers (BMCs), as well as other physical or logical protected/isolated/shielded Computing Environments (e.g. embedded Secure Elements (eSE) or Trusted Platform Modules (TPM)). Comment > About "these types of co-located environments", The previous sentences are about the Verifier and Attester don't need to be remote. So "these" is weird here, because here is about the attesting environment and target environment. Section 5 Direct Anonymous Attestation Comment > I think it's better to move this section to the bottom of the draft.


Question: _mandatory_ <del> A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. _mandatory_ </del> A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Claims included in Evidence.

DAA doesn't introduce a new information elements, and only augments the scope/definition of Attester Identity and Authentication Secret IDs, describing it after the introduction of all the 3 basic interaction models would be better. Putting DAA in the middle makes me feel the basic interaction models rely upon DAA, but actually it's not. This document extends the duties of the Endorser role as defined by the RATS architecture with respect to the provision of these Attester Identity documents to Attesters. The existing duties of the Endorser role and the duties of a DAA Issuer are quite similar as illustrated in the following subsections. Comment > Without DAA, I think the Endorser also needs to provision the Attester Identity to Attesters. And as I understand, the DAA Issuer is a supply chain entity before the Attester being shipped, so it is the Endorser when DAA is used, right? If yes, then in the next sentence, the comparison between Endorser and DAA Issuer doesn't make sense to me. Section 5.1 Endorsers Comment > Does this section have difference with the definition of Endorser in architecture draft? If not, is it necessary to keep this section? Comment > This section only describes the Layered Attestation, but the scope of Endorsement is more than what's described here. Endorsement indicates the Attester's various capabilities such as Claims collection and Evidence signing. For other situations than Layered Attestation, the Endorser and Endorsement are also needed. So why only mention Layered Attestation here? I don't see any special relationship between DAA and Layered Attestation. Section 5.2 Endorsers for Direct Anonymous Attestation In order to enable the use of DAA, an Endorser role takes on the duties of a DAA Issuer in addition to its already defined duties. DAA Issuers offer zero-knowledge proofs based on public key certificates used for a group of Attesters [DAA]. Effectively, these certificates share the semantics of Endorsements, with the following exceptions: Comment > In the first sentence, I suggest saying that "a DAA Issuer takes on the role of an Endorser".


Question: _mandatory_ <del> A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. _mandatory_ </del> A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Claims included in Evidence.

o The associated private keys are used by the DAA Issuer to provide an Attester with a credential that it can use to convince the Verifier that its Evidence is valid. To keep their anonymity the Attester randomizes this credential each time that it is used. Comment > How to understand "Evidence is valid"? Does it mean the Evidence is sent from an authentic Attester and not tampered during the conveyance? Or does it mean the Evidence comes from a RoT and is trustable (although the Evidence can diverge from the Reference Values)? Comment > When saying "Attester randomizes this credential", how many credentials does an Attester have? 1) Can a DAA Issuer have multiple key pairs and use them for one Attester? 2) Can a DAA Issuer use one key pair to generate multiple credentials for one Attester? o A credential is conveyed from an Endorser to an Attester in combination with the conveyance of the public key certificates from Endorser to Verifier. Comment > Is there another way to convey the public key certificate, for example, can the public key certificates be conveyed from Endorser to Attester first and then from Attester to Verifier? The zero-knowledge proofs required cannot be created by an Attester alone - like the Endorsements of RoTs - and have to be created by a trustable third entity - like an Endorser. Due to that semantic overlap, the Endorser role is augmented via the definition of DAA duties as defined below. This augmentation enables the Endorser to convey trustable third party statements both to Verifier roles and Attester roles. Comment > For "the definition of DAA duties as defined below", what is the definition of DAA duties? Comment > In the last sentence, the Endorsement with its original definition is the third party statement for Verifier and Attester, isn't it? So, "augmentation" isn't the correct expression. Section 6 Normative Prerequisites Attester Identity: The provenance of Evidence with respect to a distinguishable Attesting Environment MUST be correct and unambiguous. Comment > The Attester Identity is to identify which Attester the Evidence comes from. But if the Attester has multiple Attesting Environments, what should be the Attester Identity?


Question: _mandatory_ <del> A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. _mandatory_ </del> A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Claims included in Evidence.

Comment > The TPM's AIK certificate is one kind of Attester Identity, right? Attestation Evidence Authenticity: Attestation Evidence MUST be correct and authentic. Comment > Is it appropriate to say "correct Evidence"? If saying so, I think it means that the Evidence satisfies the Attestation Policy for Evidence. Authentication Secret: An Authentication Secret MUST be available exclusively to an Attester's Attesting Environment. The Attester MUST protect Claims with that Authentication Secret, thereby proving the authenticity of the Claims included in Evidence. The Authentication Secret MUST be established before RATS can take place. Comment > Does the Authentication Secret represent the identity of the Attesting Environment? Comment > How to understand the Authentication Secret, and is it necessary all the time? For example, in our implementation, during the router booting up, the BIOS measures the BootLoader and records the measured hash value into the TPM, and the BootLoader measures the OS Kernel and records the measured hash value into the TPM as well. From the Layered Attestation perspective, I think (BIOS + TPM) is the Attesting Environment and (BootLoader + TPM) is also the Attesting Environment. But the Claims (measured hash values) aren't protected separately, and they finally becomes the Evidence (TPM Quote) and it's only protected by the TPM's AIK. So, what is the Authentication Secret? Section 7 Generic Information Elements Attester Identity ('attesterIdentity'): mandatory A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. Comment > Previous section says "Attester Identity" is about "a distinguishable Attesting Environment", and here says it's about "a distinguishable Attester". Comment > How to understand "without accompanying evidence about its validity"? Attester Identity ('attesterIdentity'): mandatory In DAA, the Attester's identity is not revealed to the verifier. The Attester is issued with a credential by the Endorser that is randomized and then used to anonymously confirm the validity of their evidence. The evidence is verified using the Endorser's public key. Comment > I think here means the DAA credential represents the Attester Identity. Comment > There is ambiguity of "that is randomized", does it mean randomized Endorser or randomized credential?


Question: _mandatory_ <del> A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. _mandatory_ </del> A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Claims included in Evidence.

Comment > For "confirm the validity of their evidence", what does "their" refer to? And what does "the validity of evidence" mean? Authentication Secret IDs ('authSecID'): mandatory A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Evidence. Comment > Previous section says "Authentication Secret" is used to protect Claims, but here says it's used to protect Evidence. Comment > As I understand, if Authentication Secret represents the identity of Attesting Environment, then it's not mandatory, at least in our implementation. Authentication Secret IDs ('authSecID'): mandatory In DAA, Authentication Secret IDs are represented by the Endorser (DAA issuer)'s public key that MUST be used to create DAA credentials for the corresponding Authentication Secrets used to protect Evidence. In DAA, an Authentication Secret ID does not identify a unique Attesting Environment but associated with a group of Attesting Environments. This is because an Attesting Environment should not be distinguishable and the DAA credential which represents the Attesting Environment is randomised each time it used. Comment > In my understanding, here says that the DAA credential identities the Attesting Environment. Compared with the description in the "Attester Identity" part, what does the DAA credential represent actually? Reference Claims ('refClaims') mandatory Reference Claims are components of Reference Values as defined in [I-D.ietf-rats-architecture]. [Editor's Note: Definition might become obsolete, if replaced by Reference Values. Is there a difference between Claims and Values here? Analogously, why is not named Reference Claims in the RATS arch?] Comment > I suggest using Reference Values to keep consistent with the RATS arch. Reference Claims are used to appraise the Claims received from an Attester via appraisal by direct comparison. Comment > "Direct comparison" isn't the correct expression, the comparison can have other rules. Claim Selection ('claimSelection'): optional A statement that represents a (sub-)set of Claims that can be created by an Attester. Claim Selections can act as filters that can specify the exact set of Claims to be included in Evidence. An Attester MAY decide whether or not to provide all Claims as requested via a Claim Selection.


Question: _mandatory_ <del> A statement about a distinguishable Attester made by an Endorser without accompanying evidence about its validity - used as proof of identity. _mandatory_ </del> A statement representing an identifier list that MUST be associated with corresponding Authentication Secrets used to protect Claims included in Evidence.

Comment > The "all Claims" may be ambiguous, I'd like to double check, does it refer to all Claims that the Attester can create or refer to all Claims requested in the Claim Selection? Section 8.1 Challenge/Response Remote Attestation Comment > In the sequence diagram, some elements in the bracket are not defined in the "Information Elements" section, such as targetEnvironment, collectedClaims, eventLog. Should these elements be defined? Section 9 Additional Application-Specific Requirements Depending on the use cases covered, there can be additional requirements. An exemplary subset is illustrated in this section. Comment > Here starts to talk about "additional requirements", but I wonder there is no other places in this draft talking about requirement, so what are the basic requirements? Regards & Thanks! Wei Pan


Question: should be able to use those records while safely ignoring the third record. <del> 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. </del> <ins> To avoid name lookup deadlock, clients that use Designated Resolvers need to ensure that a specific Encrypted Resolver is not used for any queries that are needed to resolve the name of the resolver itself or to perform certificate revocation checks for the resolver, as described in Section 10 of RFC8484.  Designated Resolvers need to ensure this deadlock is avoidable as described in Section 10 of RFC8484. </ins> This document focuses on discovering DoH, DoT, and DoQ Designated Resolvers.  Other protocols can also use the format defined by I-

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: should be able to use those records while safely ignoring the third record. <del> 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. </del> <ins> To avoid name lookup deadlock, clients that use Designated Resolvers need to ensure that a specific Encrypted Resolver is not used for any queries that are needed to resolve the name of the resolver itself or to perform certificate revocation checks for the resolver, as described in Section 10 of RFC8484.  Designated Resolvers need to ensure this deadlock is avoidable as described in Section 10 of RFC8484. </ins> This document focuses on discovering DoH, DoT, and DoQ Designated Resolvers.  Other protocols can also use the format defined by I-

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: should be able to use those records while safely ignoring the third record. <del> 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. </del> <ins> To avoid name lookup deadlock, clients that use Designated Resolvers need to ensure that a specific Encrypted Resolver is not used for any queries that are needed to resolve the name of the resolver itself or to perform certificate revocation checks for the resolver, as described in Section 10 of RFC8484.  Designated Resolvers need to ensure this deadlock is avoidable as described in Section 10 of RFC8484. </ins> This document focuses on discovering DoH, DoT, and DoQ Designated Resolvers.  Other protocols can also use the format defined by I-

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: should be able to use those records while safely ignoring the third record. <del> 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. </del> <ins> To avoid name lookup deadlock, clients that use Designated Resolvers need to ensure that a specific Encrypted Resolver is not used for any queries that are needed to resolve the name of the resolver itself or to perform certificate revocation checks for the resolver, as described in Section 10 of RFC8484.  Designated Resolvers need to ensure this deadlock is avoidable as described in Section 10 of RFC8484. </ins> This document focuses on discovering DoH, DoT, and DoQ Designated Resolvers.  Other protocols can also use the format defined by I-

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: should be able to use those records while safely ignoring the third record. <del> 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. </del> <ins> To avoid name lookup deadlock, clients that use Designated Resolvers need to ensure that a specific Encrypted Resolver is not used for any queries that are needed to resolve the name of the resolver itself or to perform certificate revocation checks for the resolver, as described in Section 10 of RFC8484.  Designated Resolvers need to ensure this deadlock is avoidable as described in Section 10 of RFC8484. </ins> This document focuses on discovering DoH, DoT, and DoQ Designated Resolvers.  Other protocols can also use the format defined by I-

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: Oblivious Relay Resource also needs to observe the guidance in relay- responsibilities. <ins> An Oblivious Gateway Resource acts as a gateway for requests to the Target Resource (see HTTP).  The one exception is that any information it might forward in a response MUST be encapsulated, unless it is responding to errors it detects before removing encapsulation of the request; see errors. </ins> An Oblivious Gateway Resource, if it receives any response from the Target Resource, sends a single 200 response containing the encapsulated response.  Like the request from the client, this

Section 5 details HTTP usage. It seems it's technically correct but the section closes with a sequence of paragraphs that jump back and forth between statements about how an Oblivious Gateway Resource treats requests or responses. Perhaps these could be consolidated to present requests first consistently. I.e. swap the final two paragraphs around


Question: versions are four-byte sequences with no additional constraints on format.  Leading zeros SHOULD be omitted for brevity. <del> Syntax: </del> <ins> Syntax of the "quic" parameter value: </ins> Where multiple versions are listed, the order of the values reflects the server's preference (with the first value being the most

Use the correct ABNF grammar to express repetition and fix the Reserved Frame Type link.
There is some baggage with this parameter - URL People were a bit grumpy with changing their parser 18 months ago, I think they might be even grumpier now that we have even more client implementations in the wild. What is the benefit of this change? I think we need an issue for due process and discussion.
Oh joy. This caused me to go look at our parser in Chrome, and realized we're still doing the old (pre 1097) quic=;quic= format. So Chrome has work to do no matter how we resolve this. That being said, I'd really rather not have two different ways to do this, so +1 to NAME 's comment on the motivation.
I can remove the additional unquoted token change and keep this PR purely as editorial fix. Before the PR, the current text does not have correct ABNF grammar. I added the unquoted token variant since it is permitted (but not required) by the grammar at URL Since HTTP/3 over QUIC is not the only user of this Alt-Svc header, I can imagine that generic parsers are written such that they already understand the unquoted token value. Thus, adding support for this should not be an additional burden? I have no strong opinion here. The additional CPU cost of handling both unquoted and quoted forms should be neglible. Disallowing the unquoted form is a restriction of the RFC 7838 grammar. Should I bring this to the list and/or create a new issue?
Let's create a new issue. You're correct that non-HTTP/3 implementations might need to handle this - hence the original issue which related back to structured headers (an attempt at defining some best practice in this regard -URL). Part of the problem is not CPU cost of DQUOTEs but expressing "a list of versions" and making sure that implementations know how to do that. Alt-Svc defines the parameter syntax but not how to handle repetition of parameters.
I removed the single quote change, this should be a purely editorial fix now. I'll create a new issue for the unquoted parameter value.