Question: request of the oblivious request resource that includes the same content.  When it receives a response, it sends a response to the client that includes the content of the response from the oblivious <del> request resource.  When generating a request, the proxy MUST follow the forwarding rules in Section 7.6 of HTTP. </del> <ins> request resource. When forwarding a request, the proxy MUST follow the forwarding rules in Section 7.6 of HTTP.  A generic HTTP intermediary implementation is suitable for the purposes of serving an oblivious proxy resource, but additional care is needed to ensure that client privacy is maintained. Firstly, a generic implementation will forward unknown fields.  For oblivious HTTP, a proxy SHOULD NOT forward unknown fields.  Though clients are not expected to include fields that might contain identifying information, removing unknown fields removes this privacy risk. Secondly, generic implementations are often configured to augment requests with information about the client, such as the Via field or the Forwarded field FORWARDED.  A proxy MUST NOT add information about the client identity when forwarding requests. </ins> A proxy can also generate responses, though it assumed to not be able to examine the content of a request (other than to observe the choice of key identifier, KDF, and AEAD), so it is also assumed that it cannot generate an encapsulated response. <del> A proxy MUST NOT add information about the client identity when forwarding requests.  This includes the Via field, the Forwarded field FORWARDED, and any similar information.  A client does not depend on the proxy using an authenticated and encrypted connection to the oblivious request resource, only that information about the client not be attached to forwarded requests. </del> 7.2.1. As there are privacy benefits from having a large rate of requests

Let's be clearer about what it means to proxy here. Also, since it is the same text, talk about TLS assumptions more directly. This will interact poorly with . Sorry about that NAME
From Vienna chat. A proxy is not a generic HTTP intermediary, and therefore is not subject to the same rules.
From NAME Generic proxies would forward unknown HTTP headers between clients and targets. We should be very clear that oblivious proxies are not generic, and should not be doing things like forwarding unknown headers arbitrarily between client and target, or target and client.
requests. This includes the Via field, the Forwarded field {{?FORWARDED=RFC7239}}, and any similar information. A client does not depend on the proxy using an authenticated and encrypted connection to the oblivious request resource, only that information about the client not be attached to forwarded requests. Obviously, you need encryption on one or the other side of the proxy, right? Probably this document should require it on the inbound side, but I don't see the text that requires it. Did I just miss it?
Yeah, it's only necessary on the inbound side, per the analysis, though the document assumes it's on both sides.


Question: provide credentials to an attacker.  Browsers can authenticate servers but cannot detect cleverly misspelled domains, for example. <del> 5.2. </del> <ins> 6.2. </ins> The solution described here assumes that when the User Equipment needs to trust the API server, server authentication will be performed using TLS mechanisms. <del> 5.3. </del> <ins> 6.3. </ins> The solution described here requires that the API be secured using TLS.  This is required to allow the user equipment and API server to

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


Question: security considerations for this document. While formally the JSEP interface is an API, it is better to think of <del> it is an Internet protocol, with the JS being untrustworthy from the perspective of the endpoint.  Thus, the threat model of RFC3552 applies.  In particular, JS can call the API in any order and with any inputs, including malicious ones.  This is particularly relevant when we consider the SDP which is passed to setLocalDescription(). While correct API usage requires that the application pass in SDP which was derived from createOffer() or createAnswer(), there is no guarantee that applications do so.  The JSEP implementation MUST be prepared for the JS to pass in bogus data instead. Conversely, the application programmer needs to be aware that the JS does not have complete control of endpoint behavior.  One case that bears particular mention is that editing ICE candidates out of the SDP or suppressing trickled candidates does not have the expected behavior: implementations will still perform checks from those candidates even if they are not sent to the other side.  Thus, for instance, it is not possible to prevent the remote peer from learning your public IP address by removing server reflexive candidates. Applications which wish to conceal their public IP address should instead configure the ICE agent to use only relay candidates. </del> <ins> it is an Internet protocol, with the application JavaScript being untrustworthy from the perspective of the JSEP implementation.  Thus, the threat model of RFC3552 applies.  In particular, JavaScript can call the API in any order and with any inputs, including malicious ones.  This is particularly relevant when we consider the SDP which is passed to setLocalDescription().  While correct API usage requires that the application pass in SDP which was derived from createOffer() or createAnswer(), there is no guarantee that applications do so. The JSEP implementation MUST be prepared for the JavaScript to pass in bogus data instead. Conversely, the application programmer needs to be aware that the JavaScript does not have complete control of endpoint behavior.  One case that bears particular mention is that editing ICE candidates out of the SDP or suppressing trickled candidates does not have the expected behavior: implementations will still perform checks from those candidates even if they are not sent to the other side.  Thus, for instance, it is not possible to prevent the remote peer from learning your public IP address by removing server reflexive candidates.  Applications which wish to conceal their public IP address should instead configure the ICE agent to use only relay candidates. </ins> 9.

From "Opsdir last call review of draft-ietf-rtcweb-jsep-21" A minor observation, not even a nit, is that the text in the Security Considerations "While formally the JSEP interface is an API, it is better to think of it is an Internet protocol, with the JS being untrustworthy from the perspective of the endpoint. " could be more clear.
I have no idea what to do with this. Obviously I thought it was clear when wrote it, and still do.
This is the only place in the document where we use "JS". I think it would be good to spell out "JavaScript", and potentially use "application JavaScript" in the first usage. Finally, I think we should use "implementation" rather than "endpoint" in this para.
LGTM


Question: The client uses the "signature_algorithms" extension to indicate to the server which signature algorithms may be used in digital <del> signatures.  Clients which desire the server to authenticate via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a </del> <ins> signatures.  Clients which desire the server to authenticate itself via a certificate MUST send this extension.  If a server is authenticating via a certificate and the client has not sent a </ins> "signature_algorithms" extension then the server MUST abort the handshake with a "missing_extension" alert (see mti-extensions).

Adding "itself" makes the sentence much easier to understand. Actually, two Japanese, who are implementing TLS 1.3 independently, took a long time to understand this.


Question: Deployments should take care that the length of the PSK identity is sufficient to avoid obvious collisions. <del> [[OPEN ISSUE: discuss implication of collisions between external and resumption PSKs.]] </del> <ins> 6.1.2. It is possible, though unlikely, that an external PSK identity may clash with a resumption PSK identity.  The TLS stack implementation and sequencing of PSK callbacks influences the application's behaviour when identity collisions occur.  When a server receives a PSK identity in a TLS 1.3 ClientHello, some TLS stacks execute the application's registered callback function before checking the stack's internal session resumption cache.  This means that if a PSK identity collision occurs, the application will be given precedence over how to handle the PSK. </ins> 7.

FIxed up: some nits on recommendations. I think the wording was a bit off on low entropy PSKs, so I lifted from ekrs text from earlier in the draft. some of the stack interface stuff on hints is not valid for TLS1.3 (hints are TLS1.2 and earlier), so removed it. Some prelim text on collisions. For completeness, will take a look at gnutls and wolfssl order too. Note, even with the OpenSSL callback sequence, the application still does not know if there is a collision...
Starter text from NAME
NAME can you please take this?
Ping NAME


Question: If the "index" value is equal to the size of the group, increment the size of the group, and extend the tree accordingly <del> Verify the signature on the included UserInitKey; if the signature verification fails, abort </del> <ins> Verify the signature on the included ClientInitKey; if the signature verification fails, abort </ins> Generate a WelcomeInfo object describing the state prior to the add, and verify that its hash is the same as the value of the

Overall, this seems OK. Just using "InitKey" would be clear and less wordy.
I tried this and that led people to confuse and
Here's the Weekly Digest for : - - Last week 5 issues were created. Of these, 1 issues have been closed and 4 issues are still open. :greenheart: , by :greenheart: , by :greenheart: , by :greenheart: , by :heart: , by - - Last week, 9 pull requests were created, updated or merged. Last week, 3 pull requests were opened. :greenheart: , by :greenheart: , by :greenheart: , by Last week, 1 pull request was updated. :yellowheart: , by Last week, 5 pull requests were merged. :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by :purpleheart: , by - - Last week there were 8 commits. :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by :hammerandwrench: by - - Last week there were 2 contributors. :bustinsilhouette: :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 .
These keys are Client one-time use keys, so "UserInitKey" seems like a strange name.
I'm fine with ClientInitKey, as long as a client is not only a physical endpoint. Changes in the architecture doc should make this clear soon.


Question: 7.5. <del> The Signal could inform the User Equipment that it is being held captive.  There is no requirement that the User Equipment do something about this.  Devices MAY permit users to disable automatic reaction to captive-portal indications for privacy reasons.  However, there would be the trade-off that the user doesn't get notified when network access is restricted.  Hence, end-user devices MAY allow users to manually control captive portal interactions, possibly on the granularity of Provisioning Domains. </del> <ins> The Captive Portal Signal could inform the User Equipment that it is being held captive.  There is no requirement that the User Equipment do something about this.  Devices MAY permit users to disable automatic reaction to Captive Portal Signals indications for privacy reasons.  However, there would be the trade-off that the user doesn't get notified when network access is restricted.  Hence, end-user devices MAY allow users to manually control captive portal interactions, possibly on the granularity of Provisioning Domains. </ins>

The working group has decided that we do not need to tackle specifying the signaling protocol. Rather than leaving the document with it partially specified, remove most of the text related to it. Keep some basic examples of constraints. This also removes the text which claimed that the document would specify rqeuirements for the protocol. It does not. Made a few related editorial changes.
As suggested by NAME : Do a pass through the document with this text in mind and make sure it makes sense. Clean up anything that may have depended on removed text.
Thanks for putting this together. This seems sufficient, and brief.


Question: A token allows a server to correlate activity between the connection where the token was issued and any connection where it is used. <del> Clients that want to break continuity of identity with a server MAY </del> <ins> Clients that want to break continuity of identity with a server can </ins> discard tokens provided using the NEW_TOKEN frame.  In comparison, a token obtained in a Retry packet MUST be used immediately during the connection attempt and cannot be used in subsequent connection

NAME said:
I think "can" works equally well, given the precondition. I'll make that change.


Question: 4.1. <ins> When a client discovers Designated Resolvers from an Unencrypted Resolver IP address, it can choose to use these Designated Resolvers either automatically, or based on some other policy, heuristic, or user choice. This document defines two preferred methods to automatically use Designated Resolvers: Authenticated Discovery authenticated, for when a TLS certificate can be used to validate the resolver's identity. Opportunistic Discovery opportunistic, for when a resolver is accessed using a non-public IP address. A client MAY additionally use a discovered Designated Resolver without either of these methods, based on implementation-specific policy or user input.  Details of such policy are out of scope of this document.  Clients SHOULD NOT automatically use a Designated Resolver without some sort of validation, such as the two methods defined in this document or a future mechanism. 4.2. Authenticated Discovery is a mechanism that allows automatic use of a Designated Resolver that supports DNS encryption that performs a TLS handshake. </ins> In order to be considered an authenticated Designated Resolver, the <del> TLS certificate presented by the Encrypted Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the </del> <ins> TLS certificate presented by the Designated Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the </ins> designating Unencrypted Resolver within the SubjectAlternativeName certificate field.  The client MUST check the SubjectAlternativeName field for both the Unencrypted Resolver's IP address and the

Right now, we only allow authenticated and matching-IP opportunistic use of the DDR record. While use of the record in a case where authentication fails isn't safe to use automatically, we should clarify that implementations MAY choose to use the information anyhow by policy, and possibly with user control.
For authentication to matter, it generally has to operate without fallback. Currently the text is not very clear on this point, but it sure seems like IP-authenticated mode is expected to fall back to cleartext if no upgrade is possible. I think we need to clarify the use case for an authenticated mode, or abandon the distinction between opportunistic and authenticated. In my view, authenticated mode only makes sense if (1) the resolver is identified by its IP address AND (2) the system knows a priori that this resolver supports encrypted DNS, so that it can refuse to fall back to cleartext if the upgrade information is stripped by a network attacker. This is a sufficiently narrow use case that I lean toward dropping it entirely and recommending Discovery Using Resolver Names (Section 5) or opportunistic instead.
Currently, this is what we say (which I now see a grammatical error in, but there it is): We don't say anything else because that would be out of WG scope. The point of the document is to help a stub resolver configured with a recursive resolver known only by IP address to bootstrap into encrypted DNS. The stub resolver's posture on whether to fall back to unencrypted DNS or simply refuse to use the resolver is its own business. Look at this through a common OS scenario: the OS stub resolver learns an IP address from DHCP, and it's a public IP address (my old ISP did this). It knows of no other resolvers because the user doesn't know what DNS is and that's the default configuration (use network recommendation). If I try to use DDR and I get no answer back, then I'm in the same position as I was before DDR: I know of no other resolver, so I either have to use this one or have no DNS resolutions. DDR did not introduce that conundrum; it offers clients a way out of it when DNR is not present and there is no plain-text DNS attack present. The authenticated DDR mode allows such a client to be confident in the authenticity of the bootstrap even though it started over plain text.


Question: 4.1. <ins> When a client discovers Designated Resolvers from an Unencrypted Resolver IP address, it can choose to use these Designated Resolvers either automatically, or based on some other policy, heuristic, or user choice. This document defines two preferred methods to automatically use Designated Resolvers: Authenticated Discovery authenticated, for when a TLS certificate can be used to validate the resolver's identity. Opportunistic Discovery opportunistic, for when a resolver is accessed using a non-public IP address. A client MAY additionally use a discovered Designated Resolver without either of these methods, based on implementation-specific policy or user input.  Details of such policy are out of scope of this document.  Clients SHOULD NOT automatically use a Designated Resolver without some sort of validation, such as the two methods defined in this document or a future mechanism. 4.2. Authenticated Discovery is a mechanism that allows automatic use of a Designated Resolver that supports DNS encryption that performs a TLS handshake. </ins> In order to be considered an authenticated Designated Resolver, the <del> TLS certificate presented by the Encrypted Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the </del> <ins> TLS certificate presented by the Designated Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the </ins> designating Unencrypted Resolver within the SubjectAlternativeName certificate field.  The client MUST check the SubjectAlternativeName field for both the Unencrypted Resolver's IP address and the

I do not agree this scenario is sufficiently narrow to drop. Is your concern over the usefulness of the scenario, or over naming it "authenticated"? I am open to suggestions on the latter; I strongly disagree with the former.
Both. How is this information useful to the client? I have not heard of any proposal for any client to behave differently on the basis of whether its encrypted connection is authenticated, when the resolver is identified by IP address. As for the name, RFC 7435 is the reference. I find it a bit confusing, but here's some of the relevant text: The "authenticated" section does not seem to describe an "authenticated" protocol by this definition, because it does not provide a downgrade-resistant method to determine that authentication is expected to work.
Please suggest a more accurate name then please. I do agree behavior naming should be consistent with other documents. Your bar for useful is apparently different from mine. Before DDR, a client configured only with an IP address had only unencrypted DNS as an option. With DDR, the client can possibly encrypt that connection. A transient attacker would have to have been present for the initial SVCB discovery to prevent that; an attacker arriving after DDR has taken place will be kept out of the loop. In the worst case, a client is returned to square one. I do not agree that just because a mechanism can be prevented means the mechanism provides no value. It doesn't have to. In the common case, the client is forced by lack of knowledge to use unencrypted DNS. If it can from that default configuration divine encrypted DNS configuration, that's a net positive. Resolver selection is out of scope and has nothing to do with it.
I've updated to address this question by reformulating the concept of authentication, and being much more explicit about the threat model. Yes, that's a good step, but it doesn't rely on authentication. This is a very helpful observation. I've incorporated it in .
I believe this particular issue is largely overtaken by events. Particularly, I think we've added some clarity and escape hatches with , and protections with .


Question: 4.1. <ins> When a client discovers Designated Resolvers from an Unencrypted Resolver IP address, it can choose to use these Designated Resolvers either automatically, or based on some other policy, heuristic, or user choice. This document defines two preferred methods to automatically use Designated Resolvers: Authenticated Discovery authenticated, for when a TLS certificate can be used to validate the resolver's identity. Opportunistic Discovery opportunistic, for when a resolver is accessed using a non-public IP address. A client MAY additionally use a discovered Designated Resolver without either of these methods, based on implementation-specific policy or user input.  Details of such policy are out of scope of this document.  Clients SHOULD NOT automatically use a Designated Resolver without some sort of validation, such as the two methods defined in this document or a future mechanism. 4.2. Authenticated Discovery is a mechanism that allows automatic use of a Designated Resolver that supports DNS encryption that performs a TLS handshake. </ins> In order to be considered an authenticated Designated Resolver, the <del> TLS certificate presented by the Encrypted Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the </del> <ins> TLS certificate presented by the Designated Resolver MUST contain both the domain name (from the SVCB answer) and the IP address of the </ins> designating Unencrypted Resolver within the SubjectAlternativeName certificate field.  The client MUST check the SubjectAlternativeName field for both the Unencrypted Resolver's IP address and the

Same comment for line 337/360 about referring to the resolver as Designated versus Encrypted (it's unmodified in this PR but based on your agreement with the other in-line comment it may need modified as well) I think we will need to add some text to the Security Considerations section to mention the security promise difference between following the MAY or not (for optional use of the unverifiable designation). However, we can close this PR without it and handle that in a new PR if that's preferable.


Question: SetupBaseS() will be, as well as the aad for context.Seal().  The aad might be the entire "transcript" between the client and helper.] <del> [OPEN ISSUE: Is it safe to generate the proof once, then secret-share between each (leader, helper) pair?  Probably not in general, but maybe for Prio?] </del> [OPEN ISSUE: allow server to send joint randomness in UploadStartResp, and then enforce uniqueness via double-spend state or something else (see issue#48).]

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


Question: streams, and those have stream IDs that are divisible by four.) A variable-length integer indicating the context ID of the <del> datagram (see datagram-contexts). </del> <ins> datagram (see datagram-contexts).  Whether or not this field is present depends on which registration capsules were exchanged on the associated stream: if a REGISTER_DATAGRAM_CONTEXT capsule (see register-capsule) has been sent or received on this stream, then the field is present; if a REGISTER_DATAGRAM_NO_CONTEXT capsule (see register-no-context-capsule) has been sent or received, then this field is absent; if neither has been sent or received, then it is not yet possible to parse this datagram and the receiver MUST either drop that datagram silently or buffer it temporarily while awaiting the registration capsule. </ins> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty.

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


Question: streams, and those have stream IDs that are divisible by four.) A variable-length integer indicating the context ID of the <del> datagram (see datagram-contexts). </del> <ins> datagram (see datagram-contexts).  Whether or not this field is present depends on which registration capsules were exchanged on the associated stream: if a REGISTER_DATAGRAM_CONTEXT capsule (see register-capsule) has been sent or received on this stream, then the field is present; if a REGISTER_DATAGRAM_NO_CONTEXT capsule (see register-no-context-capsule) has been sent or received, then this field is absent; if neither has been sent or received, then it is not yet possible to parse this datagram and the receiver MUST either drop that datagram silently or buffer it temporarily while awaiting the registration capsule. </ins> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty.

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


Question: BCP 14 RFC2119 RFC8174 when, and only when, they appear in all capitals, as shown here. <del> This document uses the Augmented BNF defined in HTTP to specify valid protocol elements.  Additionally, it uses the modified "parameter" rule from RFC5987 and the "URI-Template" rule from URI-TEMPLATE. </del> <ins> This specification uses the following terms from STRUCTURED-FIELDS: List, String, Parameter. </ins> 2. <del> The Link-Template header field provides a means for serialising one or more links into HTTP message metadata.  It is semantically equivalent to the Link header field defined in WEB-LINKING, except that it uses URI Templates URI-TEMPLATE to convey the structure of links. </del> <ins> The Link-Template header field is a Structured Field STRUCTURED- FIELDS that serializes one or more links into HTTP message metadata. It is semantically equivalent to the Link header field defined in WEB-LINKING, except that it uses URI Templates URI-TEMPLATE to convey the structure of links. Its value is a List of Strings.  Each String is a URI Template, and Parameters on it carry associated metadata. </ins> For example:

Emerging best practice is to use for new headers, so that parsing is well-defined. Arguments for sticking with a -like syntax: Consistence with (IMO a very poor justification) Reuse of parsers / other software (it's not well-defined, tho) ???
We could also talk about creating a SF version of (maybe ?).
Matching SF and headers would be appealing.
In the meantime (or maybe before ;) -- URL


Question: 9. <ins> Each protocol that can run as part of a Transport Services implementation defines both its API mapping as well as implementation details. API mappings for a protocol apply most to Connections in which the given protocol is the "top" of the Protocol Stack.  For example, the mapping of the "Send" function for TCP applies to Connections in which the application directly sends over TCP.  If HTTP/2 is used on top of TCP, the HTTP/2 mappings take precendence. Each protocol has a notion of Connectedness.  Possible values for Connectedness are: Unconnected.  Unconnected protocols do not establish explicit state between endpoints, and do not perform a handshake during Connection establishment. Connected.  Connected protocols establish state between endpoints, and perform a handshake during Connection establishment.  The handshake may be 0-RTT to send data or resume a session, but bidirectional traffic is required to confirm connectedness. Multiplexing Connected.  Multiplexing Connected protocols share properties with Connected protocols, but also explictly support opening multiple application-level flows.  This means that they can support cloning new Connection objects without a new explicit handshake. Protocols also define a notion of Data Unit.  Possible values for Data Unit are: Byte-stream.  Byte-stream protocols do not define any Message boundaries of their own apart from the end of a stream in each direction. Datagram.  Datagram protocols define Message boundaries at the same level of transmission, such that only complete (not partial) Messages are supported. Message.  Message protocols support Message boundaries that can be sent and received either as complete or partial Messages.  Maximum Message lengths can be defined, and Messages can be partially reliable. </ins> 9.1. <del> Connection lifetime for TCP translates fairly simply into the the abstraction presented to an application.  When the TCP three-way handshake is complete, its layer of the Protocol Stack can be considered Ready (established).  This event will cause racing of Protocol Stack options to complete if TCP is the top-level protocol, at which point the application can be notified that the Connection is Ready to send and receive. If the application sends a Close, that can translate to a graceful termination of the TCP connection, which is performed by sending a FIN to the remote endpoint.  If the application sends an Abort, then the TCP state can be closed abruptly, leading to a RST being sent to the peer. Without a layer of framing (a top-level protocol in the established Protocol Stack that preserves message boundaries, or an application- supplied deframer) on top of TCP, the receiver side of the transport system implementation can only treat the incoming stream of bytes as a single Message, terminated by a FIN when the Remote Endpoint closes the Connection. </del> <ins> Connectedness: Connected Data Unit: Byte-stream API mappings for TCP are as follows: TCP connections between two hosts map directly to Connection objects. Calling "Initiate" on a TCP Connection causes it to reserve a local port, and send a SYN to the Remote Endpoint. Early idempotent data is sent on a TCP Connection in the SYN, as TCP Fast Open data. A TCP Connection is ready once the three-way handshake is complete. TCP can throw various errors during connection setup. Specifically, it is important to handle a RST being sent by the peer during the handshake. Once established, TCP throws errors whenever the connection is disconnected, such as due to receive a RST from the peer; or hitting a TCP retransmission timeout. Calling "Listen" for TCP binds a local port and prepares it to receive inbound SYN packets from peers. TCP Listeners will deliver new connections once they have replied to an inbound SYN with a SYN-ACK. Calling "Clone" on a TCP Connection creates a new Connection with equivalent parameters.  The two Connections are otherwise independent. TCP does not on its own preserve Message boundaries.  Calling "Send" on a TCP connection lays out the bytes on the TCP send stream without any other delineation.  Any Message marked as Final will cause TCP to send a FIN once the Message has been completely written. TCP delivers a stream of bytes without any Message delineation. All data delivered in the "Received" or "ReceivedPartial" event will be part of a single stream-wide Message that is marked Final (unless a MessageFramer is used).  EndOfMessage will be delivered when the TCP Connection has received a FIN from the peer. Calling "Close" on a TCP Connection indicates that the Connection should be gracefully closed by sending a FIN to the peer and waiting for a FIN-ACK before delivering the "Closed" event. Calling "Abort" on a TCP Connection indicates that the Connection should be immediately closed by sending a RST to the peer. </ins> 9.2. <del> UDP as a direct transport does not provide any handshake or connectivity state, so the notion of the transport protocol becoming Ready or established is degenerate.  Once the system has validated that there is a route on which to send and receive UDP datagrams, the protocol is considered Ready.  Similarly, a Close or Abort has no meaning to the on-the-wire protocol, but simply leads to the local state being torn down. </del> <ins> Connectedness: Unconnected </ins> <del> When sending and receiving messages over UDP, each Message should correspond to a single UDP datagram.  The Message can contain metadata about the packet, such as the ECN bits applied to the packet. </del> <ins> Data Unit: Datagram </ins> <del> 9.3. </del> <ins> API mappings for UDP are as follows: </ins> <del> To support sender-side stream schedulers (which are implemented on the sender side), a receiver-side Transport System should always support message interleaving RFC8260. </del> <ins> UDP connections represent a pair of specific IP addresses and ports on two hosts. </ins> <del> SCTP messages can be very large.  To allow the reception of large messages in pieces, a "partial flag" can be used to inform a (native SCTP) receiving application that a message is incomplete.  After receiving the "partial flag", this application would know that the next receive calls will only deliver remaining parts of the same message (i.e., no messages or partial messages will arrive on other streams until the message is complete) (see Section 8.1.20 in RFC6458).  The "partial flag" can therefore facilitate the implementation of the receiver buffer in the receiving application, at the cost of limiting multiplexing and temporarily creating head- of-line blocking delay at the receiver. </del> <ins> Calling "Initiate" on a UDP Connection causes it to reserve a local port, but does not generate any traffic. </ins> <del> When a Transport System transfers a Message, it seems natural to map the Message object to SCTP messages in order to support properties such as "Ordered" or "Lifetime" (which maps onto partially reliable delivery with a SCTP_PR_SCTP_TTL policy RFC6458).  However, since multiplexing of Connections onto SCTP streams may happen, and would be hidden from the application, the Transport System requires a per- stream receiver buffer anyway, so this potential benefit is lost and the "partial flag" becomes unnecessary for the system. </del> <ins> Early data on a UDP Connection does not have any special meaning. The data is sent whenever the Connection is Ready. </ins> <del> The problem of long messages either requiring large receiver-side buffers or getting in the way of multiplexing is addressed by message interleaving RFC8260, which is yet another reason why a receivers- side transport system supporting SCTP should implement this mechanism. </del> <ins> A UDP Connection is ready once the system has reserved a local port and has a path to send to the Remote Endpoint. </ins> <del> 9.4. </del> <ins> UDP Connections can only generate errors on initiation due to port conflicts on the local system. Once in use, UDP throws errors upon receiving ICMP notifications indicating failures in the network. Calling "Listen" for UDP binds a local port and prepares it to receive inbound UDP datagrams from peers. UDP Listeners will deliver new connections once they have received traffic from a new Remote Endpoint. Calling "Clone" on a UDP Connection creates a new Connection with equivalent parameters.  The two Connections are otherwise independent. Calling "Send" on a UDP connection sends the data as the payload of a complete UDP datagram.  Marking Messages as Final does not change anything in the datagram's contents. UDP only delivers complete Messages to "Received", each of which represents a single datagram received in a UDP packet. Calling "Close" on a UDP Connection releases the local port reservation. Calling "Abort" on a UDP Connection is identical to calling "Close". 9.3. </ins> The mapping of a TLS stream abstraction into the application is <del> equivalent to the contract provided by TCP (see tcp).  The Ready state should be determined by the completion of the TLS handshake, which involves potentially several more round trips beyond the TCP handshake.  The application should not be notified that the Connection is Ready until TLS is established. </del> <ins> equivalent to the contract provided by TCP (see tcp), and builds upon many of the actions of TCP connections. Connectedness: Connected Data Unit: Byte-stream Connection objects represent a single TLS connection running over a TCP connection between two hosts. Calling "Initiate" on a TLS Connection causes it to first initiate a TCP connection.  Once the TCP protocol is Ready, the TLS handshake will be performed as a client (starting by sending a "client_hello", and so on). Early idempotent data is supported by TLS 1.3, and sends encrypted application data in the first TLS message when performing session resumption.  For older versions of TLS, or if a session is not being resumed, the initial data will be delayed until the TLS handshake is complete.  TCP Fast Option can also be enabled automatically. A TLS Connection is ready once the underlying TCP connection is Ready, and TLS handshake is also complete and keys have been established to encrypt application data. In addition to TCP initiation errors, TLS can generate errors during its handshake.  Examples of error include a failure of the peer to successfully authenticate, the peer rejecting the local authentication, or a failure to match versions or algorithms. TLS connections will generate TCP errors, or errors due to failures to rekey or decrypt received messages. Calling "Listen" for TLS listens on TCP, and sets up received connections to perform server-side TLS handshakes. TLS Listeners will deliver new connections once they have successfully completed both TCP and TLS handshakes. As with TCP, calling "Clone" on a TLS Connection creates a new Connection with equivalent parameters.  The two Connections are otherwise independent. Like TCP, TLS does not preserve message boundaries.  Although application data is framed natively in TLS, there is not a general guarantee that these TLS messages represent semantically meaningful application stream boundaries.  Rather, sending data on a TLS Connection only guarantees that the application data will be transmitted in an encrypted form.  Marking Messages as Final causes a "close_notify" to be generated once the data has been written. Like TCP, TLS delivers a stream of bytes without any Message delineation.  The data is decrypted prior to being delivered to the application.  If a "close_notify" is received, the stream-wide Message will be delivered with EndOfMessage set. Calling "Close" on a TLS Connection indicates that the Connection should be gracefully closed by sending a "close_notify" to the peer and waiting for a corresponding "close_notify" before delivering the "Closed" event. Calling "Abort" on a TCP Connection indicates that the Connection should be immediately closed by sending a "close_notify", optionally preceded by "user_canceled", to the peer. Implementations do not need to wait to receive "close_notify" before delivering the "Closed" event. 9.4. DTLS follows the same behavior as TLS (tls), with the notable exception of not inheriting behavior directly from TCP.  Differences from TLS are detailed below, and all cases not explicitly mentioned should be considered the same as TLS. Connectedness: Connected Data Unit: Datagram Connection objects represent a single DTLS connection running over a set of UDP ports between two hosts. Calling "Initiate" on a DTLS Connection causes it reserve a UDP local port, and begin sending handshake messages to the peer over UDP.  These messages are reliable, and will be automatically retransmitted. A DTLS Connection is ready once the TLS handshake is complete and keys have been established to encrypt application data. Sending over DTLS does preserve message boundaries in the same way that UDP datagrams do.  Marking a Message as Final does send a "close_notify" like TLS. Receiving over DTLS delivers one decrypted Message for each received DTLS datagram.  If a "close_notify" is received, a Message will be delivered that is marked as Final. </ins> 9.5.

Starting to address This is an early review, to check if we like the structure. I'd also like help filling out the SCTP section!
I can also help with SCTP, which I would do in the same style that I suggest above (for TCP, in my example of "Abort") - also later.
We've updated Implementation mapping details for most protocols with , but we didn't tackle SCTP yet.
I'm fine with this being assigned to me. However, it's more than just writing the SCTP text. Here's the relevant part of what I wrote in PR : I don't suggest to delete much of the text that's there but definitely amend it with the RFC reference at least for what's covered in RFC 8303. There's a very direct line from this type of text in RFC 8303 to the original specs, so I do believe that should be helpful. That's (obviously) post-Montreal though!
NAME please send a PR along these lines.
LGTM modulo mwelzl changes.I think this is a good step forward. This said, I think we should describe things focusing on the transport's API call to be made (in line with the spec - that's why we have RFCs 8303 and 8304) rather than protocol internals. E.g., rather than saying that Abort on a TCP connection transmits a RST, I think we should simply say that Abort calls ABORT.TCP [RFC 8303, Section 4.1]. I can take care of these things, later. I'd still like to focus more on the API doc at this time.


Question: Changes to this behavior are currently under discussion: see https://github.com/quicwg/base-drafts/issues/602. <del> 3.5. </del> <ins> 3.6. </ins> Round-trip time of QUIC flows can be inferred by observation once per flow, during the handshake, as in passive TCP measurement; this

Re SNI and ALPN: we can certainly point at the work in progress in TLS that will encrypt this information, but IMO the document should describe the current state of the world. I've just added something pointing to the SNI encryption document; while it seems that the tunneling technique described there could pretty clearly be applied to ALPN fronting as well, is there a reference for encrypting ALPN we can use here that doesn't leave details as an exercise for the reader?
I would actually prefer to describe the wire image of TLS and associated protocols in a separate document and just point to it because that's actually not only applicable for quic
I don't have a reference for encrypting ALPN. We don't have one. Maybe I should write one... On the plus side, it's something that benefits from the same techniques as SNI (and less likely to cause deployment issues, though that is only because we haven't ossified around it as much). As for the general point about now vs. later. One of the things we've tried to do is be very clear about what the invariants are, or what promises we are making. It's not the same thing as true ossification defense, but if we make it clear what we are committing to, maybe we won't have people relying on stuff we might want to change.


Question: to achieve similar performance.  Those features were introduced to HTTP in HTTP/2 RFC7540.  Earlier versions of HTTP are capable of conveying the semantic requirements of DOH but may result in very <del> poor performance for many uses cases. </del> <ins> poor performance. </ins> 6.3.

Hello, I am a non-native English speaker but I noticed the following sentence: "Earlier versions of HTTP are capable of conveying the semantic requirements of DOH but may result in very poor performance for many uses cases." Shouldn't be there at the end? Wiktionary ( URL ) suggests that plural of "use case" is "use cases", not "uses cases".


Question: ClientHello, MUST contain the ConnectionId structure.  This structure contains the CID value the client wishes the server to use when sending messages to the client.  A zero-length CID value indicates <del> that the client is prepared to send with a CID but does not wish the </del> <ins> that the client is prepared to send using a CID but does not wish the </ins> server to use one when sending. A server willing to use CIDs will respond with a "connection_id" extension in the ServerHello, containing the CID it wishes the client to use when sending messages towards it.  A zero-length value <del> indicates that the server will send with the client's CID but does not wish the client to include a CID. </del> <ins> indicates that the server will send using the client's CID but does not wish the client to include a CID when sending. </ins> Because each party sends the value in the "connection_id" extension it wants to receive as a CID in encrypted records, it is possible for

URL Francesca Palombini has entered the following ballot position for draft-ietf-tls-dtls-connection-id-11: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL COMMENT: Thank you for the work on this document. I only have minor comments and nits below. Francesca sending messages to the client. A zero-length CID value indicates that the client is prepared to send with a CID but does not wish the server to use one when sending. ... to use when sending messages towards it. A zero-length value indicates that the server will send with the client's CID but does not wish the client to include a CID. FP: clarification question: I am not sure the following formulation is very clear to me: "to send with a(/the client's) CID". Could "send with" be rephrased to clarify? The previous paragraph uses "using a CID value", that would be better IMO. the record format defined in {{dtls-ciphertext} with the new MAC FP: nit - missing "}" in markdown. The following MAC algorithm applies to block ciphers that use the with Encrypt-then-MAC processing described in [RFC7366]. FP: remove "with" Section 10.1 FP: I believe you should specify 1. what allowed values are for this column (i.e. Y or N, and what they mean) and 2. what happens to the existing entries - namely that they all get "N" value. Section 10.2 FP: Just checking - why is 53 "incompatible with this document"? Value Extension Name TLS 1.3 DTLS Only Recommended Reference FP: nit- s/DTLS Only/DTLS-Only to be consistent with 10.1


Question: Mapping of application data to streams is application-specific and described for HTTP/s in QUIC-HTTP.  In general data that can be processed independently, and therefore would suffer from head of line <del> blocking, if forced to be received in order, should be transmitted over different streams.  If there is a logical grouping of those data chunks or messages, stream can be reused, or a new stream can be opened for each chunk/message.  If one message is mapped on a single stream, resetting the stream if the message is not needed anymore can be used to emulate partialreliability on a message basis.  If a QUIC receiver has maximum allowed concurrent streams open and the sender on the other end indicates that more streams are needed, it doesn't automatically lead to an increase of the maximum number of streams by the receiver.  Therefore it can be valuable to expose maximum number of allowed, currently open and currently used streams to the application to make the mapping of data to streams dependent on this information. </del> <ins> blocking if forced to be received in order, should be transmitted over different streams.  If the application requires certain data to be received in order, the same stream should be used for that data. If there is a logical grouping of data chunks or messages, streams can be reused, or a new stream can be opened for each chunk/message. If one message is mapped to a single stream, resetting the stream to expire an unacknowledged message can be used to emulate partial reliability on a message basis.  If a QUIC receiver has maximum allowed concurrent streams open and the sender on the other end indicates that more streams are needed, it doesn't automatically lead to an increase of the maximum number of streams by the receiver. Therefore it can be valuable to expose maximum number of allowed, currently open and currently used streams to the application to make the mapping of data to streams dependent on this information. </ins> Further, streams have a maximum number of bytes that can be sent on one stream.  This number is high enough (2^64) that this will usually

One sentences added to address remaining bits for
NAME I didn't replace "five-tuple" with "connection" in this sentence in this PR: "QUIC’s stream multiplexing feature allows applications to run multiple streams over a single connection, without head-of-line blocking between streams, associated at a point in time with a single five-tuple. " because it already has connection in the sentence; so we could only remove the last half sentence, but I actually think there is a value in leaving this in because some application may actually care about the 5-tuple.
WFM. We should probably do an editorial pass to make sure we're using terms like "5-tuple" and "connection" and "path" properly everywhere anyway.
See also section on Streams in transport draft: "Stream offsets allow for the octets on a stream to be placed in order. An endpoint MUST be capable of delivering data received on a stream in order. Implementations MAY choose to offer the ability to deliver data out of order. There is no means of ensuring ordering between octets on different streams."
See PR
lgtm modulo editorial. circleci doesn't like this but can fix after it lands.


Question: name and the same value, allowing for a trailing "*" wildcard operator as in Section 4.1 of RFC6690.  Attributes that are defined as "link-type" match if the search value matches any of their values <del> (see Section 4.1 of RFC6690; e.g. "?if=core.s" matches ";if="abc core.s";").  A resource link also matches a search criterion if its endpoint would match the criterion, and vice versa, an endpoint link matches a search criterion if any of its resource links matches it. </del> <ins> (see Section 4.1 of RFC6690; e.g. "?if=tag:example.net,2020:sensor" matches ";if="example.regname tag:example.net,2020:sensor";").  A resource link also matches a search criterion if its endpoint would match the criterion, and vice versa, an endpoint link matches a search criterion if any of its resource links matches it. </ins> Note that "href" is a valid search criterion and matches target references.  Like all search criteria, on a resource lookup it can

... and a few other cases of example errors and use of unregistered names.


Question: For each specified RTP header extension, establish a mapping between the extension ID and URI, as described in section 6 of <del> RFC5285.  If any indicated RTP header extension is unknown, this MUST result in an error. </del> <ins> RFC5285.  If any indicated RTP header extension is not supported, this MUST result in an error. </ins> If the MID header extension is supported, prepare to demux RTP data intended for this media section based on the MID header extension, as described in I-D.ietf-mmusic-msid, Section 3.2. <del> For each specified payload type, establish a mapping between the payload type ID and the actual media format, as described in RFC3264.  If any indicated payload type is unknown, this MUST result in an error. </del> <ins> For each specified media format, establish a mapping between the payload type and the actual media format, as described in RFC3264, Section 6.1.  If any indicated media format is not supported, this MUST result in an error. </ins> For each specified "rtx" media format, establish a mapping between the RTX payload type and its associated primary payload

Talk about what to do with header extensions in a remote description Expand discussion of how to handle payload types in a remote description Fail things we don’t know about in an answer ,
LGTM
NAME PTAL at my responses
URL If any indicated payload type is unknown, it MUST be ignored. [TODO: should fail on answers] (q: does this logic need to also include processing for other lines - extmap, rtcp-fb, etc - that weren't present in the offer?)
Fixed by
URL 2) * For each specified payload type that is also supported by the local implementation, establish a mapping between the payload type ID and the actual media format. [TODO - Justin to add more to explain mapping.]
Relevant to as well
Fixed by
URL 1) If the media section proto value indicates use of RTP: [TODO: header extensions]
LGTM


Question: 2.2. <del> For several types of events, it is sometimes impossible to tie them to a specific conceptual QUIC connection (e.g., a packet_dropped event triggered because the packet has an unknown connection_id in the header).  Since qlog events in a trace are typically associated with a single connection, it is unclear how to log these events. Ideally, implementers SHOULD create a separate, individual "endpoint- level" trace file (or group_id value), not associated with a specific connection (for example a "server.qlog" or group_id = "client"), and log all events that do not belong to a single connection to this grouping trace.  However, this is not always practical, depending on the implementation.  Because the semantics of most of these events are well-defined in the protocols and because they are difficult to mis-interpret as belonging to a connection, implementers MAY choose to log events not belonging to a particular connection in any other trace, even those strongly associated with a single connection. Note that this can make it difficult to match logs from different vantage points with each other.  For example, from the client side, it is easy to log connections with version negotiation or retry in the same trace, while on the server they would most likely be logged in separate traces.  Servers can take extra efforts (and keep additional state) to keep these events combined in a single trace however (for example by also matching connections on their four-tuple instead of just the connection ID). </del> <ins> A single qlog event trace is typically associated with a single QUIC connection.  However, for several types of events (for example, a transport-packetdropped event with trigger value of "connection_unknown"), it can be impossible to tie them to a specific QUIC connection, especially on the server. There are various ways to handle these events, each making certain tradeoffs between file size overhead, flexibility, ease of use, or ease of implementation.  Some options include: Log them in a separate endpoint-wide trace (or use a special group_id value) not associated with a single connection. Log them in the most recently used trace. Use additional heuristics for connection identification (for example use the four-tuple in addition to the Connection ID). Buffer events until they can be assigned to a connection (for example for version negotiation and retry events). </ins> 3.

NAME asked how to best approach logging from a server's perspective, given that things like version negotiation and stateless retry are not inherently tied to a single connection. We should add some informative guidance on how to best approach this to the spec, depending on how much state you're willing to keep around Some options: low state: keep a separate qlog file for the entire server. This logs vneg, retry, etc.. Then, when a connection is truly accepted, start a new .qlog for the individual connection, containing all events thereafter. The URL can then also contain an event signalling the acceptance of a new connection for later cross-linking between the files. low state: keep a single huge qlog file for everything, using the "groupid" field to allow later de-multiplexing into separate connections (I believe quant does this atm) stateful: if you already track vneg/retry and link them up with the final connection, you can output them in the per-connection qlog file as well Maybe also shortly talk about some of the trade-offs in each option. Also talk about how to approach server-level events like serverlistening and packet_dropped in separate scenarios.
I lean on the side of minimally and clearly identifying the challenges and maybe signpost some features and leave it up to implementers to figure out how to address this. They can always push back later in the specification lifecycle is something is deemed missing.


Question: compression-induced head-of-line blocking.  See that document for additional details. <ins> To allow for better compression efficiency, the cookie header field RFC6265 MAY be split into separate header fields, each with one or more cookie-pairs, before compression.  If a decompressed header list contains multiple cookie header fields, these MUST be concatenated before being passed into a non-HTTP/2, non-HTTP/3 context, as described in HTTP2, Section 8.1.2.5. </ins> An HTTP/3 implementation MAY impose a limit on the maximum size of the message header it will accept on an individual HTTP message.  A server that receives a larger header field list than it is willing to

This
The transport draft talks about QUIC being resilient to NAT rebindings. However, if a QUIC server is behind an L3 load balancer which simply routes based on 5-tuple, then connections to this server will (likely) not survive rebinding. I couldn't find any language which addressed whether such a deployment was "OK" or not. I think that since this load balance does not support NAT binding resilience, it is implicitly "bad" according to the draft, but others might disagree. In any case, I think there should be text to address this. Note, if the server advertised a preferredaddress which routed around the load balancer, and if clients were required to use this address, then that could obviously work. But preferredaddress support is a SHOULD, not a MUST.
We did discuss this issue. Use of empty connection IDs and demultiplexing based on source addresses. The conclusion there was that this was OK: people could do that, as long as it was clear that what they were getting was not different than TCP. That is, we made it clear that if you don't use the identifiers that you control (your addresses, the connection ID), then you accept that you can't handle migration at all and connections will drop (well, unless you do something like trial decryption, which has some obvious scaling issues). The outcome of that discussion was captured in . Assuming that Ryan finds this answer satisfactory (and I haven't missed anything), then I suggest we just close this as a duplicate of .
I don't think this captures Ryan's concern: when the server is using a non-zero CID and also is behind 4-tuple routing. I think he's looking for a section of text to coherently describe what you have to do here: send either disablemigration or preferredaddress; or forward packets between servers; or either don't use a common stateless_reset key, or put client address/port in the reset token. This is sort of ops-drafty but there real requirements on servers to behave in a secure way. I think someone with full command of the transport draft would figure this out, but it is not clearly stated anywhere.
I agree with Martin Duke and the language he suggests makes sense to me.
This does feel a bit ops-drafty to me, but I'd be happy to review a PR.


Question: compression-induced head-of-line blocking.  See that document for additional details. <ins> To allow for better compression efficiency, the cookie header field RFC6265 MAY be split into separate header fields, each with one or more cookie-pairs, before compression.  If a decompressed header list contains multiple cookie header fields, these MUST be concatenated before being passed into a non-HTTP/2, non-HTTP/3 context, as described in HTTP2, Section 8.1.2.5. </ins> An HTTP/3 implementation MAY impose a limit on the maximum size of the message header it will accept on an individual HTTP message.  A server that receives a larger header field list than it is willing to

NAME notes that: We need to normatively reference 7540 for this capability.
See also discussion thread starting at URL Hi, RFC7540 allows crumbling cookies for compression efficiency with HPACK. However, neither quic-http nor quic-qpack drafts mention cookies or crumbling. Is it considered safe for a QPACK implementation to crumble cookies before compression and concatenate them after decompression? If so, should the draft include clarification on this? Thanks, Bence


Question: Its Capsule Data field consists of: A variable-length integer indicating the context ID of the <del> datagram (see datagram-contexts). </del> <ins> datagram (see datagram-contexts).  Whether or not this field is present depends on which registration capsules were exchanged on the associated stream: if a REGISTER_DATAGRAM_CONTEXT capsule (see register-capsule) has been sent or received on this stream, then the field is present; if a REGISTER_DATAGRAM_NO_CONTEXT capsule (see register-no-context-capsule) has been sent or received, then this field is absent; if neither has been sent or received, then it is not yet possible to parse this datagram and the receiver MUST either drop that datagram silently or buffer it temporarily while awaiting the registration capsule. </ins> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty.


Question: Its Capsule Data field consists of: A variable-length integer indicating the context ID of the <del> datagram (see datagram-contexts). </del> <ins> datagram (see datagram-contexts).  Whether or not this field is present depends on which registration capsules were exchanged on the associated stream: if a REGISTER_DATAGRAM_CONTEXT capsule (see register-capsule) has been sent or received on this stream, then the field is present; if a REGISTER_DATAGRAM_NO_CONTEXT capsule (see register-no-context-capsule) has been sent or received, then this field is absent; if neither has been sent or received, then it is not yet possible to parse this datagram and the receiver MUST either drop that datagram silently or buffer it temporarily while awaiting the registration capsule. </ins> The payload of the datagram, whose semantics are defined by individual applications.  Note that this field can be empty.


Question: capitals, as shown here. This document uses the Augmented BNF defined in RFC5234 and updated <del> by RFC7405 along with the "#rule" extension defined in Section 7 of MESSAGING. </del> <ins> by RFC7405 along with the "#rule" extension defined in Section 5.6.1 of SEMANTICS. </ins> <del> The term Origin is to be interpreted as described in RFC6454 section 7. </del> <ins> The term Origin is to be interpreted as described in Section 7 of RFC6454. </ins> <del> The "delta-seconds" rule is defined in CACHING section 1.2.1. </del> <ins> The "delay-seconds" rule is defined in Section 10.2.4 of SEMANTICS. </ins> 2.

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


Question: Resolvers.  Other protocols can also use the format defined by I- D.schwartz-svcb-dns.  However, if any protocol does not involve some form of certificate validation, new validation mechanisms will need <del> to be defined to support validating equivalence as defined in </del> <ins> to be defined to support validating designation as defined in </ins> authenticated. 4.

changed equivalence instances for designated and added the possibility of multiple entities so long as they are cooperating This is to address issue
I am not sure we need to introduce "Equivalence" nor to develop who is operating the resolvers - especially as many entities may be involved in the operation of a resolver. I am not sure we need to introduce Equivalence. If so I would propose the following text: OLD: "Equivalence" in this context means that the resolvers are operated by the same entity; for example, the resolvers are accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. NEW: "Equivalence" in this context means that Encrypted and Unencrypted resolvers are either accessible on the same IP address, or there is a certificate that claims ownership over both resolvers. If Equivalence is not introduced - which I prefer -I would propose the following text: NEW: In this context the discovery process ensures that Encrypted and Unencrypted resolvers are either accessible on the same IP address, or there is a certificate that claims ownership over both resolvers.
I agree that we do not need to introduce "equivalence" in this document. It is a remnant of the DEER draft DDR is based on. Per WG discussion, we want to use the term "designation" to describe the relationship between the unencrypted resolver and the encrypted resolver to which the client is transferring. I'm editing accordingly. I have also added references to the possibility of multiple "entities" as that is definitely possible. (PR coming later tonight)
good.


Question: identification systems (such as is served by telephone numbers or email addresses in other communications systems). <del> Development of The Universal Solution has proved hard, however, for all the usual reasons. </del> <ins> Development of The Universal Solution has, however, proved hard. </ins> The last few years have also seen a new platform rise for deployment of services: The browser-embedded application, or "Web application".

Made changes to address Warren's first and third, but not 2nd nit. I'm unsure whether the changes in the spacing I introduced will fix the odd spacing in Olle's name.
Warren noted the following nits in his ballot: 1: "Development of The Universal Solution has proved hard, however, for all the usual reasons." -- this is cute, but leaves people wondering what "all the usual reasons are". Perhaps just "Development of The Universal Solution has, however, proved hard." (or just cut after the "however in the original"). 2: I'm not sure why you have "Protocol" in the terminology section. It doesn't seem like it is useful for the document, and this document doesn't seem like the right place to (re) define it. 3: Acknowledgements: Funny spacing in "Olle E. Johansson


Question: might need to allow for the time it takes requests to arrive from the , with a time window that is large enough to allow for differences in clocks.  Insufficient tolerance of time differences could result in <del> valid requests being unnecessarily rejected. </del> <ins> valid requests being unnecessarily rejected.  Beyond allowing for multiple round trip times - to account for retransmission - network delays are unlikely to be significant in determining the size of the window, unless all potential are known to have excellent time- keeping.  A specific window size might need to be determined experimentally. </ins> MUST NOT treat the time window as secret information.  An attacker can actively probe with different values for the "Date" field to

Comment by NAME In How does a client know this? Preconfiguration ? Are we talking ms? sec? minutes? Any advise to implementers ?
It can't be less than 2s, because the granularity of the field doesn't permit detecting anything finer than 1s. I've done what I can.
This still does not seem to address: Maybe just cut off the “unless” part if there is no signal for this? Paul
NAME also included URL which I think should address your concern:
Thanks. That commit does address the issue, mostly. I guess it moves it do an unspecified provisioning layer :P Paul


Question: the initiator to demonstrate reachability at its apparent network address. <ins> An attacker can also send faked message_2, message_3, message_4, or error in an attempt to trick the receiving party to send an error message and discontinue the session.  EDHOC implementations MAY evaluate if a received message is likely to have be forged by and attacker and ignore it without sending an error message or discontinuing the session. </ins> 8.6. The availability of a secure random number generator is essential for

Looks good.
The current draft has the following text in several places: "If any verification step fails, the Responder MUST send an EDHOC error message back, formatted as defined in {{error}}, and the protocol MUST be discontinued." I am not sure this is a good idea. This means that the availability of EDHOC will be low. An attacker can e.g. send a single byte as message_4 and it would make EDHOC shut down imidiatly. I think we need to soften this and give the implementation some more choice here. Are there constrained radio protocols where noice could be mistaken for an actual message and forwarded to EDHOC or do all constrained radio have strong enough CRC to make sure that that more or less never happens?
I just changed the following text OLD: If the Initiator previously received from the Responder an error message with error code 1 (see Section 6.3) indicating cipher suites supported by the Responder which also are supported by the Initiator, then the Initiator SHALL select the most preferred cipher suite of those. NEW: If the Initiator previously received from the Responder an error message with error code 1 (see Section 6.3) indicating cipher suites supported by the Responder which also are supported by the Initiator, then the Initiator SHOULD select the most preferred cipher suite of those (note that error messages are not authenticated and may be forged). Made me think about that I don't think the group has discussed if some error messages should be authenticated. Some error messages to message2 could include a MAC to prove that the error was sent by the same party that sent message3. error messages to message3 and message4 could be authenticated. I am uncertain if this is worth specifying. At least not as long as there are easier ways to an attacker to end the protocol. I think what needs to be done is to specify that a processing error does not need to discontinue the protocol, the received message can have been an attack. receiveing an error does not need to discontinue the protocol, the received error can have been an attack.


Question: the initiator to demonstrate reachability at its apparent network address. <ins> An attacker can also send faked message_2, message_3, message_4, or error in an attempt to trick the receiving party to send an error message and discontinue the session.  EDHOC implementations MAY evaluate if a received message is likely to have be forged by and attacker and ignore it without sending an error message or discontinuing the session. </ins> 8.6. The availability of a secure random number generator is essential for

from 20210422 interim: CB perhaps wisely said: "Use cases exist for multiplexing over same port/URI, so applications should normally sort/demultiplex traffic before start interpreting as EDHOC, which implies treating invalid messages that get to EDHOC code as an error or attack"
Yes, my understanding is that we only need to be concerned about attacks where an attacker sends a packet crafted so that it will be processed by EDHOC (which is not hard).
I made a pull request addressing this issue Added text on demultiplexing. Changed procession so implementation are not mandated to shut down the session if an attacker sends a few bytes to the EDHOC resource / port.. Added more security consideration on Denial of service.
Writing this PR made me think about whether we want to mandate that error messages are always fatal as well as downgrade protection. The ""Wrong selected cipher suite" error is fatal because it is sent in repsponse to message1. You could consider similar types of error sent in response to message2 and message3. E.g. IDCRED format not supported or CRED format not supported or X.509 public key algorithm not supported. [BBFGKZ16] defines the following theoretical downgrade protection for a session: The cryptographic parameters should be the same on both sides and should be the same as if the peers had been communicating in the absence of an attack. But this definition has very little to do with practical security. In practice it does not matter if an attacker can influence the chosen parameter in the current session or a following session. I am still confused regarding the purpose of the applicability statement. Is it a informal section describing things the parties need to both support to make the protocol work or is a normative security section relevant for policy and downgrade. If we want downgrade protection over multiple sessions, the parties need to agree or securely negotiate everything. Downgrade protection for a session does not make much sense to me if an attacker can force the parties to set up a second session with lower security.
Do we need to align the terminology, we use both "session" and "instance" in the draft?
Yes, I just changed "protocol" to "session" not remembering that the draft use instance in other places.
We can resolve this later, I opened . Unless there are other comments we will soon merge this.
The PR has been discussed and merged.


Question: the initiator to demonstrate reachability at its apparent network address. <ins> An attacker can also send faked message_2, message_3, message_4, or error in an attempt to trick the receiving party to send an error message and discontinue the session.  EDHOC implementations MAY evaluate if a received message is likely to have be forged by and attacker and ignore it without sending an error message or discontinuing the session. </ins> 8.6. The availability of a secure random number generator is essential for

Closing
Current specification mandates sending error messages upon certain failures. But in cases when message processing fails when no state has been allocated or when no connection identifier has been found or then a more appropriate action would be to just silently drop the message.
I think the MUST (if possible) is good. Debugging without any error messages is not nice. We now other protocols that it is good to mandate error messages. It is kind of obvious that can not send an error if you don't now where/how to send it. Don't know if that has to be pointed out....
Migth be good to not sent error if you are under a DoS attack.
This issue is addressed by pull request that also address availability
The PR has been discussed and merged. Closing


Question: Parameters on a templated-link have identical semantics to those of a Link header field.  This includes (but is not limited to) the use of the "rel" parameter to convey the relation type, the "anchor" <del> parameter to modify the context IRI, and so on. </del> <ins> parameter to modify the context IRI, and so on.  Parameter values MUST be Strings. </ins> Likewise, the requirements for parameters on templated-links are the <del> same as those for a Link header field; in particular, the "rel" parameter MUST NOT appear more than once, and if it does, the templated-link MUST be ignored by parsers. </del> <ins> same as those for a Link header field. </ins> This specification defines additional semantics for the "var-base" parameter on templated-links; see below.

Emerging best practice is to use for new headers, so that parsing is well-defined. Arguments for sticking with a -like syntax: Consistence with (IMO a very poor justification) Reuse of parsers / other software (it's not well-defined, tho) ???
We could also talk about creating a SF version of (maybe ?).
Matching SF and headers would be appealing.
In the meantime (or maybe before ;) -- URL


Question: information, expiry time, method of providing credentials, security token for validating ICMP messages. <del> This document does not specify the details of the API. </del> <ins> The API MUST use TLS for privacy and server authentication.  The implementation of the API MUST ensure both privacy and integrity of any information provided by or required by it. </ins> <del> The CAPPORT API MUST support TLS for privacy and server authentication. </del> <ins> This document does not specify the details of the API. </ins> 2.4.

We want to make TLS a requirement, not a suggestion, so I've chagned the wording around TLS to reflect this. I also added a section to the security section discussing the motivation behind the requirement.
Can you forward to the list please?


Question: The API MUST ensure the integrity of this information, as well as its confidentiality. <ins> An attacker with access to this information might be able to masquerade as a specific User Equipment when interacting with the API, which could then allow them to masquerade as that User Equipment when interacting with the User Portal.  This could give them the ability to determine whether the User Equipment has accessed the portal, or deny the User Equipment service by ending their session using mechanisms provided by the User Portal, or consume that User Equipment's quota.  An attacker with the ability to modify the information could deny service to the User Equipment, or cause them to appear as a different User Equipment. </ins> 7.4. If a Signaling Protocol is implemented, it may be possible for any

One of the reviewers asked for more information about the attacker in section 7.3. This does so, describing what the attacker could achieve by compromising the security.
Benjamin writes, Without knowing the details of the particular solution, it's a bit hard to say for sure, but roughly I'd say it's someone who wants to interact with the API using the identity of the user. E.g. if we're using an 'unguessable' URI, an attacker snooping on the communication with the API could determine the URI, and use it.


Question: bytes.  An endpoint that includes this parameter supports the DATAGRAM frame types and is willing to receive such frames on this connection.  Endpoints MUST NOT send DATAGRAM frames until they have <del> sent and received the max_datagram_frame_size transport parameter. Endpoints MUST NOT send DATAGRAM frames of size strictly larger than the value of max_datagram_frame_size the endpoint has received from its peer.  An endpoint that receives a DATAGRAM frame when it has not sent the max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  An endpoint that receives a DATAGRAM frame that is strictly larger than the value it sent in its max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  Endpoints that wish to use DATAGRAM frames need to ensure they send a max_datagram_frame_size value sufficient to allow their peer to use them.  It is RECOMMENDED to send the value 65536 in the max_datagram_frame_size transport parameter as that indicates to the peer that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet. </del> <ins> received the max_datagram_frame_size transport parameter.  Endpoints MUST NOT send DATAGRAM frames of size strictly larger than the value of max_datagram_frame_size the endpoint has received from its peer. An endpoint that receives a DATAGRAM frame when it has not sent the max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  An endpoint that receives a DATAGRAM frame that is strictly larger than the value it sent in its max_datagram_frame_size transport parameter MUST terminate the connection with error PROTOCOL_VIOLATION.  Endpoints that wish to use DATAGRAM frames need to ensure they send a max_datagram_frame_size value sufficient to allow their peer to use them.  It is RECOMMENDED to send the value 65536 in the max_datagram_frame_size transport parameter as that indicates to the peer that this endpoint will accept any DATAGRAM frame that fits inside a QUIC packet. The max_datagram_frame_size transport parameter is a unidirectional limit and indication of support of DATAGRAM frames.  Application protocols that use DATAGRAM frames MAY choose to only negotiate and use them in a single direction. </ins> When clients use 0-RTT, they MAY store the value of the server's max_datagram_frame_size transport parameter.  Doing so allows the

Defines the transport parameter as a unidirectional configuration.
The spec clearly states the following: But it's not completely clear what happens if both sides send different values. Is the value purely a unidirectional configuration? For instance, if the server advertises a value of 500, and the client advertises a value of 100, can the client still send 500 byte datagrams? Or does this essentially negotiate the max value either side can use to 100? If this is a unidirectional configuration, why require the peer to send the TP at all, if all they want to do is send datagrams, and not receive them? I'm loosely basing my thoughts on what the design could be on how we negotiate the number of streams an endpoint is willing to accept. Following that model, I'd recommend a design where, if an endpoint is willing to receive datagrams, it advertises a it's willing to accept. The TP has absolutely no meaning for the send direction. The protocol on top of QUIC decides how to interpret only a single direction allowing datagrams to be sent.
I agree with NAME principly due to this clause in the present draft: My read of the current text is that it is unidirectional. An endpoint tells it's peer that it is willing to receive a DATAGRAM up to size N by using . Having asymmetric values is fine because the paths can be asymmetric and other TPs also behave asymmetrically. The draft also says: For an application protocol like siduck, both ends need to support reception of DATAGRAM or else the application will fail. For something like an IoT sensor feed, it might be fine to support a send-only/receive-only model. The current text basically requires the application protocol to mandate that is 0 on the side that is send-only AND to describe what happens if the TP is missing - that seems like it will cause a duplication of effort.
I agree that we should make this purely unidirectional. I would resolve this by replacing with


Question: 6. <del> RFC5246, The Transport Layer Security (TLS) Protocol Version 1.2, suggests that implementations can assume support for MD5 and SHA-1 by their peer.  This update changes the suggestion to assume support for SHA-256 instead, due to MD5 and SHA-1 being deprecated. In Section 7.4.1.4.1: the text should be revised from: OLD: "Note: this is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports MD5 and SHA- 1." NEW: "Note: This is a change from TLS 1.1 where there are no explicit rules, but as a practical matter one can assume that the peer supports SHA-256." 7. </del> The document updates the "TLS SignatureScheme" registry to change the recommended status of SHA-1 based signature schemes to N (not recommended) as defined by RFC8447.  The following entries are to be

cc NAME NAME NAME
I believe this I-D should still include the "update: 5246 (if approved)" header, even though we took out the 5246 OLD/NEW section. We are still proposing that 5246 be changed to require signature_algorithms extension be sent and that MD5/SHA1 never be sent. In other words, I think you can merge this PR assuming there are no conflicts.
Verifying that this is okay on list, but Daniel suggested the following change for s6: Add the following immediately bfore the OLD/NEW, i.e., right after "due to MD5 and SHA-1 being deprecated.": In Section 7.1.4.1: the following text is removed: If the client supports only the default hash and signature algorithms (listed in this section), it MAY omit the signature_algorithms extension.
Resulted in a number of changes - see .
I think you also need to update the abstract and introduction sections, as they both mention "This document updates ..." (same as URL). Will probably conflict with URL so we should merge that first.I believe this can be merged as is. I.e., don't remove the "udpates" header, change the abstract, or intro.


Question: will still be HKDF-Extract(0, 0).  For the computation of the binder_key, the label is "ext binder" for external PSKs (those provisioned outside of TLS) and "res binder" for resumption PSKs <del> (those provisioned as the resumption main secret of a previous handshake).  The different labels prevent the substitution of one type of PSK for the other. </del> <ins> (those provisioned as the resumption secret of a previous handshake). The different labels prevent the substitution of one type of PSK for the other. </ins> There are multiple potential Early Secret values, depending on which PSK the server ultimately selects.  The client will need to compute

While we're renaming these anyway, exportersecret and resumptionsecret are just as descriptive.
exportermainsecret and resumptionmainsecret strike me as not needing an adjective in the middle at all. Perhaps exportersecret and resumptionsecret? For the exporter secret, dropping "main" avoids the acronym collision with the EMS extension, and there are no other secrets associated with exporters, so there's no use in designating this as the main one. For the resumption secret, there is a potential confusion between resumption[main]secret and the derived PSK associated with the ticket (section {#NSTMessage}), but we don't seem to give the latter a name in the first place so I think that's fine. This also gives us nice short KDF labels when we're able to change those: "exporter" and "resumption". (Or perhaps even "export" and "resume" if those don't fit in a hash block.)


Question: the connection, the session is terminated. Trade-offs: RST Packet Injection has a few advantages that make it <del> extremely popular is a censorship technique.  RST Packet Injection is </del> <ins> extremely popular as a censorship technique.  RST Packet Injection is </ins> an out-of-band prevention mechanism, allowing the avoidance of the the QoS bottleneck one can encounter with inline techniques such as Packet Dropping.  This out-of-band property allows a censor to

I think there is a trivial typo in the first sentence of "Trade-offs".
thanks!