jiebi/CodeConvo huggingface dataset:
Code change:
With static Diffie-Hellman key authentication, the authenticating endpoint can deny having participated in the protocol. <del> Two earlier versions of EDHOC have been formally analyzed Norrman20 Bruni18 and the specification has been updated based on the analysis. </del> <ins> Three earlier versions of EDHOC have been formally analyzed Jacomme23 Norrman20 Bruni18 and the specification has been updated based on the analysis. </ins> 8.2.

Related discussion:
text: Hi all, Our previous formal analysis on draft 12 and 14 lead to a publication at USENIX 23 available here URL As the two other previous formal analysis were cited in the draft, I'm proposing to add next to them our new one with this PR. As a side remark, our models are here (URL), and we are trying to update everything according to draft 17 with a new overall pass. It might be tight for IETF115, but we are trying our best! And anyway, it should only be positive results by now ;)
NAME Thanks! Great that you follow up with the latest version. The latest relevant changes are probably in -16 and only adds things to the key derivation (some of which was proposed by you :-).
Thanks for the pointer! Though, the biggest issue is not so much updating the model of the protocol, but rather making a new full pass on the security claims and new appendices, trying to have a clear systematized link between claims from the draft and what we check in the model.
NAME let's check if there are some other papers missing and what we want to say about them.
We should at least add references to work by ETH and ENS. Let's merge this as a starting point and continue discussion in .
Given the various security analyses EDHOC has seen and their insights being discussed in Section 8, would it make sense to add informative references to those (as done, e.g., for TLS 1.3, RFC 8446 Appendix E)? URL
Seems like a good idea to me
Related to
This was discussed on the IETF 116 LAKE WG meeting, and in absence of volunteers to draft such an appendix we decided to start with adding references. We may want to go somewhere in between a whole appendix and a sentence, and expand with a paragraph about each reference. We still need someone to draft that paragraph for the different references and would like to conclude on this fairly soon. We start by merging now.
Closing since is merged. Hi all, While we do not have any explicit comments on the document, we thought it is maybe still worthwhile to share the following analysis confirmation. We updated our computational analysis of the SIG-SIG mode, of which Marc presented an earlier version at IETF 114, to draft 17.
Code change:
With static Diffie-Hellman key authentication, the authenticating endpoint can deny having participated in the protocol. <del> Two earlier versions of EDHOC have been formally analyzed Norrman20 Bruni18 and the specification has been updated based on the analysis. </del> <ins> Three earlier versions of EDHOC have been formally analyzed Jacomme23 Norrman20 Bruni18 and the specification has been updated based on the analysis. </ins> 8.2.

Related discussion:
text: We could confirm that with some of the later cryptographic suggestions (PR , ) included, EDHOC SIG-SIG achieves key exchange security (key secrecy and explicit authentication) in a strong model capturing potentially colliding credential identifiers, assuming, among others, an "exclusive ownership" property of the signature scheme (established for Ed25519, conjectured for the way ECDSA is used in EDHOC SIG-SIG). Our updated analysis is not publicly available yet at this point. Let us know if a public reference would be helpful for the draft RFC; we can also share the document individually upon request. The last point actually maybe does lead to a comment on the document: Given the various security analyses EDHOC has seen and their insights being discussed in Section 8, would it make sense to add informative references to those (as done, e.g., for TLS 1.3, RFC 8446 Appendix E)? Kind regards, Felix Günther (with Marc Ilunga)
Code change:
7.2.5. The frame (type=0x05) is used to carry a promised request header <del> section from server to client on a , as in HTTP/2. </del> <ins> section from server to client on a . </ins> The payload consists of:

Related discussion:
text: Removed one HTTP/2 reference which seems extraneous, and corrected the polarity of another. This by doing almost nothing; speak now if you think more is warranted.
RFC Editor says: But fair enough -- are we overdoing it?
Having looked at the references, they all seem reasonable with the possible exception of PUSH_PROMISE noting it behaves "as in HTTP/2." Most references to HTTP/2 occur either in the first two sections of the document or in the Appendix which specifically discusses the relationship between HTTP/2 and HTTP/3. removes that one extraneous reference. Other than than, I plan to make no further changes to address this feedback unless someone wants to provide a more concrete list of places where the comparison is unnecessary.
Marginal: Section 4.1.1 and 4.1.1.1 seems to have some egregious use of phrasing similar to "Like HTTP/2, ..." or "as in HTTP/2". You could possibly condense these to a sentence such as "Like HTTP/2, HTTP/3 has additional considerations related to use of characters in field names, the Connect header field, and pseudo-header fields". That could be inserted into to thefirst para of 4.1.1, or the second para (thus breaking the para so the next one starts with "Characters in field names").
Fixed in .
Code change:
6.5.1. <del> The Replay-Nonce header field includes a server-generated value that the server can use to detect unauthorized replay in future client requests.  The server MUST generate the value provided in Replay- Nonce in such a way that they are unique to each message, with high probability, and unpredictable to anyone besides the server.  For instance, it is acceptable to generate Replay-Nonces randomly. </del> <ins> The Replay-Nonce HTTP header field includes a server-generated value that the server can use to detect unauthorized replay in future client requests.  The server MUST generate the values provided in Replay-Nonce header fields in such a way that they are unique to each message, with high probability, and unpredictable to anyone besides the server.  For instance, it is acceptable to generate Replay-Nonces randomly. </ins> <del> The value of the Replay-Nonce field MUST be an octet string encoded according to the base64url encoding described in Section 2 of </del> <ins> The value of the Replay-Nonce header field MUST be an octet string encoded according to the base64url encoding described in Section 2 of </ins> RFC7515.  Clients MUST ignore invalid Replay-Nonce values.  The ABNF RFC5234 for the Replay-Nonce header field follows:

Related discussion:
text: Some grammar fixes POST-as-GETs should be indicated as having a signature in flow Specify that the JWS profile we define in Section 6.2 is for ACME request bodies, to distinuish it from the profile used for External Account Binding. They have incompatible requirements: MUST NOT use MAC vs MUST use MAC. Clarify that Replay-Nonce is an HTTP header field since it's defined near JWS header parameters. Don't include "wildcard": false in examples. Section 7.1.4 requires that it MUST be absent when false. There was lingering language in the Section 7.5.1 about "updating" an authorization body in response to fields in a challenge POST. Since the challenge POST is now described explicitly as "an empty JSON body", this language didn't make sense. Fixed.
Per offline review, I added back in a sentence that contained a MUST:
Code change:
The tree hash of a tree is the tree hash of its root node, which we define recursively, starting with the leaves. <del> As some nodes may be blank while others contain data we use the following struct to include data if present. </del> The tree hash of a leaf node is the hash of leaf's "LeafNodeHashInput" object which might include a "LeafNode" object depending on whether or not it is blank.

Related discussion:
text: There are two changes in this PR: Pull the extension to the TLS syntax up into the Terminology section Add an extension that lets vectors have variable-length headers, allowing them to be efficient at small sizes while also accommodating large sizes All vectors are converted to the variable-length header representation. It seems like this should simplify implementation, since the encoder will no longer have to be told how many bytes of header to use for a given vector. This has been the source of several annoying interop bugs.
Looks great! I only have a small objection: there is now several valid ways to serialize a length, as the example shows, both and are valid ways to encode 37. This means that if you parse a structure, and later want to re-serialize it to check a signature for example, you need to remember how many bits were used to store the length. In short, we loose the property that . The fix is easy: can we add that "the length MUST be stored using the smallest amount of bits possible"?
Good point, updated!
I wasn't clear under which circumstances you would use a longer length with a number that would fit in a smaller range. If never, then the table should be:
DIscussion on virtual interim Some concern about being able to send gigantic stuff In adversarial cases, the 4-byte headers used for a lot of stuff might already be a problem Could also have length constraints decoupled from the syntax SIP experience shows that imposing arbitrary length limits isn't a good idea ... but applications should have a way to signal that things are too big TODO(NAME Advisory text "Beware, things can get big; consider imposing limits and clear failure cases for this" Consider streaming implementations, where you might not know that the whole message fits in memory Modulo the above TODO, clear to merge
Code change:
5. <del> Implementations of HTTP/3 that support HTTP Datagrams can indicate that to their peer by sending the H3_DATAGRAM SETTINGS parameter with a value of 1.  The value of the H3_DATAGRAM SETTINGS parameter MUST be either 0 or 1.  A value of 0 indicates that HTTP Datagrams are not supported.  An endpoint that receives the H3_DATAGRAM SETTINGS parameter with a value that is neither 0 or 1 MUST terminate the connection with error H3_SETTINGS_ERROR. Endpoints MUST NOT send QUIC DATAGRAM frames until they have both sent and received the H3_DATAGRAM SETTINGS parameter with a value of 1. When clients use 0-RTT, they MAY store the value of the server's H3_DATAGRAM SETTINGS parameter.  Doing so allows the client to send QUIC DATAGRAM frames in 0-RTT packets.  When servers decide to accept 0-RTT data, they MUST send a H3_DATAGRAM SETTINGS parameter greater than or equal to the value they sent to the client in the connection where they sent them the NewSessionTicket message.  If a client stores the value of the H3_DATAGRAM SETTINGS parameter with their 0-RTT state, they MUST validate that the new value of the H3_DATAGRAM SETTINGS parameter sent by the server in the handshake is greater than or equal to the stored value; if not, the client MUST terminate the connection with error H3_SETTINGS_ERROR.  In all cases, the maximum permitted value of the H3_DATAGRAM SETTINGS parameter is 1. It is RECOMMENDED that implementations that support receiving HTTP Datagrams using QUIC always send the H3_DATAGRAM SETTINGS parameter with a value of 1, even if the application does not intend to use HTTP Datagrams.  This helps to avoid "sticking out"; see security. 5.1. [[RFC editor: please remove this section before publication.]] Some revisions of this draft specification use a different value (the Identifier field of a Setting in the HTTP/3 SETTINGS frame) for the H3_DATAGRAM Settings Parameter.  This allows new draft revisions to make incompatible changes.  Multiple draft versions MAY be supported by either endpoint in a connection.  Such endpoints MUST send multiple values for H3_DATAGRAM.  Once an endpoint has sent and received SETTINGS, it MUST compute the intersection of the values it has sent and received, and then it MUST select and use the most recent draft version from the intersection set.  This ensures that both endpoints negotiate the same draft version. 6. </del> Data streams (see capsule-protocol) can be prioritized using any means suited to stream or request prioritization.  For example, see Section 11 of PRIORITY.

Related discussion:
text: When reviewing the latest editors copy, the document structure leaps out at a bit odd by jumping from section 3 to section 5. That indicates to me these concepts are linked and also independent of the capsule protocol. So here I propose a minor restructure by moving the H3_DATAGRAM setting stuff to be a subsection of the HTTP/3 datagram format. This makes all the top-layer sections loosely coupled, which is nicer in my opinion.
Code change:
permitted; receipt of a second stream which claims to be a control stream MUST be treated as a connection error of type HTTP_WRONG_STREAM_COUNT.  The sender MUST NOT close the control <del> stream.  If the control stream is closed at any point, this MUST be treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM. </del> <ins> stream, and the receiver MUST NOT request that the sender close the control stream.  If either control stream is closed at any point, this MUST be treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM. </ins> A pair of unidirectional streams is used rather than a single bidirectional stream.  This allows either peer to send data as soon

Related discussion:
text: Technically design, but barely.
Originally posted by NAME in URL There are three reasonable places to blow up: When you decide to stop reading a critical stream (i.e. when STOPSENDING is sent) When you discover the peer has stopped reading a critical stream (i.e. when STOPSENDING is received) When you discover the peer has closed a critical stream (when RESETSTREAM or FIN is received) My inclination would be to advise against FIN/SS/R_S on a critical stream and mandate connection termination on receipt of any of them.
Completely agree. This seems like the simplest and most obvious solution.
SGTM mike
Note that this PR does NOT address , just a comment that came up there.
Re-reading this, I think the existing text is pretty good; it just needs a little reframing. The existing requirement is to error out "If the control stream is closed at any point," without reference to whether it was closed because the peer send a FIN/RESET on their control stream or you obeyed a STOP_SENDING on yours. I think I'll add a requirement not to request closure of a control stream; do you think we need more elucidation here?
nits, but LGTM
Code change:
to an inbound SYN with a SYN-ACK. Calling "Clone" on a TCP Connection creates a new Connection with <del> equivalent parameters.  The two Connections are otherwise independent. </del> <ins> equivalent parameters.  These Connections, and Connections generated via later calls to "Clone" on one of them, form a Connection Group.  To realize "entanglement" for these Connections, with the exception of "Connection Priority", changing a Connection Property on one of them must affect the Connection Properties of the others too.  No guarantees of honoring the Connection Property "Connection Priority" are given, and thus it is safe for an implementation of a transport system to ignore this property.  When it is reasonable to assume that Connections traverse the same path (e.g., when they share the same encapsulation), support for it can also experimentally be implemented using a congestion control coupling mechanism (see for example TCP-COUPLING or RFC3124). </ins> SEND.TCP.  TCP does not on its own preserve Message boundaries. Calling "Send" on a TCP connection lays out the bytes on the TCP

Related discussion:
text: This provides more detail on how to implement Clone with TCP, and clarifies that SCTP's "Initiate" should not yield a stream of an already existing SCTP Association in case "activeReadBeforeSend" is Preferred or Required.
Currently the "Clone" part of, e.g., TCP (section 10.1) only says: "Calling Clone on a TCP Connection creates a new Connection with equivalent parameters. The two Connections are otherwise independent." This text should reflect that equivalent behavior must be maintained upon later Connection configuration calls. And, there should be more text in general on cloning (see issue ).
This text must refer to a new "do I want a Connection that supports initiate followed by listen?" property. This property will be added to address - so I'll address this issue when the PR addressing has landed.
Added a question for NAME
Code change:
Stapling RFC6961 to provide the client with certificate revocation information that does not require contacting a third party. <ins> A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI. Just as the address of a traditional DNS nameserver cannot be originally determined from that same server, a DOH client cannot use its DOH server to initially resolve the server's host name into an address.  Alternative strategies a client might employ include making the initial resolution part of the configuration, IP based URIs and corresponding IP based certificates for HTTPS, or resolving the DNS API Server's hostname via traditional DNS or another DOH server while still authenticating the resulting connection via HTTPS. </ins> 11. Joe Hildebrand contributed lots of material for a different iteration

Related discussion:
text: this is a little longer than I had hoped given that bootstrap deadlock is not a new problem for dns introduced by doh.. but the https validaton angle is worth mentioning.
If DOH uses https under the hood, how does this https host name get resolved? I would have expected this to be mentioned in the RFC, though I didn't see any mention of it, besides OCSP Stapling. Is it assumed that DOH would need to be bootstrapped by traditional DNS? Or is it assumed that a DOH endpoint would have a TLS/SSL certificate for its ip address? (Apparently a certificate for an IP address is possible in some cases, though hard to get.) I assume DOH is not intended to be used by home NAT routers? (How would the router get a signed TLS certificate? Maybe a DHCP response could say: use this DOH url and trust this self-signed cert for its ip address (though a certificate might be too big for a DHCP response). Or, in cases where no local DNS services are needed, the DHCP response could maybe say: use this public DOH url, here's the ip address for that hostname)
The document doesn't describe how a HTTPS client authenticates HTTPS... that's on purpose in order to simply leverage HTTPS without surprises. as a practical matter a number of things can be done. One is TOFU as you suggest. Another is an IP based certificate which you also suggest. Another would be to lookup the name via another, perhaps less trusted resolver, knowing that HTTPS means the IP address isn't part of the security scheme anyhow - its just a route.. subject to blocking, but not to impersonation. Another would be to bootstrap the client with a name and an address instead of one or the other. but as a general matter I think this is one step beyond the scope of the document as its basically writing down the rules for HTTPS.
This issue semi-duplicates
I think this should at least be called out as an operational concern. e.g. mentioning that you probably need an alternate resolver to find the DOH server, after which a paranoid implementation can re-query for the DOH's address as an integrity check.
This is the direction I have taken for .
Code change:
Stapling RFC6961 to provide the client with certificate revocation information that does not require contacting a third party. <ins> A DNS API client may face a similar bootstrapping problem when the HTTP request needs to resolve the hostname portion of the DNS URI. Just as the address of a traditional DNS nameserver cannot be originally determined from that same server, a DOH client cannot use its DOH server to initially resolve the server's host name into an address.  Alternative strategies a client might employ include making the initial resolution part of the configuration, IP based URIs and corresponding IP based certificates for HTTPS, or resolving the DNS API Server's hostname via traditional DNS or another DOH server while still authenticating the resulting connection via HTTPS. </ins> 11. Joe Hildebrand contributed lots of material for a different iteration

Related discussion:
text: When opening a connection to the remote DOH server, if an ip was provided, it will just use that, if not, it will try to resolve using the local stub, but that may not work.... Just like an IP has always been provided to bootstrap which nameserver to use, here we need to also be provided a name so we can validate that the server we are talking to is the one we trust.
Code change:
constraints on the selection and configuration of paths and protocols to establish a Connection with a remote endpoint.  A Connection represents a transport Protocol Stack on which data can be sent to <del> and received from a remote endpoint.  Connections can be created from Preconnections in three ways: by initiating the Preconnection (i.e., actively opening, as in a client), through listening on the Preconnection (i.e., passively opening, as in a server), or rendezvousing on the Preconnection (i.e. peer to peer establishment). </del> <ins> and/or received from a remote endpoint (i.e., depending on the kind of transport, connections can be bi-directional or unidirectional). Connections can be created from Preconnections in three ways: by initiating the Preconnection (i.e., actively opening, as in a client), through listening on the Preconnection (i.e., passively opening, as in a server), or rendezvousing on the Preconnection (i.e. peer to peer establishment). </ins> Once a Connection is established, data can be sent on it in the form of Messages.  The interface supports the preservation of message

Related discussion:
text: We don't know yet whether it is sufficient to have canread/canwrite property on the connection level to model unidirectional connections We don't have pre-connection methods to create multicast sessions yet
there's a selection property for this, tagged discuss, which we haven't discussed yet. I'm moving this down to the appendix as part of my restructuring in my work on
If help is still wanted here, I'm maybe up for an attempt or 2 at adding multicast support. Has there been some prior discussion I can review about rough ideas on pre-connection methods for multicast sessions, or should I just try making something up?

ok, with the caveat that we need to keep multicast as an open issueLGTM About the multicast concern: I agree that it would be good if this could function for multicast reception too, and I couldn't tell if this is suitable for multicast. I suspect that multicast support is much harder anyway - see RFC 3678... so for now, this is a good step forward IMO, and let's discuss how this relates to multicast when we see a concrete text proposal that addresses it.