Subject: Re: [core] Question about blockwise and object security

From: Olaf Bergmann <[email-masked]>
Date: Thu, 23 Jul 2015 16:12:00 +0200

Ludwig,

following up on our discussion during the cookie break:

Olaf Bergmann <[email-masked]> writes:

> Ludwig Seitz <[email-masked]> writes:
>
>> I am just looking at draft-ietf-core-block in conjunction with object
>> security (draft-selander-ace-object-security) , and I wonder if any of
>> you are aware of usecases, where it would make sense for a proxy to
>> "repackage" blockwise coap messages into blocks of a different size
>> (or recombine them before forwarding them).
>
> I wonder what this use-case would be:
>
> * If you did not recombine blocks, the proxy would have to pad the
>   changed blocks to the next matching block size (what happens if you
>   hit the 2048-byte-case?). Where constrainedness is an issue this leads
>   nowhere, I suppose.
>
> * If you recombined blocks, message integrity can be checked only for
>   the entire payload, as the original block boundaries are gone. Apart
>   from (potentially?) not being able to extend the protection to CoAP
>   message headers in this case, the receiver would have to recombine the
>   entire payload before it can do the integrity check.

Just wondering (I am not a crypto expert, so please forive me if this is
nonsense):

As AEAD ciphers use some sort of CBC, you could in theory emit the
contents of your MAC creation buffer while making up the distinct
blocks. Maybe*) this intermediate value could be fed together with some
header messages of the CoAP message that transfers the respective block
(such as Block1, or Block2, respectively) into some sort of MIC that
depends on the sending party's credentials**). This MIC then can be
checked by the receiving peer to immediately check the received
block.

*)  "Maybe" in this case means that it must be possible to generate
    the MIC in a way that does not reveal internal state of the AEAD
    function that then can be used to break that mechanisms. Crypto
    folks speak up, please!

**) Note that in (some of) your scenario(s), the splitting party may
    be different from the originator, so you will need to do check
    integrity and authenticity of the entire payload after receiving
    all blocks.

Grüße
Olaf

---

From: Göran Selander <[email-masked]>
Date: Mon, 27 Jul 2015 07:53:36 +0000

Hi Olaf,

I think the overall setting with the blockwise draft is that the Block
option can be changed in an unpredictable way by an intermediary node.
This makes it impossible to integrity protect that option end-to-end.
Furthermore without any restrictions what an intermediary can do I don’t
see how to define an invariant, unless more information is provided to the
endpoints or other assumptions is added on how to split into blocks.

(Still the entire message can be integrity protected and verified
independently of how it is split into blocks during transfer.)

Regards,
Göran

On 2015-07-23 16:12, "Olaf Bergmann" <[email-masked]> wrote:

>_______________________________________________
>core mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/core

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 27 Jul 2015 10:46:21 +0200

Hi Göran,

> independently of how it is split into blocks during transfer.)

You are right. As the latter would put a large burden onto the client
because it has to provide buffer space for collecting all blocks before
it can check their authenticity, the options that Ludwig and I have
discussed to deal with this problem were:

1. Either forbid/deprecate intermediaries to split a protected message
   into blocks, or

2. if an intermediary splits a protected message into blocks it must add
   some sort of integrity protection for the block to enable the
   receiver to detect and throw away blocks that have been injected by a
   malicious intermediary.

My previous post was a follow-up on option #2 which is the best you can
do if you don't go for option #1. (My personal preference is still #1.)

Grüße
Olaf

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 27 Jul 2015 11:07:15 +0100

>    receiver to detect and throw away blocks that have been injected by a

FWIW, I don't believe I've ever seen that work. The crucial problems
being that the receiver doesn't have any basis on which to accept or
reject the actions of an intermediary, and that in general this can
happen more than once on a path and it may not be the ultimate receiver
who needs to check. All that seems to always add up to something that
just doesn't work and you end up with only hop-by-hop or end-to-end
security being practical.

S.

---

From: Göran Selander <[email-masked]>
Date: Mon, 27 Jul 2015 10:58:25 +0000

Hi Olaf,

Thanks for clarifying the ambition level. Our ambition was just to protect
blockwise transfer end-to-end as defined by the current draft. If we go
beyond that then there are certainly things we could do, but I’m not sure
if such changes are attractive from the blockwise functionality point of
view. Just to give a naive example (which may very well be completely out
of scope or removing some of the desirable properties): If the sender
could in some way become informed about the minimum block size for a
particular transaction it could split the packet from the start. Even if
this would not be a default solution, allowing this as a fall back could
definitely improve the situation.

Regards,
Göran

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 27 Jul 2015 13:23:23 +0200

Hi Göran,

> definitely improve the situation.

I agree with this view.

One problem is that an adversary might be able to inject malicious
blocks during transmission to fill the receiver's buffers (the one that
must collect all blocks before it can check the MAC tag). This could be
mitigated by per-block MICs as suggested.

Grüße
Olaf

---

From: Robert Cragie <[email-masked]>
Date: Mon, 27 Jul 2015 12:25:33 +0100

> > endpoints or other assumptions is added on how to split into blocks.

<RCC>The only way I can see this working is to protect the blocks at the
originator somehow and then if an intermediary wants to change block size,
it effectively has to encapsulated the original blocks. This would work for
both splitting and recombining but is certainly awkward in many ways. Also
every intermediary would have to further encapsulate. This could get over
having to buffer a lot of stuff but is complicated as the target recipient
would have to be able to verify data from the originator and all
intermediaries.</RCC>

> it can check their authenticity,

<RCC>Not necessarily. Firmware download is often cited as a use case and
almost invariably the whole firmware image has a check code (cryptographic
or otherwise) associated with it before it can actually be used. It
therefore has to be stored somewhere, usually in a secondary flash
buffer.</RCC>

the options that Ludwig and I have
> 1. Either forbid/deprecate intermediaries to split a protected message

<RCC>Probably the safest option. Then the blocks themselves may not need to
be protected. However, unless DTLS protection is end to end, there is still
a potential for an intermediary to insert/delete/manipulate blocks</RCC>

>    receiver to detect and throw away blocks that have been injected by a

<RCC>Agree - protecting blocks at the originator but this would likely be
using something other than DTLS.</RCC>

---

From: Olaf Bergmann <[email-masked]>
Date: Mon, 27 Jul 2015 13:26:34 +0200

> security being practical.

Yes, I completely agree!

Grüße
Olaf

---

From: Göran Selander <[email-masked]>
Date: Tue, 28 Jul 2015 06:23:31 +0000

>security being practical.

Maybe this has already been discussed but just for clarification: Do we
want to secure blockwise transfer end-to-end or should we leave to the
applications of CoAP? Example of use case mentioned is firmware update.

Regards,
Göran

---

From: "weigengyu" <[email-masked]>
Date: Wed, 29 Jul 2015 18:10:56 +0800

Hi Göran,

My opinion is that CoAP should have the capability to secure blockwise 
transfer end-to-end.

Regards,

Gengyu WEI
Network Technology Center
School of Computer
Beijing University of Posts and Telecommunications
-----原始邮件----- 
From: Göran Selander
Sent: Tuesday, July 28, 2015 2:23 PM
To: core
Subject: Re: [core] Question about blockwise and object security

Regards,
Göran

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 29 Jul 2015 12:49:14 +0200

> applications of CoAP? Example of use case mentioned is firmware update.

There are two ways to do this:
Secure each exchange of the blockwise transfer or secure the blockwise
transfer as a whole.  The first one we almost get for free, unless we
want to support re-arrangement of blocks in a proxy (then it gets
hairy).  The second one is easy for the payload-only variant (PAYL) that
you are proposing, slightly less easy for the message protection (COAP):
the latter would need some rules about which options need to coincide
between the blocks to make the entire transfer valid.

I can imagine use cases for each of these variants.  For a firmware
transfer that happens on an unprotected network using NoSec mode, you
actually might want both at the same time (protect the blocks to make
denial of service harder, protect the whole because you might want to
use a more expensive operation there).  Of course, the first may be done
by DTLS (not using NoSec mode), and the second may be done by some
application-defined mechanism specifically protecting firmware updates.

Grüße, Carsten