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

[Göran Selander <[e-mail]>]

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" <[e-mail] on behalf of [e-mail]> wrote:

    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