Re: [Suit] Parameters and Commands

Koen Zandberg <koen.zandberg@inria.fr> Fri, 28 February 2020 14:46 UTC

Return-Path: <koen.zandberg@inria.fr>
X-Original-To: suit@ietfa.amsl.com
Delivered-To: suit@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 206023A18FE for <suit@ietfa.amsl.com>; Fri, 28 Feb 2020 06:46:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 pHQ0__EyM7CZ for <suit@ietfa.amsl.com>; Fri, 28 Feb 2020 06:46:41 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F4CC3A0B0F for <suit@ietf.org>; Fri, 28 Feb 2020 06:46:40 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.70,496,1574118000"; d="asc'?scan'208,217";a="340735750"
Received: from 82-197-204-96.dsl.cambrium.nl (HELO [10.1.5.26]) ([82.197.204.96]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 28 Feb 2020 15:46:37 +0100
To: suit@ietf.org
References: <27913A6B-F42C-4AA9-8A7A-64B1D546C13C@arm.com>
From: Koen Zandberg <koen.zandberg@inria.fr>
Autocrypt: addr=koen.zandberg@inria.fr; keydata= mQINBFfiUE0BEAC2GQfspM4LKuFBsuBVG5f8iKIg3SQIeyK5tG+fHrLYIt+qXIrya1rxX4MQ iGtJmG0F+iVOAZZXLvT3nd1L7jIvT83fUULRKsxGeq8swHhHRdtyiSNDCdpY3Z0PmF6nyoEV kevB5FHQPLWZIMdvX324ihJ1qN34yIBBy+Q2rk2FP8Dn0PDHcCwiY9PCzurpNDcEjQ2EdsO2 pFAUy8m04A0H9pH3Up/o6xhsQsbt4Q9U1YuGJiUpMXXBq+6hufafRtRjPIypr4LCYAVaKsds R5GxLcFrNXiMxDf3tVTrF2PebXhepamDbG7ujpiYZ5x8fKEFvrUJSM2Qz+agf0JqsueXowy7 nwNrcn9ygShydizAZ34OSphGCxnmJ6j6aTp/bo77GXJnvT3hACYHX7vmTg6ODII9pLQCYda4 ML2rL6u06oLnvyoC2Q7RQKgfMSDgA3Vx+yeWI4IoxmtNXjnFvrfGCIY347rhjBrQL4Za1xuL uw0YggCCIH1Qp6z+MNXcIuHEeS5HJJsUQlN6OfBwCWI2hfToilo+/7xv4sIc6+aknLhmE3H2 FuDYFh3Z7TUoLL3K/Jcx3ndmsajh3UNsnYPxiOLkFIKJgDfQg+Xi7eqVSaBslSPNjsw78lNc qkCSOZXuDfd7h4cuvn6m+VdFz2yRLoOhZPxc2jBd9QxSsXBIqwARAQABtC5Lb2VuIFphbmRi ZXJnIChJbnJpYSkgPGtvZW4uemFuZGJlcmdAaW5yaWEuZnI+iQJUBBMBCAA+AhsDBQsJCAcC BhUICQoLAgQWAgMBAh4BAheAFiEEgyTxs8+Xzr7AO00MaVaPK/gRSicFAl47HK4FCQg5/+AA CgkQaVaPK/gRSidZlQ//c5+ODGQ5+6fv0raabnIbIEchk3KHZobBRgPAlZ56XD8nZuUupdDz 7yo+S7V4SUwuXxJfL6UOmLcEfluWr7DQCxWMXWAjFPkH7OsGtm3WjTvINDfCMdrvER14uVQ+ 6FdGBIVzASkamteZxhgfJqQQkjIOS1IXJ4bq08Fn4nmPUELClk7aPHVMDEWPccECgMHtafSB 4a8aB8ECVBUedLpWlmYqzVN8Ev9sKZxo7o7lJbI72xw0+SuubhCegMt+2E2TDg6r3qTOL2gx G24xKGgty9N0R80I3Ek2S8A1JoOO2qc7ZNVEdm6s8CVDCt4fDsm+Sp77LY1Y/wEtpkA+YyxP RHphNbEMgTWeVeBQoDifI6gVH204MEGbfOrWFSBZUKTrOKNcGpi2DzTIbeHPj+4tCq7/NbqW GaTDqJ23hwEJbPagjFl9R0FkApX2AXhcDI84Wm9qQq/q9sD6sTByco6wHn/CKgCPRZsTWuu6 zwVHz/pgUVthKNZ8hNV8tDadC1NeTeMmk5zLiQxbpEzT245yYqhXZgpcPfs0DwJsFmRpDUFj 8tSZ9y0zfOw/a2tn0vnGZ/MkaJG813WkB07py8ka5ZW6Hx91mqPj5HL6JQXOayutSeFIsswI ZOFnT2/dCM3peZcHxuF+U2I1Xk68I9KNAsZ9jqYAcY6SEw9UGSuf5hO5Ag0EV+JQTQEQAK0M NhuCK0k78+WcrGp7iZbMeXkUkcEzsmXu1mctHoqpxONsibgNeBFL+xCuhiPkpEeBARvaj3py chH8Ckp+hv1XFYONEsSPEhPAl1Qn+d3zXwqfjjOV2J5siIJhmZdtzi7ovJn4r03Z7KEOXF3q xNYHreXjjzwUV57ukHBZAYZ2ExGTOtt3wd0fLEJ8JChCD6+FSVpbZrxgjfYC/QeGNGLbNa0B sbZe5e9x/u1A1WyfN3/yqM3BJtdg6EWkkXTbMLJZhCkR5Nt2tbFw8MBrFR4qt7ShAy9r5QD2 1bga1m7zu+jjti3HJ8Yc3LyaU87cGlbbZmQPLwPgea6AxtBCnkTqfJZVFApbXHmCsDK+26E9 258rlVsYRx326ZpLJ5erRZqnPZT/9GF1OWS6vcYk5eVIsC3MGN6KvFVxIxwFnW7zXKS96q3G e9CRg/pNO/ibSrQVqrpJyA0NEyB5Z/dngLKKKlfgLLW5ga+cZ0puQKE2jCCKdiq9ZGdyEXb3 ME2JDxHo0b6RzrHsYVdeAXaifOqDMlPUn7faeSTJgjkTuZhKQ27P6QIx4xQs/KOTeNE8/uZ3 nXieCdpPdnrzSk55HipVvaWdHpcO/eWeakb6B7MnKjQM2Bg7adi73G8hUMutg0CN/IFsn/Pk ws9jE/n84O5ieBOmvaQbs2MeWG0+E3TPABEBAAGJAjwEGAEIACYCGwwWIQSDJPGzz5fOvsA7 TQxpVo8r+BFKJwUCXjsc0QUJCDoABAAKCRBpVo8r+BFKJz/dEACP8cJNCVY3kTw/oOtTqzJz 5bAIHQHdeB+XfEHWrPT+sQCrg/Kn1fnmtewhwGQOf8n4icRef3dJ2xGQu1XMJlkNNTWIWnKO yma87zF0jv3SSroykx/dvrPHIC9oVTC4EvB4E5N07Zg4u1y5de8YHrWfFtCtBaSsKLxnhKgS PSkdvXBNaQhqXDXxt7/ZszTo7AQOcnX8kNW2cACOta/Z/xrwSV9prbi7Jbpso+WLxir/XV5V Z12EQ9ou/FVWfOAH7axWUBGFUbsBiRGC2yjvj6EMSR2GmZW91Ocbz86hN8/b95y878bafb3H Q1KDYA4gcljmtMNLcVl51QYhEuputJDTffJ1zuWh4oAmwt13tR2dZT259MKnYctbNzyt0do2 aXZYZS+cBFwnDglNvZH9C+jHkwUSqH6/L2Hbn9n3hEG3utlmktNVsDL2GoEVYigjjxOvCGH+ RGykhGzfBex//Awc6UGeFkxq0ZtAdzZADDfp8khL6jM5UQxFboTrH255i6qs3D6N42HzQKBv d7EI9agpUVZiFS3vHLlTpbopeko8ckurN7LXbO6sr6LDOEoMrzzNzKXiKToZ2/Kd/WCe0RUv khk1FTVl02BzH+T235K8u063EvqAViJX5+OvG/SZeeDObCQrfl2H+9LJOvcVITt9Q+8vpYnW 2jl2SixgvMFjDbkCDQRX4no0ARAA8ZZNM8ku1dJqLAr7rll1xMsHWXPfMVJyTnz+hbIRTajT cZe57keVBXWkayL6gsQ7XztBG0jftDx2sHdlybZisjrskV2VuEs8m9cBshu7L5YMqZrhuGpi qPPTJ/+9aXtC4i6qNHVNGSunFpYmKGdPgvWB2Ueg9LJwG9+m6XSGrA+s8ilFvCE6aClxEdP6 9B+OAO/9BX2t0XpCNsKmAJY/ZqeeWTzFCSzwDxEggkroGmcKQ80KrhuzifEdNwWmlObcirZO RcnMIj9caouzQUhyY0lEjAz2WhX+e45XCg73a4X13n7JxIukJ+KRVLN06eVDUGFIltF/2cEZ dr4tnANCFqsA4ZawAUDBYLvVT+X5atq4Y0oATKV/CS995dEzTlQwEh4A0X5epUw1261YgokZ AjYUfIkJ9VruSB5UKwMloLUCNCBIZTMKYLDDbfJHxQiqvHTXf267IbTRh3gaa4D0QY9wtOgv eRlycRYwf6ljj4KVCPPCEKVyyeejYJVt432aRYKIWIRh6e98WuoDgriVQuL5y1VugUSFX0Qb dh51Bo4W9HKThKo00J/m+sCml0KdQomiJJM7v7VcM6mjgpbwHZzleofISEf7nvjpBAGu0guG G0CdbbSW0/URfwdvmZKkIYna7+JZkC8fdnc2zR+1+Wvki7vL0Q5Q2zrTyFSmq/cAEQEAAYkE WwQYAQgAJgIbAhYhBIMk8bPPl86+wDtNDGlWjyv4EUonBQJdoHe9BQkHnzEJAinBXSAEGQEI AAYFAlfiejQACgkQDmNBH4/KgkcywBAA2oNFVLoX9T4bHYO7Vrq7zEnx944uiS9CO5mZ8T99 i2zfQeFDAOwvIHAZdJegH3zJkuahCyDFvX2zhaXiBMiSzvONpOI/lv9Vc7E6+fFPKYJaRklT Tlh7tOljAPE/WEVOoqMU00tn7l93VSOokhfeQb+CoFobqsdB/wBj41Ag0Ln8Jb/UDYj+6sld uoQWKkxKePUdmILWTV/qhbE8yYZPVKVlB+WxwqXzfgZZVNVArK23OWMJwybDlgnZIDIexGPD wQ0mcCkaiw59cih/AlE2UrQsW0oM+pQht/8tlyJPxpD2MQ9m1eYUpvK5AxmYFu7VkHak1nlC 9PJo0kEcZLbOmNv+H8BsH0nfT8ORME0K7ljKUFYEn7OTF9jdqX43DgPGXDrOZykvr6qlFSMC QF80QCkPH0XQI8c3jteWKyrqP5stkr1EmVc2r9Jdv/l06lHOJr6/WPumq9hQyxHpX1lhrAsl sUz2QkEspiJc5+i7Mte7bUWdYJkIVd/9HTplVoZyJUHPCQGORSySMvyRihPbo7HcHsv8o7if ghRaX9Sf88tiU7TIvG1AaEZ6AWj45EnqCdesS9eDGtgcFNBC3gAdF9o0uppXNKAsCfUxYr28 O7c3+9WSa5WiN8cFAURGMlhhdBaz0SNEW7RG9WjSqSuvMQ5mqP1HQtAEE05TRnaj7UAJEGlW jyv4EUonmDkP/2nwxCnfklFn7kaNVsQZELkly+HnmBNbov2GW4rLmrdjKTnQcJ7mJTeS3yiD KjVflgntDJFBH6zbUNREbmCPCuF+xcHUGPkrS1686nHf+GmzrJw3xbJD2u0KuHe3cxxFFc+v wtZfSA3LCqZceuGNRAd3gEUcl/STxo9LfnpF3kESGkHoRpmZ19KptZGXlu9aXcAwH9JVYqwM F4o6o39aGs0UfLJqOr/MxpoYldO6IV9WFZLQruMfQRw9wyonkcxxkSoLBVJ8w+CMUvGjirio ONuiIRFSlr84FereqO3+LHmLr+ey5q3oQbkXb2cWdM6UsatcYFHC9WZ1XgULft7diBhnpl0B F7lOKWuibVN8JCbCBjDGo64Zsco9zlJAyYWwZo0WIs18kFH79Ekt8g9+tcrBVRaUhYbegBy2 LijwErmuz1yLQBrMOKEGedkiIgXrQerYSVkD2Gvg4AxUssAMT+BxP5aazDdBlChcpPA5XgXT IHvlRTfWLXtZzizPL3dB7mq+2/SOWTB4A4xoRzaJ9+NJqJ0STBQ4L8YM99GLQUMoN1xyhPTb xlmxUPPMTqpXcEHPkG5aHsRgDqL3xV4puZ/03Q74/x/IUE+kz4ZhHxH9D4eo9kHtEzbfMn8i W/O5Y7GnTFKtBs1qX/1ikJKtAQutx+PT6dpcFhdSyOfsrbOW
Message-ID: <cd1d3e93-b094-e274-c07c-c400b9475b16@inria.fr>
Date: Fri, 28 Feb 2020 15:46:27 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.5.0
MIME-Version: 1.0
In-Reply-To: <27913A6B-F42C-4AA9-8A7A-64B1D546C13C@arm.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="3CwqVVIz2SwSLwWUOhjwnNogRg2t5nTjH"
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/NDORoaUXSPh6FzE_-98eT4EVtzs>
Subject: Re: [Suit] Parameters and Commands
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Feb 2020 14:50:22 -0000

Hi Brendan,

I also support the idea ofaligningall conditionals to use parameters.
From an implementation point of view I see a small downside in that the
parameter location has to be stored to be retrieved later during the
parsing of the conditional (this matches with your argument no. 2). For
the low number of parameters used this increase is probably negligible
and I don't expect any serious concerns here. 

Concerning encoding the attestation policy within the unused arguments,
I have slightly more doubts. I assume that this would replace all nil
arguments in the commands with the attestation policy (a single cbor
uint?). If this is the case I don't have any strong concerns, but it
looks a bit like swapping one inconsistency for another, mixing
arguments and policy specifications.

I will implement the changes you've proposed here in our current ietf-v3
implementation (https://github.com/RIOT-OS/RIOT/pull/13486
<https://github.com/RIOT-OS/RIOT/pull/13486)>)
<https://github.com/RIOT-OS/RIOT/pull/13486)>to get some hard numbers on
the impact of this change, and get back to you on the list.

Cheers

On 27/02/2020 14.44, Brendan Moran wrote:
> During the hackathon, I discovered that my examples and my manifest
> generator tool are generating incorrect sequences for testing vendor
> ID and class ID.
>
> There are currently two ways to handle commands (conditions or
> directives):
>
>  1. The command consumes an argument (that is the value that follows
>     the command's key)
>  2. The command consumes a parameter (that is a value set by the
>     “set-parameters” or “override-parameters” commands)
>
>
> This duality led to my error in setting up the Vendor and Class ID
> tests in the demo code.
>
> The reasons for each mode are:
>
>  1. Command consumes an argument
>      1. Encoding is more compact (encoding via parameters takes 2-3
>         more bytes, depending on the situation).
>      2. Less storage needed (the argument is consumed immediately)
>      3. Does not require matching parameter key
>      4. More explicit association between command and argument
>  2. Command consumes a parameter
>      1. More compact when the parameter is used more than once (e.g.
>         image digest)
>      2. Allows override by dependencies, when set-parameters is used
>
>
>
> We’ve talked before about “only one way to do things” and I think I
> can see a path to making that the case here. Here is my proposal:
>
> Commands consuming a parameter are absolutely necessary due to
> override and deduplication concerns. Conditions testing against an
> argument are convenient and more explicit. Therefore, harmonising
> around a single option probably means that we have to select
> parameters instead of arguments:
>
>  1. Eliminate arguments from most commands (see below)
>  2. Match most parameter keys with command keys to simplify the
>     association, make “arguments” more explicit
>
>
> Only these commands require arguments, since they either deal with
> setting parameters, setting parameter scope, or with flow control,
> which requires nested command sequences.
>
>   * Set Component Index
>   * Set Dependency Index
>   * Set Parameters
>   * Override Parameters
>   * Try-each
>   * Run Sequence
>   * For Each Component
>
>
> This leaves the majority of commands with NUL arguments. This is
> actually quite useful for another feature.
>
> We have also discussed the possibility of defining attestation policy
> within SUIT. This would mean that we need flags to indicate to the
> parser which measurements should be reported. For example, a Vendor
> ID, an image digest, or a component offset might need to be reported
> in the attestation report. Each of these is checked by a condition.
> Each of those conditions will consume a parameter under this model.
> Then, the argument can indicate: report a measurement, do not report a
> measurement, report a measurement only if comparison is successful, or
> perhaps other attestation-related policies. Bear in mind that
> attesting a failed condition may be helpful for attesting why a
> manifest has failed, as we discussed in the hackathon and virtual
> interim meeting.
>
> If we are making the majority of commands are using parameters instead
> of arguments, this becomes trivial: the arguments are replaced with
> attestation policy arguments. This allows us to tell the attestation
> engine explicitly what to report from the manifest, which allows
> secure, dynamically updatable attestation policy.
>
> This doesn’t introduce a substantial change to either the parser or
> the format. If there is some appetite for simplifying the correlation
> between commands and parameters, I think it might make sense to spend
> some effort aligning parameter keys with command keys. This could
> simplify the parser by allowing a generic parameter lookup to be done
> in one place, rather than by each handler.
>
> Best Regards,
> Brendan
> 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.
>
> _______________________________________________
> Suit mailing list
> Suit@ietf.org
> https://www.ietf.org/mailman/listinfo/suit