Subject: [core] Blocking and OSCOAP

From: Jim Schaad <[email-masked]>
Date: Thu, 16 Feb 2017 16:51:45 -0800

There has been a lot of discussions about blocking and OSCOAP both here on
this list and within a smaller set of people who are looking at doing
interop testing.  Over the course of this there have been a couple of issues
that have been identified.

1.  There are differing views on the desirability of having an integrity
check that covers the entire message and what the best way to do this is.  I
expect that there should be discussions on this at the F2F meeting.  This is
not an issue for random access, which makes it harder to think about for
sequential access.

2.  Blocking requires that two concurrent 'sessions' not exist for the same
resource from the same endpoint.  This is a problem with OSCOAP because most
of the path and arguments for the resource are going to be hidden by placing
them inside of the encrypted payload leaving only Uri-Port and Uri-Host
outside of the encryption.  One can do a level of blocking inside of the
OSCOAP encryption, but there is nothing to prevent blocking from occurring
in the wrapper layer as well.  

Background:

If you start with two different resources that a client is trying to down
load

1.  URL=coap://server/resource1, Source Address=client:60000 
2.  URL=coap://server/resource2, Source Address=client:60000

And then you apply OSCOAP to them you get

1.  URL=coap://server, OSCOAP{/resource1}, Source Address=client:60000
2.  URL=coap://server, OSCOAP{/resource2}, Source Address=client:60000

Which means that although the client might think it is trying to get two
different resources, the message that is being transmitted is now only
dealing with a single resource name for the outer blocking.  In order to
deal with this, we need to have an option that can be placed outside of the
encryption layer to distinguish between these two items.  Note that if there
is inner blocking, then this can be a unique value for each different
message that comes out of the inner blocking.  For this reason, it is not
clear that using ETag would be a correct answer.  Using ETag would allow for
an observer to do passive monitoring and correlate different blocks
together.  Since this does not need to occur it makes ETag a poor answer.  

In my opinion, fixing this requires creating of a new option with an update
to the blocking document so that a new value is created that could be
defined from a counter of some that that is added when blocking options are
added and removed when they are removed.  

Jim

---

From: Göran Selander <[email-masked]>
Date: Sun, 19 Feb 2017 05:46:05 +0000

Jim, thanks for summarising on the list and continuing the discussion.

On 2017-02-17 01:51, "core on behalf of Jim Schaad" <[email-masked]

>not an issue for random access, which makes it harder to think about for

I think this is desirable and I did not note any disagreement on that
point. On the topic of “how”, one proposal is to define separate resources
containing checksums of (large) representations:

https://mailarchive.ietf.org/arch/msg/core/gjVdDCptJ9DfYvy3uhb35uKwK54

Would that not address the issue?

(It seems I missed to answer your question "Is this something to be done
at the COSE or at the CoAP layer?” — I would say neither. This is on top
of CoAP. The checksum resource could be just a hash of the representation.
Hence you can access this resource with CoAP over your favourite security
protocol to protect it from change.)

>added and removed when they are removed.

Just to first recap the inner (encrypted) block options, which are used by
client and server end-to-end. The issue was if a client for some reason
concurrently would push (POST/PUT etc) multiple large representations to
the same resource on the same server, such that both messages are
fragmented, then the server needs to distinguish the different
representations to ensure that blocks from different representations are
not mixed up. 

RFC7959 does not support a single endpoint to perform multiple
concurrently proceeding block-wise, but hints at a work-around using
different cache keys. Christian proposed a new option "Request-Tag”,
analogously to ETag, the new option would generate different cache keys
and thus identify different representations being pushed by the client.
With the use of this new option, the chaining of integrity values between
blocks currently in OSCOAP can be removed which simplifies the processing.

Since no one has objected I guess this is an acceptable solution, but it
still remains to decide whether the new option should be defined in OSCOAP
or in a separate draft.

When it comes to the outer (unprotected) block options, which are used by
proxies to fragment OSCOAP messages, the same construction could be
applied. If a proxy is concurrently fragmenting different representations
to the same resource, a tag of the representation should be added to
differentiate between them. I believe this should solve the problem for
new proxy implementations, and would as far as I can tell not be any
additional issue with traffic analysis since all the proxy does is
fragmenting a large encrypted message into smaller and indicate that they
belong together.

Could this tag be the option you are referring to?

A work-around for legacy proxies - to what extent that is a problem - is
that the client includes a tag which is not protected by OSCOAP. This
would enable an observer to distinguish between different requests and
would create an overhead. The former is anyway possible unless some
masking of requests is performed, like continuous fill-in of dummy
requests. The latter should in most cases be negligible since the size of
the tag can be restricted to uniquely identifying the concurrent
proceeding requests, and hence tags can be reused when the transaction is
finished.

Göran

>
>Jim
>
>
>_______________________________________________
>core mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/core