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

From: Göran Selander <[email-masked]>
Date: Mon, 19 Feb 2018 17:35:29 +0000

All,

The AD review pointed at the omission of media type to use in the header
field Content-Type of an HTTP message carrying an OSCORE encrypted message.

>> If we decide to include a Content-Type header field, the main options
>>are:
>>
>> - 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)?

BR
Göran 

On 2018-02-19 15:00, "Alexey Melnikov" <[email-masked]> wrote:

>
>>> 5) In Section 10.2: which media type is used for the OSCORE-encrypted
>>> payload transported in HTTP?
>>>
>> [GS] Good question, there are a few things to note here. First, the CoAP
>> option Content-Format is Inner so the CoAP payload media type is
>> encrypted. Second, the Outer Content-Format option is not present in
>> OSCORE protected CoAP messages (in the interest of saving message
>> overhead). Third, when CoAP-mappable HTTP is protected with OSCORE, the
>> message is first mapped to CoAP and then processed with OSCORE, so the
>> media type of the OSCORE encrypted payload is carried in the encrypted
>> Content-Format option also in the case of HTTP. However, we may still
>>want
>> to have a Content-Type header field in the HTTP message transporting the
>> OSCORE message. Was this what you were referring to?
>Yes. Applications or plugin frequently get invoked based on media types.
>So if you want to allow for decoding of OSCORE payloads in a plugin, you
>should define a media type.
>
>> According to RFC 7231
>> (https://tools.ietf.org/html/rfc7231#section-3.1.1.5):
>>
>> 'A sender that generates a message containing a payload body SHOULD
>>     generate a Content-Type header field in that message unless the
>>     intended media type of the enclosed representation is unknown to the
>>     sender.  If a Content-Type header field is not present, the
>>recipient
>>     MAY either assume a media type of "application/octet-stream”
>> ([RFC2046]) or examine the data to determine its type.'
>>
>>
>> While Content-Type is recommend, noting that in the case of OSCORE we
>>want
>> to encrypt the Content-Type for the other CoAP endpoint, so whatever
>>media
>> type we would potentially include in the “Outer” message would only be a
>> dummy.
>
>Yes, but it signals to applications that "this payload is
>OSCORE-encrypted".
>
>>   Furthermore, the destination endpoint would anyway first have to
>> process the OSCORE message to recreate the HTTP message before handing
>> over for HTTP processing.
>> As I read the text above it is possible to leave Content-Type out, but
>> would that be an issue in existing networks?
>I think unlabelled content is a bad form :-).
>>   Who would be able to give
>> some advice her?
>>
>> If we decide to include a Content-Type header field, the main options
>>are:
>>
>> - 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.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 19 Feb 2018 11:00:02 -0800

> 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.)
(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.)

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.

So something like application/oscore should be registered (is there only one of these?).

Next question: Does this media type get a Content-Format value, too?

Grüße, Carsten

(*) technical term: “try to help” = destroy a protocol based on all the nicest intentions.

---

From: Göran Selander <[email-masked]>
Date: Tue, 20 Feb 2018 07:36:57 +0000

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.

>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 (*).
>

[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

---

From: Göran Selander <[email-masked]>
Date: Wed, 21 Feb 2018 07:47:43 +0000

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