for other control processes, and a short header that may be used for data transmission in an established connection.  While the long header always exposes some information (such as the version and <del> Connection IDs), the short header only optionally exposes a single Connection ID. Given that exposing this information may make it possible to associate multiple addresses with a single client during rebinding, which has privacy implications, an application may indicate to not support exposure of certain information after the handshake. Specifically, an application that has additional information that the client is not behind a NAT and the server is not behind a load balancer, and therefore it is unlikely that the addresses will be re- bound, may indicate to the transport that is wishes to not expose a </del>  Connection ID. 6.1. QUIC supports a server-generated Connection ID, transmitted to the client during connection establishment (see Section 6.1 of QUIC). <del> Servers behind load balancers should propose a Connection ID during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support stateless load balancing.  Once the server generates a Connection ID that encodes its identity, every CDN load balancer would be able to forward the packets to that server without needing information about every specific flow it is forwarding. Server-generated Connection IDs must not encode any information other that that needed to route packets to the appropriate backend server(s): typically the identity of the backend server or pool of servers, if the data-center's load balancing system keeps "local" state of all flows itself.  Care must be exercised to ensure that the information encoded in the Connection ID is not sufficient to identify unique end users.  Note that by encoding routing information in the Connection ID, load balancers open up a new attack vector that allows bad actors to direct traffic at a specific backend server or pool.  It is therefore recommended that Server-Generated Connection ID includes a cryptographic MAC that the load balancer pool server is able to identify and discard packets featuring an invalid MAC. </del>  6.2.  QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new Connection ID in that packet and the client will retry by sending

Tries to I resisted the urge to reference the QUIC-LB draft, which isn't adopted. The major substantive change is that I removed the prohibition on non-routing information in the CID. I'm happy to discuss this if people have object.
LGTM. will go ahead and land this, then fix up the lint issues.
NAME missed this during the inconsistency, will fix in working copy
(this is done)
BTW, this was meant to address
Moving URL to the ops repo.
see also -- in any case the text that is there now is not great.
NAME can you please review the existing text (orginially provided by NAME and state what else is needed? Please have also a look at issue
This is a bit OBE, but I think there might still be value in discussing how a server implementer should think about connection IDs. Fortunately, NAME has been doing a bunch of work on this in his load balancer draft. I would suggest that we leave this issue open, and either point to the LB draft or use text from it.
fixed this
Write section to provide guidance; maybe in the same section than guidance in port selection in general

for other control processes, and a short header that may be used for data transmission in an established connection.  While the long header always exposes some information (such as the version and  <ins> Connection IDs), the short header exposes at most only a single </ins> Connection ID. 6.1. QUIC supports a server-generated Connection ID, transmitted to the client during connection establishment (see Section 6.1 of QUIC).  <ins> Servers behind load balancers may need to propose a Connection ID during the handshake, encoding the identity of the server or information about its load balancing pool, in order to support stateless load balancing.  Once the server generates a Connection ID that encodes its identity, every CDN load balancer would be able to forward the packets to that server without retaining connection state. Server-generated connection IDs should seek to obscure any encoding, of routing identities or any other information.  Exposing the server mapping would allow linkage of multiple IP addresses to the same host if the server also supports migration.  Furthermore, this opens an attack vector on specific servers or pools. The best way to obscure an encoding is to appear random to observers, which is most rigorously achieved with encryption. </ins> 6.2. <ins> While sufficiently robust connection ID generation schemes will mitigate linkability issues, they do not provide full protection. Analysis of the lifetimes of six-tuples (source and destination addresses as well as the migrated CID) may expose these links anyway. In the limit where connection migration in a server pool is rare, it is trivial for an observer to associate two connection IDs. Conversely, in the opposite limit where every server handles multiple simultaneous migrations, even an exposed server mapping may be insufficient information. The most efficient mitigation for these attacks is operational, either by using a load balancing architecture that loads more flows onto a single server-side address, by coordinating the timing of migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. 6.3. </ins> QUIC provides a Server Retry packet that can be sent by a server in response to the Client Initial packet.  The server may choose a new Connection ID in that packet and the client will retry by sending


that the load balancer will redirect the next Client Initial packet to a different server in that pool. <del> 6.3. QUIC provides for multiple Server and Client Connection IDs to be used simultaneously by a given connection, which allows seamless connection migration when one of the endpoints changes IP address and/or UDP port.  Section 6.11.5 of QUIC describes how to use this facility to reduce the risk of exposing a link among these addresses to observers on the network.  However, analysis of the lifetimes of six-tuples (source and destination addresses as well as the migrated CID) may expose these links anyway. In practice, a finite set of flows will be undergoing migration within any one time window as seen from any given observation point in the network, and any migration must keep at least one endpoint address constant during the migration.  Because of this, a key insight here is that this finite set of flows represents the anonymity set for any one flow undergoing migration within it.  For endpoints with low volume, this anonymity set will be necessarily small, so there remains a significant risk of linkage exposure through timing-based analysis. The most efficient mitigation for these attacks is operational, by increasing the size of the anonymity set as seen from a passive observer in the Internet, either by using a load balancing architecture that loads more flows onto a single server-side address, by coordinating the timing of migrations to attempt to increase the number of simultaneous migrations at a given time, or through other means. </del> 7. Versioning in QUIC may change the protocol's behavior completely,

that the load balancer will redirect the next Client Initial packet to a different server in that pool.  7. Versioning in QUIC may change the protocol's behavior completely,


semantics as needed for HTTP/2 QUIC-HTTP.  Based on current deployment practices, QUIC is encapsulated in UDP and encrypted by default.  The current version of QUIC integrates TLS QUIC-TLS to <del> encrypt all payload data and most control information.  Given QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is is not meant to be mutable by the network, and is therefore integrity-protected to the extent possible. </del>  This document provides guidance for network operation on the management of QUIC traffic.  This includes guidance on how to

Address .
The section on "Passive network performance measurement and troubleshooting" is probably a bit too pessimistic. It's probably worth pointing out that one part of network troubleshooting -- "find out which box to blame" -- is substantially easier. Thanks to integrity protection, most middleboxes, can drop, delay/rate limit, and corrupt, and that's about it. These are fairly easy behaviors to diagnose. I've had some conversations with customers afraid of not having their TCP headers anymore, and I believe this fear is largely misguided. If people agree this belongs in the draft, I can file a PR.
I agree the wording is very pessimistic. However, I don't think your observation belongs in this section because it's about measurement of performance metrics. There is a sentence in the introduction: "Given QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is is not meant to be mutable by the network, and is therefore integrity-protected to the extent possible." Maybe it makes sense to add another sentence right there to also emphasis the positive effect of that, like: "While more limited information compared to TCP is visible to the network, integrity protection can also make troubleshooting easier as none of the nodes on the network path can modify the transport layer information."
LGTM, will fix Jana's suggestion manually.One nit, but LGTM. The nit is to avoid ambiguity that might arise from "transport" -- one might read that QUIC integrity-protects UDP headers as well, since those are technically transport.

semantics as needed for HTTP/2 QUIC-HTTP.  Based on current deployment practices, QUIC is encapsulated in UDP and encrypted by default.  The current version of QUIC integrates TLS QUIC-TLS to  <ins> encrypt all payload data and most control information. Given that QUIC is an end-to-end transport protocol, all information in the protocol header, even that which can be inspected, is not meant to be mutable by the network, and is therefore integrity- protected.  While less information is visible to the network than for TCP, integrity protection can also simplify troubleshooting because none of the nodes on the network path can modify the transport layer information. </ins> This document provides guidance for network operation on the management of QUIC traffic.  This includes guidance on how to


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>  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>  3.3. <del> [EDITOR'S NOTE: guidance/recommendation to us 0-RTT session resumption rather then sending keep-alives?] </del>  4.

NAME -- you mentioned wanting to have a more balanced view of zero RTT in the applicability draft: is this something like what you had in mind?
I'll go ahead and merge this to have one less editor's note in the ietf-00 submission; file an issue if this doesn't address the "thinking in 0rtt" point adequately.
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 to discuss this and why it's worth the effort, before we go straight into the dragons.

3.1.  <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.  <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.  <ins> [EDITOR'S NOTE: see https://github.com/quicwg/ops-drafts/issues/6] </ins> 4.


<del> Combining EDHOC and OSCORE </del>  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>  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>  <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>  This optimization is desirable, since the number of protocol round trips impacts the minimum number of flights, which in turn can have a

Clean-up after URL As the content-from-edhoc branch seems to be the most up-to-date one (in which the parts changed are introduced in the first place), this builds on , and only the latest commit is actually relevant.
Compared to the original bstridentifier mapping, this is a different int-to-bstr mapping, but one that's most likely efficient to implement. I have not made any statement on the efficiencies, but some guidance we could give is that from a coding density point of view, numeric Cx should only be used with -24..23; for all other values, doing it in a bstr is just as good and saves a byte in OSCORE. (In fact we may want to make that normative, so that only the single-byte case needs to be implemented where this needs explicit implementation).

<ins> Using EDHOC for OSCORE with CoAP Transport </ins> draft-ietf-core-oscore-edhoc-latest Abstract  <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.  <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>  <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>  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.

Without this optimization, it is not possible, not even in theory, to achieve the minimum number of flights.  This optimization makes it  <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.


2. <del> EDHOC is a 3-message key exchange protocol.  Section 7.2 of I-D.ietf- lake-edhoc specifies how to transport EDHOC over CoAP: the EDHOC data (referred to as "EDHOC messages") are transported in the payload of CoAP requests and responses. </del>  <del> This draft deals with the case of the Initiator acting as CoAP Client and the Responder acting as CoAP Server; instead, the case of the Initiator acting as CoAP Server cannot be optimized by using this approach. </del>  <del> That is, the CoAP Client sends a POST request containing EDHOC message_1 to a reserved resource at the CoAP Server.  This triggers the EDHOC exchange on the CoAP Server, which replies with a 2.04 (Changed) Response containing EDHOC message_2.  Finally, the CoAP Client sends EDHOC message_3, as a CoAP POST request to the same resource used for EDHOC message_1.  The Content-Format of these CoAP messages may be set to "application/edhoc". </del>  <del> After this exchange takes place, and after successful verifications specified in the EDHOC protocol, the Client and Server derive the OSCORE Security Context, as specified in Section 7.2.1 of I-D.ietf- lake-edhoc.  Then, they are ready to use OSCORE. </del>  <del> This sequential way of running EDHOC and then OSCORE is specified in fig-non-combined.  As shown in the figure, this mechanism takes 3 round trips to complete. </del>  <del> The number of roundtrips can be minimized as follows.  Already after receiving EDHOC message_2 and before sending EDHOC message_3, the CoAP Client has all the information needed to derive the OSCORE Security Context. </del>  <del> This means that the Client can potentially send at the same time both EDHOC message_3 and the subsequent OSCORE Request.  On a semantic level, this approach practically requires to send two separate REST requests at the same time. </del>  <del> The high level message flow of running EDHOC and OSCORE combined is shown in fig-combined. </del>  <del> Defining the specific details of how to transport the data and of their processing order is the goal of this specification, as defined in edhoc-in-oscore. </del>  <del> 3. </del>  <del> This section defines the EDHOC Option, used in a CoAP request to signal that the request combines EDHOC message_3 and OSCORE protected data. </del>  The EDHOC Option has the properties summarized in fig-edhoc-option, which extends Table 4 of RFC7252.  The option is Critical, Safe-to-

2.  <ins> The EDHOC protocol allows two peers to agree on a cryptographic secret, in a mutually-authenticated way and by using Diffie-Hellman ephemeral keys to achieve perfect forward secrecy.  The two peers are denoted as Initiator and Responder, as the one sending or receiving the initial EDHOC message_1, respectively. After successful processing of EDHOC message_3, both peers agree on a cryptographic secret that can be used to derive further security material, and especially to establish an OSCORE Security Context RFC8613.  The Responder can also send an optional EDHOC message_4 to achieve key confirmation, e.g. in deployments where no protected application message is sent from the Responder to the Initiator. Section 7.2 of I-D.ietf-lake-edhoc specifies how to transport EDHOC over CoAP.  That is, the EDHOC data (referred to as "EDHOC messages") are transported in the payload of CoAP requests and responses.  The default message flow consists in the CoAP Client acting as Initiator and the CoAP Server acting as Responder.  Alternatively, the two roles can be reversed.  In the rest of this document, EDHOC messages are considered to be transported over CoAP. fig-non-combined shows a Client and Server running EDHOC as Initiator and Responder, respectively.  That is, the Client sends a POST request with payload EDHOC message_1 to a reserved resource at the CoAP Server, by default at Uri-Path "/.well-known/edhoc".  This triggers the EDHOC exchange at the Server, which replies with a 2.04 (Changed) Response with payload EDHOC message_2.  Finally, the Client sends a CoAP POST request to the same resource used for EDHOC message_1, with payload EDHOC message_3.  The Content-Format of these CoAP messages may be set to "application/edhoc". After this exchange takes place, and after successful verifications as specified in the EDHOC protocol, the Client and Server can derive an OSCORE Security Context, as defined in oscore-ctx of this document.  After that, they can use OSCORE to protect their communications. </ins>  <ins> As shown in fig-non-combined, this purely-sequential way of first running EDHOC and then using OSCORE takes three round trips to complete. </ins>  <ins> edhoc-in-oscore defines an optimization for combining EDHOC 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>  <ins> 3. </ins>  <ins> When using EDHOC over CoAP for establishing an OSCORE Security Context, EDHOC messages are exchanged as defined in Section 7.2 of I- D.ietf-lake-edhoc, with the following addition. </ins>  <ins> EDHOC error messages sent as CoAP responses MUST be error responses, i.e. they MUST specify a CoAP error response code.  In particular, it is RECOMMENDED that such error responses have response code either 4.00 (Bad Request) in case of client error (e.g. due to a malformed EDHOC message), or 5.00 (Internal Server Error) in case of server error (e.g. due to failure in deriving EDHOC key material). </ins>  <ins> 4. </ins>  <ins> After successful processing of EDHOC message_3 (see Section 5.5 of I- D.ietf-lake-edhoc), the Client and Server derive Security Context parameters for OSCORE (see Section 3.2 of RFC8613) as follows. The Master Secret and Master Salt are derived by using the EDHOC- Exporter interface defined in Section 4.1 of I-D.ietf-lake-edhoc. The EDHOC Exporter Labels to use are "OSCORE Master Secret" and "OSCORE Master Salt", for deriving the OSCORE Master Secret and the OSCORE Master Salt, respectively. By default, key_length is the key length (in bytes) of the application AEAD Algorithm of the selected cipher suite for the EDHOC session.  Also by default, salt_length has value 8.  The Initiator and Responder MAY agree out-of-band on a longer key_length than the default and on a different salt_length. The AEAD Algorithm is the application AEAD algorithm of the selected cipher suite for the EDHOC session. The HKDF Algorithm is the HKDF algorithm of the selected cipher suite for the EDHOC session. In case the Client is the Initiator and the Server is the Responder, the Client's OSCORE Sender ID and the Server's OSCORE Sender ID are the byte string EDHOC connection identifier C_R and C_I for the EDHOC session, respectively.  The reverse applies in case the Client is the Responder and the Server is the Initiator. Numeric connection identifiers are converted to (naturally byte- string shaped) Sender IDs by using their CBOR encoded form.  For example, a C_R of 10 corresponds to a (typically server) Sender ID of hexadecimal '0a', -12 to hexadecimal '2b', whereas a byte- string valued C_R of h'ff' corresponds to a Sender ID of hexadecimal 'ff'. Before deriving an OSCORE Security Context, the two peers MUST ensure that the EDHOC connection identifiers are different. that is, the two peers MUST NOT derive an OSCORE Security Context from an EDHOC session, if C_R is equal to C_I for that session. If the Responder runs EDHOC with the intention of deriving an OSCORE Security Context, the Responder MUST NOT include in EDHOC message_2 a connection identifier C_R equivalent (under conversion to a Sender ID) to the connection identifier C_I received in EDHOC message_1.  If the Initiator runs EDHOC with the intention of deriving an OSCORE Security Context, the initiator MUST discontinue the protocol and reply with an EDHOC error message when receiving an EDHOC message_2 that includes a connection identifier C_R equal to C_I. The Client and Server use the parameters above to establish an OSCORE Security Context, as per Section 3.2.1 of RFC8613. From then on, the Client and Server MUST be able to retrieve the OSCORE protocol state using its chosen connection identifier, and optionally other information such as the 5-tuple, i.e., the tuple (source IP address, source port, destination IP address, destination port, transport protocol). </ins>  <ins> 5. </ins>  <ins> This section defines an optimization for combining the EDHOC exchange with the first subsequent OSCORE transaction, thus minimizing the number of round trips between the two peers. This approach can be used only if the default EDHOC message flow is used, i.e., when the Client acts as Initiator and the Server acts as Responder, while it cannot be used in the case with reversed roles. When running the purely-sequential flow of overview, the Client has all the information to derive the OSCORE Security Context already after receiving EDHOC message_2 and before sending EDHOC message_3. Hence, the Client can potentially send both EDHOC message_3 and the subsequent OSCORE Request at the same time.  On a semantic level, this requires sending two REST requests at once, as in fig-combined. To this end, the specific approach defined in this section 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, as still sent to a protected resource and with the correct CoAP method and options, but with the addition that it also transports EDHOC message_3. As 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 in the CoAP payload of the EDHOC + OSCORE request. The rest of this section specifies how to transport the data in the EDHOC + OSCORE request and their processing order.  In particular, the use of this approach is explicitly signalled by including an EDHOC Option (see edhoc-option) in the EDHOC + OSCORE request.  The processing of the EDHOC + OSCORE request is specified in client- processing for the Client side and in server-processing for the Server side. </ins>  <ins> 5.1. This section defines the EDHOC Option.  The option is used in a CoAP request, to signal that the request payload conveys both an EDHOC message_3 and OSCORE protected data, combined together. </ins> The EDHOC Option has the properties summarized in fig-edhoc-option, which extends Table 4 of RFC7252.  The option is Critical, Safe-to-


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>  The Client prepares an EDHOC + OSCORE request as follows.

EDHOC data and the OSCORE ciphertext, using the newly defined EDHOC option for signalling.  <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>  <del> 4.2. </del>  <del> When receiving an EDHOC + OSCORE request, the Server performs the following steps. </del>  <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>  Extract CIPHERTEXT_3 from the payload of the EDHOC + OSCORE request, as the first CBOR byte string in the CBOR sequence.

the CBOR sequence built at step 3. Signal the usage of this approach within the EDHOC + OSCORE  <ins> request, by including the new EDHOC Option defined in edhoc- option. </ins>  <ins> 5.3. </ins>  <ins> When receiving a request containing the EDHOC option, i.e. an EDHOC + OSCORE request, the Server MUST perform the following steps. </ins>  <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.  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.

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>  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>  <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>  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>  the EDHOC Connection Identifier C_R, which is encoded as the <del> bstr_identifier 0x08 in EDHOC message_3. </del>  <del> The EDHOC option is registered with CoAP option number 13. </del>  6.

is not applicable to the approach defined in this specification. If step 4 (EDHOC processing) fails, the server discontinues the  <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.  <ins> 5.4. </ins>  <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.  <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  <ins> bstr_identifier 0x37 in EDHOC message_3. </ins>  <ins> The EDHOC option is registered with CoAP option number 21. </ins> 6.


7.  This document has the following actions for IANA. 7.1.

7. <ins> RFC Editor: Please replace "[[this Document]]" with the RFC number of this document and delete this paragraph. </ins> This document has the following actions for IANA. 7.1.


[ The CoAP option numbers 13 and 21 are both consistent with the <del> properties of the EDHOC Option defined in signalling, and they both </del>  allow the EDHOC Option to always result in an overall size of 1 byte. This is because:

[ The CoAP option numbers 13 and 21 are both consistent with the  <ins> properties of the EDHOC Option defined in edhoc-option, and they both </ins> allow the EDHOC Option to always result in an overall size of 1 byte. This is because:


unassigned in the "CoAP Option Numbers" registry, as first available and consistent option numbers for the EDHOC option.  ]

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>  window. 6.5.3.

This prescribes explicitly one of the possible ways that the response is sent, and states the (hopefully) obvious about accepting new requests. The alternative to "MUST NOT be encrypted" would be "MUST be encrypted and MUST carry an explicit IV"; even both would work, but clients need to know what they need to be prepared for. I'd be fine with either of the two (or three) versions of the request encryption, but not stating anything might result in incompatible implementations where one only works this and one only works that way. Being explicit about (to us) obvious things like not responding with an implied IV or not accepting Repeat as Class U (or in an unencrypted request that might then clear the way for any replays) might not be necessary from a specification point of view, but could avoid implementation errors I see very vividly before my inner eye.
Come to think of it (from the considerations in URL), we have to go the other way and say that the response "MUST be encrypted, and MUST use an explicit partial IV". As we want to use this for HTTP too, this is by far the easier option; otherwise, we'd have to additionally specify how the option is transported in HTTP, so a HC proxy can convert it, and then the HC proxy would need to know whether it's transporting OSCORE (so it'd forward the Repeat option for the HTTP client to include it in a new encrypted request) or whether it's working for an OSCORE-unaware client that would not be equipped to answer the Repeat challenge (so it'd repeat the known fresh (because HTTP) request with a Repeat option by itself without bothering the client).
Did I understand right, that you take back the proposal in the PR? Partial IV generated by the server is allowed in any response. With the resolution of issue : "if Partial IV present in the message -> use that Partial IV" Hence the replay draft can specify that replay syncing MUST use the server generated PIV, in which case it will be encrypted. I probably missed the issue?
Yes; I'll still need to update the PR to say the desired. We don't need to change anything about mechanism, but we should be explicit that the server MUST reply with an encrypted Repeat and a generated partial IV.
Sorry, still not clear: OSCORE now allows the use of server-generated Partial IV. The processing for Repeat is defined in the RRT-draft. Why does anything else need to change in the OSCORE draft?
Wrote the promised changes as it's much easier to talk with concrete text; the PR is now updated as 81d47927. This doesn't change any mechanism (at least not in implementations that are based on the current text and written in full awareness of all the relevant considerations). It is just a text change that prescribes what will be obvious to some implementors but not to others. (Especially since it's not so obvious as that I would have gotten it right in the first attempt.)
(This issue takes some context from issue ). The current draft states that replay protection violation triggers a 5.03 with Max-Age 0 (Section 6.4). While this is a practical solution to issue (which is not mitigated by encrypting the code because FETCH is still safe), it could still be caught by a proxy that'd try to be smart about it (and would, AFAICT, be within its rights). I suggest that the response code be 4.01 Unauthorized with Max-Age=0. The semantics of Unauthorized are "SHOULD NOT repeat the request without first improving its authentication status to the server", and while it's a bit of a stretch to say that increasing the sequence number is sufficient to improve the authentication status, the Max-Age gives a good hint ("Come on, try again right away, don't look for other keys"), and clients can use the presence of the Max-Age option as a discriminator to tell "Sorry, no such context" apart from "Retry with a new seqno".
We also just identified this response code as not appropriate. The proposal is good, unless it results in overloading the semantics of Max-Age=0. There is already at least one requirement when Max-Age has to be zero: RFC7252, Section 5.6.1: "If an origin server wishes to prevent caching, it MUST explicitly include a Max-Age Option with a value of zero seconds." Is there a setting where the the server would not want the response 4.01 to be cached even though it is not a replay? (Obviously we have to differentiate between Inner and Outer 4.01, but is that enough?)
I don't know. I briefly thought about using an Echo here, but an HTTP proxy would react to that as a CoAP proxy would to 5.03,Max-Age=0. (See comments 2ff). I did give that some thought, and considering the Echo option thought about whether the server should just reply with an encrypted ,Max-Age=0 (or Echo=short). I decided against suggesting that because responding to a possibly fraudulent message with an owned partial IV means that any adversary that has one valid-but-used message can thus drive any server into partial-IV exhaustion.
By the way, just FYI, that Max-Age=0 with 5.03 means "service unavailable, retry in 0 seconds", which is wrong (and not what we want). (see: URL)
The current text where there MAY be a Max-Age of 0 both on "4.01, Security context not found" and on "4.01, Security context not found" means that a client can not know any more which is the case (and it should not look into the message). I see the reason for the MAY set Max-Age for most error cases in , but a client needs to keep those apart (otherwise it'd need to so something like try 3 times with a new PIV, and if the server still responds the same, assume that it doesn't know the KID). I suggest that for those two responses, the Max-Age values are enforced as "MUST NOT set a Max-Age option" and "MUST set the Max-Age option to 0", or find any other discriminator, but an implementation should be able to tell them apart.
Granted, with the current setup of POST and FETCH there are much fewer cases where replay protection errors can happen (they'd only legally happen under particular package loss situations when starting an observation via a proxy that does not support observation but does do optimizations for safe requests), but I still think that there'd be more clarity if there were a discriminant between the two error cases.
The document, as of now, specifies that Partial IV SHOULD NOT be present in responses without observe. (This refer to: https://core-URL ) The processing for protecting and verifying responses, as of now, specifies that: if Observe -> use the Partial IV in the response if not Observe -> use Partial IV of the request Should this part be changed to: if Partial IV present in the message -> use that Partial IV if not present -> use Partial IV of the request
Need to read text, but this reflects what I wanted to see.
Sorry NAME when you say "this" do you mean That's not currently included (so no text about it yet). The text right now is:
I was talking about the should change to
Section 5 - You have defined a 'sid' and said that it could be placed in the unprotected field, however you have also said that the unprotected field must be empty. These statements are contradictory
As per Christian Amsüss' message from 2017-01-05 there still seems to be confusing text in that section.
Answering both to NAME and NAME (URL) The point here is: when defining the 'sid' as a new COSE Header parameter, there is no reason related to security that would make this a "MUST be placed in the protected bucket", so instead it is a MAY. But when used in OSCOAP, the 'sid' is used in a way that it MUST be in the protected part, so the unprotected SHALL be empty. The 'sid' is analogous to 'kid' from this point of view, it is defined as a COSE parameter that MAY be unprotected, but is used protected.
Multicast removed in branch v-02 Hello OSCOAP authors, some more questions came up: 5.2 gives the context for the Encstructure as "Encrypted", while cose-msg-24 would set a "Encrypt0". Why does that differ here? states that the '"unprotected" field [...] SHALL be empty', but above states that sid 'can be placed in the unprotected headers bucket'. How do those statements go together? How are sequence numbers (which are sorted integers) mapped to partial IVs? Which endianness is used? (The padding direction follows from cose-msg-24 3.1). I'd assume (and implement) that big-endian is used because it aligns naturally with COSE's left-padding, but as I see it, that does not strictly follow from the draft. I concluded that the tag is always the last bytes of the ciphertext from example A.4, but did not find text in the spec to support that; what made me especially unsure about this is that the COSEEncrypt0 definition of cose-msg-24 5.2 only mentions the ciphertext there, which may be nil. Best regards Christian To use raw power is to make yourself infinitely vulnerable to greater powers. -- Bene Gesserit axiom

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  <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.


4.1.3.4. Observe RFC7641 is an optional feature.  An implementation MAY <del> support RFC7252 and the OSCORE option without supporting RFC7641. </del>  The Observe option as used here targets the requirements on forwarding of I-D.hartke-core-e2e-security-reqs (Section 2.2.1). <del> To support proxy operations, OSCORE MUST set Outer Observe.  If Observe was only sent encrypted end-to-end, an OSCORE-unaware proxy would not expect several responses to a request and notifications would not reach the endpoint.  Moreover, intermediaries are allowed to cancel observations at any time; forbidding this behavior would also result in notifications being dropped. An intermediary that supports Observe MUST copy the OSCORE option in the next hop request unchanged.  It is worth noting that although intermediaries are allowed to re-send notifications to other clients, when using OSCORE this does not happen, since requests from different clients will have different cache keys. </del>  In case of registrations or re-registrations, the CoAP client using Observe with OSCORE MUST set both Inner and Outer Observe to the same value (0).  This allows the server to verify that the observation was <del> requested by the client, thereby avoiding unnecessary overhead (processing and transmission of notifications) on the server, since such notifications would not benefit the client. Note that, as defined in Section 3.1 of RFC7641, the target resource for Observe registration is identified by all options in the request that are part of the Cache-Key, including OSCORE.  This means that several clients registering to the same protected resource via an intermediary, when using OSCORE, will be effectively registering to different target resources.  The intermediary may then register to the protected resource (different target resources) once per each client. The processing of the CoAP Code for Observe messages is described in coap-header. </del>  The Outer Observe option in the CoAP request may be legitimately <del> removed by a proxy or ignored by the server.  In these cases, the </del>  server processes the request as a non-Observe request and produce a non-Observe response.  If the OSCORE client receives a response to an Observe request without an Outer Observe value, then it verifies the

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.

4.1.3.4. Observe RFC7641 is an optional feature.  An implementation MAY  <ins> support RFC7252 and the OSCORE option without supporting RFC7641, in which case the Observe related processing specified in this section, sequence-numbers and processing can be omitted. </ins> The Observe option as used here targets the requirements on forwarding of I-D.hartke-core-e2e-security-reqs (Section 2.2.1).  <ins> This section specifies Observe processing associated to the Partial IV (observe-partial-iv) and Observe processing in the presence of RFC7641-compliant intermediaries (observe-option-processing). In contrast to e.g. block-wise, the Inner and Outer Observe option are not processed independently.  Outer Observe is required to support Observe operations in intermediaries, but the additional use of Inner Observe is needed to protect Observe registrations end-to- end (see observe-option-processing). observe-without-intermed specifies a simplified Observe processing which is applicable in the absence of intermediaries. Note that OSCORE is compliant with the requirement that a client must not register more than once for the same target resource (see Section 3.1 of RFC7641) since the target resource for Observe registration is identified by all options in the request that are part of the Cache-Key, including OSCORE. 4.1.3.4.1. To support proxy operations, the CoAP client using Observe with OSCORE MUST set Outer Observe.  If Observe was only sent encrypted end-to-end, an OSCORE-unaware proxy would not expect several responses to a non-Observe request and notifications would not reach the client.  Moreover, intermediaries are allowed to cancel observations and inform the server; forbidding this may result in processing and transmission of notifications on the server side which do not reach the client. </ins> In case of registrations or re-registrations, the CoAP client using Observe with OSCORE MUST set both Inner and Outer Observe to the same value (0).  This allows the server to verify that the observation was  <ins> requested by the client, thereby avoiding unnecessary processing and transmission of notifications, since such notifications would not benefit the client. An intermediary that supports Observe MUST copy the OSCORE option in the next hop request unchanged.  Although intermediaries are allowed to re-send notifications to other clients, when using OSCORE this does not happen, since requests from different clients will have different cache keys. </ins> The Outer Observe option in the CoAP request may be legitimately  <ins> removed by a proxy or ignored by a server.  In these cases, the </ins> server processes the request as a non-Observe request and produce a non-Observe response.  If the OSCORE client receives a response to an Observe request without an Outer Observe value, then it verifies the


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>  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

Outer Observe value, it stops processing the message, as specified in ver-res.  <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>  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>  4.1.3.5.

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-  <ins> protection. </ins> Clients can re-register observations to ensure that the observation is still active and establish freshness again (RFC7641  <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>  The other currently defined CoAP Header fields are Unprotected (Class U).  The sending endpoint SHALL write all other header fields of the

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  <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>  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>  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

Additionally to the previous section, the following applies when Observe is supported.  <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  <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.  7.5. To prevent reuse of an AEAD nonce with the same key, or from

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.  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>  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>  Otherwise, discard both the Outer and Inner (if present) <del> Observe options. </del>  <del> If the value of Observe in the Outer message is not 0, discard </del>  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

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:  <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,  <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)  <ins> Observe options and verify the 'Partial IV' parameter using the Replay Window, as described in replay-protection. </ins>  <ins> If the value of Observe in the Outer message is not 0, discard the </ins> decrypted Observe option if present.  8.3. If a CoAP response is generated in response to an OSCORE request, the


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

Number by one.  Compute the AEAD nonce from the Sender ID, Common IV, and Partial IV.  8.4. A client receiving a response containing the OSCORE option SHALL


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>  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>  4.1.3.2.

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.

options. An Outer Max-Age message field is used to avoid unnecessary caching  <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  <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>  Intermediaries are not assumed to have access to the OSCORE security context used by the endpoints, and thus cannot make requests or

Solves issue (from review comments by NAME : URL)
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.
Another case to make sure that works Client - please cancel my observation Server - I don't have an observation for you, but sure I am willing to tell you I canceled it. What request PIV would I use in the AAD?
Yes, the verification of cancellation would fail since the server does not have the initial registration's partial iv saved, if it does not have the observation stored. So OSCORE would fail, which is not right. We have reverted to previous version (request_piv is not exception for cancellations) in c94314321 , but we want to add some security considerations about Observe and cancellations before closing this issue. 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.

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  <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>  options: contains the Class I options (see outer-options) present in the original CoAP message encoded as described in Section 3.1

the request (see cose-object). request_piv: contains the value of the 'Partial IV' in the COSE  <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


Abstract This memo defines Object Security of CoAP (OSCOAP), a method for <del> application layer protection of message exchanges with the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE) format.  OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure binding between CoAP request and response messages.  The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this memo. </del>  1. <del> The Constrained Application Protocol (CoAP) RFC7252 is a web application protocol, designed for constrained nodes and networks RFC7228.  CoAP specifies the use of proxies for scalability and efficiency.  At the same time CoAP references DTLS RFC6347 for security.  Proxy operations on CoAP messages require DTLS to be terminated at the proxy.  The proxy therefore not only has access to the data required for performing the intended proxy functionality, but is also able to eavesdrop on, or manipulate any part of the CoAP payload and metadata, in transit between client and server.  The proxy can also inject, delete, or reorder packages without being protected or detected by DTLS. </del>  This memo defines Object Security of CoAP (OSCOAP), a data object based security protocol, protecting CoAP message exchanges end-to- end, across intermediary nodes.  An analysis of end-to-end security for CoAP messages through intermediary nodes is performed in I- D.hartke-core-e2e-security-reqs, this specification addresses the <del> forwarding case. </del>  <del> The solution provides an in-layer security protocol for CoAP which does not depend on underlying layers and is therefore favorable for providing security for "CoAP over foo", e.g.  CoAP messages passing over both unreliable and reliable transport I-D.ietf-core-coap-tcp- tls, CoAP over IEEE 802.15.4 IE I-D.bormann-6lo-coap-802-15-ie. </del>  OSCOAP builds on CBOR Object Signing and Encryption (COSE) I-D.ietf- <del> cose-msg, providing end-to-end encryption, integrity, and replay protection.  The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this memo.  The solution transforms an unprotected CoAP message into a protected CoAP message in the following way: the unprotected CoAP message is protected by including payload (if present), certain options, and header fields in a COSE object.  The message fields that have been encrypted are removed from the message whereas the Object-Security option and the COSE object are added.  We call the result the "protected" CoAP message.  Thus OSCOAP is a security protocol based on the exchange of protected CoAP messages (see oscoap-ex). OSCOAP provides protection of CoAP payload, certain options, and header fields, as well as a secure binding between CoAP request and response messages.  OSCOAP provides replay protection, but like DTLS, OSCOAP only provides relative freshness in the sense that the sequence numbers allows a recipient to determine the relative order of messages.  For applications having stronger demands on freshness (e.g. control of actuators), OSCOAP needs to be augmented with mechanisms providing absolute freshness I-D.mattsson-core-coap- actuators. </del>  OSCOAP may be used in extremely constrained settings, where DTLS cannot be supported.  Alternatively, OSCOAP can be combined with

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.

Abstract This memo defines Object Security of CoAP (OSCOAP), a method for  <ins> application layer protection of the Constrained Application Protocol (CoAP), using the CBOR Object Signing and Encryption (COSE).  OSCOAP provides end-to-end encryption, integrity and replay protection to CoAP payload, options, and header fields, as well as a secure message binding.  OSCOAP is designed for constrained nodes and networks and can be used across intermediaries and over any layer.  The use of OSCOAP is signaled with the CoAP option Object-Security, also defined in this memo. </ins> 1.  <ins> The Constrained Application Protocol (CoAP) is a web application protocol, designed for constrained nodes and networks RFC7228.  CoAP specifies the use of proxies for scalability and efficiency.  At the same time CoAP RFC7252 references DTLS RFC6347 for security.  Proxy operations on CoAP messages require DTLS to be terminated at the proxy.  The proxy therefore not only has access to the data required for performing the intended proxy functionality, but is also able to eavesdrop on, or manipulate any part of the CoAP payload and metadata, in transit between client and server.  The proxy can also inject, delete, or reorder packages without being protected or detected by DTLS. </ins> This memo defines Object Security of CoAP (OSCOAP), a data object based security protocol, protecting CoAP message exchanges end-to- end, across intermediary nodes.  An analysis of end-to-end security for CoAP messages through intermediary nodes is performed in I- D.hartke-core-e2e-security-reqs, this specification addresses the  <ins> forwarding case.  In addition to the core features defined in RFC7252, OSCOAP supports Observe RFC7641 and Blockwise RFC7959. </ins>  <ins> OSCOAP is designed for constrained nodes and networks and provides an in-layer security protocol for CoAP which does not depend on underlying layers.  OSCOAP can be used anywhere that CoAP can be used, including unreliable transport RFC7228, reliable transport I- D.ietf-core-coap-tcp-tls, and non-IP transport I-D.bormann-6lo-coap- 802-15-ie. </ins> OSCOAP builds on CBOR Object Signing and Encryption (COSE) I-D.ietf-  <ins> cose-msg, providing end-to-end encryption, integrity, replay protection, and secure message binding.  The use of OSCOAP is signaled with the CoAP option Object-Security, defined in obj-sec- option-section.  OSCOAP provides protection of CoAP payload, certain options, and header fields.  The solution transforms an unprotected CoAP message into a protected CoAP message in the following way: the unprotected CoAP message is protected by including payload (if present), certain options, and header fields in a COSE object.  The message fields that have been encrypted are removed from the message whereas the Object-Security option and the COSE object are added, see oscoap-ex. </ins> OSCOAP may be used in extremely constrained settings, where DTLS cannot be supported.  Alternatively, OSCOAP can be combined with


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>  2.

meanings. Readers are expected to be familiar with the terms and concepts  <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>  The Sender Context contains the following parameters:

, 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

use for encryption.  Its value is immutable once the security context is established.  <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>  3.2.

messages received. The 3-tuple (Cid, Sender ID, Partial IV) is called Transaction  <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.


Context Identifier (Cid) <del> Base Key (master_secret) </del>  The following input parameters MAY be pre-established.  In case any of these parameters is not pre-established, the default value

Context Identifier (Cid)  <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


Defaults are 0x01 for the endpoint initially being client, and 0x00 for the endpoint initially being server  Key Derivation Function (KDF) Default is HKDF SHA-256

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


where: <del> master_secret is defined above </del>  <del> salt is a string of zeros of the length of the hash function output in octets </del>  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>  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>  3.2.2.

where:  <ins> salt is the Master Salt as defined above </ins>  <ins> IKM is the Master Secret is defined above </ins> info is a serialized CBOR array consisting of:  <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  <ins> I-D.ietf-cose-msg) is used, L is 16 bytes for keys and 7 bytes for IVs. </ins> 3.2.2.


5. <del> This section defines how to use the COSE format I-D.ietf-cose-msg to wrap and protect data in the unprotected CoAP message.  OSCOAP uses the COSE_Encrypt0 structure with an Authenticated Encryption with Additional Data (AEAD) algorithm. </del>  The AEAD algorithm AES-CCM-64-64-128 defined in Section 10.2 of I- D.ietf-cose-msg is mandatory to implement.  For AES-CCM-64-64-128 the <del> length of Sender Key and Recipient Key SHALL be 128 bits, the length of nonce, Sender IV, and Recipient IV SHALL be 7 bytes, and the maximum Sequence Number SHALL be 2^56-1.  The nonce is constructed as described in Section 3.1 of I-D.ietf-cose-msg, i.e. by padding the Partial IV (Sequence Number in network byte order) with zeroes and XORing it with the context IV (Sender IV or Recipient IV). Since OSCOAP only makes use of a single COSE structure, there is no need to explicitly specify the structure, and OSCOAP uses the untagged version of the COSE_Encrypt0 structure (Section 2. of I- D.ietf-cose-msg).  If the COSE object has a different structure, the recipient MUST reject the message, treating it as malformed. </del>  We denote by Plaintext the data that is encrypted and integrity protected, and by Additional Authenticated Data (AAD) the data that <del> is integrity protected only, in the COSE object. The fields of COSE_Encrypt0 structure are defined as follows (see example in sem-auth-enc). </del>  <del> The "Headers" field is formed by: </del>  <del> The "protected" field, which SHALL include: </del>  <del> The "Partial IV" parameter.  The value is set to the Sender Sequence Number.  The Partial IV is a byte string (type: bstr), and SHOULD be of minimum length needed to encode the sequence number. </del>  <del> The "kid" parameter.  The value is set to the Sender ID (see sec-context-section). </del>  <del> The "unprotected" field, which SHALL be empty. </del>  The "ciphertext" field is computed from the Plaintext (see plaintext) and the Additional Authenticated Data (AAD) (see AAD) <del> and encoded as a byte string (type: bstr), following Section 5.2 of I-D.ietf-cose-msg. </del>  5.1. The Plaintext is formatted as a CoAP message without Header (see plaintext-figure) consisting of: <del> all CoAP Options present in the unprotected message which are encrypted (see coap-headers-and-options), in the order as given by the Option number (each Option with Option Header including delta to previous included encrypted option); and </del>  <del> the CoAP Payload, if present, and in that case prefixed by the one-byte Payload Marker (0xFF). </del>  5.2. <del> The Additional Authenticated Data ("Enc_structure") as described is Section 5.3 of I-D.ietf-cose-msg includes: the "context" parameter, which has value "Encrypted" </del>  <del> the "protected" parameter, which includes the "protected" part of the "Headers" field; the "external_aad" is a serialized CBOR array aad where the exact content is different in requests (external_aad_req) and responses (external_aad_resp).  It contains: ver: uint, contains the CoAP version number, as defined in Section 3 of code: uint, contains is the CoAP Code of the unprotected CoAP message, as defined in Section 3 of RFC7252. </del>  <del> alg: int, contains the Algorithm from the security context used for the exchange (see sec-context-def-section); </del>  <del> id : bstr, is the identifier for the endpoint sending the request and verifying the response; which means that for the endpoint sending the response, the id has value Recipient ID, while for the endpoint receiving the response, id has the value Sender ID. </del>  <del> seq : bstr, is the value of the "Partial IV" in the COSE object of the request (see Section 5). </del>  <del> tag-previous-block: bstr, contains the AEAD Tag of the message containing the previous block in the sequence, as enumerated by Block1 in the case of a request and Block2 in the case of a response, if the message is fragmented using a block option RFC7959. </del>  <del> The encryption process is described in Section 5.3 of I-D.ietf-cose- msg. </del>  6.

This Partly addresses
Clarify that maximum sequence number is algorithm dependant and define a formula for it.
May be simpler to just have a single structure for the externalaad. externalaad = [ ver : uint, code : uint, alg : int, id : bstr, seq : bstr, ? tag-previous-block : bstr ]
the "context" parameter, which has value "Encrypted" This should be "Encrypt0", but even better OSCOAP should just point to draft-ietf-cose-msg that already specifies this.
-00 Section 3.2.3 - You are getting ahead of yourself. The only way that the identifiers would not be unique would be if the sender and recipient collided. I do not know that this would be a problem and therefore talking about it makes no sense. I am assuming that this is supposed to have something to do with the multicast work that I have not looked at. If so it does not belong here but there.
Agree. I'll delete all text on group communication from the document.
Multicast removed in branch v-02

5.  <ins> This section defines how to use COSE I-D.ietf-cose-msg to wrap and protect data in the unprotected CoAP message.  OSCOAP uses the untagged COSE_Encrypt0 structure with an Authenticated Encryption with Additional Data (AEAD) algorithm.  The key lengths, IV lengths, and maximum sequence number are algorithm dependent.  The maximum sequence number SHALL be 2^(nonce length in bits - 1) - 1. </ins> The AEAD algorithm AES-CCM-64-64-128 defined in Section 10.2 of I- D.ietf-cose-msg is mandatory to implement.  For AES-CCM-64-64-128 the  <ins> length of Sender Key and Recipient Key is 128 bits, the length of nonce, Sender IV, and Recipient IV is 7 bytes, and the maximum Sequence Number is 2^55 - 1. The nonce is constructed as described in Section 3.1 of I-D.ietf- cose-msg, i.e. by padding the partial IV (Sequence Number in network byte order) with zeroes and XORing it with the context IV (Sender IV or Recipient IV).  The first bit in the Sender IV or Recipient IV SHALL be flipped in responses. </ins> We denote by Plaintext the data that is encrypted and integrity protected, and by Additional Authenticated Data (AAD) the data that  <ins> is integrity protected only. </ins>  <ins> The COSE Object SHALL be a COSE_Encrypt0 object with fields defined as follows </ins>  <ins> The "protected" field includes: </ins>  <ins> The "Partial IV" parameter.  The value is set to the Sender Sequence Number.  The Partial IV SHALL be of minimum length needed to encode the sequence number.  This parameter SHALL be present in requests, and MAY be present in responses. </ins>  <ins> The "kid" parameter.  The value is set to the Sender ID (see sec-context-section).  This parameter SHALL be present in requests. </ins>  <ins> The "unprotected" field is empty. </ins> The "ciphertext" field is computed from the Plaintext (see plaintext) and the Additional Authenticated Data (AAD) (see AAD)  <ins> following Section 5.2 of I-D.ietf-cose-msg. The encryption process is described in Section 5.3 of I-D.ietf-cose- msg. </ins> 5.1. The Plaintext is formatted as a CoAP message without Header (see plaintext-figure) consisting of:  <ins> all CoAP Options present in the unprotected message that are encrypted (see coap-headers-and-options).  The options are encoded as described in Section 3.1 of RFC7252, where the delta is the difference to the previously included encrypted option); and </ins>  <ins> the Payload of unprotected CoAP message, if present, and in that case prefixed by the one-byte Payload Marker (0xFF). </ins> 5.2.  <ins> The external_aad SHALL be a CBOR array as defined below: </ins>  <ins> where: </ins>  <ins> ver: uint, contains the CoAP version number, as defined in Section 3 of RFC7252. </ins>  <ins> code: uint, contains is the CoAP Code of the unprotected CoAP message, as defined in Section 3 of RFC7252. </ins>  <ins> alg: int, contains the Algorithm from the security context used for the exchange (see sec-context-def-section). </ins>  <ins> request_id : bstr, contains the identifier for the endpoint sending the request and verifying the response; which means that for the endpoint sending the response, the id has value Recipient ID, while for the endpoint receiving the response, id has the value Sender ID. </ins>  <ins> request_seq : bstr, contains the value of the "Partial IV" in the COSE object of the request (see Section 5). </ins> 6.


been changed, then the original value will already be in the OHB, so no update to the OHB is required.  5.3. To decrypt a packet, the endpoint first decrypts and verifies using

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.

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


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>  Feedback and discussion are welcome at https://github.com/quicwg/qlog [1].  Readers are advised to refer to the "editor's draft" at that

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

1. This document describes the values of the qlog name ("category" +  <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


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>  Feedback and discussion are welcome at https://github.com/quicwg/qlog [1].  Readers are advised to refer to the "editor's draft" at that

1. This document describes the values of the qlog name ("category" +  <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


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>  A server MUST respect the value it previously provided for the grease_quic_bit transport parameter if it accepts 0-RTT.  A client

Inappropriate use of MAY, lack of MUST [NOT]. Thanks to Russ Housley for schooling me on the correct usage.

treat receipt of a non-empty value as a connection error of type TRANSPORT_PARAMETER_ERROR.  <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


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>  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>  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

resulting in connection failures. A server MUST clear the QUIC bit only after processing transport  <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.  <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


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>  Furthermore, version 1 Initial packets are encrypted with keys derived from a universally known salt, which allow observers to

This uses kramdown tricks to make real links for the section references to RFC 9001 and uses a nicer label for those.

1.  <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


3. QUIC version 2 endpoints MUST implement the QUIC version 1 <del> specification as described in RFC9000, RFC9001, and RFC9002, with the </del>  following changes: The version field of long headers is TBD.  Note: Unless this

3. QUIC version 2 endpoints MUST implement the QUIC version 1  <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


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>  <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>  "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>  <del> The key and nonce used for the Retry Integrity Tag (Sec 5.8 of RFC9001) change to: </del>  4.

provisional value 0xff020000, which might change with each edition of this document.  <ins> The salt used to derive Initial keys in Section 5.2 of QUIC-TLS changes to: </ins>  <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  <ins> guidance for new versions in Section Section 9.6 of QUIC-TLS of that document. </ins>  <ins> The key and nonce used for the Retry Integrity Tag (Section 5.8 of QUIC-TLS) change to: </ins> 4.