RE: [core] Last Call: <draft-ietf-core-block-18.txt> (Block-wise transfers in CoAP) to Proposed Standard
2016-01-28 17:21:02
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(_at_)ietf(_dot_)org] On Behalf Of Göran
Selander
Sent: Wednesday, November 25, 2015 11:07 PM
To: ietf(_at_)ietf(_dot_)org
Cc: draft-ietf-core-block(_at_)ietf(_dot_)org;
core-chairs(_at_)ietf(_dot_)org; core(_at_)ietf(_dot_)org;
barryleiba(_at_)gmail(_dot_)com
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(_at_)ietf(_dot_)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(_at_)ietf(_dot_)org mailing lists by 2015-12-04. Exceptionally,
comments may
be sent to iesg(_at_)ietf(_dot_)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 mailing list
core(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/core
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- RE: [core] Last Call: <draft-ietf-core-block-18.txt> (Block-wise transfers in CoAP) to Proposed Standard,
Jim Schaad <=
|
|
|