-----Original Message-----
From: Carsten Bormann [mailto:cabo(_at_)tzi(_dot_)org]
Sent: Thursday, January 28, 2016 11:36 PM
To: Jim Schaad <ietf(_at_)augustcellars(_dot_)com>
Cc: ietf(_at_)ietf(_dot_)org; core(_at_)ietf(_dot_)org
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