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