]>

ietf@lenders.berlin

RISE AB

Isafjordsgatan 22 Kista 164 40 Sweden marco.tiloca@ri.se

Web and Internet Transport CoRE Working Group Internet-Draft In the Constrained Application Protocol (CoAP), protected requests allow the server to identify the client, also across different and unrelated data exchanges. This document defines Oblivious CoAP, which enables oblivious protected exchanges of CoAP messages for use cases where the identification of the client at the server is not desirable. Discussion Venues Discussion of this document takes place on the Constrained RESTful Environments Working Group mailing list (core@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction As in HTTP , protected requests in the Constrained Application Protocol (CoAP) can identify the client to the server. In HTTP, this can be prevented by using Oblivious HTTP . Although the ability of the server to identify the client is typically not a problem in CoAP, there are use cases where the identification of the client might not be desirable. For example:

• DNS over CoAP clients might want to hide their identity in a similar way as offered by Oblivious DNS over HTTP .
• A vendor might want to provide anonymous diagnostic reporting or telemetry transmission for their devices.
• Clients might want to securely perform anonymous queries at a well-known CoRE Resource Directory , for example to retrieve a number of proxy resources that are used to enable secure CoAP traffic with onion routing .

In these cases, even protecting CoAP messages with approaches based on CBOR Object Signing and Encryption (COSE) , such as Object Security for Constrained RESTful Environments (OSCORE) , is either not helpful or not efficient for hiding the client's identity from the server. In particular, such approaches require the client and the server to establish a long-term security context between each other (and potentially between themselves and multiple intermediary hops), which makes the same client identifiable by the server, also across different and unrelated data exchanges. Alternatively, the same client could use different identities to perform different runs of a full-fledged key establishment protocol for protecting different data exchanges with the server, which results in performance penalties. On the other hand, Oblivious HTTP uses Hybrid Public Key Encryption (HPKE) via a trusted Oblivious Relay Resource (effectively a proxy) that is not colluding with the server, in order to hide the client's identity from the server and obfuscate the data exchange from the perspective of the Oblivious Relay Resource. This document defines Oblivious CoAP, which brings the advantages of such an oblivious exchange to CoAP.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. Readers are expected to be familiar with the terms and concepts related to CoAP , OSCORE , Concise Data Definition Language (CDDL) , Concise Binary Object Representation (CBOR) , CBOR sequences , and HPKE . In addition, this document uses the following terms.

Original CoAP Request:

A CoAP request as specified in .

Original CoAP Response:

A CoAP response as specified in .

Oblivious CoAP Request:

An Original CoAP Request that is encapsulated in an HPKE-encrypted message, see . Cmp. "Encapsulated Request" in .

Oblivious CoAP Response:

An Original CoAP Response that is encapsulated in an HPKE-encrypted message, see . Cmp. "Encapsulated Response" in .

Oblivious CoAP Client:

An Oblivious CoAP Client originates Oblivious CoAP Requests. It is a client for both the Oblivious Gateway Resource and the Target Resource. When referring to a general CoAP Client as defined in , the term "CoAP Client" is used.

Oblivious Proxy Resource:

A forward-proxy as specified in and acting as an intermediary between the Oblivious CoAP Client and a single Oblivious Gateway Resource. Cmp. "Oblivious Relay Resource" in .

Oblivious Gateway Resource:

A CoAP resource as defined in that can handle Oblivious CoAP Requests, dispatch the corresponding encapsulated Original CoAP Requests to a Target Resource, receive Original CoAP Responses therefrom, and encapsulate those responses in Oblivious CoAP Responses. Cmp. "Oblivious Gateway Resource" in .

Target Resource:

The resource that is the target of the Original CoAP Request. It is typically not able to handle Oblivious CoAP Requests or Oblivious CoAP Responses, so Oblivious CoAP is transparent to it. However, it could still be able to handle otherwise encrypted requests and responses such as those protected with OSCORE . Cmp. "Target Resource" in .

Overview In the same spirit as Oblivious HTTP , an Oblivious CoAP Client needs to know the following:

• Information to reach an Oblivious Gateway Resource, which in turn might include information about the Target Resource.
• A key configuration, including:
  • The HPKE public key of the Oblivious Gateway Resource and the key identifier associated with that public key.
  • The set of HPKE algorithms to use with the Oblivious Gateway Resource.
• Information to reach an Oblivious Proxy Resource that for all intent and purposes is a CoAP forward-proxy (see ), which forwards Oblivious CoAP Requests to the Oblivious Gateway Resource and returns the resulting Oblivious CoAP Responses to the Oblivious CoAP Client.

With that information, the Oblivious CoAP Client is able to compose a protected Oblivious CoAP Request intended for the Oblivious Gateway Resource, send the Oblivious CoAP Request to the Oblivious Gateway Resource via the Oblivious Proxy Resource, and decrypt and verify the corresponding protected Oblivious CoAP Response composed by the Oblivious Gateway Resource. Since the Oblivious Proxy Resource does not indicate the client's addressing information in the forwarded Oblivious CoAP Request, the Oblivious Gateway Resource does not gain knowledge of the client's identity and is unable to associate different unrelated requests from the Oblivious CoAP Client, due to the use of different HPKE contexts across different and unrelated data exchanges. Furthermore, since the Oblivious Proxy Resource does not know the HPKE private key of the Oblivious Gateway Resource, the Oblivious Proxy Resource cannot create the HPKE context that is necessary for decrypting the Oblivious CoAP Requests and Responses that are sent to and from the Oblivious Gateway Resource.

Overview of Oblivious CoAP | Oblivious | | | | CoAP Request | | | +------------------->| Original | | | | CoAP Request | | | +-------------->| | | | | | | | Original | | | | CoAP Response | | | Oblivious |<--------------+ | | CoAP Response | | | Oblivious |<-------------------+ | | CoAP Response | | | |<----------------+ | | | | | | ]]>

provides an overview of the steps of Oblivious CoAP. Readers familiar with Oblivious HTTP will notice the strong similarities to Figure of and the steps described in . Compared to the steps of Oblivious HTTP, there are only minor differences in the steps of Oblivious CoAP, which are outlined below.

1. The Oblivious CoAP Client (Client) composes the Original CoAP Request for a Target Resource, e.g., as described in or .
2. Using HPKE with a known key configuration (see ) and according to the process described in , the Client produces a protected Oblivious CoAP Request from the Original CoAP Request.
3. The Client sends the Oblivious CoAP Request to the Oblivious Proxy Resource (Proxy Resource).
4. The Proxy Resource forwards the Oblivious CoAP Request to the Oblivious Gateway Resource (Gateway Resource).
5. The Gateway Resource receives the Oblivious CoAP Request, processes it using HPKE with its key configuration, and obtains the Original CoAP Request as a result.
6. The Gateway Resource provides the Original CoAP Request to the Target Resource.

The Gateway Resource and the Target Resource could be hosted at different servers or instead at the same server as shown in , in which case the Target Resource could even be the same as the Gateway Resource. The following refers to the "server" as the CoAP endpoint at which both the Gateway Resource and the Target Resource are hosted. Once the Gateway Resource receives the Original CoAP Response from the Target Resource, it sends the response as a reply to the Client according to the following steps:

1. Using the receiving HPKE context generated from the Oblivious CoAP Request, the Gateway Resource composes an Oblivious CoAP Response from the Original CoAP Response and sends it to the Proxy Resource.
2. The Proxy Resource forwards the Oblivious CoAP Response back to the Client.
3. The Client receives the Oblivious CoAP Response, processes it using the sending HPKE context generated for the Oblivious CoAP Request, and produces the Original CoAP Response as a result.

When a CoAP request/response is specifically an Oblivious CoAP Request/Response, it includes the OCoAP Option defined in . In addition to single data exchanges like the one discussed above, CoAP supports exchanges where one or more requests can lead to one or more responses. Non-exhaustively, these include:

• The use of CoAP Observe , for a client to register its interest in receiving unsolicited notification responses from a server, following changes in the representation of a resource at the server. Effectively, this results in one long-standing request followed by multiple related responses.
• The use of CoAP block-wise transfer , for a client and a server to split a large "body" of data into different blocks, each of which is sent as the payload of one request or response. Effectively, this results in a sequence of requests/responses that are related to the transfer of the same body of data from the client/server.

To support these exchanges, Oblivious CoAP provides a way to process these multiple, related requests and responses using the same HPKE context, according to information conveyed by the OCoAP Option.

Comparison to Oblivious HTTP Similar to Oblivious HTTP , Oblivious CoAP has only limited applicability, as it requires support from a willing Oblivious Gateway Resource, which prevents Oblivious CoAP from being used in generic applications. Notably, however, the Oblivious Proxy Resource can be any CoAP forward-proxy that can reach the Oblivious Gateway Resource. In contrast to Oblivious HTTP, Oblivious CoAP does not use a signaling Content-Format, which would bloat the IANA Content-Format registry. Rather, in the same spirit of the OSCORE security protocol, which relies on the OSCORE Option (see ), Oblivious CoAP uses a signaling OCoAP Option (see ), which also conveys information for the correct processing of multiple, related requests and responses using the same HPKE context (see ). Oblivious CoAP is intentionally similar to Oblivious HTTP and usable with generic CoAP forward-proxies, in order to allow for potential Oblivious-CoAP-to-Oblivious-HTTP proxies. These are, however, application-specific and thus out of scope for this document.

Comparison to OSCORE The security protocol OSCORE builds on COSE and provides end-to-end protection of CoAP messages between a client and a server, also in the presence of (untrusted) intermediary proxies from which as much information as possible is hidden by encryption. In contrast to OSCORE, Oblivious CoAP has the advantage that the server cannot correlate two protected requests from the same client, unless that is desired by the client (see ). Similar to OSCORE, which relies on the OSCORE Option, Oblivious CoAP relies on the OCoAP Option and thus avoids signaling an Oblivious-CoAP-related Content-Format, while hiding the Content-Format of the Original CoAP Request/Response by encrypting it when producing the Oblivious CoAP Request/Response. Since the key exchange and message protection are left to HPKE, the OCoAP Option can be even simpler: As the same HPKE context could be used to produce multiple, related Oblivious CoAP Requests/Responses (see ), the OCoAP Option value identifies the HPKE context used and allows the two endpoints to count the Oblivious CoAP Requests/Responses produced with that context. When using Oblivious CoAP, a field of an Original CoAP Request/Response is protected to achieve the same security level that is achieved by OSCORE when protecting that field (see ), which results in the same security and privacy implications as in OSCORE (see Sections and of ). For example, this applies to the protection of CoAP options, which occurs according to the same classes defined for OSCORE (see ).

Key Configuration A key configuration can be encoded as defined in . A collection of such key configurations can be distributed using the media type "application/ohttp-keys", potentially through CoAP messages with the corresponding Content-Format registered in . Alternatively, a key configuration can be expressed in an extensible CBOR map that includes the following elements:

• key_id, with map key 0 encoded as a CBOR unsigned integer. The value of this element is a CBOR unsigned integer that encodes the key identifier of the HPKE public key of the Oblivious Gateway Resource. The key identifier is of 8-bit maximum length.
• kem_id, with map key 1 encoded as a CBOR unsigned integer. The value of this element is a CBOR unsigned integer that encodes an HPKE Key Encapsulation Mechanism (KEM) identifier (see also Sections and of ). The HPKE KEM identifier is of 16-bit maximum length.
• public_key, with map key 2 encoded as a CBOR unsigned integer. The value of this element is a CBOR byte string that encodes the HPKE public key of the Oblivious Gateway Resource. The length of the public key is Npk bytes.
• A set of HPKE symmetric algorithms, with map key 3 encoded as a CBOR unsigned integer. The value of this element is a non-empty CBOR array whose elements are organized into consecutive pairs. Each pair consists of the following elements:
  • kdf_id, a CBOR unsigned integer that encodes an HPKE Key Derivation Function (KDF) identifier of 16-bit maximum length (see also Sections and of ).
  • aead_id, a CBOR unsigned integer that encodes an HPKE Authenticated Encryption with Additional Data (AEAD) identifier of 16-bit maximum length (see also Sections and of ).

shows the CDDL notation of the CBOR-encoded HPKE key configuration. Later specifications can extend the CBOR map via the $$ocoap-key-config extension point.

Format of the CBOR-encoded HPKE Key Configuration key_id, kem_id_key => kem_id, public_key_key => public_key, hpke_symmetric_algorithm_key => [ +hpke_symmetric_algorithm ], ) ]]>

A collection of key configurations of type ocoap-key-config can be distributed using the media type "application/ocoap-keys+cbor-seq" registered in , potentially through CoAP messages with the corresponding Content-Format registered in . In particular, the media type "application/ocoap-keys+cbor-seq" denotes the binary encoding of a CBOR sequence , where each element of the sequence is a CBOR map representing a key configuration of type ocoap-key-config. An Oblivious CoAP Client that receives an "application/ocoap-keys+cbor-seq" object with encoding errors might be able to recover one or more key configurations. Differences in how key configurations are recovered might be exploited to segregate Clients, so Clients MUST discard incorrectly encoded key configuration collections.

The OCoAP Option Oblivious CoAP Requests and Responses include the Oblivious CoAP Option (OCoAP Option) defined in this section. The OCoAP Option has the properties summarized in , which extends Table of . The option is Critical, Safe-to-Forward, part of the Cache-Key, and not repeatable. The OCoAP Option. C=Critical, U=Unsafe, N=NoCacheKey, R=Repeatable

No.	C	U	N	R	Name	Format	Length	Default
TBD	x				OCoAP	(*)	0-255	(none)

(*) If the length of the option value is greater than 0, the OCoAP Option value has the format shown in . The value of the non-empty OCoAP Option SHALL contain the OCoAP flag bits, the count parameter, and the id_ctx parameter as follows:

The Non-Empty OCoAP Option Value +-+-+-+-+-+-+---+-------------------+-----------------+ |0 0 0 0 0|c| n | count | id_ctx (if any) | +-+-+-+-+-+-+---+-------------------+-----------------+ ]]>

• The first byte, containing the OCoAP flag bits, encodes the following set of bits and the length of the count parameter in the option value:
  • The two least significant bits encode the unsigned integer n, which is the count length in bytes minus 1.
  • The third least significant bit c is the ID Context flag. It is set to 1 if and only if id_ctx is present in the option value.
  • The fourth-to-eighth least significant bits are reserved for future use. These bits SHALL be set to zero when not in use. According to this specification, if any of these bits are set to 1, the message is considered to be malformed and the processing of the OCoAP Option fails.
  The OCoAP flag bits are registered in the "OCoAP Flag Bits" registry defined in .
• The following n+1 bytes encode the value of the count parameter as an unsigned integer in network byte order. In an Oblivious CoAP Request/Response, count is the number of Oblivious CoAP Requests/Responses that have been protected before the present one by using the same HPKE context. That is, count=0 marks the first Oblivious CoAP Request/Response protected with a given HPKE context. The Oblivious CoAP Client and the Oblivious Gateway Resource use two 32-bit unsigned integer counters to keep track of count, separately for the Oblivious CoAP Requests and the Oblivious CoAP Responses protected with a given HPKE context. Since n in the OCoAP Option value can be at most 3, this leaves enough room to represent the value of count as a 32-bit unsigned integer.
• The remaining bytes encode the value of the id_ctx parameter, if the c flag is set (c=1). The value of id_ctx is an opaque identifier of the HPKE context used for processing the present Oblivious CoAP message.

Note that id_ctx MUST be the last field of the OCoAP Option value if c=1, even in the case in which reserved bits are used and additional fields are added to it. If the OCoAP Option value is empty, i.e., its length is 0, then it is assumed that count=0 and c=0, i.e., the empty value is equivalent to the OCoAP Option value 0x0000. The length of the OCoAP Option value thus depends on the presence and length of count and id_ctx as specified in this section, and on the presence and length of additional parameters, as defined in future documents registering those parameters. The length of the OCoAP Option value MUST NOT exceed 255 bytes. To avoid the OCoAP Option value being larger than necessary, the following applies:

• If the OCoAP flag bits consist of a single byte 0x00 and count=0, the sender endpoint SHOULD set the value of the OCoAP Option to empty. Otherwise,
• The sender endpoint SHOULD use the shortest possible length for count. That is, a count value between 0 and 255 SHOULD be encoded in 1 byte (n=0), a count value between 256 and 65535 SHOULD be encoded in 2 bytes (n=1), and so on.

The OCoAP Option is of Class I for OSCORE and is accordingly processed by OCoAP (see ). That is, the OCoAP Option is included in the associated data aad when processing an Oblivious CoAP Request/Response, consistent with what is recommended in (see also and of the present document).

Oblivious CoAP Request An Oblivious CoAP Request uses the method POST or FETCH , includes the OCoAP Option (see ), and conveys a payload. The format of the payload depends on the count value specified by the OCoAP Option. If count=0, including when the OCoAP Option has empty value, the payload is the concatenation of:

• The key identifier key_id from the key configuration used to protect the Original CoAP Request (see ), as an 8-bit unsigned integer.
• The HPKE KEM identifier kem_id from the same key configuration, as a 16-bit unsigned integer.
• One of the HPKE KDF identifiers kdf_id from the KDF-AEAD identifier pairs from the same key configuration, as a 16-bit unsigned integer.
• The HPKE AEAD identifier aead_id that is paired with the kdf_id above in the KDF-AEAD identifier pairs from the same key configuration, as a 16-bit unsigned integer.
• The encapsulated KEM shared secret enc that is produced when computing the HPKE context used to protect the Original CoAP Request. The length of enc is equal to Nenc bytes and is defined by the Encap() function of the HPKE KEM identified by kem_id (see ).
• The HPKE ciphertext ct produced when protecting the Original CoAP Request.

The length of ct can be derived by subtracting 7 bytes (for the enclosed identifiers) and Nenc bytes (for enc) from the CoAP payload length. This construct is equivalent to the Encapsulated Request structure defined in . If count>0, the payload is the HPKE ciphertext ct produced when protecting the Original CoAP Request.

Request Construction at the Client To construct an Oblivious CoAP Request from the Original CoAP Request, the Oblivious CoAP Client (Client) first picks the following values from the key configuration used:

• The key identifier key_id and the corresponding kem_id.
• The public key public_key identified by key_id, i.e., the static public key of the Oblivious Gateway Resource.
• A pair of KDF algorithm (identified by kdf_id) and AEAD algorithm (identified by aead_id) from the symmetric algorithm collection in the key configuration.

Using those parameters, the Client performs the following steps:

1. If the Original CoAP Request is the first request in the data exchange, compute a sending HPKE context sctxt by invoking the HPKE procedure SetupBaseS(pkR, info) (see ), where:
   • pkR takes public_key.
   • info takes the concatenation of: the ASCII-encoded string of the label "ocoap_request", the byte 0x00, key_id as an 8-bit unsigned integer, kem_id as a 16-bit unsigned integer, kdf_id as a 16-bit unsigned integer, and aead_id as a 16-bit unsigned integer. All these unsigned integers are in network byte order.
   The procedure returns the sending HPKE context sctxt and an encapsulated KEM shared secret enc. Specifically, enc is the ephemeral public key of the Client when using a KEM that is based on Diffie-Hellman (DH) or Non-Interactive Key Exchange (NIKE) primitives, or a KEM ciphertext otherwise. Then, set the 32-bit unsigned integer counter i for sctxt to 0. Set the 32-bit unsigned integer counter j for sctxt to not initialized. The identifier id_rctxt of the receiving HPKE context is unknown at this point. In a typical single-request-single-response exchange, the Original CoAP Request in the exchange is trivially the first one. Within an extended data exchange, the first Original CoAP Request can be, for example, an original Observe registration request , or a request conveying/requesting the first block of a block-wise transfer .
2. Ensure that the CoAP options in the Original CoAP Request specify the URI of the Oblivious Gateway Resource to which the Oblivious Proxy Resource will have to forward the Oblivious CoAP Request. (In general, the Oblivious Gateway Resource will interpret such a URI in order to forward the recovered Original CoAP Request to the Target Resource.) To this end, the Client can specify the URI as a string in the Proxy-Uri Option, or by using the Proxy-Scheme Option together with the Uri-* options (see ). Alternatively, the Client can rely on the analogous options defined in , i.e., the Proxy-Cri Option conveying a Constrained Resource Identifier (CRI) equivalent to the URI, or the Proxy-Scheme-Number Option together with the Uri-* options. When applicable, the Client can specify the URI path of the URI by using the Uri-Path-Abbrev Option , consistent with the restrictions defined in . Note that the URI path component and the URI query component are going to be encrypted when computing the Oblivious CoAP Request. Therefore, the CoAP server that receives the Oblivious CoAP Request can effectively rely only on the URI scheme and the URI authority component of the request URI, in order to identify the Oblivious Gateway Resource to which the Oblivious CoAP Request is addressed.
3. Compose an OCoAP Option such that:
   • count is set to the value of the counter i.
   • id_ctx is set to the identifier id_rctxt if that is known, or it is omitted otherwise.
   Then, encode the OCoAP Option value as defined in and add the OCoAP Option to the Original CoAP Request.
4. Construct the associated data aad as the concatenation of:
   • key_id as an 8-bit unsigned integer, kem_id as a 16-bit unsigned integer, kdf_id as a 16-bit unsigned integer, and aead_id as a 16-bit unsigned integer. All these unsigned integers are in network byte order.
   • The CoAP options of Class I for OSCORE that are present in the Original CoAP Request, which also include the OCoAP Option composed at Step 3. This set of options is encoded like the value of the CBOR byte string options in the aad_array of OSCORE (see ). That is, the Client needs to recalculate the Option Deltas of those options.
5. Construct the plaintext pt in the same manner as the plaintext is constructed in OSCORE (see ), i.e., as the concatenation of:
   • The 8-bit Code of the Original CoAP Request.
   • The CoAP options of Class E for OSCORE that are present in the Original CoAP Request, with their Option Deltas recalculated accordingly.
   • If a payload is present in the Original CoAP Request, a one-byte Payload Marker 0xff (see ) followed by the payload of the Original CoAP Request.
6. Invoke the Seal() method on sctxt (see ), providing the associated data aad from Step 4 as the first parameter and the plaintext pt from Step 5 as the second parameter. The Seal() method returns the ciphertext ct or an error on failure. If the method fails, the client MUST terminate this procedure.
7. Construct the Oblivious CoAP Request from the Original CoAP Request as follows:
   • Replace the Code with FETCH if the Original CoAP Request contains an Observe Option, or with POST otherwise.
   • Remove all the CoAP options of Class E for OSCORE and recalculate the Option Deltas of the remaining CoAP options (including the OCoAP Option added at Step 3).
   • Add a Payload Marker if the Original CoAP Request had no payload.
   • Remove the payload, if present in the Original CoAP Request.
   • Add the payload defined in , consistent with the values in the previous steps of the present procedure.
8. Increment the counter i for sctxt by 1.

Finally, the Client sends the Oblivious CoAP Request to the Oblivious Proxy Resource and retains the sending HPKE context sctxt. The Oblivious Proxy Resource then forwards the Oblivious CoAP Request to the Oblivious Gateway Resource (see ).

Request Processing at the Server When a CoAP server hosting an Oblivious Gateway Resource receives an Oblivious CoAP Request (i.e., a request that includes an OCoAP Option), the server performs the operations described in in reverse, as defined below.

1. The server reads the value of the OCoAP Option, from which it determines the value of count and of the flag bit c. As per , the empty option value is equivalent to the option value 0x0000, i.e., count=0 and c=0. Then, the server refers to the key configuration associated with the Oblivious Gateway Resource addressed by the Oblivious CoAP Request and proceeds as follows.
   • If count>0 and c=1, retrieve ct as the payload of the Oblivious CoAP Request. Then, move to Step 2.
   • If count=0 and c=0, parse the payload of the Oblivious CoAP Request into: key_id, kem_id, kdf_id, aead_id, enc, and ct. In particular, the four identifiers have a well-known, fixed length, the HPKE KEM identified by kem_id implies the length of enc, and ct is the remainder of the payload after enc. If key_id does not identify an HPKE public key of the server that matches the HPKE KEM identified by kem_id, the server MUST reply with a 4.00 (Bad Request) error response and MUST terminate this procedure. Otherwise, the server retrieves skR, i.e., its HPKE private key associated with the HPKE public key identified by key_id. If kdf_id and aead_id do not identify a KDF and AEAD algorithm pair that the server is willing to use with skR, the server MUST reply with a 4.00 (Bad Request) error response and MUST terminate this procedure. Otherwise, move to Step 2.
   • If none of the above applies, the server MUST reply with a 4.02 (Bad Option) error response and MUST terminate this procedure.
2. The server proceeds as follows, depending on the value of count.
   • If count=0, compute a receiving HPKE context rctxt by invoking the HPKE procedure SetupBaseR(enc, skR, info) (see ), where:
     • The first parameter takes the encapsulated KEM shared secret enc retrieved from the payload of the Oblivious CoAP Request.
     • The second parameter takes the HPKE private key skR of the server.
     • The third parameter info takes the same as the info parameter of the SetupBaseS() when invoked by the Oblivious CoAP Client at Step 1 of . In particular, the four HPKE identifiers are retrieved from the payload of the Oblivious CoAP Request.
     The procedure returns the receiving HPKE context rctxt. The server generates a unique binary identifier id_ctx and stores rctxt as associated with id_ctx. Then, the server sets a 32-bit unsigned integer counter k for rctxt to 0.
   • If count>0, the server retrieves id_ctx from the OCoAP Option of the Oblivious CoAP Request and uses it to retrieve the receiving HPKE context rctxt associated with id_ctx. If the server does not successfully retrieve a receiving HPKE context, the server MUST reply with a 4.00 (Bad Request) error response and MUST terminate this procedure.
3. Construct the associated data aad as described at Step 4 of , with the difference that the CoAP options of Class I to consider are those that are present in the received Oblivious CoAP Request.
4. Invoke the Open() method of the previously computed HPKE context rctxt (see ), providing the associated data aad from Step 3 as the first parameter and the ciphertext ct retrieved from the payload of the Oblivious CoAP Request as the second parameter. The Open() method returns the plaintext pt or an error on failure. If the method fails, the server MUST reply with a 4.00 (Bad Request) error response, MUST discard the Oblivious CoAP Request, and MUST terminate this procedure.
5. Parse pt into: the 8-bit Code of the Original CoAP Request, the CoAP options of Class E for OSCORE that were present in the Original CoAP Request, the one-byte Payload Marker 0xff (if present), and, if the Payload Marker 0xff is found, the payload of the Original CoAP Request. If the parsing fails, the server MUST reply with a 4.00 (Bad Request) error response.
6. Reconstruct the Original CoAP Request from the Oblivious CoAP Request as follows:
   • Replace the Code of the Oblivious CoAP Request with the Code from pt.
   • Remove the OCoAP Option from the Oblivious CoAP Request.
   • Add the CoAP options from pt and recalculate the Option Deltas of all the CoAP options in the updated option set.
   • Remove the Payload Marker 0xff and the payload from the Oblivious CoAP Request.
   • If the Payload Marker 0xff and a payload are present in pt, add those in the same order.

Finally, the server provides the Original CoAP Request to the Target Resource and retains the receiving HPKE context rctxt.

Oblivious CoAP Response An Oblivious CoAP Response has Response Code 2.04 (Changed) or 2.05 (Content), includes the OCoAP Option (see ), and conveys a payload. The format of the payload depends on the count value specified by the OCoAP Option. If count=0, including when the OCoAP Option has empty value, the payload is the concatenation of:

• A server-generated response_nonce of length max(Nn, Nk) bytes. The Nn and Nk values correspond to parameters of the AEAD used in HPKE, as per or the "HPKE AEAD Identifiers" IANA registry .
• The HPKE ciphertext ct produced when protecting the Original CoAP Response.

The length of ct can be derived by subtracting max(Nn, Nk) bytes from the CoAP payload length. This construct is equivalent to the Encapsulated Response structure defined in . If count>0, the payload is the HPKE ciphertext ct produced when protecting the Original CoAP Response.

Response Construction at the Server To construct an Oblivious CoAP Response from the Original CoAP Response received from the Target Resource, the server uses the receiving HPKE context rctxt that was used to process the corresponding Oblivious CoAP Request (see ). In particular, the server performs the following steps:

1. Retrieve the counter k for rctxt. If k>0, move to Step 7, otherwise move to Step 2.
2. Export a secret secret from rctxt, using the string "ocoap_response" as the exporter_context parameter for the Export interface of rctxt (see ). The length of secret is max(Nn, Nk), where Nn and Nk are the length of the AEAD nonce and key that are associated with rctxt.
3. Generate a random value of length max(Nn, Nk) bytes, called response_nonce.
4. Extract a pseudorandom key prk using the Extract function provided by the KDF algorithm associated with rctxt (see ). The ikm input to this function is secret from Step 2; the salt input is the concatenation of: the encapsulated KEM shared secret enc from the payload of the Original CoAP Request and response_nonce from Step 3.
5. Use the Expand function provided by the same KDF algorithm (see ) to create an AEAD key aead_key of length Nk bytes, i.e., the length of the keys used by the AEAD associated with rctxt. Generating aead_key uses the pseudorandom key prk from Step 4 as the prk parameter and the string "key" as the info parameter for the Expand function, respectively. Then, store aead_key in association with rctxt.
6. Use the same Expand function to create an AEAD Base IV aead_base_iv of length Nn bytes, i.e., the length of the nonces used by the AEAD associated with rctxt. Generating aead_base_iv uses the pseudorandom key prk from Step 4 as the prk parameter and the string "base_iv" as the info parameter for the Expand function, respectively. Then, store aead_base_iv in association with rctxt.
7. Compose an OCoAP Option such that:
   • count is set to the value of the counter k of rctxt.
   • id_ctx is set to the identifier id_rctxt of rctxt if both of the following conditions apply, or it is omitted otherwise.
     • k=0.
     • The server anticipates that, after the present first Oblivious CoAP Response under construction, it might send further Oblivious CoAP Responses in this data exchange, hence using the same receiving HPKE context rctxt to construct those. For instance, this is the case when the data exchange is a registered observation (i.e., the Oblivious CoAP Request was an original Observe registration request and later Observe notifications are expected to be sent), or when the data exchange is an active block-wise transfer (i.e., the server expects to send/solicit further blocks to/from the Oblivious Client).
   Then, encode the OCoAP Option value as defined in and add the OCoAP Option to the Original CoAP Response.
8. Construct the associated data aad as the concatenation of:
   • An 8-bit unsigned integer encoding the length in bytes of the value of the OCoAP Option from the Original CoAP Request to which the Oblivious CoAP Response replies.
   • The value of the OCoAP Option from that Original CoAP Request.
   • The CoAP options of Class I for OSCORE that are present in the Original CoAP Response, which also include the OCoAP Option composed at Step 7. This set of options is encoded like the value of the CBOR byte string options in the aad_array of OSCORE (see ). That is, the server needs to recalculate the Option Deltas of those options.
9. Construct the plaintext pt in the same manner as the plaintext is constructed in OSCORE (see ), i.e., as the concatenation of:
   • The 8-bit Response Code of the Original CoAP Response.
   • The CoAP options of Class E for OSCORE that are present in the Original CoAP Response, with their Option Deltas recalculated accordingly.
   • If a payload is present in the Original CoAP Response, a one-byte Payload Marker 0xff (see ) followed by the payload of the Original CoAP Response.
10. Compute the AEAD nonce aead_nonce of length Nn bytes, by XORing:
    • The aead_base_iv associated with rctxt; and
    • The value of the counter k of rctxt from Step 1, left-padded with 0 to the exact length of aead_base_iv.
11. Invoke the AEAD function Seal() of the AEAD associated with rctxt (see ), providing aead_key associated with rctxt as the first parameter, aead_nonce from Step 10 as the second parameter, the associated data aad from Step 8 as the third parameter, and the plaintext pt from Step 9 as the fourth parameter. The AEAD function Seal() returns the ciphertext ct or an error on failure. If the function fails, the server MUST reply with a 5.00 (Internal Server Error) response, MUST discard the Oblivious CoAP Request and the Original CoAP Response, and MUST terminate this procedure.
12. Construct the Oblivious CoAP Response from the Original CoAP Response as follows:
    • Replace the Response Code with 2.05 (Content) if the Original CoAP Response contains an Observe Option, or with 2.04 (Changed) otherwise.
    • Remove all the CoAP options of Class E for OSCORE and recalculate the Option Deltas of the remaining CoAP options (which include the OCoAP Option added at Step 7).
    • Add a Payload Marker if the Original CoAP Response had no payload.
    • Remove the payload, if present in the Original CoAP Response.
    • Add the payload defined in , consistent with the values in the previous steps of the present procedure.
13. Increment the counter k for rctxt by 1.

Finally, the server sends the Oblivious CoAP Response to the Oblivious Proxy Resource, which forwards it back to the Oblivious Client (see ) TBD: Lost ACK responses could potentially trigger a new creation of rctxt. Is that a problem? I don't think it's a problem; it's actually good. Following the lost ACK with piggybacked the first Oblivious CoAP Response to the first Oblivious CoAP Request: i) If the Client retransmits the same Oblivious CoAP Request, the server derives the same receiving HPKE Context, but then it derives a different response_nonce, hence the AEAD keying material will be different from the previous HPKE context. ii) If the Client transmits a brand new Oblivious CoAP Request, enc is different in the first place and the server creates a totally different receiving HPKE context. Still, let's keep an eye out for computational overhead in actual implementations.. If the server anticipates that it might send further Oblivious CoAP Responses in this data exchange (see also Step 7 above), the server retains the receiving HPKE context rctxt. Otherwise, the server discards rctxt.

Response Processing at the Client When the Oblivious CoAP Client (Client) receives an Oblivious CoAP Response (i.e., a response that includes an OCoAP Option), the Client retrieves the sending HPKE context sctxt that was used to construct the corresponding Oblivious CoAP Request. Then, the Client performs the operations described in in reverse, as defined below.

1. The Client reads the value of the OCoAP Option, from which it determines the value of count and of the flag bit c. As per , the empty option value is equivalent to the option value 0x0000, i.e., count=0 and c=0.
   • If count>0 and c=0, retrieve ct as the payload of the Oblivious CoAP Response. Then, move to Step 6.
   • If count=0, parse the payload of the Oblivious CoAP Response into response_nonce and ct. In particular, the length of response_nonce is max(Nn, Nk), where Nn and Nk are the length of the AEAD key and nonce that are associated with sctxt, and ct is the remainder of the payload after response_nonce. Furthermore, if c=1, retrieve the binary identifier of the receiving HPKE context from the id_ctx field in the received OCoAP Option, and store it as the identifier id_rctxt for the construction of further Oblivious CoAP Requests with sctxt (see Step 3 of ). Then, move to Step 2.
   • If none of the above applies, the Client MUST discard the Oblivious CoAP Response and MUST terminate this procedure.
2. Export the secret secret as described at Step 2 of , with the difference that sctxt is used instead of rctxt.
3. Extract a pseudorandom key prk using the Extract function provided by the KDF algorithm associated with sctxt (see ). The ikm input to this function is secret from Step 2; the salt input is the concatenation of: the encapsulated KEM shared secret enc from the payload of the Original CoAP Request and response_nonce from the payload of the received Oblivious CoAP Response.
4. Use the Expand function provided by the same KDF algorithm used in Step 3 to create the AEAD key aead_key of length Nk, i.e., the length of the keys used by the AEAD associated with sctxt. Generating aead_key uses the pseudorandom key prk from Step 3 and the string "key", as the prk parameter and the info parameter for the Expand function, respectively. Then, store aead_key in association with sctxt.
5. Use the same Expand function to create an AEAD Base IV aead_base_iv of length Nn bytes, i.e., the length of the nonces used by the AEAD associated with sctxt. Generating aead_base_iv uses the pseudorandom key prk from Step 3 and the string "base_iv" as the prk parameter and the info parameter for the Expand function, respectively. Then, store aead_base_iv in association with sctxt.
6. Construct the associated data aad as described at Step 8 of , with the difference that the CoAP options of Class I to consider are those that are present in the received Oblivious CoAP Response.
7. Compute the AEAD nonce aead_nonce of length Nn bytes, by XORing:
   • The aead_base_iv associated with sctxt; and
   • The value of the counter count retrieved at Step 1 from the OCoAP Option of the received Oblivious CoAP Response, left-padded with 0 to the exact length of aead_base_iv.
8. Invoke the AEAD function Open() of the AEAD associated with sctxt (see ), providing aead_key associated with sctxt as the first parameter, aead_nonce from Step 7 as the second parameter, the associated data aad from Step 6 as the third parameter, and the ciphertext ct from the payload of the received Oblivious CoAP Response as the fourth parameter. The AEAD function Open() returns the plaintext pt or an error on failure. If the function fails, the Client MUST discard the Oblivious CoAP Response and MUST terminate this procedure.
9. If the OCoAP Option value in the received Oblivious CoAP Response specifies count=0 and the counter j for sctxt is not initialized yet (see ), then initialize j to 0, and move to Step 10. Otherwise, the Client MUST check whether it already used sctxt to decrypt a previous Oblivious CoAP Response whose OCoAP Option specified the same count as the present Oblivious CoAP Response:
   • If that is the case (i.e., a replay is detected), the Client MUST discard the Oblivious CoAP Response and MUST terminate this procedure.
   • Otherwise, if count specified in the OCoAP Option of the present Oblivious CoAP Response is such that count>j, then j takes the value of count. This keeps track of the most recent received Oblivious CoAP Response processed with sctxt, which allows the Client application to order such Oblivious CoAP Responses with respect to one another.
   This is analogous to what a CoAP client does for the replay-check and ordering of Observe notifications when using OSCORE, by relying on the Partial IV of the OSCORE Option value and the local Notification Number (see Sections , , and of ).
10. Parse pt into: the 8-bit Code of the Original CoAP Response, the CoAP options of Class E for OSCORE that were present in the Original CoAP Response, the one-byte Payload Marker 0xff (if present), and, if the Payload Marker 0xff is found, the payload of the Original CoAP Response. If the parsing fails, the Client MUST discard the Oblivious CoAP Response and MUST terminate this procedure.
11. Reconstruct the Original CoAP Response from the Oblivious CoAP Response as follows:
    • Replace the Response Code of the Oblivious CoAP Response with the Response Code from pt.
    • Remove the OCoAP Option from the Oblivious CoAP Response.
    • Add the CoAP options from pt and recalculate the Option Deltas of all the CoAP options in the updated option set.
    • Remove the Payload Marker 0xff and the payload from the Oblivious CoAP Response.
    • If the Payload Marker 0xff and a payload are present in pt, add those in the same order.

The Client discards the sending HPKE context sctxt if any of the following applies, or retains it otherwise:

• The OCoAP Option value of the received Oblivious CoAP Response specifies count=0 and c=0.
• The Client will not send further Oblivious CoAP Requests and does not expect to receive further Oblivious CoAP Responses in this data exchange, which would require using sctxt. An example with such further Oblivious CoAP Requests/Responses is the case where the data exchange is a registered observation , hence the Client might send a cancellation request (see ) and could receive Observe notifications. Another example is the case where the data exchange is an active block-wise transfer , hence the Client expects to send/receive further blocks to/from the server hosting the Oblivious Gateway Resource).

Security Considerations The security considerations that apply to this document are largely the same as those compiled in , , and as well as in and , if applicable to HPKE or CoAP. The following security considerations also apply.

Request Replays As with Oblivious HTTP , Oblivious CoAP Requests can be easily replayed by the Oblivious Proxy Resource or an external adversary. Two approaches can mitigate this issue:

1. As with Cacheable OSCORE , the fact that the request was replayed can be disregarded if the received Oblivious CoAP Request uses a safe REST method (see ) and the server is able to verify that it is indeed safe to proceed with handling the request.
2. For non-safe Oblivious CoAP Requests and as a more general approach, the server can identify an Oblivious CoAP Request to be a replay, in which case it stops processing that request, unless handling that request is deemed appropriate. To practically detect replayed Oblivious CoAP Requests, the server can rely on the following information:
   • For the first Oblivious CoAP Request of a data exchange (i.e., with the OCoAP Option indicating count=0 and c=0), the server can rely on the encapsulated KEM shared secret enc conveyed in the request payload. That is, like in Oblivious HTTP (see ), the server can use enc in place of a nonce to uniquely identify the Oblivious CoAP Request and detect if it has been previously received. Specifically, the server can rely on enc as is when that is the DH/NIKE ephemeral public key of the Oblivious Client, or on a (hash-based) identifier of enc when that is a KEM ciphertext.
   • For follow-up Oblivious CoAP Requests throughout a data exchange, the server can rely on the counter count in the integrity-protected OCoAP Option of those requests, e.g., by evaluating it against a Replay Window paired with the receiving HPKE context rctxt.
   A protected Echo Option can further increase replay protection, similar to how it is used with OSCORE.

IANA Considerations This document has the following actions for IANA. Note to RFC Editor: Please replace all occurrences of "[RFC-XXXX]" with the RFC number of this specification and delete this paragraph.

Media Type Registrations This document registers the media type "application/ocoap-keys+cbor-seq". This registration follows the procedures specified in .

• Type name: application
• Subtype name: ocoap-keys+cbor-seq
• Required parameters: N/A
• Optional parameters: N/A
• Encoding considerations: Must be encoded as a CBOR sequence of CBOR maps . Each of the CBOR maps is a key configuration for Oblivious CoAP encoded as defined in of [RFC-XXXX].
• Security considerations: See of [RFC-XXXX].
• Interoperability considerations: N/A
• Published specification: [RFC-XXXX]
• Applications that use this media type: Applications that need to describe, distribute, and store a CBOR-encoded representation of a key configuration for Oblivious CoAP (see of [RFC-XXXX]).
• Fragment identifier considerations: N/A
• Additional information: N/A
• Person & email address to contact for further information: CoRE WG mailing list (core@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org)
• Intended usage: COMMON
• Restrictions on usage: None
• Author/Change controller: IETF
• Provisional registration: No

CoAP Content-Formats Registry IANA is asked to add the following entries to the "CoAP Content-Formats" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group. Content Type: application/ohttp-keys Content Coding: - ID: TBD (value between 0 and 255) Reference: [RFC-XXXX]
Content Type: application/ocoap-keys+cbor-seq Content Coding: - ID: TBD (value between 0 and 255) Reference: [RFC-XXXX] Note to RFC Editor: In the table above, please replace TBD with the registered Content-Format ID. Then, please delete this paragraph.

CoAP Option Numbers Registry IANA is asked to add the following option number to the "CoAP Option Numbers" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group. Registration in the CoAP Option Numbers Registry

Number	Name	Reference
TBD	OCoAP	[RFC-XXXX]

For the OCoAP Option, the preferred value range is 0-255. Note to RFC Editor: In the table above, please replace TBD with the registered option number. Then, please delete this paragraph and the previous paragraph.

OCoAP Flag Bits Registry This document establishes the "OCoAP Flag Bits" registry within the "Constrained RESTful Environments (CoRE) Parameters" registry group. The registration policy is "Expert Review" per . "Expert Review" guidelines are provided in . The columns of this registry are:

• Bit Position: This indicates the position of the bit in the set of OCoAP flag bits, starting at 0 for the most significant bit. The bit position must be an integer or a range of integers between 0 and 63 (inclusive).
• Name: This is a descriptive name that enables easier reference to the item. The name MUST be unique. It is not used in the protocol.
• Description: This contains a brief description of the use of the bit in this item.
• Reference: This contains a pointer to the public specification for the item, if one exists.

This registry is initially populated by the entries in . The entry with Bit Position of 0 is marked as "Reserved". It is expected that it will be specified in a future document and will be used to expand the space for the OCoAP flag bits in , so that entries 8-63 of the registry are defined. OCoAP Flag Bits

Bit Position	Name	Description	Reference
0	Reserved
1	Unassigned
2	Unassigned
3	Unassigned
4	Unassigned
5	ID Context Flag	Set to 1 if the HPKE ID Context is present	of [RFC-XXXX]
6-7	Count Length	Encodes the Count length minus 1	of [RFC-XXXX]
8-63	Unassigned

Expert Review Instructions "Expert Review" is the registration policy defined for the IANA registry established in this document. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason, so they should be given substantial latitude. Expert reviewers should take into consideration the following points:

• Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage solves a valid use case that could not be solved better in a different way, is not going to duplicate one that is already registered, and that the point is likely to be used in deployments.
• Experts are expected to check the clarity of purpose and use of the requested code points. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.
• Experts should take into account the expected usage of fields when approving point assignment. The length of the encoded value should be weighed against how many code points of that length are left, the size of device it will be used on, and the number of code points left that encode to that size.
• Experts should block registrations for entries 8-63 until these points are defined (i.e., until the mechanism for the OCoAP flag bits expansion via bit 0 is specified).

References Normative References This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. The Constrained Application Protocol (CoAP) is a specialized web transfer protocol for use with constrained nodes and constrained (e.g., low-power, lossy) networks. The nodes often have 8-bit microcontrollers with small amounts of ROM and RAM, while constrained networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs) often have high packet error rates and a typical throughput of 10s of kbit/s. The protocol is designed for machine- to-machine (M2M) applications such as smart energy and building automation. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types. CoAP is designed to easily interface with HTTP for integration with the Web while meeting specialized requirements such as multicast support, very low overhead, and simplicity for constrained environments. Many protocols make use of points of extensibility that use constants to identify various protocol parameters. To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper. For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA). To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed. This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry. This is the third edition of this document; it obsoletes RFC 5226. The methods defined in RFC 7252 for the Constrained Application Protocol (CoAP) only allow access to a complete resource, not to parts of a resource. In case of resources with larger or complex data, or in situations where resource continuity is required, replacing or requesting the whole resource is undesirable. Several applications using CoAP need to access parts of the resources. This specification defines the new CoAP methods, FETCH, PATCH, and iPATCH, which are used to access and update parts of a resource. This document proposes a notational convention to express Concise Binary Object Representation (CBOR) data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON. This document defines Object Security for Constrained RESTful Environments (OSCORE), a method for application-layer protection of the Constrained Application Protocol (CoAP), using CBOR Object Signing and Encryption (COSE). OSCORE provides end-to-end protection between endpoints communicating using CoAP or CoAP-mappable HTTP. OSCORE is designed for constrained nodes and networks supporting a range of proxy operations, including translation between different transport protocols. Although an optional functionality of CoAP, OSCORE alters CoAP options processing and IANA registration. Therefore, this document updates RFC 7252. This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor-seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document describes Oblivious HTTP, a protocol for forwarding encrypted HTTP messages. Oblivious HTTP allows a client to make multiple requests to an origin server without that server being able to link those requests to the client or to identify the requests as having come from the same client, while placing only limited trust in the nodes used to forward the messages. Universität Bremen TZI Fraunhofer SIT The Constrained Resource Identifier (CRI) is a complement to the Uniform Resource Identifier (URI) that represents the URI components in Concise Binary Object Representation (CBOR) rather than as a sequence of characters. This approach simplifies parsing, comparison, and reference resolution in environments with severe limitations on processing power, code size, and memory size. This RFC updates RFC 7595 by adding a column on the "URI Schemes" registry. // (This "cref" paragraph will be removed by the RFC editor:) After // approval of -28 and nit fixes in -29, the present revision -30 // contains two more small fixes for nits that were uncovered in the // RPC intake process. Sandelman Software Works Applications built on CoAP face a conflict between the technical need for short message sizes and the interoperability requirement of following BCP190 and thus using (relatively verbose) well-known URI paths. This document introduces the Uri-Path-Abbrev CoAP option that allows expressing well-known URI paths in as little as two bytes. Using this option revealed a subtle flaw in RFC7252 that severely limited the extension point of critical options. This document updates RFC7252 to rectify that. IANA IANA IANA In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References The Constrained Application Protocol (CoAP) is a RESTful application protocol for constrained nodes and networks. The state of a resource on a CoAP server can change over time. This document specifies a simple protocol extension for CoAP that enables CoAP clients to "observe" resources, i.e., to retrieve a representation of a resource and keep this representation updated by the server over a period of time. The protocol follows a best-effort approach for sending new representations to clients and provides eventual consistency between the state observed by each client and the actual resource state at the server. The Constrained Application Protocol (CoAP) is a RESTful transfer protocol for constrained nodes and networks. Basic CoAP messages work well for small payloads from sensors and actuators; however, applications will need to transfer larger payloads occasionally -- for instance, for firmware updates. In contrast to HTTP, where TCP does the grunt work of segmenting and resequencing, CoAP is based on datagram transports such as UDP or Datagram Transport Layer Security (DTLS). These transports only offer fragmentation, which is even more problematic in constrained nodes and networks, limiting the maximum size of resource representations that can practically be transferred. Instead of relying on IP fragmentation, this specification extends basic CoAP with a pair of "Block" options for transferring multiple blocks of information from a resource representation in multiple request-response pairs. In many important cases, the Block options enable a server to be truly stateless: the server can handle each block transfer separately, with no need for a connection setup or other server-side memory of previous block transfers. Essentially, the Block options provide a minimal way to transfer larger representations in a block-wise fashion. A CoAP implementation that does not support these options generally is limited in the size of the representations that can be exchanged, so there is an expectation that the Block options will be widely used in CoAP implementations. Therefore, this specification updates RFC 7252. Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of CoAP over UDP includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or Transport Layer Security (TLS). This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates RFC 7641 for use with these transports and RFC 7959 to enable the use of larger messages over a reliable transport. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document specifies the HTTP/1.1 message syntax, message parsing, connection management, and related security concerns. This document obsoletes portions of RFC 7230. This document specifies enhancements to the Constrained Application Protocol (CoAP) that mitigate security issues in particular use cases. The Echo option enables a CoAP server to verify the freshness of a request or to force a client to demonstrate reachability at its claimed network address. The Request-Tag option allows the CoAP server to match block-wise message fragments belonging to the same request. This document updates RFC 7252 with respect to the following: processing requirements for client Tokens, forbidding non-secure reuse of Tokens to ensure response-to-request binding when CoAP is used with a security protocol, and amplification mitigation (where the use of the Echo option is now recommended). In many Internet of Things (IoT) applications, direct discovery of resources is not practical due to sleeping nodes or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. The input to an RD is composed of links, and the output is composed of links constructed from the information stored in the RD. This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, look up, and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. This document specifies alternative Constrained Application Protocol (CoAP) block-wise transfer options: Q-Block1 and Q-Block2. These options are similar to, but distinct from, the CoAP Block1 and Block2 options defined in RFC 7959. The Q-Block1 and Q-Block2 options are not intended to replace the Block1 and Block2 options but rather have the goal of supporting Non-confirmable (NON) messages for large amounts of data with fewer packet interchanges. Also, the Q-Block1 and Q-Block2 options support faster recovery should any of the blocks get lost in transmission. This document describes a protocol that allows clients to hide their IP addresses from DNS resolvers via proxying encrypted DNS over HTTPS (DoH) messages. This improves privacy of DNS operations by not allowing any one server entity to be aware of both the client IP address and the content of DNS queries and answers. This experimental protocol has been developed outside the IETF and is published here to guide implementation, ensure interoperability among implementations, and enable wide-scale experimentation. This document defines a protocol for exchanging DNS queries (OPCODE 0) over the Constrained Application Protocol (CoAP). These CoAP messages can be protected by (D)TLS-Secured CoAP or Object Security for Constrained RESTful Environments (OSCORE) to provide encrypted DNS message exchange for constrained devices in the Internet of Things (IoT). RISE AB RISE AB The CoAP protocol was designed with direct connections and proxies in mind. This document defines mechanisms by which chains of proxies can be set up. In combination, they enable the operation of hidden services and of clients similar to how Tor (onion routing) enables it for TCP-based protocols. RISE AB When using the Constrained Application Protocol (CoAP), exchanged messages can be protected end-to-end also across untrusted intermediary proxies. This can be achieved with Object Security for Constrained RESTful Environments (OSCORE) or, in the case of group communication, with Group Object Security for Constrained RESTful Environments (Group OSCORE). However, this sidesteps the proxies' abilities to cache responses from the origin server(s). This document restores cacheability of end-to-end protected responses at proxies, by using Group OSCORE and introducing consensus requests, which any client in an OSCORE group can send to one server or multiple servers in the same group.

Change Log

Since draft-lenders-core-oblivious-coap-00

• Editorial fixes

Acknowledgments The work on this document has been partly supported by Sweden's Innovation Agency VINNOVA and the Celtic-Next project CYPRESS, as well as by the Sovereign Tech Standards program.