Re: [Fud] A few questions / observations

Brendan Moran <Brendan.Moran@arm.com> Wed, 04 October 2017 13:40 UTC

Return-Path: <Brendan.Moran@arm.com>
X-Original-To: fud@ietfa.amsl.com
Delivered-To: fud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71408134218 for <fud@ietfa.amsl.com>; Wed, 4 Oct 2017 06:40:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.909
X-Spam-Level:
X-Spam-Status: No, score=-2.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MUg3zxNgwBI1 for <fud@ietfa.amsl.com>; Wed, 4 Oct 2017 06:40:05 -0700 (PDT)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0059.outbound.protection.outlook.com [104.47.0.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CF201326DF for <Fud@ietf.org>; Wed, 4 Oct 2017 06:40:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8vumqmM7VJ3RgAkCIjkGtPIZIs4DpaOYX24WoPujg8k=; b=aiERWEJ1R6m4WLvw5cTGZlVY8GmEmclxZ7POjD8M/G/zYs8MkLteSEAfReT3/WWYeSo7K6urse6zAIhO8P2oa+RPjguA49O+pnNacVOoL+sSCNUAd3egGzEOmPKVauG3PfXnBmHuZ5eyw0pBENQZDpu6NJ5ZlZL6jPsoBnM4MUo=
Received: from DB5PR08MB0615.eurprd08.prod.outlook.com (10.169.32.149) by DB5PR08MB0616.eurprd08.prod.outlook.com (10.169.32.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Wed, 4 Oct 2017 13:39:57 +0000
Received: from DB5PR08MB0615.eurprd08.prod.outlook.com ([fe80::5c03:d255:c707:556e]) by DB5PR08MB0615.eurprd08.prod.outlook.com ([fe80::5c03:d255:c707:556e%14]) with mapi id 15.20.0077.018; Wed, 4 Oct 2017 13:39:57 +0000
From: Brendan Moran <Brendan.Moran@arm.com>
To: "Smith, Ned" <ned.smith@intel.com>
CC: "Fud@ietf.org" <Fud@ietf.org>
Thread-Topic: [Fud] A few questions / observations
Thread-Index: AQHTLjdsLe1oeSwl+Em8FCdFITDsKqLHtvcAgAA0MwCAC+TagA==
Date: Wed, 4 Oct 2017 13:39:57 +0000
Message-ID: <F0841595-E703-4AFD-A557-4A02E21AD5ED@arm.com>
References: <D531874E-95BF-4A12-8049-15794BCD1039@intel.com> <2BF4654C-4260-4C7C-8DD5-CF892628711B@arm.com> <88B5ACDC-AEB9-4611-B3D5-8A3C720E2795@intel.com>
In-Reply-To: <88B5ACDC-AEB9-4611-B3D5-8A3C720E2795@intel.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3273)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Brendan.Moran@arm.com;
x-originating-ip: [217.140.96.140]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB5PR08MB0616; 6:Xk4R5uVy4ZGA1Cf7y4VnxZi8C50BoufdhWftJpMMTWGnQ0Gcw/39AKluBVLXRRH9hj/WS40+Yba5TmsbLej1aQIPFi7JcCGwHygpR1NiSIdLj4vXre63fKiJGpPsAfolcomO1DJ6VBO7bnosjXpf8MWzA31B9NxtKipquliIzsa7FS2PzlxhyrmYm418NpQkGSBDb7rwoWO4+wnEW8lsvu+gVR/brhxH6plIbigYqzIhCdjPbapEZkf4KX4OO2Dp9SJEgsDKj3zAktYe2fCBQvenB+DzRPty51Gdcls1t7HliAuTvotUW17WEGThPG9xttOzSGjDgfejq5XOm5ho3Q==; 5:MvNxPyuae+ulkHg7GRfoZqqC2t7HECQUxlTgkS/6yxPLxxzVwjf6aYzzRz78aLGto7v2cVU8MGihDJRZiug35YjKrPmvasDFuXAadfiFJ7rWG8tOyNNi8/6XPta4VpiZwLD5Wy9vjn39L5EXwfhXbQ==; 24:wEvDh3DcYcuOtQVWd2jvWpt9BHFMT5vbWKjjShnaGEIDbNNCGO0MpgakA0APVOMezMoif3AHE31g5QrOaLAgho/+O8NdGAwRtA0a+ehYVSk=; 7:PKQIlnZUPmv9kKdrkjb/OfvMNJFuDMulBzeLNJ60D+kQvsbZxun9EY2cLEjqyaHrvcp8y3izahBMK7YTn1ICAC1aUZVun9ampsOhIu0OCo7R6OaLZVNoVWOgqloIMSlHgQLDlNasOhdUbXdajqLDqoE+bfJcZN7XYULkWspf5C+XSU24i2ayjiv209lPEkENEOWu00/5bgVsOl3SKwaJ2TWkgZGxpx+bYCgpIGdKvmQ=
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: 63a4bd6a-01a5-4e01-aa7a-08d50b2d6741
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DB5PR08MB0616;
x-ms-traffictypediagnostic: DB5PR08MB0616:
x-exchange-antispam-report-test: UriScan:(190756311086443)(180628864354917)(192374486261705)(131327999870524)(228905959029699);
x-microsoft-antispam-prvs: <DB5PR08MB0616E76CB2820650E4D0155DEA730@DB5PR08MB0616.eurprd08.prod.outlook.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB5PR08MB0616; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB5PR08MB0616;
x-forefront-prvs: 0450A714CB
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(24454002)(199003)(40434004)(51444003)(377454003)(189002)(5890100001)(99286003)(6512007)(53936002)(5250100002)(236005)(54896002)(6916009)(6306002)(33656002)(2950100002)(6246003)(2900100001)(81156014)(81166006)(66066001)(4326008)(83716003)(8676002)(57306001)(36756003)(8936002)(76176999)(101416001)(50986999)(6436002)(7736002)(105586002)(106356001)(6486002)(5660300001)(53546010)(229853002)(86362001)(72206003)(25786009)(606006)(6506006)(2906002)(316002)(97736004)(3660700001)(6116002)(478600001)(966005)(68736007)(3280700002)(14454004)(82746002)(189998001)(50226002)(102836003)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB5PR08MB0616; H:DB5PR08MB0615.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_F0841595E7034AFDA5574A02E21AD5EDarmcom_"
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2017 13:39:57.5333 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB5PR08MB0616
Archived-At: <https://mailarchive.ietf.org/arch/msg/fud/P1fBSdlCra9KSMFvM1Bl7OOOpiw>
Subject: Re: [Fud] A few questions / observations
X-BeenThere: fud@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: FUD - Firmware Updating Description <fud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/fud>, <mailto:fud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/fud/>
List-Post: <mailto:fud@ietf.org>
List-Help: <mailto:fud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/fud>, <mailto:fud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Oct 2017 13:40:09 -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 <ned.smith@intel.com<mailto:ned.smith@intel.com>> wrote:

See additional comments inline below.
-Ned

From: Brendan Moran <Brendan.Moran@arm.com<mailto:Brendan.Moran@arm.com>>
Date: Tuesday, September 26, 2017 at 1:54 PM
To: "Smith, Ned" <ned.smith@intel.com<mailto:ned.smith@intel.com>>
Cc: "Fud@ietf.org<mailto:Fud@ietf.org>" <Fud@ietf.org<mailto:Fud@ietf.org>>
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 <ned.smith@intel.com<mailto:ned.smith@intel.com>> 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
Fud@ietf.org<mailto:Fud@ietf.org>
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.