Re: [core] Last Call: <draft-ietf-core-block-18.txt> (Block-wise transfers in CoAP) to Proposed Standard

["Jim Schaad" <[e-mail]>]

> -----Original Message-----
> From: Carsten Bormann [mailto:[e-mail]]
> Sent: Thursday, January 28, 2016 11:36 PM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [core] Last Call: <draft-ietf-core-block-18.txt> (Block-wise transfers
> in CoAP) to Proposed Standard
> 
> Hi Jim,
> 
> great discussion, thank you.
> Retroactively adding security over insecure channels to CoAP is not an area with
> easy answers.
> 
> A couple of random observations:
> 
> -- indeed, block is meant to help getting larger messages through the network.
> The individual blocks are generally not really worth individual protection.  I think
> the biggest remaining question with this is what to do against an attacker
> polluting a cache with a bad block (creating a problem for availability, not
> integrity).  (In RFC7252's security model, DTLS prevents that from happening.)
> 
> -- in CoAP, options are given option numbers that expose some of their
> characteristics, e.g., critical/elective, safe-to-forward, cache-key, so some
> operations are possible on options that the system handling them doesn't know.
> We didn't think to have bits in the option number for the security properties of
> the option.  Can we possibly derive everything we need from the existing bits?
> Do we maybe have to carry that information separately with a message secured
> at the CoAP level?

This is not dealing with the issue that I raised.  Consider the following case

In block 1, the content type is set to 1.
In block 2, the content type is set to 2.

Now, this can be an error.  This can be a use the first value.  This can be a use the last value.

Which of the above three cases should I evaluate to on the base protocol.  Nothing to do with security.

The same question arises when if content type is absent in block2. 

There are going to be some item which can and will change.  This are probably the unsafe to forward items.  The behavior might change based on some type of criticality bit in the option number.   This should be documented in the core protocol.

Jim

> 
> -- A small group is working on classifying the desirable security objectives for the
> existing CoAP options.  That is not an easy project, but I hope we will have
> something to look at for Buenos Aires.
> 
> -- As a random coincidence, have a look at the new
> https://tools.ietf.org/html/draft-thomson-http-mice-00
> 
> Grüße, Carsten