Re: [Fud] A few questions / observations

[Brendan Moran <[e-mail]>]

Hi Ned,
I’ve placed my comments inline.

Thanks for your feedback!

Best Regards,
Brendan


On 15 Sep 2017, at 16:29, Smith, Ned <[e-mail]<mailto:[e-mail]>> wrote:

•         Is it possible for the image type to be an existing “manifest” such as “packages” or “bundles”?

I don’t see why not. The manifest is a pretty generic wrapper.

•         Is the push model supported (cloud storage pushes update file proactively)?

Certainly. This is one of the expected use-cases, however manifest must precede payload.

•         Why was ASN.1 selected as the encoding format? (Why not COSE?)

ASN.1 was used for a few reasons.

  1.  It is the default format for certificates. Most tools use DER rather than COSE for packing certificates, so this reduces the number of parsers in the target. Where interwork with HSMs is involved, using a format the HSM supports is beneficial.
  2.  PCKS7 / CMS / RFC5652 are widely supported. For example, OpenSSL’s smime command handles CMS signing/validation directly. This makes the custom tooling required simpler. This will also, hopefully, improve compatibility with existing HSMs
  3.  Direct code generation. In a scenario where the parser does not create a document object model, but extracts or validates specific fields, ASN.1 provides a grammar that makes it possible to generate a parser programatically.
  4.  The meaning of “length” for composite types. In DER, the length of a field is unambiguous. It is always the length, in bytes, of the contained object. This allows a parser that understands the document being parsed to skip large chunks of a deeply nested tree. In CBOR, the “length” of an array or map is the number of elements it contains. This makes it impossible for the parser to “skip” anything. It has to parse the entire structure. It is possible to circumvent some of these limitations using tagging, in particular tag 24 (encoded CBOR data item), but this has the downside of breaking translatability to JSON, which is a key advantage of CBOR. Consistent TLV representation makes parsing in a constrained environment offers a notional performance improvement, but this is minor and may not play out in practice.

Never the less, I think that CBOR/COSE would be perfectly serviceable for this use. I’m not even certain that ASN.1 can’t be used as a schema for CBOR (see 3 above). That being the case, I can see a case for DER manifests with CMS, and CBOR manifests with COSE.


•         It isn’t clear how the manifest and the image (package / bundle) will share the available A /B storage area. Possibly it is assumed the manifest related operations are to be integrated into an existing SW update capability and be taught to understand the manifest structure. Consider the case where version 1 of a SW update tool understands bundles but it receives a file that contains a manifest. Is it expected that the v1 tool will be able to process the update nevertheless (ignoring the manifest). This assumes the encryption option isn’t being applied of course.

The expectation was that manifest would be stored into a separate key/value store.

•         The arch didn’t mention integrity as a requirement. Maybe it is implied but it seems possible for a clever attacker to replace one cipher text with a different cipher text unless integrity were mentioned as a goal and steps taken to allow only cipher suites that achieve both objectives.

This is an interesting point. We may have drafted it as an implicit requirement. I have made the assumption that integrity is a prerequisite for authenticity and authenticity is an expressly stated goal. However, you are correct, this should be made explicit.

•         There is no mention of which crypto algorithms will be supported.

The current expectation is SHA256, AES128-CTR, and ECC secp256r1. There is an argument to be made for SHA512, AES256-CTR, and an equivalent ECC algorithm. We have also discussed using ed25519.

•         There are still a few typos.

I have a few updates coming, so I will review the draft at the same time.


_______________________________________________
Fud mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/fud

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.