Re: [core] Last Call: <draft-ietf-core-block-18.txt> (Block-wise transfers in CoAP) to Proposed Standard
Göran Selander <goran.selander@ericsson.com> Thu, 26 November 2015 07:07 UTC
Return-Path: <goran.selander@ericsson.com>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A48C41B29B1; Wed, 25 Nov 2015 23:07:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.901
X-Spam-Level:
X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PPMDfiFsrJlx; Wed, 25 Nov 2015 23:07:02 -0800 (PST)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B848A1B29AA; Wed, 25 Nov 2015 23:07:01 -0800 (PST)
X-AuditID: c1b4fb2d-f79456d000001332-38-5656af93bfb7
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 54.CB.04914.39FA6565; Thu, 26 Nov 2015 08:06:59 +0100 (CET)
Received: from ESESSMB303.ericsson.se ([169.254.3.32]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.03.0248.002; Thu, 26 Nov 2015 08:06:59 +0100
From: Göran Selander <goran.selander@ericsson.com>
To: "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: Last Call: <draft-ietf-core-block-18.txt> (Block-wise transfers in CoAP) to Proposed Standard
Thread-Index: AQHRI9sb/ga71FS+3UKAe+rFI8Rp+56t6kEA
Date: Thu, 26 Nov 2015 07:06:57 +0000
Message-ID: <D27C68A8.3F21C%goran.selander@ericsson.com>
References: <20151120213250.32473.53283.idtracker@ietfa.amsl.com>
In-Reply-To: <20151120213250.32473.53283.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.4.7.141117
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="utf-8"
Content-ID: <79B2126946DF18499FEA44FA77A7995C@ericsson.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAIsWRmVeSWpSXmKPExsUyM2J7oO7k9WFhBj+nyVt8f36NxWLbxgts Fvverme2aDw0j9Hi2cb5LBbPnrcwOrB57Jx1l91jyZKfTB63X89nDmCO4rJJSc3JLEst0rdL 4Mo4cry24F14xdrDFxgbGM+EdjFyckgImEgc3zyJDcIWk7hwbz2QzcUhJHCYUeLOovcsEM5i RonDDS3sIFVsAi4SDxoeMYHYIgLKEgdm3mAFKWIW+Mkosfn2bRaQhLBAjsSLb5+AijiAinIl ls+0hqg3Aip5xwgSZhFQlWhqNAMJ8wpYSKza9xasU0jAUeLJ3SlgqzgFnCQebLvACmIzAh33 /dQasLXMAuISt57MZ4I4WkBiyZ7zzBC2qMTLx//A6kUF9CRWXm+CekxJonHJE1aQtcwCmhLr d+lDmNYSJ8+oQExUlJjS/ZAd4hpBiZMzn7BMYJSYhWTZLITmWQjNs5A0z0LSvICRdRWjaHFq cXFuupGxXmpRZnJxcX6eXl5qySZGYLwe3PJbdwfj6teOhxgFOBiVeHgLbMPChFgTy4orcw8x SnAwK4nwxmQDhXhTEiurUovy44tKc1KLDzFKc7AoifO2MD0IFRJITyxJzU5NLUgtgskycXBK NTCKC1V/2aPBabbxwrZPql0rj0ieCPl3kmffciXL5Lg3jpozZ0dMW/Xu94uT6v8eqvDWr+MU mJ1SeSyiet1t56sPQmaaXyvYqnErSSF/T7Feom572+x9W550B5/1comN2LXs8PusY/FnPO26 p22QcXhbHyIrq2Tws/dX2pzqZ1ZRH2e8u8lxN2OuEktxRqKhFnNRcSIA7xQkc9MCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/core/XNJHSKRQm0BVC4c9WSYxD2yCL4g>
Cc: "draft-ietf-core-block@ietf.org" <draft-ietf-core-block@ietf.org>, "core-chairs@ietf.org" <core-chairs@ietf.org>, "core@ietf.org" <core@ietf.org>, "barryleiba@gmail.com" <barryleiba@gmail.com>
Subject: Re: [core] Last Call: <draft-ietf-core-block-18.txt> (Block-wise transfers in CoAP) to Proposed Standard
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 26 Nov 2015 07:07:05 -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 On 2015-11-20 22:32, "The IESG" <iesg-secretary@ietf.org> 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@ietf.org mailing lists by 2015-12-04. Exceptionally, comments may be >sent to iesg@ietf.org 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] Last Call: <draft-ietf-core-block-18.txt> … The IESG
- Re: [core] Last Call: <draft-ietf-core-block-18.t… Göran Selander
- Re: [core] Last Call: <draft-ietf-core-block-18.t… Carsten Bormann
- Re: [core] Last Call: <draft-ietf-core-block-18.t… Göran Selander
- Re: [core] Last Call: <draft-ietf-core-block-18.t… Jim Schaad
- Re: [core] Last Call: <draft-ietf-core-block-18.t… Carsten Bormann
- Re: [core] Last Call: <draft-ietf-core-block-18.t… Jim Schaad
- Re: [core] Last Call: <draft-ietf-core-block-18.t… Göran Selander
- Re: [core] Last Call: <draft-ietf-core-block-18.t… Jim Schaad
- Re: [core] Last Call: <draft-ietf-core-block-18.t… Göran Selander
- Re: [core] Last Call: <draft-ietf-core-block-18.t… Jim Schaad
- Re: [core] Last Call: <draft-ietf-core-block-18.t… Carsten Bormann
- Re: [core] Last Call: <draft-ietf-core-block-18.t… Ludwig Seitz
- Re: [core] Last Call: <draft-ietf-core-block-18.t… Göran Selander