Subject: [core] OSCORE: clarification on protected-response requirement

From: Christian Amsüss <[email-masked]>
Date: Wed, 10 Mar 2021 13:40:24 +0100

Hello all,

OSCORE contains this sentence:

   A successful response to a request with the OSCORE option SHALL
   contain the OSCORE option.  Whether error responses contain the
   OSCORE option depends on the error type (see Section 8).

I ask for clarification on the applicability of this statement. I think
it is reasonable to clarify this (whether that's in an erratum, a piece
of CoRE lore or corr-clarr I don't know):

   This is requirement applies to responders in which the request
   actually becomes subject to OSCORE processing.

This clarification is relevant whenever there are options or mechanisms
that occur before OSCORE processing and explicitly state that they can
take effect even if there are particular other options; the prototypical
example is core-oscore-edhoc.

Protocols built around such options are, if the RFC8613 statement is
interpreted strictly, limited to non-successful responses. For different
reasons ("Don't abuse protocol errors for application errors", caching,
maybe others) it makes sense to allow successful codes in responses too,
and this is what the clarification is about. For example, if in EDHOC
the preference should become to respond successful with an
application/edhoc message (even if inside that there is an error), the
response to a request

    POST EDHOC: M3 OSCORE:... encrypted { GET /foo }

could be

    2.04 Changed Content-Format: application/edhoc { error-code, ... }

which is understood as a response to the EDHOC option part due to its
criticality, and for the same reason understood to have ignored the
OSCORE option (as processing didn't get that far anyway).

I think this also be relevant for any cases of application-layer
redirection (given we don't want to mint 3.xx codes for that) and
protocol negotiation (nothing fleshed out yet, but knowing the
boundaries will ease exploration).

BR
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Göran Selander <[email-masked]>
Date: Fri, 12 Mar 2021 19:25:57 +0000

Hi Christian,

As far as I recall, this sentence intends to say that if an OSCORE request is successfully processed in the server by OSCORE, then the response SHALL be protected with OSCORE i.e. have an OSCORE option. So indeed, this corresponds to the case when the request "is subject to OSCORE processing", which is the only case considered in the draft. Errors during CoAP processing will be protected  by OSCORE whereas the errors during OSCORE processing are unprotected. 

As you point out, in draft-palombini-core-oscore-edhoc, it is specified how an OSCORE request containing EDHOC message_3 is preprocessed by EDHOC. So the question is how an error in EDHOC processing is reflected in the CoAP response. Clearly there can't be an OSCORE option in the response since the request did not successfully complete the OSCORE processing - it didn't even start. If I understand right, your question is what is the restriction on CoAP status codes in cases like this.

This goes beyond what was considered in RFC 8613. Although the sentence seems to forbid the use of success code in this case, with the interpretation as above the sentence does not actually say anything about this case, since the condition of the "if" is not fulfilled. 

Your proposal to extend the applicability of the current text to new situations makes sense to me. I don't know if this needs an erratum, but I think that we at least should document this interpretation whenever it is relevant.

I hope I answered the question.

Göran

On 2021-03-10, 13:40, "core on behalf of Christian Amsüss" <[email-masked] on behalf of [email-masked]> wrote:

    Hello all,

    could be

    BR
    Christian