Subject: Re: [Fud] A few questions / observations

From: Brendan Moran <[email-masked]>
Date: Wed, 4 Oct 2017 13:39:57 +0000

Hi Ned,

============
COSE

I think that COSE could be very beneficial in environments where a generic CBOR parser is available and a generic ASN.1 DER parser is not. CBOR has a minor compactness improvement for basic, un-tagged types. I expect COSE adoption to increase over the long term, barring some unexpected problem with the encoding. HSMs are a moot point, since I’m not aware of any support for either CMS or COSE directly on an HSM.

I do have some concerns about the use of CBOR manifests with COSE signatures for firmware updates.

1. Availability on microcontrollers
The primary target of FUD/SUIT is microcontrollers. Each of OpenSSL, mbedTLS, tinyDTLS contain a X.509 parser, which contains everything that is needed for parsing a DER-encoded manifest—N.B. a schema is still needed in each case. In fact, I would be surprised if there were a TLS library available that doesn’t have an X.509 parser. That suggests to me that DER parsers are effectively ubiquitous and that one is already present on every device that is targeted by FUD, since it is unlikely that there would be a FUD target without a TLS library. It may be in the future that CBOR parsers and COSE certificates also become ubiquitous, but it is too early to tell.

2. Schemas
In ASN.1, the meaning of a field is determined by its position in the schema, so the semantics of any field are implicit. CBOR explicitly states that no schema is needed, citing:

> This works much better in a world where both ends of a communication relationship may be evolving at high speed.

While I do anticipate that this is useful in many circumstances, I’m not convinced that it is accurate in Firmware Update. The lack of schema causes several problems:
a) In order to identify a particular field in a group at the same nesting level, CBOR uses maps. Maps require an additional type per field. This eliminates any savings in size that are granted by the compactness of CBOR’s basic type encoding.
b) If a particular map is parsed and then re-encoded, it may not re-encode the same way as it was originally encoded. This causes problems from a signature verification perspective, and it is the reason that ASN.1 DER was derived from ASN.1 BER.
c) Even without a formal schema, an informal schema must be created. Whether this is existence checks or non-existence checks, it leaves the schema up to each implementor, which can be error-prone. A formal schema is a much more robust error checking mechanism, particularly if it is possible to generate the parser directly from the schema.
d) Devices may support this format for more than 20 years, so a rapidly changing environment is not helpful. A schema that can be tested against helps when future implementations need to be tested for backwards compatibility.

Therefore, if COSE were to be used, I believe that we should use a schema with the CBOR manifest. Perhaps, if that were the case, there might be a DML that is both descriptive enough to layout a CBOR manifest, and has enough tooling to generate a specialised C CBOR parser explicitly for the manifest.

3. Maturity
CMS has been in use since at least 1998 (as PKCS7 before that) and has broad support and validation. This has provided time for problems such as those detailed in RFC6211 to be identified and corrected. COSE was proposed in 2015 and standardised in July 2017. CMS is a far more mature standard than COSE. This is not to say that COSE doesn’t have advantages over CMS. Simply that CMS has an enormous number of deployed instances and an enormous quantity of testing behind it.

Ultimately, I think that CBOR/COSE will become very useful for this sort of use-case. At the moment, however, I think that ASN.1 DER/CMS is the pragmatic choice, due to availability on MCUs, availability of a DML/schema language with relevant tooling, and the maturity of the format.

============

HSMs:

On the role of HSMs in firmware update: Please consider the use of smart cards, hardware tokens, and other smart-card equivalents. This class of device is both effectively an HSM and intended as a message processor.

One of the threats to firmware update I have considered is the exposure of a developer private key, either via exfiltration of the key itself, or through remote access to the developer machine. Should this happen, the full fleet of devices for which the developer has access rights could be compromised. Given that smart cards and hardware tokens are available, low cost, and mitigate this threat by hosting private keys, it would seem prudent to use them for large scale production environments.

This is not to say that the use of HSMs should be mandated, but that any solution should make it easy to use them.

Thanks,

Brendan
On 27 Sep 2017, at 01:01, Smith, Ned <[email-masked]<mailto:[email-masked]>> wrote:

See additional comments inline below.
-Ned

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

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:
[stuff deleted]
•         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.

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

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.

            [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

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

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: Jim Schaad <[email-masked]>
Date: Wed, 4 Oct 2017 13:29:53 -0700

I have been asked to respond to this – so some comments inline

From: Russ Housley [mailto:[email-masked]] 
Sent: Wednesday, October 4, 2017 6:53 AM
To: Jim Schaad <[email-masked]>
Subject: Fwd: [Fud] A few questions / observations

If you are not on the FUD mail list, please join at least for this part of the discussion.

Russ

Begin forwarded message:

From: Brendan Moran <[email-masked] <mailto:[email-masked]> >

Date: October 4, 2017 at 9:39:57 AM EDT

To: "Smith, Ned" <[email-masked] <mailto:[email-masked]> >

Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >

Hi Ned,

============

COSE

[JLS] I think that at present it is true that the code for DER decoding is present in all of these code bases.  It may or may not be true that the code makes it from the code base to the deployment.  Many of the people that I have talked to are looking at using either raw public keys or pre-shared keys as the authentication mode for doing TLS.  This means that the need for any ASN.1 decoding goes away from TLS and the DER encoder would not be needed on the end product.  I think this might be a YMMV statement.

2. Schemas

[JLS}  First let me address the statement that CBOR has that it does not need a schema for decoding.  This may not be the best of language in the spec, but it does not refer the question of what many people think of as the purpose of a schema.  The issues with not requiring a schema are the following:

1.	Implicit tags in ASN.1 require that a schema be known by the decoder in order to do the correct decoding.  CBOR only has explicit tags and thus the schema is not required
2.	Default values in ASN.1 require that the schema be known if the decoder is going to fill in a location in a structure with the correct value.  The default value is omitted from the encoded format and thus needs to be supplied by the decoder.  CBOR does not support default values.  Any defaulting in maps is required to be done at the application level.
3.	Some of the ASN.1 encoding formats, PER comes to mind, require knowledge of the schema in order to correctly get the encoding and decoding correct as the encoded format needs to have information about such things as the range of values in order to decode things.  CBOR does not have this type of encoding so a schema is not required.

This said, there is a schema language (CDDL) that is being developed for CBOR.  The question therefore when you think of a schema is are you looking at just describing where things are, in which case CBOR and ASN.1 are going to have the same properties, or are you using it to try and omit or shrink the final output, in which case CBOR is not going to support it.

[JLS]  CBOR has both maps and arrays.  Maps correspond to SETs while arrays correspond to SEQUENCEs.  Both can be used and thus there is no requirement that everything be a map.  This means that the size savings is still preserved.

[JLS] This is a problem at the moment.  There is a preliminary version of conical encoding for CBOR that exists, and which I personally do not like, so it is always possible that one can allow for re-encoding.  However, to be honest the very idea of decoding and re-encoding is probably not something that should be relied on to any extent.  With certificates there have been far too many examples of people who either did not use DER or got the DER encoding wrong so that doing a decode and then later re-encoding caused all sorts of problems.  I have found it far more convenient to do what both CMS and COSE do for these cases which is to wrap things in a binary blob and do multiple passes of decoding to make sure that if it was not encoding correctly it will still validate.

[JLS} The ability to create code and structures from a schema is one of the things that I have found to be extremely useful with ASN.1.  I regret that this is not currently considered to be a priority with CDDL at the moment although this may change in the future.  With some restrictions, it would be possible to come up with a CBOR encoding method for ASN.1 but as this does not currently seem where that world is going I have not even done more than a preliminary look at what things would look like.  When I did do it I found that the data models are not quite aligned so it does cause some problems.  However, it should be possible to have both an ASN.1 and a CDDL schema which are going to look close enough to each other to be used.  I do agree that a machine readable schema format is a huge win despite what some other say.  

3. Maturity

[JLS] I am sure you have already noticed that the author of COSE and the author of RFC 6211 are the same individual.  COSE has benefited from many of the developments and problems that have been identified over time in CMS and is going to be around the same level of maturity from that standpoint.  I would be foolish to claim that I have gotten all of the problems of COSE worked out, but I do not believe that it is going to be any less problematic over time.  That said,, I do completely agree that there is a much greater amount of deployment and use of CMS and that is a big advantage

============

HSMs:

 

Thanks,

Brendan

On 27 Sep 2017, at 01:01, Smith, Ned <[email-masked] <mailto:[email-masked]> > wrote:

-Ned

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

Hi Ned,

Best Regards,

Brendan

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

[stuff deleted]

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

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

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.

Thx,

Ned

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

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

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 9 Oct 2017 10:40:22 +0200

Hi Jim,

let me respond to this issue:

On 10/04/2017 10:29 PM, Jim Schaad wrote:
> Many of the people that I have talked to are looking at using either raw
> public keys or pre-shared keys as the authentication mode for doing
> TLS.  This means that the need for any ASN.1 decoding goes away from TLS
> and the DER encoder would not be needed on the end product.  I think
> this might be a YMMV statement.

I guess it depends who you talk to.

As you know, I am co-author of the TLS PSK and the TLS raw public key
mechanism and as such I had obviously expected (or was hoping for) a
widespread adoption of those mechanisms since they provide much better
performance on paper. Since we always hear these stories about
limitations of these IoT devices we obviously buy into these stories.

However, our experience at ARM was a bit different. Those companies who
cared about IoT security tend to be rather conservative and once they
decide to go for the full-blown IoT solution (which includes a device
management solution with firmware updates) they want to go for a
certificate based approach. Of course, there is more overhead but often
there are other factors that play a role in the decision making. For
example, many of these companies are interested in reusing their
existing infrastructure and processes. This might also explain why there
is suddenly interest in standardizing the EST over CoAP-based
certificate management protocol in ACE.

Hence, I believe there is a disconnect between the " optimize like hell"
and the "I need to deploy something I am familiar with" approaches.

Ciao
Hannes

---

From: Jim Schaad <[email-masked]>
Date: Mon, 9 Oct 2017 14:58:03 -0700

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Monday, October 9, 2017 1:40 AM
> To: Jim Schaad <[email-masked]>; [email-masked]
> > Many of the people that I have talked to are looking at using either
> > raw public keys or pre-shared keys as the authentication mode for
> > doing TLS.  This means that the need for any ASN.1 decoding goes away
> > from TLS and the DER encoder would not be needed on the end product.
> > I think this might be a YMMV statement.
> 

I completely agree on that.  It might be a bit higher after the OAuth stuff gets deployed, I don't know

Jim

> performance on paper. Since we always hear these stories about limitations
> of these IoT devices we obviously buy into these stories.
> 
> cared about IoT security tend to be rather conservative and once they decide
> to go for the full-blown IoT solution (which includes a device management
> solution with firmware updates) they want to go for a certificate based
> approach. Of course, there is more overhead but often there are other
> factors that play a role in the decision making. For example, many of these
> companies are interested in reusing their existing infrastructure and
> processes. This might also explain why there is suddenly interest in
> standardizing the EST over CoAP-based certificate management protocol in
> ACE.
>