jiebi/CodeConvo huggingface dataset:
3.1. <del> [EDITOR'S NOTE: Jana noted at the interim in Paris that we should point out that applications need to be re-thought slightly to get the benefits of zero RTT.  Add a little text here to discuss this and why it's worth the effort, before we go straight into the dragons.] </del> <ins> A transport protocol that provides 0-RTT connection establishment to recently contacted servers is qualitatively different than one that does not from the point of view of the application using it. Relative tradeoffs between the cost of closing and reopening a connection and trying to keep it open are different; see resumption- v-keepalive. Applications must be slightly rethought in order to make best use of 0-RTT resumption.  Most importantly, application operations must be divided into idempotent and non-idempotent operations, as only idempotent operations may appear in 0-RTT packets.  This implies that the interface between the application and transport layer exposes idempotence either ecplicitly or implicitly. </ins> 3.2. <del> However, data in the frames contained in 0-RTT packets of a such a connection must be treated specially by the application layer. Replay of these packets can cause the data to processed twice.  This is further described in HTTP-RETRY. 0-RTT data also does not benefit from perfect forward secrecy (PFS). Applications that cannot treat data that may appear in a 0-RTT connection establishment as idempotent MUST NOT use 0-RTT establishment.  For this reason the QUIC transport SHOULD provide an interface for the application to indicate if 0-RTT support is in general desired or a way to indicate whether data is idempotent, and/ or whether PFS is a hard requirement </del> <ins> Retransmission or (malicious) replay of data contained in 0-RTT resumption packets could cause the server side to receive two copies of the same data.  This is further described in HTTP-RETRY.  Data sent during 0-RTT resumption also cannot benefit from perfect forward secrecy (PFS). Data in the first flight sent by the client in a connection established with 0-RTT MUST be idempotent.  Applications MUST be designed, and their data MUST be framed, such that multiple reception of idempotent data is recognized as such by the receiverApplications that cannot treat data that may appear in a 0-RTT connection establishment as idempotent MUST NOT use 0-RTT establishment.  For this reason the QUIC transport SHOULD provide an interface for the application to indicate if 0-RTT support is in general desired or a way to indicate whether data is idempotent, and/or whether PFS is a hard requirement for the application. </ins> 3.3. <del> [EDITOR'S NOTE: guidance/recommendation to us 0-RTT session resumption rather then sending keep-alives?] </del> <ins> [EDITOR'S NOTE: see https://github.com/quicwg/ops-drafts/issues/6] </ins> 4.
<del> Combining EDHOC and OSCORE </del> <ins> Using EDHOC for OSCORE with CoAP Transport </ins> draft-ietf-core-oscore-edhoc-latest Abstract <del> This document defines an optimization approach for combining the lightweight authenticated key exchange protocol EDHOC run over CoAP with the first subsequent OSCORE transaction.  This combination reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. </del> <ins> This document defines how the lightweight authenticated key exchange protocol EDHOC is used for establishing an OSCORE Security Context, using CoAP for message transferring.  Furthermore, this document defines an optimization approach for combining EDHOC run over CoAP with the first subsequent OSCORE transaction.  This reduces the number of round trips required to set up an OSCORE Security Context and to complete an OSCORE transaction using that Security Context. </ins> 1. <del> This document defines an optimization approach to combine the lightweight authenticated key exchange protocol EDHOC I-D.ietf-lake- edhoc, when running over CoAP RFC7252, with the first subsequent OSCORE RFC8613 transaction. </del> <ins> Ephemeral Diffie-Hellman Over COSE (EDHOC) I-D.ietf-lake-edhoc is a lightweight authenticated key exchange protocol, especially intended for use in constrained scenarios.  As defined in Section 7.2 of I- D.ietf-lake-edhoc, EDHOC messages can be transported over the Constrained Application Protocol (CoAP) RFC7252. </ins> <del> This allows for a minimum number of round trips necessary to setup the OSCORE Security Context and complete an OSCORE transaction, for example when an IoT device gets configured in a network for the first time. </del> <ins> This document builds on the EDHOC specification I-D.ietf-lake-edhoc and defines how EDHOC run over CoAP is used for establishing a Security Context for Object Security for Constrained RESTful Environments (OSCORE) RFC8613. In addition, this document defines an optimization approach that combines EDHOC run over CoAP with the first subsequent OSCORE transaction.  This allows for a minimum number of round trips necessary to setup the OSCORE Security Context and complete an OSCORE transaction, for example, when an IoT device gets configured in a network for the first time. </ins> This optimization is desirable, since the number of protocol round trips impacts the minimum number of flights, which in turn can have a
Without this optimization, it is not possible, not even in theory, to achieve the minimum number of flights.  This optimization makes it <del> possible also in practice, since the last message of the EDHOC </del> <ins> possible also in practice since the last message of the EDHOC </ins> protocol can be made relatively small (see Section 1 of I-D.ietf- lake-edhoc), thus allowing additional OSCORE protected CoAP data within target MTU sizes.
EDHOC data and the OSCORE ciphertext, using the newly defined EDHOC option for signalling. <del> 4. The approach defined in this specification consists of sending EDHOC message_3 inside an OSCORE protected CoAP message. The resulting EDHOC + OSCORE request is in practice the OSCORE Request from fig-non-combined, sent to a protected resource and with the correct CoAP method and options, with the addition that it also transports EDHOC message_3. Since EDHOC message_3 may be too large to be included in a CoAP Option, e.g. if containing a large public key certificate chain, it has to be transported through the CoAP payload. The use of this approach is explicitly signalled by including an EDHOC Option (see signalling) in the EDHOC + OSCORE request. 4.1. </del> <ins> 5.2. </ins> The Client prepares an EDHOC + OSCORE request as follows.
the CBOR sequence built at step 3. Signal the usage of this approach within the EDHOC + OSCORE <del> request, by including the new EDHOC Option defined in signalling. </del> <ins> request, by including the new EDHOC Option defined in edhoc- option. </ins> <del> 4.2. </del> <ins> 5.3. </ins> <del> When receiving an EDHOC + OSCORE request, the Server performs the following steps. </del> <ins> When receiving a request containing the EDHOC option, i.e. an EDHOC + OSCORE request, the Server MUST perform the following steps. </ins> <del> Check the presence of the EDHOC option defined in signalling, to determine that the received request is an EDHOC + OSCORE request. If this is the case, the Server continues with the steps defined below. </del> <ins> Check that the payload of the EDHOC + OSCORE request is a CBOR sequence composed of two CBOR byte strings.  If this is not the case, the Server MUST stop processing the request and MUST respond with a 4.00 (Bad Request) error message. </ins> Extract CIPHERTEXT_3 from the payload of the EDHOC + OSCORE request, as the first CBOR byte string in the CBOR sequence.
derivation, as per Section 5.4.3 and Section 7.2.1 of I-D.ietf- lake-edhoc, respectively. <ins> If the applicability statement used in the EDHOC session specifies that EDHOC message_4 shall be sent, the Server MUST stop the EDHOC processing and consider it failed, as due to a client error. </ins> Extract the OSCORE ciphertext from the payload of the EDHOC + OSCORE request, as the value of the second CBOR byte string in the CBOR sequence.
is not applicable to the approach defined in this specification. If step 4 (EDHOC processing) fails, the server discontinues the <del> protocol as per Section 5.4.3 of I-D.ietf-lake-edhoc and sends an EDHOC error message, formatted as defined in Section 6.1 of I-D.ietf- lake-edhoc.  In particular, the CoAP response conveying the EDHOC error message: MUST have Content-Format set to application/edhoc defined in Section 9.5 of I-D.ietf-lake-edhoc. MUST specify a CoAP error response code, i.e. 4.00 (Bad Request) in case of client error (e.g. due to a malformed EDHOC message_3), or 5.00 (Internal Server Error) in case of server error (e.g. due to failure in deriving EDHOC key material). </del> <ins> protocol as per Section 5.4.3 of I-D.ietf-lake-edhoc and responds with an EDHOC error message, formatted as defined in Section 6.1 of I-D.ietf-lake-edhoc.  In particular, the CoAP response conveying the EDHOC error message MUST have Content-Format set to application/edhoc defined in Section 9.5 of I-D.ietf-lake-edhoc. </ins> If step 4 (EDHOC processing) is successfully completed but step 7 (OSCORE processing) fails, the same OSCORE error handling applies as defined in Section 8.2 of RFC8613. <del> 5. </del> <ins> 5.4. </ins> <del> An example based on the OSCORE test vector from Appendix C.4 of RFC8613 and the EDHOC test vector from Appendix B.2 of I-D.ietf-lake- edhoc is given in fig-edhoc-opt-2.  In particular, the example assumes that: </del> <ins> fig-edhoc-opt-2 shows an example of EDHOC + OSCORE Request, based on the OSCORE test vector from Appendix C.4 of RFC8613 and the EDHOC test vector from Appendix B.2 of I-D.ietf-lake-edhoc.  In particular, the example assumes that: </ins> The used OSCORE Partial IV is 0, consistently with the first request protected with the new OSCORE Security Context. <del> The OSCORE Sender ID of the Client is 0x20.  This corresponds to </del> <ins> The OSCORE Sender ID of the Client is 0x00.  This corresponds to </ins> the EDHOC Connection Identifier C_R, which is encoded as the <del> bstr_identifier 0x08 in EDHOC message_3. </del> <ins> bstr_identifier 0x37 in EDHOC message_3. </ins> <del> The EDHOC option is registered with CoAP option number 13. </del> <ins> The EDHOC option is registered with CoAP option number 21. </ins> 6.
unassigned in the "CoAP Option Numbers" registry, as first available and consistent option numbers for the EDHOC option. <ins> This document suggests 21 (TBD21) as option number to be assigned to the new EDHOC option, since both 13 and 21 are consistent for the use case in question, but different use cases or protocols may make better use of the option number 13. </ins> ] <ins> 7.2. IANA is asked to enter the following entries to the "EDHOC Exporter Label" registry defined in I-D.ietf-lake-edhoc. </ins>
For each stored security context, the first time after boot the server receives an OSCORE request, the server uses the Repeat option I-D.amsuess-core-repeat-request-tag to get a request with <del> verifiable freshness and uses that to synchronize the replay window.  If the server can verify the fresh request, the Partial IV in the fresh request is set as the lower limit of the replay </del> <ins> verifiable freshness. The Request option in the server's response MUST be encrypted, and the server MUST NOT use the same nonce as the request in its reply. If the server can verify a second request as fresh, the Partial IV of the second request is set as the lower limit of the replay </ins> window. 6.5.3.
Outer Observe value, it stops processing the message, as specified in ver-res. <del> It the server accepts the Observe registration, a Partial IV must be </del> <ins> In order to support Observe processing in OSCORE-unaware intermediaries, for messages with the Observe option the Outer Code SHALL be set to 0.05 (FETCH) for requests and to 2.05 (Content) for responses. 4.1.3.4.2. It the server accepts an Observe registration, a Partial IV must be </ins> included in all notifications (both successful and error).  To secure the order of notifications, the client SHALL maintain a Notification Number for each Observation it registers.  The Notification Number is
Partial IV MUST always be compared with the Notification Number, which thus MUST NOT be forgotten after 128 seconds.  Further details of replay protection of notifications are specified in replay- <del> protection.  The client MAY ignore the Observe option value. </del> <ins> protection. </ins> Clients can re-register observations to ensure that the observation is still active and establish freshness again (RFC7641 <del> Section 3.3.1).  When an OSCORE observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and OSCORE option) change.  The server uses the new request's Partial IV as the 'request_piv' of new responses. </del> <ins> Section 3.3.1).  When an OSCORE protected observation is refreshed, not only the ETags, but also the partial IV (and thus the payload and OSCORE option) change.  The server uses the new request's Partial IV as the 'request_piv' of new responses. </ins> 4.1.3.5.
The sending endpoint SHALL write the Code of the original CoAP message into the plaintext of the COSE object (see plaintext).  After that, the sending endpoint writes an Outer Code to the OSCORE <del> message.  The Outer Code SHALL be set to 0.02 (POST) or 0.05 (FETCH) for requests.  For non-Observe requests the client SHALL set the Outer Code to 0.02 (POST).  For responses, the sending endpoint SHALL respond with Outer Code 2.04 (Changed) to 0.02 (POST) requests, and with Outer Code 2.05 (Content) to 0.05 (FETCH) requests.  Using FETCH with Observe allows OSCORE to be compliant with the Observe processing in OSCORE-unaware intermediaries.  The choice of POST and FETCH RFC8132 allows all OSCORE messages to have payload. The receiving endpoint SHALL discard the Outer Code in the OSCORE message and write the Code of the COSE object plaintext (plaintext) into the decrypted CoAP message. </del> <ins> message.  With one exeception (see observe-option-processing) the Outer Code SHALL by default be set to 0.02 (POST) for requests and to 2.04 (Changed) for responses.  The receiving endpoint SHALL discard the Outer Code in the OSCORE message and write the Code of the COSE object plaintext (plaintext) into the decrypted CoAP message. </ins> The other currently defined CoAP Header fields are Unprotected (Class U).  The sending endpoint SHALL write all other header fields of the
Additionally to the previous section, the following applies when Observe is supported. <del> Observe allows re-registration of observations (see 3.3.1 of RFC7641).  A server receiving an Observe registration identical to a previously stored one (including Partial IV and Token) SHALL treat it as valid and reply with the last notification sent. </del> <ins> 7.4.1.1. </ins> A client receiving a notification SHALL compare the Partial IV of a received notification with the Notification Number associated to that <del> Observe registration.  Observe reordering MUST be linked to OSCORE's ordering of notifications.  The client MAY do so by copying the least significant bytes of the Partial IV into the Observe option, before passing it to CoAP processing.  If the verification of the response succeeds, and the received Partial IV was greater than the </del> <ins> Observe registration.  The ordering of notifications after OSCORE processing MUST be aligned with the Partial IV.  The client MAY do so by copying the least significant bytes of the Partial IV into the Observe option, before passing it to CoAP processing.  The client MAY ignore an Outer Observe option value.  If the verification of the response succeeds, and the received Partial IV was greater than the </ins> Notification Number, then the client SHALL update the corresponding Notification Number with the received Partial IV.  The client MUST stop processing notifications with a Partial IV which has been
replay protection data.  The operation of validating the Partial IV and updating the replay protection data MUST be atomic. <ins> 7.4.1.2. In order to allow intermediaries to re-register their interest in a resource (see 3.3.1 of RFC7641), a server receiving an Observe registration with Token, Kid and Partial IV identical to a previously received registration, and which decrypts without error SHALL not treat it as a replay and SHALL respond with a notification.  The notification may be a cached copy of the latest sent notification (with the same Token, Kid and Partial IV) or it may be a newly generated notification with a fresh Partial IV. </ins> 7.5. To prevent reuse of an AEAD nonce with the same key, or from
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
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.
Every time a client issues a new Observe request, a new Partial IV MUST be used (see cose-object), and so the payload and OSCORE option are changed.  The server uses the Partial IV of the new request as <del> the 'request_piv' of all associated notifications (see AAD).  The Partial IV of the registration is also used as 'request_piv' of associated cancellations (see AAD). </del> <ins> the 'request_piv' of all associated notifications (see AAD). </ins> Intermediaries are not assumed to have access to the OSCORE security context used by the endpoints, and thus cannot make requests or
the request (see cose-object). request_piv: contains the value of the 'Partial IV' in the COSE <del> object of the request (see cose-object), with one exception: in case of protection or verification of Observe cancellations, the request_piv contains the value of the 'Partial IV' in the COSE object of the corresponding registration (see observe- registration). </del> <ins> object of the request (see cose-object). </ins> options: contains the Class I options (see outer-options) present in the original CoAP message encoded as described in Section 3.1
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.
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:
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.
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.