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

From: The IESG <[email-masked]>
Date: Fri, 20 Nov 2015 13:32:50 -0800

The IESG has received a request from the Constrained RESTful Environments
WG (core) to consider the following document:
- 'Block-wise transfers in CoAP'
  <draft-ietf-core-block-18.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2015-12-04. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   CoAP is a RESTful transfer protocol for constrained nodes and
   networks.  Basic CoAP messages work well for the small payloads we
   expect from temperature sensors, light switches, and similar
   building-automation devices.  Occasionally, however, applications
   will need to transfer larger payloads -- for instance, for firmware
   updates.  With HTTP, TCP does the grunt work of slicing large
   payloads up into multiple packets and ensuring that they all arrive
   and are handled in the right order.

   CoAP is based on datagram transports such as UDP or DTLS, which
   limits the maximum size of resource representations that can be
   transferred without too much fragmentation.  Although UDP supports
   larger payloads through IP fragmentation, it is limited to 64 KiB
   and, more importantly, doesn't really work well for constrained
   applications and networks.

   Instead of relying on IP fragmentation, this specification extends
   basic CoAP with a pair of "Block" options, for transferring multiple
   blocks of information from a resource representation in multiple
   request-response pairs.  In many important cases, the Block options
   enable a server to be truly stateless: the server can handle each
   block transfer separately, with no need for a connection setup or
   other server-side memory of previous block transfers.

   In summary, the Block options provide a minimal way to transfer
   larger representations in a block-wise fashion.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-core-block/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-core-block/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Göran Selander <[email-masked]>
Date: Thu, 26 Nov 2015 07:06:57 +0000

There was a thread on the CoRE WG mailing list a couple of months ago on
the topic of blockwise and object security. The starting point was a
question if CoAP proxies can (re-)partition messages into blocks as
defined in this draft, and the implications on end-to-end security between
client and server through such a proxy. The conclusions of that discussion
has an impact on this draft, but there are no considerations of this kind
made in version -18. More details are given below, including some
alternative proposals for how to address this. Apologies for the long
e-mail. 

Background:

There is an ongoing discussion in CoRE and ACE WGs since a year on the
end-to-end security properties of CoAP, i.e. protecting the communication
between a client and a server through proxies. RFC 7252 and other
specifications in the CoAP suite define a set of legitimate proxy
operations on CoAP messages which requires DTLS to be terminated at
proxies. This implies that the proxy has access not only with the data
required for perform the intended proxy operation but is also able to
eavesdrop or manipulate any part of the CoAP payload and metadata in
transit between client and server without being protected or detected by
DTLS.

One way to mitigate this threat is to complement or replace DTLS with
application layer protection of CoAP payload and metadata between client
and server for the use cases where the proxy should not be fully trusted.
This has been discussed in the CoRE WG meetings during the three last IETF
F2F meetings and there are draft solutions using the message format being
developed in the COSE WG.

With the COAP proxy operations standardized so far it has been possible to
protect the CoAP messages adequately with security on transport layer,
application layer or a combination thereof. In the case where the
legitimate proxy operation is predictable by client and server,
application layer security can be defined to both verify that no
illegitimate changes has been performed as well as verifying the
legitimate changes. In the case where proxy operations are not predictable
— even if the data the proxy is operating on cannot be protected — it has
so far been possible to use other information elements to provide the
required end-to-end security properities.  For example, the CoAP header
field Token may be changed by a proxy, but instead a transaction
identifier can be introduced in the application security wrapper (COSE
header) to define a message (exchange) identifier common to client and
server.

Blockwise:

With the definition of blockwise transfer as specified in this draft a
proxy may partition or re-partitioning a message into blocks where the
size of the blocks are decided by the proxy. As a consequence, it is not
possible to integrity protect individual blocks end-to-end between client
and server: DTLS does not protect the message data within the proxy, and
application layer integrity protection of individual blocks cannot be
performed unless the partitioning into blocks as received by one endpoint
is identical to that sent by the other endpoint. Hence, when CoAP Block
options are used as defined in this draft, end-to-end security of the
individual CoAP request and response breaks down. For example: a proxy may
addBlock options, send any number of blocks with any payload to an
endpoint without being possible to detect or protect against. In contrast
to the existing standards in the CoAP suite, in this case it is not
possible to bypass the construction and define a secure end-to-end block
partitioning with less than disabling block partitioning as specified in
this draft. 

One solution to this is to disallow proxies to re-partition a message,
thus redefine the Block options such that they are possible to integrity
protect end-to-end.  Integrity protecting each block and corresponding
Block options as defined in the current draft has additional benefits: If
any block in the sequence fails verification, it can be individually
requested to be resent. When all blocks has been verified the entire
message has been verified.  A receiving node may even perform certain
actions based on received verified blocks before the entire message has
been received.

Instead of delegating to proxies to partition into blocks, the sending
endpoint would need to anticipate or get information about the relevant
block size, e.g. using a size indication in the link-format description
[RFC6990]. Additional methods for blocksize discovery may also be defined.
While this may not be as simple as leaving it entirely to the proxy to
decide, considering the additional security benefits I believe this is the
right trade off to make.

An alternative solution is to prevent proxies from re-partitioning a
message only in the case where end-to-end security of CoAP message is
applied, which in current solution proposals is indicated with the
presence of a certain CoAP option X (which e.g. contains the COSE object).
This would have the same benefits as the previous solution, but requires
the code in the proxy implementing this draft to be aware of option X, and
hence that dependency needs to be specified in this draft. And option X is
not standardized yet, so would require introducing a placeholder.

There are other alternatives as well but this e-mail is already too long.
The main point I wanted to make is that given that we now have a better
understanding of how to achieve security between client and server through
proxies compared to when RFC7252 was written, my opinon is that we should
not ignore these security issues in new standards.

Göran

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 26 Nov 2015 09:08:35 +0100

Göran Selander wrote:
> we should

Definitely, we shouldn't ignore these security issues when defining new
standards.

Now why is this a comment on the IETF last-call for an existing
specification?  It's not like Block was invented yesterday and people
are still figuring out how to implement it.  For years, it has actually
been part of a number of specifications that were derived from the CoAP
specifications.  It isn't very likely that spending another year or two
on finding out what specific mandates on proxies might possibly make
life a bit easier for a new object security specification would have any
influence on today's CoAP implementations.

When you have found out what is needed, write what you need into that
object security specification.  Document the level of backwards
compatibility achieved (hint: You may want to carefully define your
objectives here).  (And don't forget that you should be solving the
problem for cross-protocol proxies as well.)

Grüße, Carsten <not wearing chair hat today because I happen to be the
author of that specification>

---

From: Göran Selander <[email-masked]>
Date: Thu, 26 Nov 2015 08:43:20 +0000

On 2015-11-26 09:08, "Carsten Bormann" <[email-masked]> wrote:

>specification? 

I’m sorry if you find this comment coming a bit late. Let me expand on the
history. 

As mentioned the object security work has been going on since a year
starting with CoAP. When turning to the other drafts in the CoAP suite, we
couldn't understand how blockwise works with proxies from the draft and
asked the question to the CORE list (June). The only answer we got was
actually wrong, in the sense that it gave the impression that this is not
a proxy operation that would be of any use - an indication that  blockwise
proxy operations, although not invented yesterday, has not been well
understood.

It was not until the social event in Prague (July) where we learnt (in
private conversation) that this is not a corner case. In the mail
discussion that follow on the CoRE list I formulate this problem as a
question to you but I don’t get any answer (Sept. 2). In the CORE WG f2f
meeting in Yokohama I raised the issue with blockwise and proposed
solution in my presentation (Nov. 5), but there is no comment.

That is why this is a comment on the IETF last-call.

Göran