Merge pull request #3 from core-wg/oscore

Describe how OSCORE works with non-traditional responses

draft-bormann-core-responses.md

@@ -161,6 +161,80 @@ 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 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.
+
+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 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 (Verifying the Request) of -oscore}} item 3.
+
+To avoid reinventing the same rules as for Observe requests for any other non-traditional response,
+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 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 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]
+
+  <!-- Conveniently, this is obsoleting some text that's rotting away in lwig-oscore. -->
+
+  As a convenient effect, this generalized rule also implies
+  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.
+
+  It is unclear why one would delay sending the one response that has the least overhead,
+  but that may be lack of imagination.
+  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,
+  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.
+
+<!-- Unlike the other items which all correspond to the "Supporting Observe" sub-items of 8.3/8.4, this corresponds to 7.4.1. -->
+* 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