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