From a148b19a5225583207e1003b5cdfdbc44963a64e Mon Sep 17 00:00:00 2001 From: chrysn Date: Sat, 2 Mar 2024 17:34:47 +0100 Subject: [PATCH 1/4] Describe how OSCORE works with non-traditional responses --- draft-bormann-core-responses.md | 67 +++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) diff --git a/draft-bormann-core-responses.md b/draft-bormann-core-responses.md index f0fe112..097bd17 100644 --- a/draft-bormann-core-responses.md +++ b/draft-bormann-core-responses.md @@ -161,6 +161,73 @@ generated by the client, or in close collaboration with the client (for example by the client allowing a third party to use a subset of its token values in order to set up non-traditional responses). +# OSCORE processing for non-traditional responses + +OSCORE {{oscore}} is built with the assumption that requests are processed into exactly one response. +The specification contains explicit provisions for Observe requests, +and a whole protocol extension for multicast requests. + +OSCORE's binding between requests and responses remains unmodified: +Each response is cryptographically bound to an OSCORE request. +Therefore, any phantom request needs to be an OSCORE request as well, +and the parties need to agree on the sender and sequence number of the phantom request. +An easy way to do that securely is to deliver the phantom request in a way the server do the full OSCORE request processing on it. +The server may process the OSCORE request into internal data structures at reception time, +or may process it whenever a response is to be sent. +In the latter case, it may need to relax the requirements of {{Section 8.2 of oscore}} item 3. + +To avoid reinventing the same rules as for Observe requests for any other non-traditional response, +this documents defines a set of processing instructions which can be referenced when specifying their options. +These rules generalize {{Sections 8.3 and 8.4 of oscore}}: + +* In 8.3 step 3, "use the AEAD nonce from the request" is only an option one time + after the sequence number expressed in that request was removed from the replay window. + This option is usually taken in the first response, + necessitating the use encoded Sender Sequence Numbers in later responses. + (Non-traditional responses such as Observe that rely on message ordering may require that request's nonce is used either in the first response or not at all). + [^maybealwaysfirst] + + + + As a convenient effect, this generalized rule also implies + that when a server performs {{Appendix B.1.2 of oscore}}, + it needs to use its own Partial IV for the nonce + (which without this generalized rule necessitated a "MUST" statement in the appendix). + +[^maybealwaysfirst]: CA: We could also just mandate the "either the first or never" behavior. + I don't know why one would save the efficient response, + but that may be lack of imagination. + An affine type system can make this doable in a safe way. + In the end it's a tradeoff between implementer flexibility and specification simplicity. + +* In 8.4 between steps 5 and 6, + the Sender Sequence Number of the response establishes an order in the received messages, + which users of non-traditional responses may rely on. + If an option specified that only the first response may use the request's nonce, + then the one response that uses it is ordered before all other responses to the same request. + + +* If the handling of multiple responses is not idempotent, + then at 8.4 step 5: + + - For responses that use a Sender Sequence Number from the server, + the client consults the replay window before decryption, + and removes its number from the replay window after successful decryption. + - For responses that use the request's Sender Sequence Number, + duplication is tracked for each request. + + As a simplification, + applications that only process the latest response + may track the latest sequence number for deduplication. + +* In 8.4 step 8, the option establishing the non-traditional responses may specify + that error conditions processing a response are not fatal for the whole request. + This should be done when an option allows immediate follow-up requests. + This is the case for the Observe option: + When an observation is refreshed, a response encrypted with the earlier request's request_kid may still be in flight. + That in-flight response will fail decryption, + but responses generated after the server has received the refresh will be decryptable again. + # Response with embedded request A server can send a response to a request that it did not actually From b27087828884d0beb935d15fe0f90568ba5955e0 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Sat, 2 Mar 2024 20:17:13 +0100 Subject: [PATCH 2/4] Editorial round --- draft-bormann-core-responses.md | 32 +++++++++++++++++++------------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/draft-bormann-core-responses.md b/draft-bormann-core-responses.md index 097bd17..9c1356d 100644 --- a/draft-bormann-core-responses.md +++ b/draft-bormann-core-responses.md @@ -163,7 +163,8 @@ token values in order to set up non-traditional responses). # OSCORE processing for non-traditional responses -OSCORE {{oscore}} is built with the assumption that requests are processed into exactly one response. +OSCORE {{-oscore}} is built with the general assumption that requests +are processed into exactly one response. The specification contains explicit provisions for Observe requests, and a whole protocol extension for multicast requests. @@ -171,31 +172,36 @@ OSCORE's binding between requests and responses remains unmodified: Each response is cryptographically bound to an OSCORE request. Therefore, any phantom request needs to be an OSCORE request as well, and the parties need to agree on the sender and sequence number of the phantom request. -An easy way to do that securely is to deliver the phantom request in a way the server do the full OSCORE request processing on it. +An easy way to do that securely is to deliver the phantom request in a +way that the server can do the full OSCORE request processing on it. The server may process the OSCORE request into internal data structures at reception time, or may process it whenever a response is to be sent. -In the latter case, it may need to relax the requirements of {{Section 8.2 of oscore}} item 3. +In the latter case, it may need to relax the requirements of {{Section +8.2 (Verifying the Request) of -oscore}} item 3. To avoid reinventing the same rules as for Observe requests for any other non-traditional response, -this documents defines a set of processing instructions which can be referenced when specifying their options. -These rules generalize {{Sections 8.3 and 8.4 of oscore}}: +this document defines a set of processing instructions which can be referenced when specifying their options. +These rules generalize {{Sections 8.3 (Protecting the Response) and 8.4 +(Verifying the Response) of -oscore}}: -* In 8.3 step 3, "use the AEAD nonce from the request" is only an option one time - after the sequence number expressed in that request was removed from the replay window. +* In 8.3 step 3, "use the AEAD nonce from the request" is only an option once, + i.e., after the sequence number expressed in that request was removed from the replay window. This option is usually taken in the first response, - necessitating the use encoded Sender Sequence Numbers in later responses. - (Non-traditional responses such as Observe that rely on message ordering may require that request's nonce is used either in the first response or not at all). + necessitating the use of encoded Sender Sequence Numbers in later responses. + (Non-traditional responses such as Observe that rely on message + ordering may require that the request's nonce is used either in the first response or not at all.) [^maybealwaysfirst] As a convenient effect, this generalized rule also implies - that when a server performs {{Appendix B.1.2 of oscore}}, + that when a server performs {{Appendix B.1.2 (Replay Window) of -oscore}}, it needs to use its own Partial IV for the nonce (which without this generalized rule necessitated a "MUST" statement in the appendix). [^maybealwaysfirst]: CA: We could also just mandate the "either the first or never" behavior. - I don't know why one would save the efficient response, + + It is unclear why one would save the efficient response, but that may be lack of imagination. An affine type system can make this doable in a safe way. In the end it's a tradeoff between implementer flexibility and specification simplicity. @@ -220,9 +226,9 @@ These rules generalize {{Sections 8.3 and 8.4 of oscore}}: applications that only process the latest response may track the latest sequence number for deduplication. -* In 8.4 step 8, the option establishing the non-traditional responses may specify +* In 8.4 step 8, the Option establishing the non-traditional responses may specify that error conditions processing a response are not fatal for the whole request. - This should be done when an option allows immediate follow-up requests. + This should be done when an Option allows immediate follow-up requests. This is the case for the Observe option: When an observation is refreshed, a response encrypted with the earlier request's request_kid may still be in flight. That in-flight response will fail decryption, From 28a0f4e941ef1ff15ab103d9085edfb2fe7a396e Mon Sep 17 00:00:00 2001 From: chrysn Date: Sat, 2 Mar 2024 21:07:32 +0100 Subject: [PATCH 3/4] Clarifications in maybealwaysfirst comment --- draft-bormann-core-responses.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-bormann-core-responses.md b/draft-bormann-core-responses.md index 9c1356d..75099a8 100644 --- a/draft-bormann-core-responses.md +++ b/draft-bormann-core-responses.md @@ -201,9 +201,9 @@ These rules generalize {{Sections 8.3 (Protecting the Response) and 8.4 [^maybealwaysfirst]: CA: We could also just mandate the "either the first or never" behavior. - It is unclear why one would save the efficient response, + It is unclear why one would delay sending the one response that has the least overhead, but that may be lack of imagination. - An affine type system can make this doable in a safe way. + An affine type system (where instances can not generally be duplicated and are used at most once) can make this doable in a safe way. In the end it's a tradeoff between implementer flexibility and specification simplicity. * In 8.4 between steps 5 and 6, From 231a17a6baf127fae8e7bea48bcb17415649aed9 Mon Sep 17 00:00:00 2001 From: Carsten Bormann Date: Sat, 2 Mar 2024 22:29:56 +0100 Subject: [PATCH 4/4] Move scary words into a parenthesis --- draft-bormann-core-responses.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/draft-bormann-core-responses.md b/draft-bormann-core-responses.md index 75099a8..e8366df 100644 --- a/draft-bormann-core-responses.md +++ b/draft-bormann-core-responses.md @@ -203,7 +203,8 @@ These rules generalize {{Sections 8.3 (Protecting the Response) and 8.4 It is unclear why one would delay sending the one response that has the least overhead, but that may be lack of imagination. - An affine type system (where instances can not generally be duplicated and are used at most once) can make this doable in a safe way. + An approach where instances can not generally be duplicated and are + used at most once (as in an affine type system) can make this doable in a safe way. In the end it's a tradeoff between implementer flexibility and specification simplicity. * In 8.4 between steps 5 and 6,