Göran, I finally got caught up on reading the CORE mailing list (lots of boredom on issues I don’t think I care about) and I did not find any responses to your mail on this issue. I would like to propose a different solution to the problem which I think you will find both workable and potential not requiring any updates to the current draft. When I read this draft the first time, I read it as a network fragmentation draft rather than as a messaging draft. As such I did not have the same concerns about object security as you seem to have. I made the decision that I would apply the security to the entirety of the message being sent, and then fragment it into blocks afterwards. Such an approach allows for a number of things that you are having problems with to be ignored. How the fragmentation is done, is change or is removed become immaterial as the end recipient would need to have all of the fragments delivered and in the correct order in order to process the message and do validation. Overhead is smaller because the overhead of encrypting/signing at the object security level is done once rather than once per fragment. This allows for fewer bytes to be sent across the wire. The headers of the first message in the fragment are the ones that the object security system would be using both for security calculation purposes and for the receiver to process the validated message. There are still some question that potentially need to be dealt with: 1) Are the block option headers authenticated? The probable answer should be no as they are designed to be changed by intermediaries. This can be deferred until the general discussion about the rest of the current headers. 2) What options are required to be copied forward into subsequent messages and which can be omitted? I was unable to find any guidance on this issue from reading the document and thus would naively make the assumption that all options not specified by this document are copied forward and should be checked to make sure that they are unchanged in future messages. However I doubt that is the desire of the authors. This however is not a security specific issue and needs to be addressed in this document. 3) Do we want to apply per message security as well - that is an issue that can and should be punted to a future object security draft. However, I don't see the point except to protect the ACK/NACK or lack of on each individual hop. But this is point-to-point not end-to-end. Jim > -----Original Message----- > From: core [mailto:core-bounces@xxxxxxxx] On Behalf Of Göran Selander > Sent: Wednesday, November 25, 2015 11:07 PM > To: ietf@xxxxxxxx > Cc: draft-ietf-core-block@xxxxxxxx; core-chairs@xxxxxxxx; core@xxxxxxxx; > barryleiba@xxxxxxxxx > Subject: Re: [core] Last Call: <draft-ietf-core-block-18.txt> (Block-wise transfers > in CoAP) to Proposed Standard > > > > 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 > > > > On 2015-11-20 22:32, "The IESG" <iesg-secretary@xxxxxxxx> wrote: > > > > >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 > >ietf@xxxxxxxx mailing lists by 2015-12-04. Exceptionally, comments may > >be sent to iesg@xxxxxxxx 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. > > > > > > _______________________________________________ > core mailing list > core@xxxxxxxx > https://www.ietf.org/mailman/listinfo/core