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

[Michael Richardson <[e-mail]>]

{please note that this converation is incomprehensible unless you render the
HTML, so the archives are be useless. I feel that this thread should be in
the SUIT WG too, but I won't CC because catching up will be hard}


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.

    > This could be an even harder question to ask with the use of an external
    > dictionary.  There is one potential benefit w/ COSE in that the hash of the
    > dictionary could be included as external data.

i.e. it could go into the protected bucket.

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

    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 :-)

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.

    > This has several advantages:
    > - It’s compatible with including a packed CBOR object inside a packed
    > CBOR object without rewriting any references.
    > - The data model for dictionary traversal is fairly simple

I agree.

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

    > - 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" :-)

    > However, this may be naive as well. It implies that there is only a
    > list of dictionaries that applies at any point, rather than a
    > tree. This is probably accurate when looking at nested packed
    > objects. It might be more of a problem with external dictionaries.

    > I think that external dictionaries *outside* an authentication object
    > probably don’t require authentication, since the authentication object
    > itself will naturally verify these data. However, any external
    > dictionary represented *inside* an authentication object MUST also be
    > authenticated.

--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-