Subject: Re: [core] Blocking and OSCOAP

From: Christian Amsüss <[email-masked]>
Date: Fri, 3 Mar 2017 14:02:11 +0100

Hello,

On Sun, Feb 19, 2017 at 05:46:05AM +0000, Göran Selander wrote:
> >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 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.)

(Once more, I'm focusing on block2 here for simplicity reasons).

I still don't quite see how inner ETags on inner blockwise transfers
could reproduce an erroneous state transfer via OSCOAP between a
well-behaved server and client. (I'd say that well-behaved server means
that it implements an ETag that is a (collision-free) function of the
resource state and all blocks it ever produces for a representation fit
together, and that well-behaved client means it only modifies the the
block number when querying successive blocks).

As I understand CoAP, there is no such thing as an "entire message".

> >2.  Blocking requires that two concurrent 'sessions' not exist for
> >the same resource from the same endpoint.

I'm shaping the Request-Tag proposal[1] into a generally usable draft.
This would mitigate both the situation around all block requests hitting
the same server resource from the same port and the integrity protection
of POST bodies and that like.

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

That only affects outer blockwise, where the client strictly speaking
would need to detect that it's doing a block1 operation on the same
resource and thus serialize the requests.

Outer blockwise on a GET request needs to hit some deduplication /
caching layer before OSCOAP anyway (lest it trigger a replay
protection), at which point the relationship to the original request is
established.

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

If there is inner blocking, I don't think we should have any indication
on the outside at all. The correlation between the requesting messages
should happen purely on encrypted identifiers, both securing the
connection and mitigating leaks.

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

I'd sketch it up as a standalone draft, because I think it has
applications both for proxies and any other situations where two
communication partners are "running out of endpoints".

Best regards
Christian

[1]: https://mailarchive.ietf.org/arch/msg/core/gc1e2NRsNunG09P8PSbyU5E26co

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom

---

From: Göran Selander <[email-masked]>
Date: Sat, 4 Mar 2017 16:41:58 +0000

Hi Christian,

On 2017-03-03 14:02, "Christian Amsüss" <[email-masked]>
wrote:

>well-behaved server and client.

You are right, there is no issue with GET. All blocks, including block
numbers, related to a particular representation (=body, see below) for
which ETag is used can be verified, and hence so can the whole
representation/body. Jim’s comment (item 1 above) as I understand it was
an additional feature to get an integrity value of the whole
representation/body. And the solution I mentioned was to define a special
resource which can be used for that. But that doesn’t have to be
standardised.

>(I'd say that well-behaved server means

RFC7959 (“blockwise”) distinguishes between “payload” and “body”, would it
make more sense to use  those terms instead?

   "In the following, the term "payload" will be used for the actual
   content of a single CoAP message, i.e., a single block being
   transferred, while the term "body" will be used for the entire
   resource representation that is being transferred in a block-wise
   fashion.  The Content-Format Option applies to the body, not to the
   payload; in particular, the boundaries between the blocks may be in
   places that are not separating whole units in terms of the structure,
   encoding, or content-coding used by the Content-Format.  (Similarly,
   the ETag Option defined in Section 5.10.6 of [RFC7252]
<https://tools.ietf.org/html/rfc7252#section-5.10.6> applies to the
   whole representation of the resource, and thus to the body of the
   response.)"

Göran

>[1]: 
>https://mailarchive.ietf.org/arch/msg/core/gc1e2NRsNunG09P8PSbyU5E26co
>
>--

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 4 Mar 2017 17:53:32 +0100

> make more sense to use  those terms instead?

Indeed; I was going to say this, too.

Grüße, Carsten