Subject: [Fud] A few questions / observations

From: "Smith, Ned" <[email-masked]>
Date: Fri, 15 Sep 2017 15:29:30 +0000

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

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

·         Why was ASN.1 selected as the encoding format? (Why not 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 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.

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

·         There are still a few typos.

---

From: Brendan Moran <[email-masked]>
Date: Tue, 26 Sep 2017 20:54:54 +0000

Hi Ned,
I’ve placed my comments inline.

Thanks for your feedback!

Best Regards,
Brendan

On 15 Sep 2017, at 16:29, Smith, Ned <[email-masked]<mailto:[email-masked]>> 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
[email-masked]<mailto:[email-masked]>
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.

---

From: "Smith, Ned" <[email-masked]>
Date: Wed, 27 Sep 2017 00:01:43 +0000

See additional comments inline below.
-Ned

From: Brendan Moran <[email-masked]>
Date: Tuesday, September 26, 2017 at 1:54 PM
To: "Smith, Ned" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Fud] A few questions / observations

Hi Ned,

Best Regards,
Brendan

[stuff deleted]

  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.
[nms] HSMs are a computing environment that is constrained to operations involving mostly cryptographic and key exchange operations. Your observation is that ASN.1 is the data model language of choice by the HSM community. I agree that is the correct choice for that constrained environment. However, it is also the case that there are other environments that have chosen different data model languages and operate in a constrained environment. COSE, JSON and XML are commonly available parsers in these other environments. The logic that argues for propagation of ASN.1 because the HSM “constrained environment already supports it and therefore avoids ‘bloat’ of an additional parser” can be used to argue the other side as well. Since the constrained device already supports an alternative (e.g. COSE, JSON, XML…) and the dependence on ASN.1 represents additional overhead to the constrained environment. In cases where both an application processor and HSM environments exist it makes sense to use one or the other or both, but not introduce a third. I’m not taking a strong position on ASN.1 vs. COSE (or some other alternative) except to observe that it shouldn’t be the objective of FUD to advocate a particular data model language over another, but rather should try to accommodate the data model language choices of the constrained environments for which this RFC hopes to be relevant. It should be noted that most data model languages that embrace security typically make accommodation for a security DML by encapsulating PKCS and X.509 - implying ASN.1/BER/DER support exists somewhere in the platform. However, support for PKCS/X.509 should translate to general and broad support for anything ASN.1 as the range of objects known to PKCS and X.509 is typically rather small.
My opinion is the environment that generates, distributes and installs software updates isn’t entirely HSM or application framework (e.g. LWM2M). Therefore, it is reasonable to expect multiple encodings may be required.

  1.  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
[nms] It is also the case that constrained environments may not have chosen OpenSSL, but instead rely on embedTLS, tinyDTLS or other library that doesn’t have the same dependency on SMIME. Compatibility with HSMs is important, but the question for FUD potentially is to understand how much of the RFC’s solution should be computed within the HSM vs. the host processing environment or an available TEE.

  1.  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 programmatically.
[nms] It is true that the ASN.1 tools ecosystem is mature. ASN.1 has been around for a while. That however has not prevented the invention and proliferation of alternative data model languages. If the argument is that ASN.1 will eventually win, we just need to wait longer, then I respectfully disagree. The ecosystems supporting alternative DMLs may be less mature, but they are evolving quickly.

  1.  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.
[nms] The question to ask is whether this sort of parsing inefficiency is a larger pain point than having to do semantic mapping of structures that already are meaningful in the context of the application environment that is performing the update. In such a case, ASN.1 may be the greater pain point.

            [nms] Given COSE encodes X.509 and PKCS structures it would seem the designers anticipated interoperation with HSMs, at least at the key and certificate levels of abstraction. But given COSE defines a cryptographic message syntax of its own, it anticipates relevance in messaging processor environments. My understanding of HSMs are that they don’t anticipate being used as message processors. My question may be a bit more philosophical. Do the authors of the RFC regard the exchange of SW updates and their manifests as being fundamentally an HSM workload or something else; such as device management or possibly a distributed compute?

Thx,
Ned

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 27 Sep 2017 11:43:45 +0200

One minor remark:

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

The way to convey manifests and firmware images is actually independent
from the manifest format itself. This group aims to standardize the
manifest format. The different ways to transport the manifest/firmware
image to the devices can happen using a variety of protocols and in
different flavors, including push and pull approaches. We are using
LwM2M as a way to transport the firmware/manifest, for example.

Ciao
Hannes