Subject: [core] OSCOAP and BLOCK

From: Jim Schaad <[email-masked]>
Date: Thu, 1 Dec 2016 16:42:55 -0800

I did not include this comment in the previous message because I was sure
that there must have been something that I was just missing.  I have now
spent a couple of hours just trying to understand what is document says
about BLOCK and I still have absolutely no idea what is going on.

The document says that the BLOCK options are to be duplicated in both the
wrapper and protected CoAP object.  The reasoning for this makes no sense to
me.  From the point of view of a proxy sitting between the two end-points
the message must be treated as a single atomic message and not as part of a
sequence of blocks.  This is because a proxy that did any type of combining
or blocking of one of these messages is going to mess up the fact that the
internal encrypted object needs to be treated as an atomic item by the final
recipient.  Otherwise it will not correctly parse and validate.  

On the other hand, if a single block between the two end points happens to
be broken into a set of blocks by an intermediate proxy, then there would be
no problems to the message.  This means that the two sets of blockings are
treated as completely independent objects.  For this reason, I believe that
the blocking options should be copied to the internal CoAP object and
deleted from the wrapping one.

I also have no idea where the MAC value that is being used to chain blocked
messages is coming from.

---

From: Göran Selander <[email-masked]>
Date: Fri, 2 Dec 2016 14:42:34 +0000

On 2016-12-02 01:42, "Jim Schaad" <[email-masked]> wrote:

>that there must have been something that I was just missing.

Just testing one thing which we realized is not very clear in the current
writing: the two instances of the duplicate options a) in general don’t
have the same value, and b) do not both need to be present in a given
message. Was this the source for misunderstanding?

The inner block option, which is protected by the COSE message is only
talking about the segmentation end-to-end, whereas the outer unprotected
block option is only about the segmentation in the current hop, and the
values of those options are thus set independently. In fact, the outer
block option may change multiple times throughout the journey of the
message if it becomes fragmented and reassembled several times, whereas
the inner block option remains constant (or, if it is changed, will be
detected).

>I also have no idea where the MAC value that is being used to chain

This MAC is the last bytes of the AEAD output of the COSE message
containing a fragment generated by the originating endpoint, and verified
by the destination endpoint.

Does it make more sense?

Göran

---

From: Jim Schaad <[email-masked]>
Date: Fri, 2 Dec 2016 18:09:13 -0800

> -----Original Message-----
> From: Göran Selander [mailto:[email-masked]]
> Sent: Friday, December 02, 2016 6:43 AM
> To: Jim Schaad <[email-masked]>; draft-ietf-core-object-
> [email-masked]
> Cc: [email-masked]
> Subject: Re: OSCOAP and BLOCK
> 
> 
> >I did not include this comment in the previous message because I was
> >sure that there must have been something that I was just missing.
> 
> writing: the two instances of the duplicate options a) in general don’t have the
> same value, and b) do not both need to be present in a given message. Was this
> the source for misunderstanding?

That would be a very large cause of misunderstanding.  The word duplicate to me means that they start with the same value, even if the values may be changed at a later date.  If that is the case, then I think there may be other items which should be marked as duplicate.  One example of that would be Uri-Path as I suggested in a different mail where all OSCOAP mail could be sent to a well-known point and thus there would be a Uri-Path in the duplicate column.  

The test code that I wrote automatically copied the option to the encrypted request and left it alone in the unencrypted request.  This must not be what you meant and that is a surprise.

> 
> The inner block option, which is protected by the COSE message is only talking
> about the segmentation end-to-end, whereas the outer unprotected block
> option is only about the segmentation in the current hop, and the values of
> those options are thus set independently. In fact, the outer block option may
> change multiple times throughout the journey of the message if it becomes
> fragmented and reassembled several times, whereas the inner block option
> remains constant (or, if it is changed, will be detected).
> 
> 
> >
> >I also have no idea where the MAC value that is being used to chain
> >blocked messages is coming from.
> >
> 
> This MAC is the last bytes of the AEAD output of the COSE message containing a
> fragment generated by the originating endpoint, and verified by the destination
> endpoint.

This would be call the AEAD Tag value not the MAC value.  Different beast.

Jim