idnits 2.17.1 draft-amsuess-core-cachable-oscore-03.txt: -(2): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(920): 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 5 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 (25 October 2021) is 907 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 (-10) 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 (-46) exists of draft-ietf-ace-oauth-authz-45 == Outdated reference: A later version (-02) exists of draft-bormann-core-responses-00 Summary: 1 error (**), 0 flaws (~~), 8 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: 28 April 2022 RISE AB 6 25 October 2021 8 Cacheable OSCORE 9 draft-amsuess-core-cachable-oscore-03 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 28 April 2022. 50 Copyright Notice 52 Copyright (c) 2021 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 Simplified BSD License text 61 as described in Section 4.e of the Trust Legal Provisions and are 62 provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . . 8 74 3.4. Use of Deterministic Requests . . . . . . . . . . . . . . 9 75 3.4.1. Pre-Conditions . . . . . . . . . . . . . . . . . . . 10 76 3.4.2. Client Processing of Deterministic Request . . . . . 10 77 3.4.3. Server Processing of Deterministic Request . . . . . 12 78 3.4.4. Response to a Deterministic Request . . . . . . . . . 14 79 3.4.5. Deterministic Requests to Multiple Servers . . . . . 15 80 4. Obtaining Information about the Deterministic Client . . . . 15 81 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 82 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 83 6.1. CoAP Option Numbers Registry . . . . . . . . . . . . . . 17 84 6.2. OSCORE Security Context Parameters Registry . . . . . . . 18 85 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 87 7.2. Informative References . . . . . . . . . . . . . . . . . 20 88 Appendix A. Change log . . . . . . . . . . . . . . . . . . . . . 21 89 Appendix B. Padding . . . . . . . . . . . . . . . . . . . . . . 22 90 B.1. Definition of the Padding Option . . . . . . . . . . . . 23 91 B.2. Using and processing the Padding option . . . . . . . . . 23 92 Appendix C. Simple Cacheability using Ticket Requests . . . . . 24 93 Appendix D. Application for More Efficient End-to-End Protected 94 Multicast Notifications . . . . . . . . . . . . . . . . . 25 95 Appendix E. Open questions . . . . . . . . . . . . . . . . . . . 26 96 Appendix F. Unsorted further ideas . . . . . . . . . . . . . . . 26 97 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 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 protected with Group OSCORE that 188 can be used repeatedly to access a particular resource, hosted at 189 one or more servers in the OSCORE group. 191 A Consensus Request has all the properties relevant to caching, 192 but its transport dependent properties (e.g. Token or Message ID) 193 are not defined. Thus, different requests on the wire can be said 194 to "be the same Consensus Request" even if they have different 195 Tokens or source addresses. 197 The Consensus Request is the reference for request-response 198 binding. In general, a client processing a response to a 199 consensus request did not generate (and thus sign) the consensus 200 request. The client not only needs to decrypt the Consensus 201 Request to understand a response to it (for example to tell which 202 path was requested), it also needs to verify that this is the only 203 Consensus Request that could elicit this response. 205 * Deterministic Client: a fictitious member of an OSCORE group, 206 having no Sender Sequence Number, no asymmetric key pair, and no 207 Recipient Context. 209 The Group Manager sets up the Deterministic Client, and assigns it 210 a unique Sender ID as for other group members. Furthermore, the 211 Deterministic Client has only the minimum common set of privileges 212 shared by all group members. 214 * Deterministic Request: a Consensus Request generated by the 215 Deterministic Client. The use of Deterministic Requests is 216 defined in Section 3. 218 * Ticket Request: a Consensus Request generated by the server 219 itself. 221 This term is not used in the main document, but is useful in 222 comparison with other applications of consensus requests that are 223 generated in a different way than as a Deterministic Request. The 224 prototypical Ticket Request is the Phantom Request defined in 225 [I-D.ietf-core-observe-multicast-notifications]. 227 In Appendix C, the term is used to bridge the gap to that draft. 229 2. OSCORE processing without source authentication 231 The request-response binding of OSCORE is achieved by the request_kid 232 / request_pid items (and, in group OSCORE, request_kid_context) 233 present in the response's AAD. It security depends on the server 234 obtaining source authentication for the request: Without, a malicious 235 group member could alter a request to the server (without altering 236 the request_ details above), and the client would still accept the 237 response as if it were a response to its request. 239 Source authentication is thus a precondition to secure use of OSCORE. 240 However, it is hard to provide when: 242 * Requests are built exclusively using shared key material (as in a 243 deterministic client). 245 * Requests are sent without source authentication, or where the 246 source authentication is not checked. (This was part of 247 [I-D.ietf-core-oscore-groupcomm] in revisions before -12). 249 This document does not [ yet? ] give full guidance on how to restore 250 request-response binding for the general case, but currently only 251 offers suggestions: 253 * The response can contain the full request. An option that allows 254 doing that was presented in [I-D.bormann-core-responses]. 256 * The response can contain a cryptographic hash of the full request. 257 This is used in Section 3.3. 259 * The above details can be transported in a Class E option 260 (encrypted) or a a Class I option (unencrypted but part of the 261 AAD). The latter has the advantage that it can be removed in 262 transit and reconstructed at the receiver. 264 * Alternatively, the agreed-on request data can be placed in a 265 different position in the AAD, or be part of the security context 266 derivation. In the latter case, care needs to be taken to never 267 initialize a security context twice with the same input, as that 268 would lead to nonce reuse. 270 [ Suggestion for any OSCORE v2: avoid request details in the 271 request's AAD as individual elements. Rather than having 272 'request_kid', 'request_piv' and (in Group OSCORE) 273 'request_kid_context' as separate fields, they can better be 274 something more pluggable. This would avoid the need to make up an 275 option before processing, and would allow just plugging in the hash 276 or request in there replacing the request_ items. ] 278 Additional care has to be taken that details not expressed in the 279 request itself (like the security context from which it is assumed to 280 have originated) are captured. 282 Processing of requests without source authentication has to be done 283 assuming only the minimal possible privilege of the requester [ which 284 currently described as the authorization of the deterministic client, 285 and may be moved up here in later versions of this document ]. If a 286 response is built to such a request that contains data more sensitive 287 than that (which might be justified if the response is protected for 288 an authorized group member in pairwise response mode), special 289 consideration for any side channels like response size or timing is 290 required. 292 3. Deterministic Requests 294 This section defines a method for clients starting from a same plain 295 CoAP request to independently arrive at a same Deterministic Request 296 protected with Group OSCORE. 298 3.1. Deterministic Unprotected Request 300 Clients build the unprotected Deterministic Request in a way which is 301 as much reproducible as possible. This document does not set out 302 full guidelines for minimizing the variation, but considered starting 303 points are: 305 * Set the inner Observe option to 0, even if no observation is 306 intended (and no outer Observe is set). Thus, both observing and 307 non-observing requests can be aggregated into a single request, 308 that is upstreamed as an observation at the latest when any 309 observing request reaches the proxy. 311 * Avoid setting the ETag option in requests on a whim. Only set it 312 when there was a recent response with that ETag. When obtaining 313 later blocks, do not send the known-stale ETag. 315 * In block-wise transfer, maximally sized large inner blocks (szx=6) 316 should be selected. This serves not only to align the clients on 317 consistent cache entries, but also helps amortize the additional 318 data transferred in the per-message signatures. 320 Outer block-wise transfer can then be used if these messages excede a 321 hop's efficiently usable MTU size. 323 (If BERT [RFC8323] is usable with OSCORE, its use is fine as well; in 324 that case, the server picks a consistent block size for all clients 325 anyway). 327 * If padding (see Appendix B) is used to limit an adversary's 328 ability to deduce requests' content from their length, the 329 requests are padded to reach a total length that should be agreed 330 on among all users of a security context. 332 These only serve to ensure that cache entries are utilized; failure 333 to follow them has no more severe consequences than decreasing the 334 utility and effectiveness of a cache. 336 3.2. Design Considerations 338 The hard part is arriving at a consensus pair (key, nonce) to be used 339 with the AEAD cipher for encrypting the Deterministic Request, while 340 also avoiding reuse of the same (key, nonce) pair across different 341 requests. 343 Diversity can conceptually be enforced by applying a cryptographic 344 hash function to the complete input of the encryption operation over 345 the plain CoAP request (i.e., the AAD and the plaintext of the COSE 346 object), and then using the result as source of uniqueness. Any non- 347 malleable cryptographically secure hash of sufficient length to make 348 collisions sufficiently unlikely is suitable for this purpose. 350 A tempting possibility is to use a fixed (group) key, and use the 351 hash as a deterministic AEAD nonce for each Deterministic Request 352 throught the Partial IV component (see Section 5.2 of [RFC8613]). 353 However, the 40 bit available for the Partial IV are by far 354 insufficient to ensure that the deterministic nonce is not reused 355 across different Deterministic Requests. Even if the full 356 deterministic AEAD nonce could be set, the sizes used by common 357 algorithms would still be too small. 359 As a consequence, the proposed method takes the opposite approach, by 360 considering a fixed deterministic AEAD nonce, while generating a 361 different deterministic encryption key for each Deterministic 362 Request. That is, the hash computed over the plain CoAP request is 363 taken as input to the key generation. As an advantage, this approach 364 does not require to transport the computed hash in the OSCORE option. 366 [ Note: This has a further positive side effect arising with version 367 -11 of Group OSCORE. That is, since the full encoded OSCORE option 368 is part of the AAD, it avoids a circular dependency from feeding the 369 AAD into the hash computation, which in turn needs crude workarounds 370 like building the full AAD twice, or zeroing out the hash-to-be. ] 372 3.3. Request-Hash 374 In order to transport the hash of the plain CoAP request, a new CoAP 375 option is defined, which MUST be supported by clients and servers 376 that support Deterministic Requests. 378 The option is called Request-Hash. As summarized in Figure 1, the 379 Request-Hash option is elective, safe to forward, part of the cache 380 key and repeatable. 382 +------+---+---+---+---+--------------+--------+--------+---------+ 383 | No. | C | U | N | R | Name | Format | Length | Default | 384 +------+---+---+---+---+--------------+--------+--------+---------+ 385 | TBD1 | | | | x | Request-Hash | opaque | any | (none) | 386 +------+---+---+---+---+--------------+--------+--------+---------+ 388 Figure 1: Request-Hash Option 390 The Request-Hash option is identical in all its properties to the 391 Request-Tag option defined in [I-D.ietf-core-echo-request-tag], with 392 the following exceptions: 394 * It may be arbitrarily long. 396 Implementations can limit its length to that of the longest output 397 of the supported hash functions. 399 * A proxy MAY use any fresh cached response from the selected server 400 to respond to a request with the same Request-Hash (or possibly 401 even if the new request's Request-Hash is a prefix of the cached 402 one). 404 This is a potential future optimization which is not mentioned 405 anywhere else yet, and allows clients to elide all other options 406 and payload if it has reason to believe that it can produce a 407 cache hit with the abbreviated request alone. 409 * It may be present in responses (TBD: Does this affect any other 410 properties?). 412 * When used with a Deterministic Request, this option is created at 413 message protection time by the sender, and used before message 414 unprotection by the recipient. Therefore, in this use case, it is 415 treated as Class U for OSCORE [RFC8613] in requests. In the same 416 application, for responses, it is treated as Class I, and often 417 elided from sending (but reconstructed at the receiver). Other 418 uses of this option can put it into different classes for the 419 OSCORE processing. 421 This option achieves request-response binding described in Section 2. 423 3.4. Use of Deterministic Requests 425 This section defines how a Deterministic Request is built on the 426 client side and then processed on the server side. 428 3.4.1. Pre-Conditions 430 The use of Deterministic Requests in an OSCORE group requires that 431 the interested group members are aware of the Deterministic Client in 432 the group. In particular, they need to know: 434 * The Sender ID of the Deterministic Client, to be used as 'kid' 435 parameter for the Deterministic Requests. This allows all group 436 members to compute the Sender Key of the Deterministic Client. 438 The Sender ID of the Deterministic Client is immutable throughout 439 the lifetime of the OSCORE group. That is, it is not relinquished 440 and it does not change upon changes of the group keying material 441 following a group rekeying performed by the Group Manager. 443 * The hash algorithm to use for computing the hash of a plain CoAP 444 request, when producing the associated Deterministic Request. 446 Group members have to obtain this information from the Group Manager. 447 A group member can do that, for instance, when obtaining the group 448 keying material upon joining the OSCORE group, or later on as an 449 active member by sending a request to a dedicated resource at the 450 Group Manager. 452 The joining process based on the Group Manager defined in 453 [I-D.ietf-ace-key-groupcomm-oscore] can be easily extended to support 454 the provisioning of information about the Deterministic Client. Such 455 an extension is defined in Section 4 of this document. 457 3.4.2. Client Processing of Deterministic Request 459 In order to build a Deterministic Request, the client protects the 460 plain CoAP request using the pairwise mode of Group OSCORE (see 461 Section 9 of [I-D.ietf-core-oscore-groupcomm]), with the following 462 alterations. 464 1. When preparing the OSCORE option, the external_aad and the AEAD 465 nonce: 467 * The used Sender ID is the Deterministic Client's Sender ID. 469 * The used Partial IV is 0. 471 When preparing the external_aad, the element 'sender_public_key' 472 in the aad_array takes the empty CBOR byte string. 474 2. The client uses the hash function indicated for the Deterministic 475 Client, and computes a hash H over the following input: the 476 Sender Key of the Deterministic Client, concatenated with the 477 external_aad from step 1, concatenated with the COSE plaintext. 479 Note that the payload of the plain CoAP request (if any) is not 480 self-delimiting, and thus hash functions are limited to non- 481 malleable ones. 483 3. The client derives the deterministic Pairwise Sender Key K as 484 defined in Section 2.3.1 of [I-D.ietf-core-oscore-groupcomm], 485 with the following differences: 487 * The Sender Key of the Deterministic Client is used as first 488 argument of the HKDF. 490 * The hash H from step 2 is used as second argument of the HKDF, 491 i.e. as a pseudo IKM-Sender computable by all the group 492 members. 494 Note that an actual IKM-Sender cannot be obtained, since there 495 is no public key associated with the deterministic client, to 496 be used as Sender Public Key and for computing an actual 497 Diffie-Hellman Shared Secret. 499 * The Sender ID of the Deterministic Client is used as value for 500 the 'id' element of the 'info' parameter used as third 501 argument of the HKDF. 503 4. The client includes a Request-Hash option in the request to 504 protect, with value set to the hash H from Step 2. 506 5. The client protects the request using the pairwise mode of Group 507 OSCORE as defined in Section 9.3 of 508 [I-D.ietf-core-oscore-groupcomm], using the AEAD nonce from step 509 1, the deterministic Pairwise Sender Key K from step 3 as AEAD 510 encryption key, and the finalized AAD. 512 6. The client sets FETCH as the outer code of the protected request 513 to make it usable for a proxy's cache, even if no observation is 514 requested [RFC7641]. 516 The result is the Deterministic Request to be sent. 518 Since the encryption key K is derived using material from the whole 519 plain CoAP request, this (key, nonce) pair is only used for this very 520 message, which is deterministically encrypted unless there is a hash 521 collision between two Deterministic Requests. 523 The deterministic encryption requires the used AEAD algorithm to be 524 deterministic in itself. This is the case for all the AEAD 525 algorithms currently registered with COSE in [COSE.Algorithms]. For 526 future algorithms, a flag in the COSE registry is to be added. 528 Note that, while the process defined above is based on the pairwise 529 mode of Group OSCORE, no information about the server takes part to 530 the key derivation or is included in the AAD. This is intentional, 531 since it allows for sending a deterministic request to multiple 532 servers at once (see Section 3.4.5). On the other hand, it requires 533 later checks at the client when verifying a response to a 534 Deterministic Request (see Section 3.4.4). 536 3.4.3. Server Processing of Deterministic Request 538 Upon receiving a Deterministic Request, a server performs the 539 following actions. 541 A server that does not support Deterministic Requests would not be 542 able to create the necessary Recipient Context, and thus will fail 543 decrypting the request. 545 1. If not already available, the server retrieves the information 546 about the Deterministic Client from the Group Manager, and 547 derives the Sender Key of the Deterministic Client. 549 2. The server actually recognizes the request to be a Deterministic 550 Request, due to the presence of the Request-Hash option and to 551 the 'kid' parameter of the OSCORE option set to the Sender ID of 552 the Deterministic Client. 554 If the 'kid' parameter of the OSCORE option specifies a different 555 Sender ID than the one of the Deterministic Client, the server 556 MUST NOT take the following steps, and instead processes the 557 request as per Section 9.4 of [I-D.ietf-core-oscore-groupcomm]. 559 3. The server retrieves the hash H from the Request-Hash option. 561 4. The server derives a Recipient Context for processing the 562 Deterministic Request. In particular: 564 * The Recipient ID is the Sender ID of the Deterministic Client. 566 * The Recipient Key is derived as the key K in step 3 of 567 Section 3.4.2, with the hash H retrieved at the previous step. 569 5. The server verifies the request using the pairwise mode of Group 570 OSCORE, as defined in Section 9.4 of 571 [I-D.ietf-core-oscore-groupcomm], using the Recipient Context 572 from step 4, with the following differences. 574 * The server does not perform replay checks against a Replay 575 Window (see below). 577 In case of successful verification, the server MUST also perform the 578 following actions, before possibly delivering the request to the 579 application. 581 * Starting from the recovered plain CoAP request, the server MUST 582 recompute the same hash that the client computed at step 2 of 583 Section 3.4.2. 585 If the recomputed hash value differs from the value retrieved from 586 the Request-Hash option at step 3, the server MUST treat the 587 request as invalid and MAY reply with an unprotected 4.00 (Bad 588 Request) error response. The server MAY set an Outer Max-Age 589 option with value zero. The diagnostic payload MAY contain the 590 string "Decryption failed". 592 This prevents an attacker that guessed a valid authentication tag 593 for a given Request-Hash value to poison caches with incorrect 594 responses. 596 * The server MUST verify that the unprotected request is safe to be 597 processed in the REST sense, i.e. that it has no side effects. If 598 verification fails, the server MUST discard the message and SHOULD 599 reply with a protected 4.01 (Unauthorized) error response. 601 Note that some CoAP implementations may not be able to prevent 602 that an application produces side effects from a safe request. 603 This may incur checking whether the particular resource handler is 604 explicitly marked as eligible for processing deterministic 605 requests. An implementation may also have a configured list of 606 requests that are known to be side effect free, or even a pre- 607 built list of valid hashes for all sensible requests for them, and 608 reject any other request. 610 These checks replace the otherwise present requirement that the 611 server needs to check the Replay Window of the Recipient Context 612 (see step 5 above), which is inapplicable with the Recipient 613 Context derived at step 4 from the value of the Request-Hash 614 option. The reasoning is analogous to the one in 615 [I-D.amsuess-lwig-oscore] to treat the potential replay as 616 answerable, if the handled request is side effect free. 618 3.4.4. Response to a Deterministic Request 620 When treating a response to a deterministic request, the Request-Hash 621 option is treated as a Class I option. This creates the request- 622 response binding ensuring that no mismatched responses can be 623 successfully unprotected (see Section 2). The option does not 624 actually need to be present in the message as transported (the server 625 SHOULD elide it for compactness). The client MUST reject responses 626 with a Request-Hash not matching the one it sent in the request. 628 When preparing the response, the server performs the following 629 actions. 631 * The server sets a non-zero Max-Age option, thus making the 632 Deterministic Request usable for the proxy cache. 634 * The server preliminarily sets the Request-Hash option with the 635 full request hash. 637 * The server MUST protect the response using the group mode of Group 638 OSCORE, as defined in Section 8.3 of 639 [I-D.ietf-core-oscore-groupcomm]. This is required to ensure that 640 the client can verify source authentication of the response, since 641 the "pairwise" key used for the Deterministic Request is actually 642 shared among all the group members. 644 Note that the Request-Hash option is treated as Class I here. 646 * The server MUST use its own Sender Sequence Number as Partial IV 647 to protect the response, and include it as Partial IV in the 648 OSCORE option of the response. This is required since the server 649 does not perform replay protection on the Deterministic Request 650 (see Section 3.4.4). 652 * The server uses 2.05 (Content) as outer code even though it is not 653 necessarily an Observe notification [RFC7641], in order to make 654 the response cacheable. 656 * The server SHOULD remove the Request-Hash option from the message 657 before sending. 659 Upon receiving the response, the client performs the following 660 actions. 662 * In case the response includes a 'kid' in the OSCORE option and 663 unless responses from multiple servers are expected (see 664 Section 3.4.5), the client MUST verify it to be exactly the 'kid' 665 of the server to which the Deterministic Request was sent. 667 * The client sets the Request-Hash option with the full request hash 668 on the reponse. If an option of a different value is already 669 present, it rejects the response. 671 * The client verifies the response using the group mode of Group 672 OSCORE, as defined in Section 8.4 of 673 [I-D.ietf-core-oscore-groupcomm]. In particular, the client 674 verifies the counter signature in the response, based on the 'kid' 675 of the server it sent the request to. When verifying the 676 response, the Request-Hash option is treated as a Class I option. 678 3.4.5. Deterministic Requests to Multiple Servers 680 A Deterministic Request _can_ be sent to a CoAP group, e.g. over UDP 681 and IP multicast [I-D.ietf-core-groupcomm-bis], thus targeting 682 multiple servers at once. 684 To simplify key derivation, such a Deterministic Request is still 685 created in the same way as a one-to-one request and still protected 686 with the pairwise mode of Group OSCORE, as defined in Section 3.4.2. 688 [ Note: If it was protected with the group mode, the request hash 689 would need to be fed into the group key derivation just for this 690 corner case. Furthermore, there would need to be a signature from 691 the absent public key. ] 693 When a server receives a request from the Deterministic Client as 694 addressed to a CoAP group, the server proceeds as defined in 695 Section 3.4.3, with the difference that it MUST include its own 696 Sender ID in the response, as 'kid' parameter of the OSCORE option. 698 Although it is normally optional for the server to include its Sender 699 ID when replying to a request protected in pairwise mode, it is 700 required in this case for allowing the client to retrieve the 701 Recipient Context associated to the server originating the response. 703 4. Obtaining Information about the Deterministic Client 705 This section extends the Joining Process defined in 706 [I-D.ietf-ace-key-groupcomm-oscore], and based on the ACE framework 707 for Authentication and Authorization [I-D.ietf-ace-oauth-authz]. 708 Upon joining the OSCORE group, this enables a new group member to 709 obtain from the Group Manager the required information about the 710 Deterministic Client (see Section 3.4.1). 712 With reference to the 'key' parameter of the Joining Response defined 713 in Section 6.4 of [I-D.ietf-ace-key-groupcomm-oscore], the 714 Group_OSCORE_Input_Material object specified as its value contains 715 also the two additional parameters 'det_senderId' and 'det_hash_alg'. 716 These are defined in Section 6.2 of this document. In particular: 718 * The 'det_senderId' parameter, if present, has as value the OSCORE 719 Sender ID assigned to the Deterministic Client by the Group 720 Manager. This parameter MUST be present if the OSCORE group uses 721 deterministic requests as defined in this document. Otherwise, 722 this parameter MUST NOT be present. 724 * The 'det_hash_alg' parameter, if present, has as value the hash 725 algorithm to use for computing the hash of a plain CoAP request, 726 when producing the associated Deterministic Request. This 727 parameter takes values from the "Value" column of the "COSE 728 Algorithms" Registry [COSE.Algorithms]. This parameter MUST be 729 present if the OSCORE group uses deterministic requests as defined 730 in this document. Otherwise, this parameter MUST NOT be present. 732 The same extension above applies also to the 'key' parameter when 733 included in a Key Distribution Response (see Sections 8.1 and 8.2 of 734 [I-D.ietf-ace-key-groupcomm-oscore]) and in a Signature Verification 735 Data Response (see Section 13 of 736 [I-D.ietf-ace-key-groupcomm-oscore]). 738 5. Security Considerations 740 The same security considerations from [RFC7252][I-D.ietf-core-groupco 741 mm-bis][RFC8613][I-D.ietf-core-oscore-groupcomm] hold for this 742 document. 744 Compared to Group OSCORE, deterministic requests dispense with some 745 of OSCORE's security properties by just so much as to make caching 746 possible: 748 * Receiving a response to a deterministic request does not mean that 749 the response was generated after the request was sent. 751 It still contains two freshness statements, though: 753 - It is more recent than any other response from the same group 754 member that has a smaller sequence number. 756 - It is more recent than the original creation of the 757 deterministic security context's key material. 759 * Request privacy is limited. 761 An intermediary can determine that two requests from different 762 clients are identical, and associate the different responses 763 generated for them. A server producing responses of varying size 764 to a request can use the Padding option to hide when the response 765 is changing. 767 * Source authentication for requests is lost. 769 Instead, the server must verify that the request (precisely: its 770 handler) is side effect free. The distinct semantics of the CoAP 771 request codes can help the server make that assessment. 773 [ More on the verification of the Deterministic Request ] 775 6. IANA Considerations 777 This document has the following actions for IANA. 779 6.1. CoAP Option Numbers Registry 781 IANA is asked to enter the following option numbers to the "CoAP 782 Option Numbers" registry defined in [RFC7252] within the "CoRE 783 Parameters" registry. 785 +--------+--------------+-------------------+ 786 | Number | Name | Reference | 787 +--------+--------------+-------------------+ 788 | TBD1 | Request-Hash | [[this document]] | 789 +--------+--------------+-------------------+ 790 | TBD2 | Padding | [[this document]] | 791 +--------+--------------+-------------------+ 793 Figure 2: CoAP Option Numbers 795 [ 797 For the Request-Hash option, the number suggested to IANA is 548. 799 For the Padding option, the option number is picked to be the highest 800 number in the Experts Review range; the high option number allows it 801 to follow practically all other options, and thus to be set when the 802 final unpadded message length including all options is known. 803 Therefore, the number suggested to IANA is 64988. 805 Applications that make use of the "Experimental use" range and want 806 to preserve that property are invited to pick the largest suitable 807 experimental number (65532) 808 Note that unless other high options are used, this means that padding 809 a message adds an overhead of at least 3 bytes, i.e. 1 byte for 810 option delta/length and two more bytes of extended option delta. 811 This is considered acceptable overhead, given that the application 812 has already chosen to prefer the privacy gains of padding over wire 813 transfer length. 815 ] 817 6.2. OSCORE Security Context Parameters Registry 819 IANA is asked to register the following entries in the "OSCORE 820 Security Context Parameters" Registry defined in Section 9.4 of 821 [I-D.ietf-ace-oscore-profile]. 823 * Name: det_senderId 825 * CBOR Label: TBD3 827 * CBOR Type: bstr 829 * Registry: - 831 * Description: OSCORE Sender ID assigned to the Deterministic Client 832 of an OSCORE group 834 * Reference: [[this document]] (Section 4) 836 * Name: det_hash_alg 838 * CBOR Label: TBD4 840 * CBOR Type: int / tstr 842 * Registry: - 844 * Description: Hash algorithm to use in an OSCORE group when 845 producing a Deterministic Request 847 * Reference: [[this document]] (Section 4) 849 7. References 851 7.1. Normative References 853 [I-D.ietf-core-groupcomm-bis] 854 Dijk, E., Wang, C., and M. Tiloca, "Group Communication 855 for the Constrained Application Protocol (CoAP)", Work in 856 Progress, Internet-Draft, draft-ietf-core-groupcomm-bis- 857 05, 25 October 2021, 858 . 861 [I-D.ietf-core-oscore-groupcomm] 862 Tiloca, M., Selander, G., Palombini, F., Mattsson, J. P., 863 and J. Park, "Group OSCORE - Secure Group Communication 864 for CoAP", Work in Progress, Internet-Draft, draft-ietf- 865 core-oscore-groupcomm-13, 25 October 2021, 866 . 869 [I-D.ietf-cose-rfc8152bis-struct] 870 Schaad, J., "CBOR Object Signing and Encryption (COSE): 871 Structures and Process", Work in Progress, Internet-Draft, 872 draft-ietf-cose-rfc8152bis-struct-15, 1 February 2021, 873 . 876 [I-D.ietf-cose-rfc8152bis-algs] 877 Schaad, J., "CBOR Object Signing and Encryption (COSE): 878 Initial Algorithms", Work in Progress, Internet-Draft, 879 draft-ietf-cose-rfc8152bis-algs-12, 24 September 2020, 880 . 883 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 884 Requirement Levels", BCP 14, RFC 2119, 885 DOI 10.17487/RFC2119, March 1997, 886 . 888 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 889 Application Protocol (CoAP)", RFC 7252, 890 DOI 10.17487/RFC7252, June 2014, 891 . 893 [RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and 894 FETCH Methods for the Constrained Application Protocol 895 (CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017, 896 . 898 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 899 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 900 May 2017, . 902 [RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, 903 "Object Security for Constrained RESTful Environments 904 (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, 905 . 907 [COSE.Algorithms] 908 IANA, "COSE Algorithms", 909 . 912 7.2. Informative References 914 [RFC7641] Hartke, K., "Observing Resources in the Constrained 915 Application Protocol (CoAP)", RFC 7641, 916 DOI 10.17487/RFC7641, September 2015, 917 . 919 [I-D.ietf-core-echo-request-tag] 920 Amsüss, C., Mattsson, J. P., and G. Selander, "CoAP: Echo, 921 Request-Tag, and Token Processing", Work in Progress, 922 Internet-Draft, draft-ietf-core-echo-request-tag-14, 4 923 October 2021, . 926 [I-D.ietf-ace-key-groupcomm-oscore] 927 Tiloca, M., Park, J., and F. Palombini, "Key Management 928 for OSCORE Groups in ACE", Work in Progress, Internet- 929 Draft, draft-ietf-ace-key-groupcomm-oscore-12, 25 October 930 2021, . 933 [I-D.amsuess-lwig-oscore] 934 Amsüss, C., "OSCORE Implementation Guidance", Work in 935 Progress, Internet-Draft, draft-amsuess-lwig-oscore-00, 29 936 April 2020, . 939 [I-D.ietf-core-observe-multicast-notifications] 940 Tiloca, M., Höglund, R., Amsüss, C., and F. Palombini, 941 "Observe Notifications as CoAP Multicast Responses", Work 942 in Progress, Internet-Draft, draft-ietf-core-observe- 943 multicast-notifications-02, 25 October 2021, 944 . 947 [I-D.ietf-ace-oauth-authz] 948 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 949 H. Tschofenig, "Authentication and Authorization for 950 Constrained Environments (ACE) using the OAuth 2.0 951 Framework (ACE-OAuth)", Work in Progress, Internet-Draft, 952 draft-ietf-ace-oauth-authz-45, 29 August 2021, 953 . 956 [I-D.ietf-ace-oscore-profile] 957 Palombini, F., Seitz, L., Selander, G., and M. Gunnarsson, 958 "OSCORE Profile of the Authentication and Authorization 959 for Constrained Environments Framework", Work in Progress, 960 Internet-Draft, draft-ietf-ace-oscore-profile-19, 6 May 961 2021, . 964 [SW-EPIV] Lucas, G., "Star Wars", Lucasfilm Ltd. , 1977. 966 [I-D.bormann-core-responses] 967 Bormann, C., "CoAP: Non-traditional response forms", Work 968 in Progress, Internet-Draft, draft-bormann-core-responses- 969 00, 12 November 2017, 970 . 973 [RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., 974 Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained 975 Application Protocol) over TCP, TLS, and WebSockets", 976 RFC 8323, DOI 10.17487/RFC8323, February 2018, 977 . 979 Appendix A. Change log 981 Since -02: 983 * Separate parts needed to respond to unauthenticated requests from 984 the remaining deterministic response part. (Currently this is 985 mainly an addition; the document will undergo further refactoring 986 if that split proves helpful). 988 * Inner Observe is set unconditionally in deterministic requests. 990 * Clarifications around padding and security considerations. 992 Since -01: 994 * Not meddling with request_kid any more. 996 Instead, Request-Hash in responses is treated as Class I, but 997 typically elided. 999 In requests, this removes the need to compute the external_aad 1000 twice. 1002 * Derivation of the hash now uses the external_aad, rather than the 1003 full AAD. This is good enough because AAD is a function only of 1004 the external_aad, and the external_aad is easier to get your hands 1005 on if COSE manages all the rest. 1007 * The Sender ID of the Deterministic Client is immutable throughout 1008 the group lifetime. Hence, no need for any related expiration/ 1009 creation time and mechanisms to perform its update in the group. 1011 * Extension to the ACE Group Manager of ace-key-groupcomm-oscore to 1012 provide required info about the Deterministic Client to new group 1013 members when joining the group. 1015 * Alignment with changes in core-oscore-groupcomm-12. 1017 * Editorial improvements. 1019 Since -00: 1021 * More precise specification of the hashing (guided by first 1022 implementations) 1024 * Focus shifted to deterministic requests (where it should have been 1025 in the first place; all the build-up of Token Requests was moved 1026 to a motivating appendix) 1028 * Aligned with draft-tiloca-core-observe-responses-multicast-05 (not 1029 submitted at the time of submission) 1031 * List the security properties lost compared to OSCORE 1033 Appendix B. Padding 1035 As discussed in Section 5, information can be leaked by the length of 1036 a response or, in different contexts, of a request. 1038 In order to hide such information and mitigate the impact on privacy, 1039 the following Padding option is defined, to allow increasing a 1040 message's length without changing its meaning. 1042 The option can be used with any CoAP transport, but is especially 1043 useful with OSCORE as that does not provide any padding of its own. 1045 Before choosing to pad a message by using the Padding option, 1046 application designers should consider whether they can arrange for 1047 common message variants to have the same length by picking a suitable 1048 content representation; the canonical example here is expressing 1049 "yes" and "no" with "y" and "n", respectively. 1051 B.1. Definition of the Padding Option 1053 As summarized in Figure 3, the Padding option is elective, safe to 1054 forward and not part of the cache key; these follow from the usage 1055 instructions. The option may be repeated, as that may be the only 1056 way to achieve a certain total length for the padded message. 1058 +------+---+---+---+---+---------+--------+--------+---------+ 1059 | No. | C | U | N | R | Name | Format | Length | Default | 1060 +------+---+---+---+---+---------+--------+--------+---------+ 1061 | TBD2 | | | x | x | Padding | opaque | any | (none) | 1062 +------+---+---+---+---+---------+--------+--------+---------+ 1064 Figure 3: Padding Option 1066 When used with OSCORE, the Padding option is of Class E, this makes 1067 it indistinguishable from other Class E options or the payload to 1068 third parties. 1070 B.2. Using and processing the Padding option 1072 When a server produces different responses of different length for a 1073 given class of requests but wishes to produce responses of consistent 1074 length (typically to hide the variation from anyone but the intended 1075 recipient), the server can pick a length that all possible responses 1076 can be padded to, and set the Padding option with a suitable all-zero 1077 option value in all responses to that class of requests. 1079 Likewise, a client can decide on a class of requests that it pads to 1080 consistent length. (This is of little applicability to Deterministic 1081 Requests; there, the observer can group requests even if they are of 1082 the same length, and padding would hinder convergence on a single 1083 consensus request). 1085 Any party receiving a Padding option MUST ignore it. In particular, 1086 a server MUST NOT make its choice of padding dependent on any padding 1087 present in the request. (An option to coordinate response padding 1088 driven by the client is out of scope for this document). 1090 Proxies that see a padding option MAY discard it. 1092 Appendix C. Simple Cacheability using Ticket Requests 1094 Building on the concept of Phantom Requests and Informative Responses 1095 defined in [I-D.ietf-core-observe-multicast-notifications], basic 1096 caching is already possible without building a Deterministic Request. 1098 The approach discussed in this appendix is not provided for 1099 application. In fact, it is efficient only when dealing with very 1100 large representations and no OSCORE inner Block-Wise mode (which is 1101 inefficient for other reasons), or when dealing with observe 1102 notifications (which are already well covered in 1103 [I-D.ietf-core-observe-multicast-notifications]). 1105 Rather, it is more provided as a "mental exercise" for the authors 1106 and interested readers to bridge the gap between this document and 1107 [I-D.ietf-core-observe-multicast-notifications]. 1109 That is, instead of replying to a client with a regular response, a 1110 server can send an Informative Response, defined as a protected 5.03 1111 (Service Unavailable) error message. The payload of the Informative 1112 Response contains the Phantom Request, which is a Ticket Request in 1113 this document's broader terminology. 1115 Unlike a Deterministic Request, a Phantom Request is protected in 1116 Group Mode. Instead of verifying a hash, the client can see from the 1117 signature that this was indeed the request the server is answering. 1118 The client also verifies that the request URI is identical between 1119 the original request and the Ticket Request. 1121 The remaining exchange largely plays out like in 1122 [I-D.ietf-core-observe-multicast-notifications]'s "Example with a 1123 Proxy and Group OSCORE": The client sends the Phantom Request to the 1124 proxy (but, lacking a tp_info, without a Listen-To-Multicast- 1125 Responses option), which forwards it to the server for lack of the 1126 option. 1128 The server then produces a regular response and includes a non-zero 1129 Max-Age option as an outer CoAP option. Note that there is no point 1130 in including an inner Max-Age option, as the client could not pin it 1131 in time. 1133 When a second, different client later asks for the same resource at 1134 the same server, its new request uses a different 'kid' and 'Partial 1135 IV' than the first client's. Thus, the new request produces a cache 1136 miss at the proxy and is forwarded to the server, which responds with 1137 the same Ticket Request provided to the first client. After that, 1138 when the second client sends the Ticket Request, a cache hit at the 1139 proxy will be produced, and the Ticket Request can be served from the 1140 proxy's cache. 1142 When multiple proxies are in use, or the response has expired from 1143 the proxy's cache, the server receives the Ticket Request multiple 1144 times. It is a matter of perspective whether the server treats that 1145 as an acceptable replay (given that this whole mechansim only makes 1146 sense on requests free of side effects), or whether it is 1147 conceptualized as having an internal proxy where the request produces 1148 a cache hit. 1150 Appendix D. Application for More Efficient End-to-End Protected 1151 Multicast Notifications 1153 [I-D.ietf-core-observe-multicast-notifications] defines how a CoAP 1154 server can serve all clients observing a same resource at once, by 1155 sending notifications over multicast. The approach supports the 1156 possible presence of intermediaries such as proxies, also if Group 1157 OSCORE is used to protect notifications end-to-end. 1159 However, comparing the "Example with a Proxy" in Appendix A of 1160 [I-D.ietf-core-observe-multicast-notifications] and the "Example with 1161 a Proxy and Group OSCORE" in Appendix B of 1162 [I-D.ietf-core-observe-multicast-notifications] shows that, when 1163 using Group OSCORE, more requests need to hit the server. This is 1164 because every client originally protects its Observation request 1165 individually, and thus needs a custom response served to obtain the 1166 Phantom Request as a Ticket Request. 1168 If the clients send their requests as the same deterministic request, 1169 the server can use these requests as Ticket Requests as well. Thus, 1170 there is no need for the server to provide a same Phantom Request to 1171 each client. 1173 Instead, the server can send a single unprotected Informative 1174 Response - very much like in the example without Group OSCORE - hence 1175 setting the proxy up and optionally providing also the latest 1176 notification along the way. 1178 The proxy can thus be configured by the server following the first 1179 request from the clients, after which it has an active observation 1180 and a fresh cache entry in time for the second client to arrive. 1182 Appendix E. Open questions 1184 * Is "deterministic encryption" something worthwhile to consider in 1185 COSE? 1187 COSE would probably specify something more elaborate for the KDF 1188 (the current KDF round is the pairwise mode's; COSE would probably 1189 run through KDF with a KDF context structure). 1191 COSE would give a header parameter name to the Request-Hash (which 1192 for the purpose of OSCORE deterministic requests would put back 1193 into Request-Hash by extending the option compression function 1194 across the two options). 1196 Conceptually, they should align well, and the implementation 1197 changes are likely limited to how the KDF is run. 1199 * An unprotection failure from a mismatched hash will not be part of 1200 the ideally constant-time code paths that otherwise lead to AEAD 1201 unprotect failures. Is that a problem? 1203 After all, it does tell the attacker that they did succeed in 1204 producing a valid MAC (it's just not doing it any good, because 1205 this key is only used for deterministic requests and thus also 1206 needs to pass the Request-Hash check). 1208 Appendix F. Unsorted further ideas 1210 * All or none of the deterministic requests should have an inner 1211 observe option. Preferably none -- that makes messages shorter, 1212 and clients need to ignore that option either way when checking 1213 whether a Consensus Request matches their intended request. 1215 Acknowledgments 1217 The authors sincerely thank Michael Richardson, Jim Schaad and Goeran 1218 Selander for their comments and feedback. 1220 The work on this document has been partly supported by VINNOVA and 1221 the Celtic-Next project CRITISEC; and by the H2020 project SIFIS-Home 1222 (Grant agreement 952652). 1224 Authors' Addresses 1226 Christian Amsüss 1227 Austria 1229 Email: christian@amsuess.com 1230 Marco Tiloca 1231 RISE AB 1232 Isafjordsgatan 22 1233 SE-16440 Stockholm Kista 1234 Sweden 1236 Email: marco.tiloca@ri.se