jiebi/CodeConvo huggingface dataset:
Code change:
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

Related discussion:
text: 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.
Code change:
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

Related discussion:
text: 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
Code change:
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.

Related discussion:
text: 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.
Code change:
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.

Related discussion:
text: 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...
Code change:
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.

Related discussion:
text: 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.
Code change:
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".

Related discussion:
text: 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
Code change:
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

Related discussion:
text: 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
Code change:
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

Related discussion:
text: 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.
Code change:
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

Related discussion:
text: 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.
Code change:
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

Related discussion:
text: 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
Code change:
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.

Related discussion:
text: 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
Code change:
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.

Related discussion:
text: 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?
Code change:
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

Related discussion:
text: 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.