Subject: [core] End-to-end integrity protection only

From: Göran Selander <[email-masked]>
Date: Wed, 23 Nov 2016 14:34:43 +0000

Hi Jim,

Referring to your comment in the CoRE f2f on integrity protection only on
application layer, i.e. the use of a MAC algorithm instead of an AEAD as
traffic protection in OSCOAP.

If I understand right, the idea is that an intermediate node should be
able to read but not change payload which is integrity protected between
endpoints.

First of all, as was similarly discussed in COSE, in order for the
intermediary to depend upon the payload it would need to verify its
integrity (a MAC), and if it has the key to do so, that key could with
negligible performance penalty be used to encrypt the payload. So if we
are speaking application layer protection of message between endpoint and
proxy, then I don’t see the need for a MAC.

Another use case previously discussed is hop-by-hop endpoint-proxy
communication protected with (D)TLS and endpoint-endpoint communication
protected by OSCOAP. In this case the proxy would verify the DTLS record
layer message. But in order to read out the application layer payload, the
proxy would need to parse the OSCOAP message, without being able to verify
the COSE object, neither the payload nor the options or header, since by
assumption only the endpoints share that key. But the point with using
OSCOAP is exactly that it protects not only payload but essentially all
options and headers that are not part of CoAP message layer, that it is
possible to verify that request and response belong together etc.. Nothing
of this would available to the proxy.

Additionally, the use of duplicate CoAP options for proxy and endpoint
respectively, as currently specified will not work with integrity
protection only, since only one set of options are available. So, e.g. the
use of Blockwise as is currently specified for use both end-to-end and
hop-by-hop would not work.

While DTLS and OSCOAP can be combined for additional protection of the few
header fields which are not already encrypted, I think that the use case
discussed here where security on different layers is used for protecting
one and the same payload should be addressed with OSCON or even COSE
directly over DTLS, rather than OSCOAP over DTLS. So, using the OSCON
format or other simple COSE wrapping of payload and potentially metadata,
this can be more easily parsed by an intermediate node for this use case.
Alternatively payload protection hop-by-hop and end-to-end could be
entirely solved on application layer. This would actually be a use case
for a counter-MAC.

Does it make sense?

Göran

---

From: Jim Schaad <[email-masked]>
Date: Wed, 23 Nov 2016 12:21:05 -0800

> -----Original Message-----
> From: Göran Selander [mailto:[email-masked]]
> Sent: Wednesday, November 23, 2016 6:35 AM
> To: Jim Schaad <[email-masked]>; [email-masked]
> Cc: Francesca Palombini <[email-masked]>
> Subject: End-to-end integrity protection only
> 
> Hi Jim,
> 
> application layer, i.e. the use of a MAC algorithm instead of an AEAD as traffic
> protection in OSCOAP.

I would not limit it to MAC, a signature would also be equally effective in terms of dealing with this issue.

> 
> If I understand right, the idea is that an intermediate node should be able to read
> but not change payload which is integrity protected between endpoints.

That was what was presented at the Berlin F2F.

> 
> First of all, as was similarly discussed in COSE, in order for the intermediary to
> depend upon the payload it would need to verify its integrity (a MAC), and if it
> has the key to do so, that key could with negligible performance penalty be used
> to encrypt the payload. So if we are speaking application layer protection of
> message between endpoint and proxy, then I don’t see the need for a MAC.

The use case presented is that the intermediary can read, but not verify the integrity, of the payload.  That is, it wants to be able to monitor the content being sent back but does not care if it occasionally gets a bad answer.  Note the use case is not mine.

> protected by OSCOAP. In this case the proxy would verify the DTLS record layer
> message. But in order to read out the application layer payload, the proxy would
> need to parse the OSCOAP message, without being able to verify the COSE
> object, neither the payload nor the options or header, since by assumption only
> the endpoints share that key. But the point with using OSCOAP is exactly that it
> protects not only payload but essentially all options and headers that are not
> part of CoAP message layer, that it is possible to verify that request and
> response belong together etc.. Nothing of this would available to the proxy.
> 
> respectively, as currently specified will not work with integrity protection only,
> since only one set of options are available. So, e.g. the use of Blockwise as is
> currently specified for use both end-to-end and hop-by-hop would not work.

I don't follow this.  If it was true, then it would not work for encryption either.  Duplicating the options inside of the payload should be just fine for either case.  If it is integrity only protected, then the ones inside the payload are ignored by the proxy just as is done with encryption.  Additionally, one could place some of the attributes in the external application data and protect them in that manner even if one did not duplicate them.

> header fields which are not already encrypted, I think that the use case discussed
> here where security on different layers is used for protecting one and the same
> payload should be addressed with OSCON or even COSE directly over DTLS,
> rather than OSCOAP over DTLS. So, using the OSCON format or other simple
> COSE wrapping of payload and potentially metadata, this can be more easily
> parsed by an intermediate node for this use case.

Using just OSCON does not protect headers which I think is going to be of importance.  One will want to protect the Uri-Port and Uri-Path options for a PUT.  

Jim

> Alternatively payload protection hop-by-hop and end-to-end could be entirely
> solved on application layer. This would actually be a use case for a counter-
> MAC.
> 
> Does it make sense?
> 
> 
> Göran

---

From: Göran Selander <[email-masked]>
Date: Thu, 24 Nov 2016 09:35:54 +0000

>in terms of dealing with this issue.

A signature makes much more sense from the point of view that any
intermediary could actually verify the message. In this case the secure
group communication for CoAP [1] can be applied directly with one
intermediary as “listener”.

>>able to read

I didn’t find it in the minutes, was this a smart meter scenario? I recall
a previous discussion where the intermediary was the actual smart meter
and the purpose of reading out was to be able to read out the consumption
locally.

>>intermediary to
>The use case presented is that the intermediary can read, but not verify
>the integrity, of the payload.  That is, it wants to be able to monitor
>the content being sent back but does not care if it occasionally gets a
>bad answer.  Note the use case is not mine.

OK. IMHO, the part “not care if it occasionally gets a bad answer” is not
perfectly matching the smart meter scenario. It would be good if the owner
of this use case could provide more details.

>>protection only,
>I don't follow this.  If it was true, then it would not work for
>encryption either.  Duplicating the options inside of the payload should
>be just fine for either case.  If it is integrity only protected, then
>the ones inside the payload are ignored by the proxy just as is done with
>encryption.  Additionally, one could place some of the attributes in the
>external application data and protect them in that manner even if one did
>not duplicate them.

I think you are right about this point. The duplicate options could work
equally well with the payload of COSE_Mac0 analogous to the plaintext of
COSE_Encrypt0, the same external_AAD, etc.. I was thinking of a previous
version of the draft supporting MACs where the payload of the MAC object
was detached, in which case no other CoAP options and payload could be
sent than the options and payload of the unprotected CoAP message.

But I’m not yet convinced that we need to support MAC-only.

>Using just OSCON does not protect headers which I think is going to be of
>importance.  One will want to protect the Uri-Port and Uri-Path options
>for a PUT.  

That is what I intended with “wrapping .. potentially metadata”. But
irrespective of COSE, OSCON or OSCOAP, with symmetric keys only, it
becomes a matter of the intermediary parsing a COSE message without
verifying it (unless there is a counter-MAC) and I question the sense in
that.

To summarise: 

- Current drafts support the case of multiple parties reading and
verifying source and integrity of end-to-end protected CoAP messages
without being able to unseen modify the data in transit.

- More input motivating the parsing of COSE objects without verification
is welcome.

Göran

[1] https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap