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.
>
>