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

From: Göran Selander <[email-masked]>
Date: Mon, 1 Feb 2016 08:20:00 +0000

Hi Jim

Thanks for picking up the thread.

We spent some time in Prague thinking about this. You are right that there
are different options with different characteristics. Here are the cases
we have considered.

Just to recap the objective, this is about protecting communication
between CoAP client and CoAP server while allowing legitimate operations
of one or more intermediary CoAP proxies. Client and server are assumed to
have a security association.

On a high level the candidate solutions are either built entirely on top
of CoAP or add new CoAP options.

Looking at the former first, one solution is to wrap just the CoAP
payload/content, e.g. using COSE [1]. (We called this object security of
content, OSCON). This is useful if the payload includes certain meta data,
like in the case of CWT, or if certain information, such as resource
identifier etc., is implicit from the security association.

This solution however does not protect the metadata sent in the CoAP
message, such as e.g. Code (GET/DELETE/etc), Uri-Path or Content Format.
Even if such information would be integrity protected, e.g. using
External-AAD in [1], it neither protects messages which do not have
payload, like e.g. GET requests, nor does it address confidentiality
desirable for a subset of such metadata for privacy reasons.

An alternative solution on top of CoAP is to move the RESTful protocol out
of CoAP and only use POST with some dummy Uri-Path, Content Format etc. In
this way all messages could carry a protected object as in [1] and the
nature of the interaction and content is contained in this object. This is
probably violating the purpose of CoAP too much to be of any interest.

Those are the only solutions we have considered on top of CoAP. I'm not
sure if the solution you propose is related to one of these?

All other solutions I'm aware of which address the general problem space,
e.g. OSCOAP, are built "within" CoAP, using CoAP options to carry
protected objects (such as [1]) which include integrity protection of the
payload and meta-data. Now, what happens if the payload is large? If the
originating endpoint does the fragmentation then the destination endpoint
can verify the integrity. If a proxy using the blockwise draft
(re-)fragments the payload (which also changes a Block option) such that
it is different when reaching the destination endpoint, then integrity
verification will fail. The destination endpoint cannot distinguish a
legitimate introduction/change of payload and Block option from any other
change of the message, hence it cannot verify integrity. This can be used
to disable integrity protection at CoAP layer also for shorter messages,
since the destination endpoint must treat the existence of a Block option
as a generic "security off" button.

This is quite different from the CoAP options standardized so far where
you can protect individual messages between client and server at the same
time as allowing legitimate proxy operation, even verifying that
intermediate nodes has performed the correct CoAP option manipulations
such as e.g. when forward proxies change the Uri-* options making the
message reach the correct destination URI.

IMHO CoAP should not allow an intermediate device to legitimately turn off
integrity protecting between client and server. CoAP should definitely
support integrity protection of short messages between client and server
through proxies. This is where CoAP shines brightly. Given that, it is
straightforward to integrity protect messages fragmented at the endpoints.
And with the Block options integrity protected the entire message built up
of the fragments is automatically protected as well.

Göran

[1] https://tools.ietf.org/html/draft-ietf-cose-msg

On 2016-01-29 00:18, "Jim Schaad" <[email-masked]> wrote:

>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:[email-masked]] On Behalf Of Göran Selander
>> Sent: Wednesday, November 25, 2015 11:07 PM
>> To: [email-masked]
>> Cc: [email-masked]; [email-masked]; [email-masked];
>> [email-masked]
>> 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" <[email-masked]> 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
>> >[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.
>> >
>> >
>> 
>> _______________________________________________
>> core mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/core
>

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 1 Feb 2016 12:28:59 -0800

Göran,

You apparently have missed the main point of what I was saying in my message.

I see both of these cases as having a single message to be protected:
1.  I am sending a small message that does not get fragmented
2.  I am sending a large message that needs to be fragmented into 5 messages using the Block-wise transfer options.

In both cases I am doing an integrity protection/encryption operation on a single message that might later be fragmented into multiple pieces.  I do not want to integrity protect each of the 5 block transfer messages independently because of a number of problems which you have pointed out about messages getting re-fragmented in transit.  Additionally, I do not want to deal with each messages separately because I do not want to be in a situation where a block could be changed for a different block from a different stream.

This would be the case of sending A1 A2 A3 A4 and receiving A1 A2 B3 A4 where each of the fragments individually verifies, but the entire stream has been changed.  Doing a single integrity operation over the entire stream of (A1 A2 A3 A4) means that receiving (A1 A2 B3 A4) would fail to validate because the entire stream of bytes would fail validation.

This means that I treat security identically if the block options are there or if the block options are not there.

There are other discussions that need to be dealt with about options and how they interact with security, but the report of the group working on this has not yet come up for review. I am just worried about getting this draft finished.

jim

> From: Göran Selander [mailto:[email-masked]]
> Sent: Monday, February 01, 2016 12:20 AM
> To: Jim Schaad <[email-masked]>; [email-masked]
> Subject: Re: [core] Last Call: <draft-ietf-core-block-18.txt> (Block-wise transfers
> We spent some time in Prague thinking about this. You are right that there are
> different options with different characteristics. Here are the cases we have
> considered.
> 
> Just to recap the objective, this is about protecting communication between
> CoAP client and CoAP server while allowing legitimate operations of one or
> more intermediary CoAP proxies. Client and server are assumed to have a
> security association.
> 
> On a high level the candidate solutions are either built entirely on top of CoAP or
> add new CoAP options.
> 
> payload/content, e.g. using COSE [1]. (We called this object security of content,
> OSCON). This is useful if the payload includes certain meta data, like in the case
> of CWT, or if certain information, such as resource identifier etc., is implicit
> from the security association.
> 
> This solution however does not protect the metadata sent in the CoAP message,
> such as e.g. Code (GET/DELETE/etc), Uri-Path or Content Format.
> Even if such information would be integrity protected, e.g. using External-AAD in
> [1], it neither protects messages which do not have payload, like e.g. GET
> requests, nor does it address confidentiality desirable for a subset of such
> metadata for privacy reasons.
> 
> An alternative solution on top of CoAP is to move the RESTful protocol out of
> CoAP and only use POST with some dummy Uri-Path, Content Format etc. In this
> way all messages could carry a protected object as in [1] and the nature of the
> interaction and content is contained in this object. This is probably violating the
> purpose of CoAP too much to be of any interest.
> 
> Those are the only solutions we have considered on top of CoAP. I'm not sure if
> the solution you propose is related to one of these?
> 
> All other solutions I'm aware of which address the general problem space, e.g.
> OSCOAP, are built "within" CoAP, using CoAP options to carry protected objects
> (such as [1]) which include integrity protection of the payload and meta-data.
> Now, what happens if the payload is large? If the originating endpoint does the
> fragmentation then the destination endpoint can verify the integrity. If a proxy
> using the blockwise draft (re-)fragments the payload (which also changes a
> Block option) such that it is different when reaching the destination endpoint,
> then integrity verification will fail. The destination endpoint cannot distinguish a
> change of the message, hence it cannot verify integrity. This can be used to
> disable integrity protection at CoAP layer also for shorter messages, since the
> destination endpoint must treat the existence of a Block option as a generic
> "security off" button.
> 
> This is quite different from the CoAP options standardized so far where you can
> protect individual messages between client and server at the same time as
> allowing legitimate proxy operation, even verifying that intermediate nodes has
> performed the correct CoAP option manipulations such as e.g. when forward
> proxies change the Uri-* options making the message reach the correct
> destination URI.
> 
> integrity protecting between client and server. CoAP should definitely support
> integrity protection of short messages between client and server through
> proxies. This is where CoAP shines brightly. Given that, it is straightforward to
> integrity protect messages fragmented at the endpoints.
> And with the Block options integrity protected the entire message built up of the
> fragments is automatically protected as well.
> 
> 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.
> >
> >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.
> >
> >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.
> >
> >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
> >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
> >
> >
> >
> >> Cc: [email-masked]; [email-masked];
> >>[email-masked];  [email-masked]
> >>(Block-wise transfers  in CoAP) to Proposed Standard
> >>
> >>
> >>
> >>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:
> >>
> >>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.
> >>
> >>
> >>client and  server for the use cases where the proxy should not be
> >>fully trusted.
> >>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
> >>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.
> >>
> >>

---

From: Göran Selander <[email-masked]>
Date: Mon, 1 Feb 2016 21:55:03 +0000

Jim,

Yes, apparently we do talk past each other. Inline.

On 2016-02-01 21:28, "Jim Schaad" <[email-masked]> wrote:

>2.  I am sending a large message that needs to be fragmented into 5
>messages using the Block-wise transfer options.
>
>In both cases I am doing an integrity protection/encryption operation on
>a single message that might later be fragmented into multiple pieces.

I don’t understand how your solution protects CoAP metadata like Code,
Content-Format and Uri-Path. I may be wrong but it seems you are only
protecting CoAP payload, which is sufficient for certain use cases, but
for other use cases we also need to protect metadata. The blockwise draft
applies to both kind of use cases.

> I do not want to integrity protect each of the 5 block transfer messages
>independently because of a number of problems which you have pointed out
>about messages getting re-fragmented in transit.

My point of view is that messages should not be re-fragmented in transit.

> Additionally, I do not want to deal with each messages separately
>because I do not want to be in a situation where a block could be changed
>for a different block from a different stream.

This is not an issue if you integrity protect the appropriate Block
option, which contains the number of the block and if it is the last.
Re-fragmentation prevents Block options from being possible to integrity
protect between client and server.

>
>This would be the case of sending A1 A2 A3 A4 and receiving A1 A2 B3 A4
>where each of the fragments individually verifies, but the entire stream
>has been changed.  Doing a single integrity operation over the entire
>stream of (A1 A2 A3 A4) means that receiving (A1 A2 B3 A4) would fail to
>validate because the entire stream of bytes would fail validation.

This is not an issue if you integrity protect the appropriate Block option.

>
>This means that I treat security identically if the block options are
>there or if the block options are not there.

Yes, since you focus on an over-the-top solution you can do that. But the
only over-the-top solution I know of that protects metadata is the one
mentioned below which moves REST out of CoAP.

>
>There are other discussions that need to be dealt with about options and
>how they interact with security, but the report of the group working on
>this has not yet come up for review. I am just worried about getting this
>draft finished.

And I’m worried that this draft voids the candidate solutions for
protecting payload and metadata.

Göran

>>between
>>message,
>>External-AAD in
>>sure if
>>you can
>>support

---

From: "Jim Schaad" <[email-masked]>
Date: Mon, 1 Feb 2016 14:52:27 -0800

Göran,

It I always more helpful to be on the same page.

See below

> Sent: Monday, February 01, 2016 1:55 PM
> >1.  I am sending a small message that does not get fragmented 2.  I am
> >sending a large message that needs to be fragmented into 5 messages
> >using the Block-wise transfer options.
> >
> >In both cases I am doing an integrity protection/encryption operation
> >on a single message that might later be fragmented into multiple pieces.
> 
> protecting CoAP payload, which is sufficient for certain use cases, but for other
> use cases we also need to protect metadata. The blockwise draft applies to both
> kind of use cases.

Remember that I am looking at dealing with this as a single message.  There is going to be a solution for using COSE with CoAP that is protecting the headers in a single message.  I am assuming that this is the same solution that needs to be used for dealing with the fragmented message as well.  The set of options from the fragmented message is built into an external object which is then authenticated as part of the process of authenticating the base block.

This is where the current BLOCK draft falls apart on its own merits.  It does not discuss what should happen if the set of options is not the same between all of the blocks. This is a problem if one is using security or not.  The correct set of headers is the set that needs to be protected, but there is no way to determine what the set of headers is supposed to be.

> 
> 
> > I do not want to integrity protect each of the 5 block transfer
> >messages independently because of a number of problems which you have
> >pointed out about messages getting re-fragmented in transit.
> 

Why do you believe that this is a problem?  I cannot see any problems with it myself.

> >because I do not want to be in a situation where a block could be
> >changed for a different block from a different stream.
> 
> This is not an issue if you integrity protect the appropriate Block option, which
> contains the number of the block and if it is the last.

That is insufficient to provide the protection.  In addition you would need to be able to protect some value which says that all of these are from a single fragmented message as well.  This means that one would need to ensure that this value is not reused under some set of constraints.  What happens if I received a block 4 of 5 from server A and a block 4 of 5 from server B.  The block values are going to be correct, but they are from different streams.  So protecting what stream they are from is needed as well as making sure that there is some value which to protect from different streams from the same server.  (Ok - I just found another thing that I need to make sure that the BLOCK draft supports correctly.)

> >where each of the fragments individually verifies, but the entire
> >stream has been changed.  Doing a single integrity operation over the
> >entire stream of (A1 A2 A3 A4) means that receiving (A1 A2 B3 A4) would
> >fail to validate because the entire stream of bytes would fail validation.
> 

Not that the block option  is the same for both A3 and B3.  
NUM = 3, M = no, SZX=1K

> Yes, since you focus on an over-the-top solution you can do that. But the only
> over-the-top solution I know of that protects metadata is the one mentioned
> below which moves REST out of CoAP.
> 
> >
> >There are other discussions that need to be dealt with about options
> >and how they interact with security, but the report of the group
> >working on this has not yet come up for review. I am just worried about
> >getting this draft finished.
> 
> And I’m worried that this draft voids the candidate solutions for protecting
> payload and metadata.

There I cannot help as I have not seen anything yet.

Jim

> >> We spent some time in Prague thinking about this. You are right that
> >>there are  different options with different characteristics. Here are
> >>the cases we have  considered.
> >>
> >>between  CoAP client and CoAP server while allowing legitimate
> >>operations of one or  more intermediary CoAP proxies. Client and
> >>server are assumed to have a  security association.
> >>
> >> On a high level the candidate solutions are either built entirely on
> >>top of CoAP or  add new CoAP options.
> >>
> >>payload/content, e.g. using COSE [1]. (We called this object security
> >>of content,  OSCON). This is useful if the payload includes certain
> >>meta data, like in the case  of CWT, or if certain information, such
> >>as resource identifier etc., is implicit  from the security
> >>association.
> >>
> >>payload, like e.g.
> >>GET
> >> requests, nor does it address confidentiality desirable for a subset
> >>of such  metadata for privacy reasons.
> >>
> >> An alternative solution on top of CoAP is to move the RESTful
> >>protocol out of  CoAP and only use POST with some dummy Uri-Path,
> >>Content Format etc. In this  way all messages could carry a protected
> >>object as in [1] and the nature of the  interaction and content is
> >>contained in this object. This is probably violating the  purpose of
> >>CoAP too much to be of any interest.
> >>
> >> Those are the only solutions we have considered on top of CoAP. I'm
> >>not sure if  the solution you propose is related to one of these?
> >>
> >> OSCOAP, are built "within" CoAP, using CoAP options to carry
> >>protected objects  (such as [1]) which include integrity protection of
> >>the payload and meta-data.
> >> Now, what happens if the payload is large? If the originating
> >>endpoint does the  fragmentation then the destination endpoint can
> >>verify the integrity.
> >>If a proxy
> >> using the blockwise draft (re-)fragments the payload (which also
> >>changes a  Block option) such that it is different when reaching the
> >>destination endpoint,  then integrity verification will fail. The
> >>destination endpoint cannot distinguish a  legitimate
> >>introduction/change of payload and Block option from any other  change
> >>of the message, hence it cannot verify integrity. This can be used to
> >>disable integrity protection at CoAP layer also for shorter messages,
> >>since the  destination endpoint must treat the existence of a Block
> >>option as a generic  "security off" button.
> >>
> >> This is quite different from the CoAP options standardized so far
> >>where you can  protect individual messages between client and server
> >>at the same time as  allowing legitimate proxy operation, even
> >>verifying that intermediate nodes has  performed the correct CoAP
> >>option manipulations such as e.g. when forward  proxies change the
> >>Uri-* options making the message reach the correct  destination URI.
> >>
> >> IMHO CoAP should not allow an intermediate device to legitimately
> >>turn off  integrity protecting between client and server. CoAP should
> >>definitely support  integrity protection of short messages between
> >>client and server through  proxies. This is where CoAP shines
> >>brightly. Given that, it is straightforward to  integrity protect
> >>messages fragmented at the endpoints.
> >> And with the Block options integrity protected the entire message
> >>built up of the  fragments is automatically protected as well.
> >>
> >> Göran
> >>
> >> >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.
> >> >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.
> >> >
> >> >This can be deferred until the general discussion about the rest of
> >> >the current headers.
> >> >
> >> >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
> >> >
> >> >
> >> >
> >> >> 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:
> >> >>
> >> >>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.
> >> >>
> >> >>
> >> >>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
> >> >>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
> >> >> 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
> >> >>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
> >> >>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.
> >> >>
> >> >>
> >> >> would need to anticipate or get information about the relevant
> >> >>block size, e.g.
> >> >> While this may not be as simple as leaving it entirely to the
> >> >>proxy
> >>to
> >> >>decide,
> >> >>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
> >> >>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
> >> >> There are other alternatives as well but this e-mail is already
> >> >>too long.
> >> >>through  proxies compared to when RFC7252 was written, my opinon is
> >> >>that we should  not ignore these security issues in new standards.
> >> >>
> >> >>
> >> >>
> >> >> Göran
> >> >>
> >> >>
> >> >>
> >> >> >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
> >> >> >
> >> >> >
> >> >> >   networks.  Basic CoAP messages work well for the small
> >> >> > payloads
> >>we

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 02 Feb 2016 00:15:14 +0100

> This is where the current BLOCK draft falls apart on its own merits.  It does not discuss what should happen if the set of options is not the same between all of the blocks. This is a problem if on…

This is not entirely true.  For Content-Format, 2.3 has this discussion:

   The Content-Format Option sent with the requests or responses MUST
   reflect the content-format of the entire body.  If blocks of a
   response body arrive with different content-format options, it is up
   to the client how to handle this error (it will typically abort any
   ongoing block-wise transfer).  If blocks of a request arrive at a
   server with mismatching content-format options, the server MUST NOT
   assemble them into a single request; this usually leads to a 4.08
   (Request Entity Incomplete, Section 2.9.2) error response on the
   mismatching block.

For ETag, 2.4 has:

   Block-wise transfers can be used to GET resources the representations
   of which are entirely static (not changing over time at all, such as
   in a schema describing a device), or for dynamically changing
   resources.  In the latter case, the Block2 Option SHOULD be used in
   conjunction with the ETag Option, to ensure that the blocks being
   reassembled are from the same version of the representation: The
   server SHOULD include an ETag option in each response.  If an ETag
   option is available, the client's reassembler, when reassembling the
   representation from the blocks being exchanged, MUST compare ETag
   Options.  If the ETag Options do not match in a GET transfer, the
   requester has the option of attempting to retrieve fresh values for
   the blocks it retrieved first.  To minimize the resulting

It is hard to discuss all potential options because new options may have
interesting interactions with the Block options, which I hope will be
specified with those options.

More interesting is Max-Age, as this can change during the transfer, or
Size2.  Location-Path/-Query is something that is often only available
at the end of the block transfer, so I would expect that to come with
the block(s) carrying the 2.01.

Also, 2.4 specifies:

   When a request is answered with a response carrying a Block2 Option
   with the M bit set, the requester may retrieve additional blocks of
   the resource representation by sending further requests with the same
   options as the initial request and...

While I agree this could be spelled out in more detail, the information
basically is there.

Grüße, Carsten

---

From: Göran Selander <[email-masked]>
Date: Tue, 2 Feb 2016 14:27:58 +0000

Jim,

>It I always more helpful to be on the same page.

Yes, I hope we get there soon :-) Clearly we have different solutions in
mind and value the drawbacks differently.

More inline.

>>for other
>Remember that I am looking at dealing with this as a single message.
>There is going to be a solution for using COSE with CoAP that is
>protecting the headers in a single message.  I am assuming that this is
>the same solution that needs to be used for dealing with the fragmented
>message as well.  The set of options from the fragmented message is built
>into an external object which is then authenticated as part of the
>process of authenticating the base block.
>
>This is where the current BLOCK draft falls apart on its own merits.  It
>does not discuss what should happen if the set of options is not the same
>between all of the blocks. This is a problem if one is using security or
>not.  The correct set of headers is the set that needs to be protected,
>but there is no way to determine what the set of headers is supposed to
>be.
>
>> 
>> 

I find it problematic with a Block option which whenever used has as
effect that the receiver cannot verify the integrity of the received CoAP
message; that requires the message to be cached; and that only after
having received an unspecified number of subsequent messages it is maybe
possible to verify the integrity of.

>>option, which
>That is insufficient to provide the protection.  In addition you would
>need to be able to protect some value which says that all of these are
>from a single fragmented message as well.  This means that one would need
>to ensure that this value is not reused under some set of constraints.
>What happens if I received a block 4 of 5 from server A and a block 4 of
>5 from server B.  The block values are going to be correct, but they are
>from different streams.  So protecting what stream they are from is
>needed as well as making sure that there is some value which to protect
>from different streams from the same server.  (Ok - I just found another
>thing that I need to make sure that the BLOCK draft supports correctly.)

As mentioned, we assume a security association per server so we can tell
apart blocks from different servers. For OSCOAP we assume a freshness
parameter which could potentially be used to distinguish different
fragments from the same server, unless there is parallel transmission of
different streams. And as you noted, in that case there must be some other
way to distinguish the fragments, and that information is potentially
already integrity protected (e.g. by being part of an option that is
integrity protected) or can become integrity protected.

>>option.

Well I meant you integrity protect also the Block option, in addition to
the other options, payload and freshness parameter.

>There I cannot help as I have not seen anything yet.

Sorry, I thought it was clear that I was referring to constructions like
draft-selander-ace-object-security or draft-bergmann-ace-dcaf-cose.

Göran