Return-Path: 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 B634C13114E for ; Thu, 14 Jun 2018 06:12:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.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, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, 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 bcS_P-LdYvmp for ; Thu, 14 Jun 2018 06:11:56 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0084.outbound.protection.outlook.com [104.47.2.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF55113115D for ; Thu, 14 Jun 2018 06:11:55 -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:X-MS-Exchange-SenderADCheck; bh=fjsN+6UXeiwzjQcwxtMYtWSQclWkL1jVoF5MqNVlARY=; b=sQXJNaXiueTPmcltA9ntlkBjyErEbvl20jXqD3N9xcYFbJkHNM1ZCHO1ecOu819QT9zikysppnWprVB2rAqNluzbhXjwyU7h92oInwN88l4bKxrf2nwi4jVN6vRRtjMsr4gk82QP4YiV9SPXJPZ8u3lN5A72dIpXYzCdXsBsQRA= Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com (10.173.75.16) by VI1PR0801MB1358.eurprd08.prod.outlook.com (10.167.198.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.16; Thu, 14 Jun 2018 13:11:53 +0000 Received: from VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35]) by VI1PR0801MB2112.eurprd08.prod.outlook.com ([fe80::d1df:1498:96ec:6b35%4]) with mapi id 15.20.0841.019; Thu, 14 Jun 2018 13:11:53 +0000 From: Hannes Tschofenig To: "suit@ietf.org" Thread-Topic: SUIT Conference Call Minutes - 14th June 2018 Thread-Index: AdQD4RWFB1sO4QG2QU+xcJ0lVo3uJw== Date: Thu, 14 Jun 2018 13:11:53 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [156.67.195.102] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0801MB1358; 7:vaCLdhuJo8Wyq7Kt30ifC45ZxmiZD2KWog6amZe3LrXWhwI1t8/pJrauy9iB8VUiE2cGKdBYvuUiznHljrwdCKL7BqNBK7oBYLu+2xl0KCeSXWtqt/r0RpZp4wg+2fd9fuCdT9Gex6EecYBA8rVfgPqnqBoy56m+UFqRElJrll+AxuDx+bWt3MN0yB1gEy9kZu3zPYRddHyF4Q3LglTggkZApspni3yVzNmo/AhGBE8aIU6laSCqqMxiQOL4DACU x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 1d7a0b6f-3234-440d-3fd5-08d5d1f865fe x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR0801MB1358; x-ms-traffictypediagnostic: VI1PR0801MB1358: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(192374486261705)(131327999870524)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(10201501046)(93006095)(93001095)(3002001)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(6072148)(201708071742011)(7699016); SRVR:VI1PR0801MB1358; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0801MB1358; x-forefront-prvs: 0703B549E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(39380400002)(376002)(346002)(40434004)(57704003)(189003)(199004)(105586002)(106356001)(3660700001)(5660300001)(2900100001)(6116002)(3846002)(66066001)(790700001)(3280700002)(6916009)(8936002)(1730700003)(2906002)(81156014)(8676002)(81166006)(86362001)(5890100001)(102836004)(26005)(59450400001)(2501003)(7696005)(6506007)(5630700001)(186003)(5250100002)(25786009)(74316002)(99286004)(316002)(6436002)(966005)(9686003)(72206003)(5640700003)(33656002)(53936002)(6306002)(7736002)(54896002)(478600001)(97736004)(14454004)(2351001)(55016002)(486006)(68736007)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR0801MB1358; H:VI1PR0801MB2112.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: 9OrAwBi13QG/X8RtuZQs4OpGLkf2jXXYOkdhTXQUW+u78Wfe1Q4OYhKufnGWXAqEdUQqL9i2Djqs2XN6D82aRk3aTDjnnezj2HCQgCbMcQnTDK0Z/q8STK86yypv2JjTDYNes9IQTPzl6M/8A2DTS2r60HCjbnHITe+RNd0v4bruM6AaPqoBMLJwZK2U8Hec spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0801MB2112781D5D6C6072B0A82D58FA7D0VI1PR0801MB2112_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1d7a0b6f-3234-440d-3fd5-08d5d1f865fe X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2018 13:11:53.4928 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1358 Archived-At: Subject: [Suit] SUIT Conference Call Minutes - 14th June 2018 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 13:12:02 -0000 --_000_VI1PR0801MB2112781D5D6C6072B0A82D58FA7D0VI1PR0801MB2112_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Participants: - Frank Audun Kvamtr=F8 (Nordic Semiconductor) - =D8yvind R=F8nningstad (Nordic Semiconductor) - Carsten Bormann (Uni Bremen TZI) - Markus Gueller (Infineon) - Brendan Moran (Arm) - Hannes Tschofenig (Arm) - Henk Birkholz (Fraunhofer) Changes to the informational model have been discussed at the Hackathon and= at the virtual interim meeting. Brendan went through the document. A question about protocol extensibility was raised by Carsten. This is some= thing we need to look into. Brendan states that a new security requirement (MFSR8) has been added about= access control list. Carsten: Are there any hooks that the manifest needs to provide? For exampl= e, do we need to provide names for the fields so that they can be reference= d in the ACLs. The approach of explicit names for elements was discussed an= d also the approach of considering the path into the parse tree of the mani= fest. The latter was seen as a bit brittle. Q: Which elements do you consider to be overrideable? URIs, conditions, and= directives Brendan: The ACL should say whether it is allowed to add or delete from tha= t list. Q about the signed payload descriptor (MFSR4): The idea with the list of el= ements documented in the draft is that they need to be signed. The conclusi= on is that they need to be placed into the manifest. The requirements need = to be formatted so that the correlation between the implementation and the = threat. Suggestion to change the name of MFSR4 to Authenticated Resource Descriptor MFSR5: Cryptographic Authenticity --> Needs to come before MFSR4. MFSR7 (firmware encryption): The manifest information model must support en= cryption of firmware images. Carsten: Is this only for the firmware image or also for other fields? The= expectation is that channel security is sufficient to protect the manifest= content itself against information disclosure. Brendan will document it. The difficulty with encrypted payloads is key distribution. Therefore the m= anifest must convey the information required to allow an intended recipient= to decrypt an encrypted payload. The idea is that every device can receive= an encrypted key that only that device can decrypt. Class keys are obvious= ly possible too. Brendan talked about the key table structure. Not entire s= ure whether the information model is the right document to put this informa= tion in there. Does the group think that the information model document should contain the= key table concept for uniquely distributing content encryption keys to the= device? The group discussed where the best place would be to place the inf= ormation. No conclusion was made. Possible places are: information model, s= erialization document, or separate document. Carsten: What do we sign and in what order (encrypted or unencrypted payloa= d)? Brendan says that it might be best to have the signature cover the installe= d image. The payload description should specify what appears on the payload= after all the processing has happened. The raw payload digest refers to th= e state before any decryption has happened. Frank mentioned that they shared an email about the post condition idea. He= re is the email: https://www.ietf.org/mail-archive/web/suit/current/msg00467.html The pre-conditions need to hold before the update is started and the post-c= onditions need to hold when the update is applied. Discussions didn't not consider the sign after encryption vs. encryption af= ter sign case but rather about what is being signed. Hannes points out that there are security implications of the order. Brendan mentions that there are denial of service. Brendan can see the benefits of the proposed format for post- and pre-condi= tions. How well does this format deals with nested containers isn't clear t= o him though? Does this support "Use Case MFUS7: Prevent Devices from Unpac= king Unknown Formats"? Brendan thinks there should be a list of processing steps the device has to= take. Brendan argues for the ability to determine as quickly as possible w= hat the processing steps are. ... quite a long discussion about the different alternatives ... A tentative conclusion, which needs to be described to the group on the mai= ling list is: We will use out-of-band containers (to put a nil in the cose = structure; when it is nil the meaning is that the protected content is some= where else). The manifest would follow immediately afterwards. If you follo= w this approach for them manifest then the rest is an application specific = decision. The processing steps list will be something that can be transmit= ted separately. The goal is to make the manifest parsing friendly to nested= and non-nested structures. Since we ran out of time we were thinking about having another conference c= all next week. IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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. --_000_VI1PR0801MB2112781D5D6C6072B0A82D58FA7D0VI1PR0801MB2112_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Participants:

- Frank Audun Kvamtr=F8 (Nordic Semiconductor)<= /o:p>

- =D8yvind R=F8nningstad (Nordic Semiconductor)=

- Carsten Bormann (Uni Bremen TZI)

- Markus Gueller (Infineon)

- Brendan Moran (Arm)

- Hannes Tschofenig (Arm)

- Henk Birkholz (Fraunhofer)

 

Changes to the informational model have been discuss= ed at the Hackathon and at the virtual interim meeting.

 

Brendan went through the document.

 

A question about protocol extensibility was raised b= y Carsten. This is something we need to look into.

 

Brendan states that a new security requirement (MFSR= 8) has been added about access control list.

 

Carsten: Are there any hooks that the manifest needs= to provide? For example, do we need to provide names for the fields so tha= t they can be referenced in the ACLs. The approach of explicit names for el= ements was discussed and also the approach of considering the path into the parse tree of the manifest. The = latter was seen as a bit brittle.

 

Q: Which elements do you consider to be overrideable= ? URIs, conditions, and directives

 

Brendan: The ACL should say whether it is allowed to= add or delete from that list.

 

Q about the signed payload descriptor (MFSR4): The i= dea with the list of elements documented in the draft is that they need to = be signed. The conclusion is that they need to be placed into the manifest.= The requirements need to be formatted so that the correlation between the implementation and the threat.

 

Suggestion to change the name of MFSR4 to Authentica= ted Resource Descriptor

 

MFSR5: Cryptographic Authenticity --> Needs to co= me before MFSR4.

 

MFSR7 (firmware encryption): The manifest informatio= n model must support encryption of firmware images.

 

Carsten: Is this only for the firmware image or also= for other fields?  The expectation is that channel security is suffic= ient to protect the manifest content itself against information disclosure.= Brendan will document it.

 

The difficulty with encrypted payloads is key distri= bution. Therefore the manifest must convey the information required to allo= w an intended recipient to decrypt an encrypted payload. The idea is that e= very device can receive an encrypted key that only that device can decrypt. Class keys are obviously possible t= oo. Brendan talked about the key table structure. Not entire sure whether t= he information model is the right document to put this information in there= .

 

Does the group think that the information model docu= ment should contain the key table concept for uniquely distributing content= encryption keys to the device? The group discussed where the best place wo= uld be to place the information. No conclusion was made. Possible places are: information model, serialization= document, or separate document.

 

Carsten: What do we sign and in what order (encrypte= d or unencrypted payload)?

 

Brendan says that it might be best to have the signa= ture cover the installed image. The payload description should specify what= appears on the payload after all the processing has happened. The raw payl= oad digest refers to the state before any decryption has happened.

 

Frank mentioned that they shared an email about the = post condition idea. Here is the email:

https://www.ietf.org/mail-archive/web/suit/current/m= sg00467.html

 

The pre-conditions need to hold before the update is= started and the post-conditions need to hold when the update is applied.

 

Discussions didn't not consider the sign after encry= ption vs. encryption after sign case but rather about what is being signed.

 

Hannes points out that there are security implicatio= ns of the order.

Brendan mentions that there are denial of service.

 

Brendan can see the benefits of the proposed format = for post- and pre-conditions. How well does this format deals with nested c= ontainers isn't clear to him though? Does this support "Use Case MFUS7= : Prevent Devices from Unpacking Unknown Formats"?

 

Brendan thinks there should be a list of processing = steps the device has to take. Brendan argues for the ability to determine a= s quickly as possible what the processing steps are.

 

... quite a long discussion about the different alte= rnatives ...

 

A tentative conclusion, which needs to be described = to the group on the mailing list is: We will use out-of-band containers (to= put a nil in the cose structure; when it is nil the meaning is that the pr= otected content is somewhere else). The manifest would follow immediately afterwards. If you follow this appro= ach for them manifest then the rest is an application specific decision.&nb= sp; The processing steps list will be something that can be transmitted sep= arately. The goal is to make the manifest parsing friendly to nested and non-nested structures. 

 

Since we ran out of time we were thinking about havi= ng another conference call next week.

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease 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. --_000_VI1PR0801MB2112781D5D6C6072B0A82D58FA7D0VI1PR0801MB2112_--