idnits 2.17.1 draft-amsuess-core-cachable-oscore-04.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1028): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 6 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 782 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-11) exists of draft-ietf-core-groupcomm-bis-05 == Outdated reference: A later version (-21) exists of draft-ietf-core-oscore-groupcomm-13 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-cose-rfc8152bis-struct' ** Downref: Normative reference to an Informational draft: draft-ietf-cose-rfc8152bis-algs (ref. 'I-D.ietf-cose-rfc8152bis-algs') == Outdated reference: A later version (-16) exists of draft-ietf-ace-key-groupcomm-oscore-12 == Outdated reference: A later version (-08) exists of draft-ietf-core-observe-multicast-notifications-02 == Outdated reference: A later version (-02) exists of draft-bormann-core-responses-01 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Working Group C. Amsüss 3 Internet-Draft 4 Intended status: Standards Track M. Tiloca 5 Expires: 8 September 2022 RISE AB 6 7 March 2022 8 Cacheable OSCORE 9 draft-amsuess-core-cachable-oscore-04 11 Abstract 13 Group communication with the Constrained Application Protocol (CoAP) 14 can be secured end-to-end using Group Object Security for Constrained 15 RESTful Environments (Group OSCORE), also across untrusted 16 intermediary proxies. However, this sidesteps the proxies' abilities 17 to cache responses from the origin server(s). This specification 18 restores cacheability of protected responses at proxies, by 19 introducing consensus requests which any client in a group can send 20 to one server or multiple servers in the same group. 22 Discussion Venues 24 This note is to be removed before publishing as an RFC. 26 Discussion of this document takes place on the CORE Working Group 27 mailing list (core@ietf.org), which is archived at 28 https://mailarchive.ietf.org/arch/browse/core/. 30 Source for this draft and an issue tracker can be found at 31 https://gitlab.com/chrysn/core-cachable-oscore/. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at https://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on 8 September 2022. 50 Copyright Notice 52 Copyright (c) 2022 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 57 license-info) in effect on the date of publication of this document. 58 Please review these documents carefully, as they describe your rights 59 and restrictions with respect to this document. Code Components 60 extracted from this document must include Revised BSD License text as 61 described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Revised BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Use cases . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. OSCORE processing without source authentication . . . . . . . 5 70 3. Deterministic Requests . . . . . . . . . . . . . . . . . . . 7 71 3.1. Deterministic Unprotected Request . . . . . . . . . . . . 7 72 3.2. Design Considerations . . . . . . . . . . . . . . . . . . 8 73 3.3. Request-Hash . . . . . . . . . . . . . . . . . . . . . . 9 74 3.4. Use of Deterministic Requests . . . . . . . . . . . . . . 10 75 3.4.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . 10 76 3.4.2. Client Processing of Deterministic Request . . . . . 11 77 3.4.3. Server Processing of Deterministic Request . . . . . 13 78 3.4.4. Response to a Deterministic Request . . . . . . . . . 15 79 3.4.5. Deterministic Requests to Multiple Servers . . . . . 16 80 4. Obtaining Information about the Deterministic Client . . . . 17 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 83 6.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 18 84 6.2. OSCORE Security Context Parameters Registry . . . . . . . 19 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 20 87 7.2. Informative References . . . . . . . . . . . . . . . . . 21 88 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 23 89 Appendix B. Padding . . . . . . . . . . . . . . . . . . . . . . 24 90 B.1. Definition of the Padding Option . . . . . . . . . . . . 24 91 B.2. Using and processing the Padding option . . . . . . . . . 25 92 Appendix C. Simple Cacheability using Ticket Requests . . . . . 25 93 Appendix D. Application for More Efficient End-to-End Protected 94 Multicast Notifications . . . . . . . . . . . . . . . . . 27 95 Appendix E. Open questions . . . . . . . . . . . . . . . . . . . 27 96 Appendix F. Unsorted further ideas . . . . . . . . . . . . . . . 28 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 28 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 100 1. Introduction 102 The Constrained Application Protocol (CoAP) [RFC7252] supports also 103 group communication, for instance over UDP and IP multicast 104 [I-D.ietf-core-groupcomm-bis]. In a group communication environment, 105 exchanged messages can be secured end-to-end by using Group Object 106 Security for Constrained RESTful Environments (Group OSCORE) 107 [I-D.ietf-core-oscore-groupcomm]. 109 Requests and responses protected with the group mode of Group OSCORE 110 can be read by all group members, i.e., not only by the intended 111 recipient(s), thus achieving group-level confidentiality. 113 This allows a trusted intermediary proxy which is also a member of 114 the OSCORE group to populate its cache with responses from origin 115 servers. Later on, the proxy can possibly reply to a request in the 116 group with a response from its cache, if recognized as an eligible 117 server by the client. 119 However, an untrusted proxy which is not member of the OSCORE group 120 only sees protected responses as opaque, uncacheable ciphertext. In 121 particular, different clients in the group that originate a same 122 plain CoAP request would send different protected requests, as a 123 result of their Group OSCORE processing. Such protected requests 124 cannot yield a cache hit at the proxy, which makes the whole caching 125 of protected responses pointless. 127 This document addresses this complication and enables cacheability of 128 protected responses, also for proxies that are not members of the 129 OSCORE group and are unaware of OSCORE in general. To this end, it 130 builds on the concept of "consensus request" initially considered in 131 [I-D.ietf-core-observe-multicast-notifications], and defines 132 "deterministic request" as a convenient incarnation of such concept. 134 All clients wishing to send a particular GET or FETCH request are 135 able to deterministically compute the same protected request, using a 136 variation on the pairwise mode of Group OSCORE. It follows that 137 cache hits become possible at the proxy, which can thus serve clients 138 in the group from its cache. Like in 139 [I-D.ietf-core-observe-multicast-notifications], this requires that 140 clients and servers are already members of a suitable OSCORE group. 142 Cacheability of protected responses is useful also in applications 143 where several clients wish to retrieve the same object from a single 144 server. Some security properties of OSCORE are dispensed with to 145 gain other desirable properties. 147 In order to clearly handle the protocol's security properties, and to 148 broaden applicability to group situations outside the deterministic 149 case, the technical implementation is split in two halves: 151 * maintaining request-response bindings in absence of request source 152 authentication, and 154 * building and processing of deterministic requests (which have no 155 source authentication, and thus require the former). 157 1.1. Use cases 159 When firmware updates are delivered using CoAP, many similar devices 160 fetch large representations at the same time. Collecting them at a 161 proxy not only keeps the traffic low, but also lets the clients ride 162 single file to hide their numbers[SW-EPIV] and identities. 164 When relying on intermediaries to fan out the delivery of multicast 165 data protected end-to-end as in 166 [I-D.ietf-core-observe-multicast-notifications], deterministic 167 requests allow for a more efficient setup, by reducing the amount of 168 message exchanges and enabling early population of cache entries (see 169 Appendix D). 171 1.2. Terminology 173 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 174 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 175 "OPTIONAL" in this document are to be interpreted as described in BCP 176 14 [RFC2119] [RFC8174] when, and only when, they appear in all 177 capitals, as shown here. 179 Readers are expected to be familiar with terms and concepts of CoAP 180 [RFC7252] and its method FETCH [RFC8132], group communication for 181 CoAP [I-D.ietf-core-groupcomm-bis], COSE 182 [I-D.ietf-cose-rfc8152bis-struct][I-D.ietf-cose-rfc8152bis-algs], 183 OSCORE [RFC8613], and Group OSCORE [I-D.ietf-core-oscore-groupcomm]. 185 This document introduces the following new terms. 187 * Consensus Request: a CoAP request that multiple clients use to 188 repeatedly access a particular resource. In this document, it 189 exclusively refers to requests protected with Group OSCORE to a 190 resource hosted at one or more servers in the OSCORE group. 192 A Consensus Request has all the properties relevant to caching, 193 but its transport dependent properties (e.g., Token or Message ID) 194 are not defined. Thus, different requests on the wire can be said 195 to "be the same Consensus Request" even if they have different 196 Tokens or source addresses. 198 The Consensus Request is the reference for request-response 199 binding. In general, a client processing a response to a 200 consensus request did not generate (and thus sign) the consensus 201 request. The client not only needs to decrypt the Consensus 202 Request to understand a response to it (for example to tell which 203 path was requested), it also needs to verify that this is the only 204 Consensus Request that could elicit this response. 206 * Deterministic Client: a fictitious member of an OSCORE group, 207 having no Sender Sequence Number, no asymmetric key pair, and no 208 Recipient Context. 210 The Group Manager sets up the Deterministic Client, and assigns it 211 a unique Sender ID as for other group members. Furthermore, the 212 Deterministic Client has only the minimum common set of privileges 213 shared by all group members. 215 * Deterministic Request: a Consensus Request generated by the 216 Deterministic Client. The use of Deterministic Requests is 217 defined in Section 3. 219 * Ticket Request: a Consensus Request generated by the server 220 itself. 222 This term is not used in the main document, but is useful in 223 comparison with other applications of consensus requests that are 224 generated in a different way than as a Deterministic Request. The 225 prototypical Ticket Request is the Phantom Request defined in 226 [I-D.ietf-core-observe-multicast-notifications]. 228 In Appendix C, the term is used to bridge the gap to that draft. 230 2. OSCORE processing without source authentication 232 The request-response binding of OSCORE is achieved by the request_kid 233 / request_piv items (and, in group OSCORE, request_kid_context) 234 present in the response's AAD. Its security depends on the server 235 obtaining source authentication for the request: Without, a malicious 236 group member could alter a request to the server (without altering 237 the request_ details above), and the client would still accept the 238 response as if it were a response to its request. 240 Source authentication is thus a precondition to secure use of OSCORE. 241 However, it is hard to provide when: 243 * Requests are built exclusively using shared key material (as in a 244 Deterministic Client). 246 * Requests are sent without source authentication, or where the 247 source authentication is not checked. (This was part of 248 [I-D.ietf-core-oscore-groupcomm] in revisions before -12). 250 This document does not [ yet? ] give full guidance on how to restore 251 request-response binding for the general case, but currently only 252 offers suggestions: 254 * The response can contain the full request. An option that allows 255 doing that was presented in [I-D.bormann-core-responses]. 257 * The response can contain a cryptographic hash of the full request. 258 This is used in Section 3.3. 260 * The above details can be transported in a Class E option 261 (encrypted) or a a Class I option (unencrypted but part of the 262 AAD). The latter has the advantage that it can be removed in 263 transit and reconstructed at the receiver. 265 * Alternatively, the agreed-on request data can be placed in a 266 different position in the AAD, or be part of the security context 267 derivation. In the latter case, care needs to be taken to never 268 initialize a security context twice with the same input, as that 269 would lead to nonce reuse. 271 [ Suggestion for any OSCORE v2: avoid request details in the 272 request's AAD as individual elements. Rather than having 273 'request_kid', 'request_piv' and (in Group OSCORE) 274 'request_kid_context' as separate fields, they can better be 275 something more pluggable. This would avoid the need to make up an 276 option before processing, and would allow just plugging in the hash 277 or request in there replacing the request_ items. ] 279 Additional care has to be taken that details not expressed in the 280 request itself (like the security context from which it is assumed to 281 have originated) are captured. 283 Processing of requests without source authentication has to be done 284 assuming only the minimal possible privilege of the requester [ which 285 currently described as the authorization of the Deterministic Client, 286 and may be moved up here in later versions of this document ]. If a 287 response is built to such a request that contains data more sensitive 288 than that (which might be justified if the response is protected for 289 an authorized group member in pairwise response mode), special 290 consideration for any side channels like response size or timing is 291 required. 293 3. Deterministic Requests 295 This section defines a method for clients starting from a same plain 296 CoAP request to independently arrive at a same Deterministic Request 297 protected with Group OSCORE. 299 3.1. Deterministic Unprotected Request 301 Clients build the unprotected Deterministic Request in a way which is 302 as much reproducible as possible. This document does not set out 303 full guidelines for minimizing the variation, but considered starting 304 points are: 306 * Set the inner Observe option to 0 even if no observation is 307 intended (and hence no outer Observe is set). Thus, both 308 observing and non-observing requests can be aggregated into a 309 single request, that is upstreamed as an observation at the latest 310 when any observing request reaches a caching proxy. 312 In this case, following a Deterministic Request that includes only 313 an inner Observe option, servers include an inner Observe option 314 (but no outer Observe option) in a successful response sent as 315 reply. Also, when receiving a response to such a Deterministic 316 Request previously sent, clients have to silently ignore the inner 317 Observe option in that response. 319 * Avoid setting the ETag option in requests on a whim. Only set it 320 when there was a recent response with that ETag. When obtaining 321 later blocks, do not send the known-stale ETag. 323 * In block-wise transfer, maximally sized large inner blocks (szx=6) 324 should be selected. This serves not only to align the clients on 325 consistent cache entries, but also helps amortize the additional 326 data transferred in the per-message signatures. 328 Outer block-wise transfer can then be used if these messages excede a 329 hop's efficiently usable MTU size. 331 (If BERT [RFC8323] is usable with OSCORE, its use is fine as well; in 332 that case, the server picks a consistent block size for all clients 333 anyway). 335 * The Padding option defined in Appendix B can be used to limit an 336 adversary's ability to deduce the content and the target resource 337 of Deterministic Requests from their length. In particular, all 338 Deterministic Requests of the same class (ideally, all requests to 339 a particular server) can be padded to reach the same total length, 340 that should be agreed on among all users of the same OSCORE 341 Security Context. 343 * Clients should not send any inner Echo options [RFC9175] in 344 deterministic requests. 346 This limits the use of the Echo option in combination with 347 deterministic requests to unprotected (outer) options, and thus is 348 limited to testing the reachability of the client. This is not 349 practically limiting, as the use as an inner option would be to 350 prove freshness, which is something deterministic requests simply 351 cannot provide anyway. 353 These only serve to ensure that cache entries are utilized; failure 354 to follow them has no more severe consequences than decreasing the 355 utility and effectiveness of a cache. 357 3.2. Design Considerations 359 The hard part is arriving at a consensus pair (key, nonce) to be used 360 with the AEAD cipher for encrypting the Deterministic Request, while 361 also avoiding reuse of the same (key, nonce) pair across different 362 requests. 364 Diversity can conceptually be enforced by applying a cryptographic 365 hash function to the complete input of the encryption operation over 366 the plain CoAP request (i.e., the AAD and the plaintext of the COSE 367 object), and then using the result as source of uniqueness. Any non- 368 malleable cryptographically secure hash of sufficient length to make 369 collisions sufficiently unlikely is suitable for this purpose. 371 A tempting possibility is to use a fixed (group) key, and use the 372 hash as a deterministic AEAD nonce for each Deterministic Request 373 throught the Partial IV component (see Section 5.2 of [RFC8613]). 374 However, the 40 bit available for the Partial IV are by far 375 insufficient to ensure that the deterministic nonce is not reused 376 across different Deterministic Requests. Even if the full 377 deterministic AEAD nonce could be set, the sizes used by common 378 algorithms would still be too small. 380 As a consequence, the proposed method takes the opposite approach, by 381 considering a fixed deterministic AEAD nonce, while generating a 382 different deterministic encryption key for each Deterministic 383 Request. That is, the hash computed over the plain CoAP request is 384 taken as input to the key generation. As an advantage, this approach 385 does not require to transport the computed hash in the OSCORE option. 387 [ Note: This has a further positive side effect arising with version 388 -11 of Group OSCORE. That is, since the full encoded OSCORE option 389 is part of the AAD, it avoids a circular dependency from feeding the 390 AAD into the hash computation, which in turn needs crude workarounds 391 like building the full AAD twice, or zeroing out the hash-to-be. ] 393 3.3. Request-Hash 395 In order to transport the hash of the plain CoAP request, a new CoAP 396 option is defined, which MUST be supported by clients and servers 397 that support Deterministic Requests. 399 The option is called Request-Hash. As summarized in Figure 1, the 400 Request-Hash option is elective, safe to forward, part of the cache 401 key and repeatable. 403 +------+---+---+---+---+--------------+--------+--------+---------+ 404 | No. | C | U | N | R | Name | Format | Length | Default | 405 +------+---+---+---+---+--------------+--------+--------+---------+ 406 | TBD1 | | | | x | Request-Hash | opaque | any | (none) | 407 +------+---+---+---+---+--------------+--------+--------+---------+ 409 Figure 1: Request-Hash Option 411 The Request-Hash option is identical in all its properties to the 412 Request-Tag option defined in [RFC9175], with the following 413 exceptions: 415 * It may be arbitrarily long. 417 Implementations can limit its length to that of the longest output 418 of the supported hash functions. 420 * It may be present in responses (TBD: Does this affect any other 421 properties?). 423 A response's Request-Hash is, as a matter of default value, equal 424 to the request's. The response is only valid if its Request-Hash 425 is equal to the matching request's. 427 Servers (including proxies) thus generally SHOULD NOT need to send 428 the Request-Hash option explicitly in responses, especially as a 429 matter of bandwidth efficiency. 431 A reason (and, currently, the only known) to actually send a 432 Request-Hash in a response are non-traditional responses as 433 described in [I-D.bormann-core-responses], which in terms of that 434 document are non-matching to the request (and thus easily usable); 435 the request hash in the response allows populating caches (see 436 below) and decryption of the response in deterministic request 437 contexts. In the context of non-traditional responses, a matching 438 request's Request-Hash can be inferred from its value in the 439 response. 441 * A proxy MAY use any fresh cached response from the selected server 442 to respond to a request with the same Request-Hash; this may save 443 it some memory. 445 A proxy can add or remove the request's Request-Tag value to / 446 from a response. 448 * When used with a Deterministic Request, this option is created at 449 message protection time by the sender, and used before message 450 unprotection by the recipient. Therefore, in this use case, it is 451 treated as Class U for OSCORE [RFC8613] in requests. In the same 452 application, for responses, it is treated as Class I, and often 453 elided from sending (but reconstructed at the receiver). Other 454 uses of this option can put it into different classes for the 455 OSCORE processing. 457 This option achieves request-response binding described in Section 2. 459 3.4. Use of Deterministic Requests 461 This section defines how a Deterministic Request is built on the 462 client side and then processed on the server side. 464 3.4.1. Pre-Conditions 466 The use of Deterministic Requests in an OSCORE group requires that 467 the interested group members are aware of the Deterministic Client in 468 the group. In particular, they need to know: 470 * The Sender ID of the Deterministic Client, to be used as 'kid' 471 parameter for the Deterministic Requests. This allows all group 472 members to compute the Sender Key of the Deterministic Client. 474 The Sender ID of the Deterministic Client is immutable throughout 475 the lifetime of the OSCORE group. That is, it is not relinquished 476 and it does not change upon changes of the group keying material 477 following a group rekeying performed by the Group Manager. 479 * The hash algorithm to use for computing the hash of a plain CoAP 480 request, when producing the associated Deterministic Request. 482 Group members have to obtain this information from the Group Manager. 483 A group member can do that, for instance, when obtaining the group 484 keying material upon joining the OSCORE group, or later on as an 485 active member by sending a request to a dedicated resource at the 486 Group Manager. 488 The joining process based on the Group Manager defined in 489 [I-D.ietf-ace-key-groupcomm-oscore] can be easily extended to support 490 the provisioning of information about the Deterministic Client. Such 491 an extension is defined in Section 4 of this document. 493 3.4.2. Client Processing of Deterministic Request 495 In order to build a Deterministic Request, the client protects the 496 plain CoAP request using the pairwise mode of Group OSCORE (see 497 Section 9 of [I-D.ietf-core-oscore-groupcomm]), with the following 498 alterations. 500 1. When preparing the OSCORE option, the external_aad and the AEAD 501 nonce: 503 * The used Sender ID is the Deterministic Client's Sender ID. 505 * The used Partial IV is 0. 507 When preparing the external_aad, the element 'sender_public_key' 508 in the aad_array takes the empty CBOR byte string. 510 2. The client uses the hash function indicated for the Deterministic 511 Client, and computes a hash H over the following input: the 512 Sender Key of the Deterministic Client, concatenated with the 513 external_aad from step 1, concatenated with the COSE plaintext. 515 Note that the payload of the plain CoAP request (if any) is not 516 self-delimiting, and thus hash functions are limited to non- 517 malleable ones. 519 3. The client derives the deterministic Pairwise Sender Key K as 520 defined in Section 2.3.1 of [I-D.ietf-core-oscore-groupcomm], 521 with the following differences: 523 * The Sender Key of the Deterministic Client is used as first 524 argument of the HKDF. 526 * The hash H from step 2 is used as second argument of the HKDF, 527 i.e., as a pseudo IKM-Sender computable by all the group 528 members. 530 Note that an actual IKM-Sender cannot be obtained, since there 531 is no authentication credential (and public key included 532 therein) associated with the Deterministic Client, to be used 533 as Sender Authentication Credential and for computing an 534 actual Diffie-Hellman Shared Secret. 536 * The Sender ID of the Deterministic Client is used as value for 537 the 'id' element of the 'info' parameter used as third 538 argument of the HKDF. 540 4. The client includes a Request-Hash option in the request to 541 protect, with value set to the hash H from Step 2. 543 5. The client MAY include an inner Observe option set to 0 to be 544 protected with OSCORE, even if no observation is intended (see 545 Section 3.1). 547 6. The client protects the request using the pairwise mode of Group 548 OSCORE as defined in Section 9.3 of 549 [I-D.ietf-core-oscore-groupcomm], using the AEAD nonce from step 550 1, the deterministic Pairwise Sender Key K from step 3 as AEAD 551 encryption key, and the finalized AAD. 553 7. The client MUST NOT include an unprotected (outer) Observe option 554 if no observation is intended, even in case an inner Observe 555 option was included at step 5 above. 557 8. The client sets FETCH as the outer code of the protected request 558 to make it usable for a proxy's cache, even if no observation is 559 requested [RFC7641]. 561 The result is the Deterministic Request to be sent. 563 Since the encryption key K is derived using material from the whole 564 plain CoAP request, this (key, nonce) pair is only used for this very 565 message, which is deterministically encrypted unless there is a hash 566 collision between two Deterministic Requests. 568 The deterministic encryption requires the used AEAD algorithm to be 569 deterministic in itself. This is the case for all the AEAD 570 algorithms currently registered with COSE in [COSE.Algorithms]. For 571 future algorithms, a flag in the COSE registry is to be added. 573 Note that, while the process defined above is based on the pairwise 574 mode of Group OSCORE, no information about the server takes part to 575 the key derivation or is included in the AAD. This is intentional, 576 since it allows for sending a deterministic request to multiple 577 servers at once (see Section 3.4.5). On the other hand, it requires 578 later checks at the client when verifying a response to a 579 Deterministic Request (see Section 3.4.4). 581 3.4.3. Server Processing of Deterministic Request 583 Upon receiving a Deterministic Request, a server performs the 584 following actions. 586 A server that does not support Deterministic Requests would not be 587 able to create the necessary Recipient Context, and thus will fail 588 decrypting the request. 590 1. If not already available, the server retrieves the information 591 about the Deterministic Client from the Group Manager, and 592 derives the Sender Key of the Deterministic Client. 594 2. The server actually recognizes the request to be a Deterministic 595 Request, due to the presence of the Request-Hash option and to 596 the 'kid' parameter of the OSCORE option set to the Sender ID of 597 the Deterministic Client. 599 If the 'kid' parameter of the OSCORE option specifies a different 600 Sender ID than the one of the Deterministic Client, the server 601 MUST NOT take the following steps, and instead processes the 602 request as per Section 9.4 of [I-D.ietf-core-oscore-groupcomm]. 604 3. The server retrieves the hash H from the Request-Hash option. 606 4. The server derives a Recipient Context for processing the 607 Deterministic Request. In particular: 609 * The Recipient ID is the Sender ID of the Deterministic Client. 611 * The Recipient Key is derived as the key K in step 3 of 612 Section 3.4.2, with the hash H retrieved at the previous step. 614 5. The server verifies the request using the pairwise mode of Group 615 OSCORE, as defined in Section 9.4 of 616 [I-D.ietf-core-oscore-groupcomm], using the Recipient Context 617 from step 4, with the difference that the server does not perform 618 replay checks against a Replay Window (see below). 620 In case of successful verification, the server MUST also perform the 621 following actions, before possibly delivering the request to the 622 application. 624 * Starting from the recovered plain CoAP request, the server MUST 625 recompute the same hash that the client computed at step 2 of 626 Section 3.4.2. 628 If the recomputed hash value differs from the value retrieved from 629 the Request-Hash option at step 3, the server MUST treat the 630 request as invalid and MAY reply with an unprotected 4.00 (Bad 631 Request) error response. The server MAY set an Outer Max-Age 632 option with value zero. The diagnostic payload MAY contain the 633 string "Decryption failed". 635 This prevents an attacker that guessed a valid authentication tag 636 for a given Request-Hash value to poison caches with incorrect 637 responses. 639 * The server MUST verify that the unprotected request is safe to be 640 processed in the REST sense, i.e., that it has no side effects. 641 If verification fails, the server MUST discard the message and 642 SHOULD reply with a protected 4.01 (Unauthorized) error response. 644 Note that some CoAP implementations may not be able to prevent 645 that an application produces side effects from a safe request. 646 This may incur checking whether the particular resource handler is 647 explicitly marked as eligible for processing deterministic 648 requests. An implementation may also have a configured list of 649 requests that are known to be side effect free, or even a pre- 650 built list of valid hashes for all sensible requests for them, and 651 reject any other request. 653 These checks replace the otherwise present requirement that the 654 server needs to check the Replay Window of the Recipient Context 655 (see step 5 above), which is inapplicable with the Recipient 656 Context derived at step 4 from the value of the Request-Hash 657 option. The reasoning is analogous to the one in 658 [I-D.amsuess-lwig-oscore] to treat the potential replay as 659 answerable, if the handled request is side effect free. 661 3.4.4. Response to a Deterministic Request 663 When treating a response to a deterministic request, the Request-Hash 664 option is treated as a Class I option (but usually not sent). This 665 creates the request-response binding ensuring that no mismatched 666 responses can be successfully unprotected (see Section 2). The 667 client MUST reject responses with a Request-Hash not matching the one 668 it sent in the request. 670 When preparing the response, the server performs the following 671 actions. 673 1. The server sets a non-zero Max-Age option, thus making the 674 Deterministic Request usable for the proxy cache. 676 2. The server preliminarily sets the Request-Hash option with the 677 full request hash. 679 3. If the Deterministic Request included an inner Observe option but 680 not an outer Observe option, the server MUST include an inner 681 Observe option in the response. 683 4. The server MUST protect the response using the group mode of 684 Group OSCORE, as defined in Section 8.3 of 685 [I-D.ietf-core-oscore-groupcomm]. This is required to ensure 686 that the client can verify source authentication of the response, 687 since the "pairwise" key used for the Deterministic Request is 688 actually shared among all the group members. 690 Note that the Request-Hash option is treated as Class I here. 692 5. The server MUST use its own Sender Sequence Number as Partial IV 693 to protect the response, and include it as Partial IV in the 694 OSCORE option of the response. This is required since the server 695 does not perform replay protection on the Deterministic Request 696 (see Section 3.4.4). 698 6. The server uses 2.05 (Content) as outer code even though it is 699 not necessarily an Observe notification [RFC7641], in order to 700 make the response cacheable. 702 7. The server SHOULD remove the Request-Hash option from the message 703 before sending as per the general option mechanism of 704 Section 3.3. 706 8. If the Deterministic Request included an inner Observe option but 707 not an outer Observe option, the server MUST NOT include an outer 708 Observe option in the response. 710 Upon receiving the response, the client performs the following 711 actions. 713 1. In case the response includes a 'kid' in the OSCORE option and 714 unless responses from multiple servers are expected (see 715 Section 3.4.5), the client MUST verify it to be exactly the 'kid' 716 of the server to which the Deterministic Request was sent. 718 2. The client sets the Request-Hash option with the full request 719 hash on the reponse. If an option of a different value is 720 already present, it rejects the response. 722 3. The client verifies the response using the group mode of Group 723 OSCORE, as defined in Section 8.4 of 724 [I-D.ietf-core-oscore-groupcomm]. In particular, the client 725 verifies the counter signature in the response, based on the 726 'kid' of the server it sent the request to. When verifying the 727 response, the Request-Hash option is treated as a Class I option. 729 4. If the Deterministic Request included an inner Observe option but 730 not an outer Observe option (see Section 3.1), the client MUST 731 silently ignore the inner Observe option in the response and MUST 732 NOT stop processing the response. 734 [ Note: This deviates from Section 4.1.3.5.2 of RFC 8613, but it is 735 limited to a very specific situation, where the client and server 736 both know exactly what happens. This does not affect the use of 737 OSCORE in other situations. ] 739 3.4.5. Deterministic Requests to Multiple Servers 741 A Deterministic Request _can_ be sent to a CoAP group, e.g., over UDP 742 and IP multicast [I-D.ietf-core-groupcomm-bis], thus targeting 743 multiple servers at once. 745 To simplify key derivation, such a Deterministic Request is still 746 created in the same way as a one-to-one request and still protected 747 with the pairwise mode of Group OSCORE, as defined in Section 3.4.2. 749 [ Note: If it was protected with the group mode, the request hash 750 would need to be fed into a group key derivation just for this corner 751 case. Furthermore, there would need to be a signature in spite of no 752 authentication credential (and public key included therein) 753 associated with the Deterministic Client. ] 754 When a server receives a request from the Deterministic Client as 755 addressed to a CoAP group, the server proceeds as defined in 756 Section 3.4.3, with the difference that it MUST include its own 757 Sender ID in the response, as 'kid' parameter of the OSCORE option. 759 Although it is normally optional for the server to include its Sender 760 ID when replying to a request protected in pairwise mode, it is 761 required in this case for allowing the client to retrieve the 762 Recipient Context associated with the server originating the 763 response. 765 4. Obtaining Information about the Deterministic Client 767 This section extends the Joining Process defined in 768 [I-D.ietf-ace-key-groupcomm-oscore], and based on the ACE framework 769 for Authentication and Authorization [I-D.ietf-ace-oauth-authz]. 770 Upon joining the OSCORE group, this enables a new group member to 771 obtain from the Group Manager the required information about the 772 Deterministic Client (see Section 3.4.1). 774 With reference to the 'key' parameter of the Joining Response defined 775 in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore], the 776 Group_OSCORE_Input_Material object specified as its value contains 777 also the two additional parameters 'det_senderId' and 'det_hash_alg'. 778 These are defined in Section 6.2 of this document. In particular: 780 * The 'det_senderId' parameter, if present, has as value the OSCORE 781 Sender ID assigned to the Deterministic Client by the Group 782 Manager. This parameter MUST be present if the OSCORE group uses 783 deterministic requests as defined in this document. Otherwise, 784 this parameter MUST NOT be present. 786 * The 'det_hash_alg' parameter, if present, has as value the hash 787 algorithm to use for computing the hash of a plain CoAP request, 788 when producing the associated Deterministic Request. This 789 parameter takes values from the "Value" column of the "COSE 790 Algorithms" Registry [COSE.Algorithms]. This parameter MUST be 791 present if the OSCORE group uses deterministic requests as defined 792 in this document. Otherwise, this parameter MUST NOT be present. 794 The same extension above applies also to the 'key' parameter when 795 included in a Key Distribution Response (see Sections 8.1 and 8.2 of 796 [I-D.ietf-ace-key-groupcomm-oscore]) and in a Signature Verification 797 Data Response (see Section 13 of 798 [I-D.ietf-ace-key-groupcomm-oscore]). 800 5. Security Considerations 802 The same security considerations from [RFC7252][I-D.ietf-core-groupco 803 mm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this 804 document. 806 Compared to Group OSCORE, deterministic requests dispense with some 807 of OSCORE's security properties by just so much as to make caching 808 possible: 810 * Receiving a response to a deterministic request does not mean that 811 the response was generated after the request was sent. 813 It still contains two freshness statements, though: 815 - It is more recent than any other response from the same group 816 member that has a smaller sequence number. 818 - It is more recent than the original creation of the 819 deterministic security context's key material. 821 * Request privacy is limited. 823 An intermediary can determine that two requests from different 824 clients are identical, and associate the different responses 825 generated for them. A server producing responses of varying size 826 to a request can use the Padding option to hide when the response 827 is changing. 829 * Source authentication for requests is lost. 831 Instead, the server must verify that the request (precisely: its 832 handler) is side effect free. The distinct semantics of the CoAP 833 request codes can help the server make that assessment. 835 [ More on the verification of the Deterministic Request ] 837 6. IANA Considerations 839 This document has the following actions for IANA. 841 6.1. CoAP Option Numbers Registry 843 IANA is asked to enter the following option numbers to the "CoAP 844 Option Numbers" registry defined in [RFC7252] within the "CoRE 845 Parameters" registry. 847 +--------+--------------+-------------------+ 848 | Number | Name | Reference | 849 +--------+--------------+-------------------+ 850 | TBD1 | Request-Hash | [[this document]] | 851 +--------+--------------+-------------------+ 852 | TBD2 | Padding | [[this document]] | 853 +--------+--------------+-------------------+ 855 Figure 2: CoAP Option Numbers 857 [ 859 For the Request-Hash option, the number suggested to IANA is 548. 861 For the Padding option, the option number is picked to be the highest 862 number in the Experts Review range; the high option number allows it 863 to follow practically all other options, and thus to be set when the 864 final unpadded message length including all options is known. 865 Therefore, the number suggested to IANA is 64988. 867 Applications that make use of the "Experimental use" range and want 868 to preserve that property are invited to pick the largest suitable 869 experimental number (65532) 871 Note that unless other high options are used, this means that padding 872 a message adds an overhead of at least 3 bytes, i.e., 1 byte for 873 option delta/length and two more bytes of extended option delta. 874 This is considered acceptable overhead, given that the application 875 has already chosen to prefer the privacy gains of padding over wire 876 transfer length. 878 ] 880 6.2. OSCORE Security Context Parameters Registry 882 IANA is asked to register the following entries in the "OSCORE 883 Security Context Parameters" Registry defined in Section 9.4 of 884 [I-D.ietf-ace-oscore-profile]. 886 * Name: det_senderId 888 * CBOR Label: TBD3 890 * CBOR Type: bstr 892 * Registry: - 893 * Description: OSCORE Sender ID assigned to the Deterministic Client 894 of an OSCORE group 896 * Reference: [[this document]] (Section 4) 898 * Name: det_hash_alg 900 * CBOR Label: TBD4 902 * CBOR Type: int / tstr 904 * Registry: - 906 * Description: Hash algorithm to use in an OSCORE group when 907 producing a Deterministic Request 909 * Reference: [[this document]] (Section 4) 911 7. References 913 7.1. Normative References 915 [I-D.ietf-core-groupcomm-bis] 916 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 917 for the Constrained Application Protocol (CoAP)", Work in 918 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 919 05, 25 October 2021, 920 . 923 [I-D.ietf-core-oscore-groupcomm] 924 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 925 and J. Park, "Group OSCORE - Secure Group Communication 926 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 927 core-oscore-groupcomm-13, 25 October 2021, 928 . 931 [I-D.ietf-cose-rfc8152bis-struct] 932 Schaad, J., "CBOR Object Signing and Encryption (COSE): 933 Structures and Process", Work in Progress, Internet-Draft, 934 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 935 . 938 [I-D.ietf-cose-rfc8152bis-algs] 939 Schaad, J., "CBOR Object Signing and Encryption (COSE): 940 Initial Algorithms", Work in Progress, Internet-Draft, 941 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 942 . 945 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 946 Requirement Levels", BCP 14, RFC 2119, 947 DOI 10.17487/RFC2119, March 1997, 948 . 950 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 951 Application Protocol (CoAP)", RFC 7252, 952 DOI 10.17487/RFC7252, June 2014, 953 . 955 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 956 FETCH Methods for the Constrained Application Protocol 957 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 958 . 960 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 961 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 962 May 2017, . 964 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 965 "Object Security for Constrained RESTful Environments 966 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 967 . 969 [COSE.Algorithms] 970 IANA, "COSE Algorithms", 971 . 974 7.2. Informative References 976 [RFC7641] Hartke, K., "Observing Resources in the Constrained 977 Application Protocol (CoAP)", RFC 7641, 978 DOI 10.17487/RFC7641, September 2015, 979 . 981 [RFC9175] Amsüss, C., Preuß Mattsson, J., and G. Selander, 982 "Constrained Application Protocol (CoAP): Echo, Request- 983 Tag, and Token Processing", RFC 9175, 984 DOI 10.17487/RFC9175, February 2022, 985 . 987 [I-D.ietf-ace-key-groupcomm-oscore] 988 Tiloca, M., Park, J., and F. Palombini, "Key Management 989 for OSCORE Groups in ACE", Work in Progress, Internet- 990 Draft, draft-ietf-ace-key-groupcomm-oscore-12, 25 October 991 2021, . 994 [I-D.amsuess-lwig-oscore] 995 Amsüss, C., "OSCORE Implementation Guidance", Work in 996 Progress, Internet-Draft, draft-amsuess-lwig-oscore-00, 29 997 April 2020, . 1000 [I-D.ietf-core-observe-multicast-notifications] 1001 Tiloca, M., Höglund, R., Amsüss, C., and F. Palombini, 1002 "Observe Notifications as CoAP Multicast Responses", Work 1003 in Progress, Internet-Draft, draft-ietf-core-observe- 1004 multicast-notifications-02, 25 October 2021, 1005 . 1008 [I-D.ietf-ace-oauth-authz] 1009 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 1010 H. Tschofenig, "Authentication and Authorization for 1011 Constrained Environments (ACE) using the OAuth 2.0 1012 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 1013 draft-ietf-ace-oauth-authz-46, 8 November 2021, 1014 . 1017 [I-D.ietf-ace-oscore-profile] 1018 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 1019 "OSCORE Profile of the Authentication and Authorization 1020 for Constrained Environments Framework", Work in Progress, 1021 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 1022 2021, . 1025 [SW-EPIV] Lucas, G., "Star Wars", Lucasfilm Ltd. , 1977. 1027 [I-D.bormann-core-responses] 1028 Bormann, C. and C. Amsüss, "CoAP: Non-traditional response 1029 forms", Work in Progress, Internet-Draft, draft-bormann- 1030 core-responses-01, 3 February 2022, 1031 . 1034 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 1035 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 1036 Application Protocol) over TCP, TLS, and WebSockets", 1037 RFC 8323, DOI 10.17487/RFC8323, February 2018, 1038 . 1040 Appendix A. Change log 1042 Since -03: 1044 * Processing steps in case only inner Observe is included. 1046 * Clarified preserving/eliding the Request-Hash option in responses. 1048 * Clarified limited use of the Echo option. 1050 * Clarifications on using the Padding option. 1052 Since -02: 1054 * Separate parts needed to respond to unauthenticated requests from 1055 the remaining deterministic response part. (Currently this is 1056 mainly an addition; the document will undergo further refactoring 1057 if that split proves helpful). 1059 * Inner Observe is set unconditionally in deterministic requests. 1061 * Clarifications around padding and security considerations. 1063 Since -01: 1065 * Not meddling with request_kid any more. 1067 Instead, Request-Hash in responses is treated as Class I, but 1068 typically elided. 1070 In requests, this removes the need to compute the external_aad 1071 twice. 1073 * Derivation of the hash now uses the external_aad, rather than the 1074 full AAD. This is good enough because AAD is a function only of 1075 the external_aad, and the external_aad is easier to get your hands 1076 on if COSE manages all the rest. 1078 * The Sender ID of the Deterministic Client is immutable throughout 1079 the group lifetime. Hence, no need for any related expiration/ 1080 creation time and mechanisms to perform its update in the group. 1082 * Extension to the ACE Group Manager of ace-key-groupcomm-oscore to 1083 provide required info about the Deterministic Client to new group 1084 members when joining the group. 1086 * Alignment with changes in core-oscore-groupcomm-12. 1088 * Editorial improvements. 1090 Since -00: 1092 * More precise specification of the hashing (guided by first 1093 implementations) 1095 * Focus shifted to deterministic requests (where it should have been 1096 in the first place; all the build-up of Token Requests was moved 1097 to a motivating appendix) 1099 * Aligned with draft-tiloca-core-observe-responses-multicast-05 (not 1100 submitted at the time of submission) 1102 * List the security properties lost compared to OSCORE 1104 Appendix B. Padding 1106 As discussed in Section 5, information can be leaked by the length of 1107 a response or, in different contexts, of a request. 1109 In order to hide such information and mitigate the impact on privacy, 1110 the following Padding option is defined, to allow increasing a 1111 message's length without changing its meaning. 1113 The option can be used with any CoAP transport, but is especially 1114 useful with OSCORE as that does not provide any padding of its own. 1116 Before choosing to pad a message by using the Padding option, 1117 application designers should consider whether they can arrange for 1118 common message variants to have the same length by picking a suitable 1119 content representation; the canonical example here is expressing 1120 "yes" and "no" with "y" and "n", respectively. 1122 B.1. Definition of the Padding Option 1124 As summarized in Figure 3, the Padding option is elective, safe to 1125 forward and not part of the cache key; these follow from the usage 1126 instructions. The option may be repeated, as that may be the only 1127 way to achieve a certain total length for the padded message. 1129 +------+---+---+---+---+---------+--------+--------+---------+ 1130 | No. | C | U | N | R | Name | Format | Length | Default | 1131 +------+---+---+---+---+---------+--------+--------+---------+ 1132 | TBD2 | | | x | x | Padding | opaque | any | (none) | 1133 +------+---+---+---+---+---------+--------+--------+---------+ 1135 Figure 3: Padding Option 1137 When used with OSCORE, the Padding option is of Class E, this makes 1138 it indistinguishable from other Class E options or the payload to 1139 third parties. 1141 B.2. Using and processing the Padding option 1143 When a server produces different responses of different length for a 1144 given class of requests but wishes to produce responses of consistent 1145 length (typically to hide the variation from anyone but the intended 1146 recipient), the server can pick a length that all possible responses 1147 can be padded to, and set the Padding option with a suitable all-zero 1148 option value in all responses to that class of requests. 1150 Likewise, a client can decide on a class of requests that it pads to 1151 consistent length. This has considerably less efficacy and 1152 applicability when applied to Deterministic Requests. That is: an 1153 external observer can group requests even if they are of the same 1154 length; and padding would hinder convergence on a single Consensus 1155 Request, thus requiring all users of the same OSCORE Security Context 1156 to agree on the same total length in advance. 1158 Any party receiving a Padding option MUST ignore it. In particular, 1159 a server MUST NOT make its choice of padding dependent on any padding 1160 present in the request. (An option to coordinate response padding 1161 driven by the client is out of scope for this document). 1163 Proxies that see a padding option MAY discard it. 1165 Appendix C. Simple Cacheability using Ticket Requests 1167 Building on the concept of Phantom Requests and Informative Responses 1168 defined in [I-D.ietf-core-observe-multicast-notifications], basic 1169 caching is already possible without building a Deterministic Request. 1171 The approach discussed in this appendix is not provided for 1172 application. In fact, it is efficient only when dealing with very 1173 large representations and no OSCORE inner Block-Wise mode (which is 1174 inefficient for other reasons), or when dealing with observe 1175 notifications (which are already well covered in 1176 [I-D.ietf-core-observe-multicast-notifications]). 1178 Rather, it is more provided as a "mental exercise" for the authors 1179 and interested readers to bridge the gap between this document and 1180 [I-D.ietf-core-observe-multicast-notifications]. 1182 That is, instead of replying to a client with a regular response, a 1183 server can send an Informative Response, defined as a protected 5.03 1184 (Service Unavailable) error message. The payload of the Informative 1185 Response contains the Phantom Request, which is a Ticket Request in 1186 this document's broader terminology. 1188 Unlike a Deterministic Request, a Phantom Request is protected in 1189 Group Mode. Instead of verifying a hash, the client can see from the 1190 signature that this was indeed the request the server is answering. 1191 The client also verifies that the request URI is identical between 1192 the original request and the Ticket Request. 1194 The remaining exchange largely plays out like in 1195 [I-D.ietf-core-observe-multicast-notifications]'s "Example with a 1196 Proxy and Group OSCORE": The client sends the Phantom Request to the 1197 proxy (but, lacking a tp_info, without a Listen-To-Multicast- 1198 Responses option), which forwards it to the server for lack of the 1199 option. 1201 The server then produces a regular response and includes a non-zero 1202 Max-Age option as an outer CoAP option. Note that there is no point 1203 in including an inner Max-Age option, as the client could not pin it 1204 in time. 1206 When a second, different client later asks for the same resource at 1207 the same server, its new request uses a different 'kid' and 'Partial 1208 IV' than the first client's. Thus, the new request produces a cache 1209 miss at the proxy and is forwarded to the server, which responds with 1210 the same Ticket Request provided to the first client. After that, 1211 when the second client sends the Ticket Request, a cache hit at the 1212 proxy will be produced, and the Ticket Request can be served from the 1213 proxy's cache. 1215 When multiple proxies are in use, or the response has expired from 1216 the proxy's cache, the server receives the Ticket Request multiple 1217 times. It is a matter of perspective whether the server treats that 1218 as an acceptable replay (given that this whole mechansim only makes 1219 sense on requests free of side effects), or whether it is 1220 conceptualized as having an internal proxy where the request produces 1221 a cache hit. 1223 Appendix D. Application for More Efficient End-to-End Protected 1224 Multicast Notifications 1226 [I-D.ietf-core-observe-multicast-notifications] defines how a CoAP 1227 server can serve all clients observing a same resource at once, by 1228 sending notifications over multicast. The approach supports the 1229 possible presence of intermediaries such as proxies, also if Group 1230 OSCORE is used to protect notifications end-to-end. 1232 However, comparing the "Example with a Proxy" in Appendix A of 1233 [I-D.ietf-core-observe-multicast-notifications] and the "Example with 1234 a Proxy and Group OSCORE" in Appendix B of 1235 [I-D.ietf-core-observe-multicast-notifications] shows that, when 1236 using Group OSCORE, more requests need to hit the server. This is 1237 because every client originally protects its Observation request 1238 individually, and thus needs a custom response served to obtain the 1239 Phantom Request as a Ticket Request. 1241 If the clients send their requests as the same deterministic request, 1242 the server can use these requests as Ticket Requests as well. Thus, 1243 there is no need for the server to provide a same Phantom Request to 1244 each client. 1246 Instead, the server can send a single unprotected Informative 1247 Response - very much like in the example without Group OSCORE - hence 1248 setting the proxy up and optionally providing also the latest 1249 notification along the way. 1251 The proxy can thus be configured by the server following the first 1252 request from the clients, after which it has an active observation 1253 and a fresh cache entry in time for the second client to arrive. 1255 Appendix E. Open questions 1257 * Is "deterministic encryption" something worthwhile to consider in 1258 COSE? 1260 COSE would probably specify something more elaborate for the KDF 1261 (the current KDF round is the pairwise mode's; COSE would probably 1262 run through KDF with a KDF context structure). 1264 COSE would give a header parameter name to the Request-Hash (which 1265 for the purpose of OSCORE deterministic requests would put back 1266 into Request-Hash by extending the option compression function 1267 across the two options). 1269 Conceptually, they should align well, and the implementation 1270 changes are likely limited to how the KDF is run. 1272 * An unprotection failure from a mismatched hash will not be part of 1273 the ideally constant-time code paths that otherwise lead to AEAD 1274 unprotect failures. Is that a problem? 1276 After all, it does tell the attacker that they did succeed in 1277 producing a valid MAC (it's just not doing it any good, because 1278 this key is only used for deterministic requests and thus also 1279 needs to pass the Request-Hash check). 1281 Appendix F. Unsorted further ideas 1283 * All or none of the deterministic requests should have an inner 1284 observe option. Preferably none -- that makes messages shorter, 1285 and clients need to ignore that option either way when checking 1286 whether a Consensus Request matches their intended request. 1288 * We could allows clients to elide all other options than Request- 1289 Hash, and elide the payload, if it has reason to believe that it 1290 can produce a cache hit with the abbreviated request alone. 1292 This may prove troublesome in terms of cache invalidation (the 1293 server would have to use short-lived responses to indicate that it 1294 does need the full request, or we'd need special handling for 1295 error responses, or criteria by which proxies don't even forward 1296 these if they don't have a response at hand). 1298 That may be more trouble than it's worth without a strong use case 1299 (say, of complex but converging FETCH requests). 1301 Hashes could also be used in truncated form for that. 1303 Acknowledgments 1305 The authors sincerely thank Michael Richardson, Jim Schaad and Goeran 1306 Selander for their comments and feedback. 1308 The work on this document has been partly supported by VINNOVA and 1309 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 1310 (Grant agreement 952652). 1312 Authors' Addresses 1314 Christian Amsüss 1315 Austria 1316 Email: christian@amsuess.com 1317 Marco Tiloca 1318 RISE AB 1319 Isafjordsgatan 22 1320 SE-16440 Stockholm Kista 1321 Sweden 1322 Email: marco.tiloca@ri.se