Re: [core] Media type for OSCORE in HTTP (Was: AD review of draft-ietf-core-object-security-08)

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

Responding to my own mail -- got an off-list comment that the reasoning
was hard to follow so here is another try.

When an OSCORE message is sent with CoAP the Content-Format option is
redundant (i.e. the Content-Format of the CoAP message visible on the
wire, not the Content-Format of the original unprotected CoAP message
which is encrypted and part of the ciphertext of the COSE message). The
Object-Security option, containing the compressed COSE headers, has all
information necessary to process the COSE object in addition to signaling
“this is an OSCORE message”. Since there is no default for Content-Format
this should be sufficient for CoAP. Intermediary nodes that perform
legitimate proxy operations on an OSCORE message either understands
OSCORE, in which case they can know where to find the necessary
information in the message (e.g. reading class I options, mapping between
HTTP and CoAP), or if they don’t understand OSCORE can process the message
as an ordinary CoAP message (e.g. CoAP proxy forwarding, blockwise
fragmentation).

When an OSCORE message is sent with HTTP we need to explicitly signal that
this is OSCORE for which the new media type 'application/oscore' is
defined. 

Hope that makes more sense.

Göran


On 2018-02-20 08:36, "Göran Selander" <[e-mail]> wrote:

>Hi Carsten, 
>
>The intent is to allow a few defined operations independent of media type
>of payload between OSCORE wrapping in the sending endpoint and OSCORE
>unwrapping in the recipient endpoint, including: CoAP proxy operations,
>blockwise fragmentation and reading class I options. And with the addition
>of HTTP processing, also the operation of mapping between HTTP and CoAP.
>Before OSCORE wrapping and after OSCORE unwrapping the processing should
>be handled by the normal transfer layer. So, a special media type like
>'application/oscore' keeping “helpful” HTTP processing away seems to be
>right. Apart from that I don’t see a reason to make any special use of
>Content-Type/Content-Format. But maybe I’m missing something?
>
>Additional comments inline.
>
>
>On 2018-02-19 20:00, "Carsten Bormann" <[e-mail]> wrote:
>
>>On Feb 19, 2018, at 09:35, Göran Selander <[e-mail]>
>>wrote:
>>> 
>>>>> - reuse of "application/cose” defined in RFC 8152 (if appropriate)
>>>>> - new media type e.g. “application/oscore” to be defined in this
>>>>>draft.
>>>> Either of these work for me.
>>> 
>>> 
>>> Does anyone have an strong opinion here (or deviating opinion about the
>>> necessity of having this header field)?
>>
>>Generally, REST bodies (as transferred in payloads in CoAP) need to have
>>a media type.
>>
>>OSCORE skirts around this for CoAP by having the Object-Security option
>>essentially supplant Content-Format.
>>That is not great design.  (It also isn’t a disaster.)
>
>[GS] The other alternatives add more message overhead.
>
>
>>(This works, as long as these are not in error responses, since
>>Content-Format does not have a default, see RFC 7252 Section 5.5.1.)
>
>[GS] Error responses protected by OSCORE are not visible as error
>messages.
>
>>
>>For HTTP and its valiant ecosystem, there may be stronger reasons to
>>indicate a media type so existing implementations don’t feel like they
>>should try to help (*).
>>
>>application/cose is not useful because the OSCORE payload isn’t.
>
>[GS] There was a request to use one of the reserved flag bits to indicate
>a variant when the OSCORE payload is a COSE object instead of a compressed
>COSE, but in general that would not be the case, and the discussion of the
>reserved flag bits was deferred to Group OSCORE.
>
>>
>>So something like application/oscore should be registered
>
>[GS] OK. Unless there are other comments I will add this in a new
>subsection in the IANA considerations and the additional HTTP-CoAP mapping
>rule.
>
>
>>(is there only one of these?).
> 
>[GS] As stated above, I don’t see the need to make any other distinction
>based on media type.
>
>>
>>Next question: Does this media type get a Content-Format value, too?
>
>[GS] Same answer here, I don’t see the need. But if someone can give a
>good reason we can define that.
>
>Göran
>
>
>>
>>Grüße, Carsten
>>
>>(*) technical term: “try to help” = destroy a protocol based on all the
>>nicest intentions.
>>
>