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

[Göran Selander]

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
- 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

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
'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
- 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.

[Carsten Bormann]

Post by Göran Selander

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

[Göran Selander]

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.

Post by Carsten Bormann

Post by Göran Selander

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

Post by Carsten Bormann
(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.

Post by Carsten Bormann
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.

Post by Carsten Bormann
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.

Post by Carsten Bormann
(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.

Post by Carsten Bormann
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

Post by Carsten Bormann
Grüße, Carsten
(*) technical term: “try to help” = destroy a protocol based on all the
nicest intentions.

[Göran Selander]

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

Post by Göran Selander
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.

Post by Carsten Bormann

Post by Göran Selander

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

Post by Carsten Bormann
(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.

Post by Carsten Bormann
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.

Post by Carsten Bormann
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.

Post by Carsten Bormann
(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.

Post by Carsten Bormann
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

Post by Carsten Bormann
Grüße, Carsten
(*) technical term: “try to help” = destroy a protocol based on all the
nicest intentions.