Re: [Cbor] Review: draft-bormann-cbor-packed-00 & SUIT

[Brendan Moran <[e-mail]>]

> On 29 Jul 2020, at 18:53, Michael Richardson <[e-mail]> wrote:
>
>
> Brendan Moran <[e-mail]> wrote:
>> My intent was to verify first, then unpack. This is because the
>> unpacked structure never exists, in its entirety, in memory. If you
>> have to unpack straight into the digest algorithm in order to verify,
>> you introduce a TOCTOU problem. If you verify first, you at least have
>> a static, verified object.
>
> I agree.  I would write the encoder "sign the packed structure"
> (so decoder we verify first, then unpack...)
>
> I like this because it means:
> a) a third party can verify the signature without having the dictionaries.
>  Clearly it can't audit the contents without the external dictionar(y/ies).
>
> b) at this point in the specification I'm unclear if multiple passes of the
>  unpacked content is required.  But, if we did want to permit such
>  self-referential things, the decoder could wind up decoding infinite
>  things.  Such a thing ight be a desireable feature!
>  We could accomodate such a thing if with sign the packed structure,
>  because the decoder would know it's authentic before it tried to
>  expand.

The original specification prohibits loops, but leaves the implementation up to the reader.

>> The problem with this approach is dictionary selection. We need some
>> way to hint a dictionary identifier if it’s not obvious. This could be
>> a tag, an element in the Tag 6 array, some kind of OOB signal, or
>> something else.
>
> I think it needs to be in the tag 6 array.

Possibly, but this opens the question of where it goes. Maybe it needs to be explicitly included. Suppose that we use a special case:

Tag 6([rump, Tag 6(dictionary-id)]).

The context of the second Tag 6 (normally, there would be an array there) makes it clear that this is an external reference dictionary. We could specify a reference digest in the tag as well:

Tag 6([rump, Tag 6([digest-alg, digest-bytes, dictionary-id])])

I’m not sure this is the right approach, but I like that it keeps Tag 6 information in Tag 6

>
>   cabo> There are two aspects here:
>   cabo> — how do we make sure the external dictionary cannot be surreptitiously
>   cabo> exchanged by an attacker
>
>> This requires some sort of security mechanism. Using a COSE feature
>> that includes additional data is not ideal in SUIT because we support
>> COSE_Sign, COSE_Sign1, COSE_MAC, or COSE_MAC0, or any combination
>> thereof. This would mean that a COSE feature that includes extra data
>> would be duplicated for as many COSE objects as are included. Of
>> course, that’s not particularly relevant if the list of COSE objects is
>> also using packed CBOR, so maybe it’s fine.
>
>> Including a dictionary reference as AAD seems fine to me. In the SUIT
>> case, I think I would make it more explicit because we need to identify
>> which external dictionary to digest.
>
>   cabo> — how do we make sure there is an unambiguous
>   cabo> way to integrate the external dictionary/-ies into the prefix and sharing tables?
>
>> We need to (logically) concatenate the dictionaries together. The question is: which order?
>
>> From a pull parser perspective, I think I would suggest a stack-based model:
>> - Each dictionary is an element in a singly linked list.
>> - When you encounter a new dictionary, you push it onto the head of the list
>> - When you finish a rump element, you pop the dictionary associated
>> with it from the head of the list.
>
>> - When you find a dictionary reference in the rump, you traverse the
>> dictionary list, starting at the most recent.
>
>> - When you find a dictionary reference in a dictionary element, you
>> traverse the dictionary list, starting at the current dictionary.
>
> Implying that dictionaries can be created that are self-referential, and can
> blow up to infinite data streams :-)

As above, the original specification prohibits loops, but leaves the implementation up to the reader.

>
> Unless you mean that dictionaries should be sorted so that they always (can only)
> reference forward, and you can start at the current location in the current
> dictionary.

Possibly, but I’m not sure that’s universally advantageous. Remember that we want high reference frequency items to be at the start. Suppose that I have the prefixes [“https://“, “www.”, “files.”, “domain.com”]. Clearly, I want to be able to compose these in one of two ways:

https://www.domain.com
https://files.domain.com

Only these two prefixes will appear in my object, the others will not, which renders their compression less important. I would expect something like:

[[Tag 225(simple(0)), Tag 226(simple(0), Tag 227(“www.”), Tag 227(“files”), “https://“], “domain.com"]

Note that the sorting is the opposite of what’s implied.

But what if “https://" is used extensively? Then we need to change our sort order so that it can be referenced with Tag 6().

I think we need to be very clear about what’s allowed because otherwise, there will be a lot of varied implementations with varied limitations.

>> It has several disadvantages:
>> - References have inconsistent meanings (Tag 6 (1) doesn’t mean the
>> same dictionary entry everywhere. It points to different dictionaries
>> in different places)
>
>> - The stack model requires some kind of allocation strategy to keep
>> track of the dictionaries.
>
> It's a stack of pointers.  It can point at the in-band dictionary which can
> be processed by a pull-parser.  Or at an out-of-band dictionary which is
> probably in "ROM" in some convenient format (probably CBOR map)

Indeed. Not too bad, I think.

>
>> - The compressor has to be aware of the dictionaries of packed CBOR
>> objects it traverses in order to pack anything that appears within an
>> already packed CBOR object.
>
> In the SUIT case, the compressor is "cloud" :-)

Yup. Let’s not make things hard for constrained nodes because it’s easier for unconstrained ones.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.