jiebi/CodeConvo huggingface dataset:
Code change:
This PR should (hopefully) conclude the main rewrite of Observe which was triggered by the security analysis and additional reviews of Observe. It should (hopefully) now be clear what part of the Observe related processing can be omitted in case Observe is not supported or in case intermediaries are not used. A new appendix E is covering the latter case.

Related discussion:
text: For example, an If-Match Outer option is discarded, Uri-Host Outer option is not discarded, Observe is not discarded. <ins> Replace step 3 in ver-req with: B.  If Observe is present in the received message, and has value 0, check if the Token, Kid and Partial IV are identical to a previously received Observe registration.  In this case, replay verification is postponed until step C.  Otherwise verify the 'Partial IV' parameter using the Replay Window, as described in replay-protection. </ins> Insert the following steps between step 6 and 7 of ver-req: <del> B.  If Observe was present in the received message (in step 1): </del> <ins> C.  If Observe was present in the received message (in step 1): </ins> If the value of Observe in the Outer message is 0: If Observe is present and has value 0 in the decrypted options, <del> discard the Outer Observe; </del> <ins> discard the Outer Observe.  If the Token, Kid and Partial IV are identical to a previously received Observe registration, respond with a notification as described in observe-replay- processing; </ins> Otherwise, discard both the Outer and Inner (if present) <del> Observe options. </del> <ins> Observe options and verify the 'Partial IV' parameter using the Replay Window, as described in replay-protection. </ins> <del> If the value of Observe in the Outer message is not 0, discard </del> <ins> If the value of Observe in the Outer message is not 0, discard the </ins> decrypted Observe option if present. <del> Insert the following steps between step 6 and 7 of ver-req: C.  If the message is an Observe registration, store it in memory for later comparison with re-registrations (see replay-protection). D.  If the message is an Observe cancellation, delete from memory the previously stored registration related to that observation (see replay-protection). </del> 8.3. If a CoAP response is generated in response to an OSCORE request, the
Code change:
This PR should (hopefully) conclude the main rewrite of Observe which was triggered by the security analysis and additional reviews of Observe. It should (hopefully) now be clear what part of the Observe related processing can be omitted in case Observe is not supported or in case intermediaries are not used. A new appendix E is covering the latter case.

Related discussion:
text: Number by one.  Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV. <del> Add the following step after step 5: B.  If the message is an Observe notification, store it in memory for use with re-registrations (see replay-protection), and delete from memory any older one previously stored. </del> 8.4. A client receiving a response containing the OSCORE option SHALL
Code change:
Solves issue (from review comments by NAME : URL)
Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option.
Closed in 84403c4c4 Section 4.1.3.1 - I am unclear why an OSCORE error response can be cached by an OSCORE unaware intermediate would be cached, but a success message is never going to be cached. Based on this, I don't plan to set an outer Max-Age option. In section 5.4 you have the text requestpiv: contains the value of the 'Partial IV' in the COSE object of the request (see Section 5), with one exception: in case of protection or verification of Observe cancellations, the requestpiv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see Section 4.1.3.5.1). I am unclear how/why this is different for observations. A cancelation is a message, so the IV is the request. A re-registration is a request message, any response would correspond to that request. The only interesting question has to do with updating the MID on a re-registration but not how PIVs work for this field. Section 6.1 - Is a registry needed for the leading byte of compression? Behavior if bits 0, 1, or 2 is set in the flags byte on decode? Section C - given the way that my system is implemented, it would be nice if the outputs included the first full IV to be used for both the sender and the recipient. That would allow for a test that the combination of ids and common ivs is done correctly. In my case I do not have the shared IV available for testing as I immediately or in the id.

Related discussion:
text: options. An Outer Max-Age message field is used to avoid unnecessary caching <del> of OSCORE error responses at OSCORE-unaware intermediary nodes.  A server MAY set a Class U Max-Age message field with value zero to OSCORE error responses, which are described in Sections replay- protection, ver-req, and ver-res.  Such a message field is then processed according to outer-options. </del> <ins> of error responses caused by OSCORE processing at OSCORE-unaware intermediary nodes.  A server MAY set a Class U Max-Age message field with value zero to such error responses, described in Sections replay-protection, ver-req, and ver-res, since these error responses are cacheable, but subsequent OSCORE requests would never create a hit in the intermediary caching it.  Setting the Outer Max-Age to zero relieves the intermediary from uselessly caching responses. </ins> Successful OSCORE responses do not need to include an Outer Max-Age <del> option since the responses are non-cacheable by construction (see coap-header). </del> <ins> option since the responses appear to the OSCORE-unaware intermediary as 2.04 Changed responses, which are non-cacheable (see coap-header). The Outer Max-Age message field is processed according to outer- options. </ins> 4.1.3.2.
Code change:
UTF-8 über alles.
Abstract: Explain that OSCOAP works across intermediaries and over any layer.Intro: Explain that OSCOAP works for Observe and Blockwise.Intro: Move details on replay and freshness to some other section.Terminology: Explain the references and add COSE.

Related discussion:
text: meanings. Readers are expected to be familiar with the terms and concepts <del> described in RFC7252 and RFC7641.  Readers are also expected to be familiar with RFC7049 and understand I-D.greevenbosch-appsawg-cbor- cddl.  Terminology for constrained environments, such as "constrained device", "constrained-node network", is defined in RFC7228. </del> <ins> described in CoAP RFC7252, Observe RFC7641, Blockwise RFC7959, COSE I-D.ietf-cose-msg, CBOR RFC7049, CDDL I-D.greevenbosch-appsawg-cbor- cddl, and constrained environments RFC7228. </ins> 2.
Code change:
, and
This goes against Jim's wish to have things in bits rather than bytes... But HKDF uses octets and to combine the two parameters as wanted by Ludwig, they need the same unit.
Fixed in branch v-02
OSCOAP refers to HKDF [RFC5869], but it not clearly defined how the parameters map to HKDF-Extract and HKDF-Expand. E.g. IKM. Salt should be made optional.
In section 3.2.1. outlen is defined as "the key/IV size of the AEAD algorithm" and outputlength as "is the size of the AEAD key/IV in bytes encoded as an 8-bit unsigned integer" Isn't that essentially the same?
I just created a v-02 branch for the next update. I'll make an update as soon as possible trying to address this.
Fixed in brach v-02

Related discussion:
text: use for encryption.  Its value is immutable once the security context is established. <del> Base Key (master_secret).  Variable length, uniformly random byte string containing the key used to derive traffic keys and IVs. Its value is immutable once the security context is established. </del> <ins> Master Secret.  Variable length, uniformly random byte string containing the key used to derive traffic keys and IVs.  Its value is immutable once the security context is established. Master Salt (OPTIONAL).  Variable length byte string containing the salt used to derive traffic keys and IVs.  Its value is immutable once the security context is established. </ins> The Sender Context contains the following parameters:
Code change:
, and
This goes against Jim's wish to have things in bits rather than bytes... But HKDF uses octets and to combine the two parameters as wanted by Ludwig, they need the same unit.
Fixed in branch v-02
OSCOAP refers to HKDF [RFC5869], but it not clearly defined how the parameters map to HKDF-Extract and HKDF-Expand. E.g. IKM. Salt should be made optional.
In section 3.2.1. outlen is defined as "the key/IV size of the AEAD algorithm" and outputlength as "is the size of the AEAD key/IV in bytes encoded as an 8-bit unsigned integer" Isn't that essentially the same?
I just created a v-02 branch for the next update. I'll make an update as soon as possible trying to address this.
Fixed in brach v-02

Related discussion:
text: messages received. The 3-tuple (Cid, Sender ID, Partial IV) is called Transaction <del> Identifier (Tid), and SHALL be unique for each Base Key. The Tid is used as a unique challenge in the COSE object of the protected CoAP request.  The Tid is part of the Additional Authenticated Data (AAD, see sec-obj-cose) of the protected CoAP response message, which is how responses are bound to requests. </del> <ins> Identifier (Tid), and SHALL be unique for each Master Secret.  The Tid is used as a unique challenge in the COSE object of the protected CoAP request.  The Tid is part of the Additional Authenticated Data (AAD, see sec-obj-cose) of the protected CoAP response message, which is how responses are bound to requests. </ins> 3.2.
Code change:
, and
This goes against Jim's wish to have things in bits rather than bytes... But HKDF uses octets and to combine the two parameters as wanted by Ludwig, they need the same unit.
Fixed in branch v-02
OSCOAP refers to HKDF [RFC5869], but it not clearly defined how the parameters map to HKDF-Extract and HKDF-Expand. E.g. IKM. Salt should be made optional.
In section 3.2.1. outlen is defined as "the key/IV size of the AEAD algorithm" and outputlength as "is the size of the AEAD key/IV in bytes encoded as an 8-bit unsigned integer" Isn't that essentially the same?
I just created a v-02 branch for the next update. I'll make an update as soon as possible trying to address this.
Fixed in brach v-02

Related discussion:
text: Context Identifier (Cid) <del> Base Key (master_secret) </del> <ins> Master Secret </ins> The following input parameters MAY be pre-established.  In case any of these parameters is not pre-established, the default value
Code change:
, and
This goes against Jim's wish to have things in bits rather than bytes... But HKDF uses octets and to combine the two parameters as wanted by Ludwig, they need the same unit.
Fixed in branch v-02
OSCOAP refers to HKDF [RFC5869], but it not clearly defined how the parameters map to HKDF-Extract and HKDF-Expand. E.g. IKM. Salt should be made optional.
In section 3.2.1. outlen is defined as "the key/IV size of the AEAD algorithm" and outputlength as "is the size of the AEAD key/IV in bytes encoded as an 8-bit unsigned integer" Isn't that essentially the same?
I just created a v-02 branch for the next update. I'll make an update as soon as possible trying to address this.
Fixed in brach v-02

Related discussion:
text: Defaults are 0x01 for the endpoint initially being client, and 0x00 for the endpoint initially being server <ins> Master Salt Default is the empty string </ins> Key Derivation Function (KDF) Default is HKDF SHA-256
Code change:
, and
This goes against Jim's wish to have things in bits rather than bytes... But HKDF uses octets and to combine the two parameters as wanted by Ludwig, they need the same unit.
Fixed in branch v-02
OSCOAP refers to HKDF [RFC5869], but it not clearly defined how the parameters map to HKDF-Extract and HKDF-Expand. E.g. IKM. Salt should be made optional.
In section 3.2.1. outlen is defined as "the key/IV size of the AEAD algorithm" and outputlength as "is the size of the AEAD key/IV in bytes encoded as an 8-bit unsigned integer" Isn't that essentially the same?
I just created a v-02 branch for the next update. I'll make an update as soon as possible trying to address this.
Fixed in brach v-02

Related discussion:
text: where: <del> master_secret is defined above </del> <ins> salt is the Master Salt as defined above </ins> <del> salt is a string of zeros of the length of the hash function output in octets </del> <ins> IKM is the Master Secret is defined above </ins> info is a serialized CBOR array consisting of: <del> output_length is the size of the AEAD key/IV in bytes encoded as an 8-bit unsigned integer </del> <ins> L is the key/IV size of the AEAD algorithm in octets without leading zeroes. </ins> For example, if the algorithm AES-CCM-64-64-128 (see Section 10.2 in <del> I-D.ietf-cose-msg) is used, output_length for the keys is 128 bits and output_length for the IVs is 56 bits. </del> <ins> I-D.ietf-cose-msg) is used, L is 16 bytes for keys and 7 bytes for IVs. </ins> 3.2.2.
Code change:
This is an important security consideration for the re-encryption case, which doesn't appear to be covered by the current text.
Salt could be the same, but key definitely needs to be different. Requiring both to be different is best, of course.

Related discussion:
text: been changed, then the original value will already be in the OHB, so no update to the OHB is required. <ins> A Media Distributor that decrypts, modifies, and re-encrypts packets in this way MUST use an independent key for each recipient, SHOULD use an independent salt for each recipient, and MUST NOT re-encrypt the packet using the sender's keys.  If the Media Distributor decrypts and re-encrypts with the same key and salt, it will result in the reuse of a (key, nonce) pair, undermining the security of GCM. </ins> 5.3. To decrypt a packet, the endpoint first decrypts and verifies using
Code change:
First, these documents can now refer to the published QUIC RFCs. While doing that, let's just replace all [REF] with {{REF}}, which works better for our tooling. Lastly, lets brush up the cross references between documents a bit.
I checked this locally and everything was good. It's easy enough to fix up later if I did break something.
qlog alreaady refers to the -34 drafts. Nominally this change should be easy. Although some section references might need double checking.
lgtm, assuming that the build tool correctly sets the links to the RFCs

Related discussion:
text: 1. This document describes the values of the qlog name ("category" + <del> "event") and "data" fields and their semantics for the HTTP/3 and QPACK protocols.  This document is based on draft-34 of the HTTP/3 I-D QUIC-HTTP and draft-21 of the QPACK I-D QUIC-QPACK.  QUIC events are defined in a separate document QLOG-QUIC. </del> <ins> "event") and "data" fields and their semantics for HTTP/3 RFC9114 and QPACK QPACK. </ins> Feedback and discussion are welcome at https://github.com/quicwg/qlog [1].  Readers are advised to refer to the "editor's draft" at that
Code change:
First, these documents can now refer to the published QUIC RFCs. While doing that, let's just replace all [REF] with {{REF}}, which works better for our tooling. Lastly, lets brush up the cross references between documents a bit.
I checked this locally and everything was good. It's easy enough to fix up later if I did break something.
qlog alreaady refers to the -34 drafts. Nominally this change should be easy. Although some section references might need double checking.
lgtm, assuming that the build tool correctly sets the links to the RFCs

Related discussion:
text: 1. This document describes the values of the qlog name ("category" + <del> "event") and "data" fields and their semantics for the QUIC protocol. This document is based on draft-34 of the QUIC I-Ds QUIC-TRANSPORT, QUIC-RECOVERY, and QUIC-TLS.  HTTP/3 and QPACK events are defined in a separate document QLOG-H3. </del> <ins> "event") and "data" fields and their semantics for QUIC; see QUIC- TRANSPORT, QUIC-RECOVERY, and QUIC-TLS. </ins> Feedback and discussion are welcome at https://github.com/quicwg/qlog [1].  Readers are advised to refer to the "editor's draft" at that
Code change:
Inappropriate use of MAY, lack of MUST [NOT]. Thanks to Russ Housley for schooling me on the correct usage.

Related discussion:
text: treat receipt of a non-empty value as a connection error of type TRANSPORT_PARAMETER_ERROR. <del> Advertising the grease_quic_bit transport parameter indicates that packets sent to this endpoint MAY set a value of 0 for the QUIC Bit. The QUIC Bit is defined as the second-to-most significant bit of the first byte of QUIC packets (that is, the value 0x40). </del> <ins> An endpoint that advertises the grease_quic_bit transport parameter MUST accept packets with the QUIC Bit set to a value of 0.  The QUIC Bit is defined as the second-to-most significant bit of the first byte of QUIC packets (that is, the value 0x40). </ins> A server MUST respect the value it previously provided for the grease_quic_bit transport parameter if it accepts 0-RTT.  A client
Code change:
Inappropriate use of MAY, lack of MUST [NOT]. Thanks to Russ Housley for schooling me on the correct usage.

Related discussion:
text: resulting in connection failures. A server MUST clear the QUIC bit only after processing transport <del> parameters from a client.  A server cannot remember that a client </del> <ins> parameters from a client.  A server MUST NOT remember that a client </ins> negotiated the extension in a previous connection and clear the QUIC Bit based on that information. <del> An endpoint cannot clear the QUIC Bit without knowing whether the </del> <ins> An endpoint MUST NOT clear the QUIC Bit without knowing whether the </ins> peer supports the extension.  As Stateless Reset packets (Section 10.3 of QUIC) are only used after a loss of connection state, endpoints are unlikely to be able to clear the QUIC Bit on
Code change:
This uses kramdown tricks to make real links for the section references to RFC 9001 and uses a nicer label for those.

Related discussion:
text: 1. <del> QUIC RFC9000 has numerous extension points, including the version number that occupies the second through fifth octets of every long header (see RFC8999).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version octets always being 0x00000001. </del> <ins> QUIC QUIC has numerous extension points, including the version number that occupies the second through fifth octets of every long header (see RFC8999).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version octets always being 0x00000001. </ins> Furthermore, version 1 Initial packets are encrypted with keys derived from a universally known salt, which allow observers to
Code change:
This uses kramdown tricks to make real links for the section references to RFC 9001 and uses a nicer label for those.

Related discussion:
text: 3. QUIC version 2 endpoints MUST implement the QUIC version 1 <del> specification as described in RFC9000, RFC9001, and RFC9002, with the </del> <ins> specification as described in QUIC, QUIC-TLS, and RFC9002, with the </ins> following changes: The version field of long headers is TBD.  Note: Unless this
Code change:
This uses kramdown tricks to make real links for the section references to RFC 9001 and uses a nicer label for those.

Related discussion:
text: provisional value 0xff020000, which might change with each edition of this document. <del> The salt used to derive Initial keys in Sec 5.2 of RFC9001 changes to </del> <ins> The salt used to derive Initial keys in Section 5.2 of QUIC-TLS changes to: </ins> <del> The labels used in RFC9001 to derive packet protection keys (Sec 5.1), header protection keys (Sec 5.4), Retry Integrity Tag keys (Sec 5.8), and key updates (Sec 6.1) change from "quic key" to </del> <ins> The labels used in QUIC-TLS to derive packet protection keys (Section Section 5.1 of QUIC-TLS), header protection keys (Section Section 5.4 of QUIC-TLS), Retry Integrity Tag keys (Section Section 5.8 of QUIC-TLS), and key updates (Section Section 6.1 of QUIC-TLS) change from "quic key" to </ins> "quicv2 key", from "quic iv" to "quicv2 iv", from "quic hp" to "quicv2 hp", and from "quic ku" to "quicv2 ku", to meet the <del> guidance for new versions in Section 9.6 of that document. </del> <ins> guidance for new versions in Section Section 9.6 of QUIC-TLS of that document. </ins> <del> The key and nonce used for the Retry Integrity Tag (Sec 5.8 of RFC9001) change to: </del> <ins> The key and nonce used for the Retry Integrity Tag (Section 5.8 of QUIC-TLS) change to: </ins> 4.
Code change:
, , , , , .
Just a style thing (and something we should try an capture in a QUIC style guide).
There a bit of inconsistency through the document. Personally I prefer the QUIC version N style.
is there a missing word here?
Nope, extra word, thanks
I find this awkward to read in isolation, it requires converting the RFC 9000 types definition format into a different encoding to realize there is a change. A clearer alternative could be "All version 2 Long Packet Types are different: Initial: 0b01 0-RTT: 0b10 Handshake 0b11 Retry: 0b00
Starting with This might be a matter of style but to me the term "changes" imply that you're modifying the original, not creating something new. How about we term these as differences instead? The the opening paragraph of Section 3 could be something like "QUIC version 2 endpoints MUST implement the QUIC version 1 specification as described in ], ], and ]. However, the following differences apply in version 2."
This might have been important earlier in the document lifetime but it seems to stick out now.
This could be misread to imply the salt is universally known and universally applicable, which I don't think is your intention. In fact, I find the construction of this entire paragraph a bit awkward. Can we rephrase this for better clarity? Something like "In QUIC version 1, Initial packets are encrypted with the version-specific salt as described in Section 5.2 of [QUIC-TLS]. Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Clent Hello or Server Hello messages. Again, there is the potential for middleboxes to ossify on the 1 key derivation and packet formats."
Couple of nits but otherwise LGTM

Related discussion:
text: QUIC QUIC has numerous extension points, including the version number that occupies the second through fifth bytes of every long header <del> (see RFC8999).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes always being </del> <ins> (see QUIC-INVARIANTS).  If experimental versions are rare, and QUIC version 1 constitutes the vast majority of QUIC traffic, there is the potential for middleboxes to ossify on the version bytes always being </ins> 0x00000001. <del> Furthermore, version 1 Initial packets are encrypted with keys derived from a universally known salt, which allow observers to inspect the contents of these packets, which include the TLS Client Hello and Server Hello messages.  Again, middleboxes may ossify on </del> <ins> In QUIC version 1, Initial packets are encrypted with the version- specific salt as described in Section 5.2 of QUIC-TLS.  Protecting Initial packets in this way allows observers to inspect their contents, which includes the TLS Client Hello or Server Hello messages.  Again, there is the potential for middleboxes to ossify on </ins> the version 1 key derivation and packet formats. Finally QUIC-VN provides two mechanisms for endpoints to negotiate