From nobody Sun Aug 2 17:14:27 2020 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 7F8F23A0E09 for ; Sun, 2 Aug 2020 17:14:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 gwXWSQusYzqr for ; Sun, 2 Aug 2020 17:14:24 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84713A0DB9 for ; Sun, 2 Aug 2020 17:14:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 393933899D; Sun, 2 Aug 2020 19:53:46 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id kyfdlcdTyRHZ; Sun, 2 Aug 2020 19:53:45 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 4AB5838991; Sun, 2 Aug 2020 19:53:45 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D4CA29A; Sun, 2 Aug 2020 20:14:21 -0400 (EDT) From: Michael Richardson To: Brendan Moran , suit In-Reply-To: <21C2CB5D-37E1-4C74-A0FD-36623F4CCD2E@arm.com> References: <70453005-8DFA-4DBE-8C04-9882839D5005@arm.com> , <13874.1596131258@localhost> <21C2CB5D-37E1-4C74-A0FD-36623F4CCD2E@arm.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Suit] Review of draft-ietf-suit-manifest-09 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 00:14:27 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brendan Moran wrote: > ClassID =3D uuid5(uuid5(OID_NAMESPACE_UUID, encode_oid([1,3,6,1,4,1,P= EN]), Class-Specific-Information) > But then we need to define encode_oid because RFC4122 doesn=E2=80=99t= specify which OID encoding to use. Yeah, I see no advantage to including the OID here. > Also, we need to support sub-assignments from a PEN, since large > organisations may have policies that require the use of specific > sub-assignments. Since this is just to produce a ClassID, it seems that there could be an integer that could be incremented to form sub-assignments. Second, I believe that for larger organizations, IANA will assign multiple PENs to e.g. "ExampleCOM Consumer Devices" vs "ExampleCOM Transportation Sy= stems" > How does this approach handle continuity if a vendor were to spin out= a > sub-entity using the PEN? Is it a situation where the next firmware > update needs to replace the PEN? I guess that is the worse case here. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8nVt0ACgkQgItw+93Q 3WVikAf/Tb81cb6zd4By48KodGDRTVSK2xBPJuE/gIyN0fIpUC/2SzRuQzQhDZtc LwXQDvefgeYWmVf+dylCf41RQFDM/Xw5vxT0kWPhYO5APdjTuRmuLeOFG1sT8KBf CVsFHG5KfKW92a2n0PRir7tmlFJ7RgQv20YQZUzlS8WeD+rxaHsa9plu4UQcfJMK bYpB5G4Juk3V7hrOVs/EfM3rk/63L53aRikgcczvD+NtChAaz/WDe16UrPHdvKSB vVS+qFkAXLq5Aizfp66xk9hBTe9L1MdnpAQmgyrERaJ/rYy7EHD7Q4cKtLU2V6QD WC2y4T3mWWx3DNjCJpdfBnM8WGk9Zw== =yHXO -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 3 03:05:05 2020 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 A48843A0D72 for ; Mon, 3 Aug 2020 03:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 header.b=2kYm3v49; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=2kYm3v49 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 mjWvGvPOt8ta for ; Mon, 3 Aug 2020 03:05:02 -0700 (PDT) Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60040.outbound.protection.outlook.com [40.107.6.40]) (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 3E4533A0D71 for ; Mon, 3 Aug 2020 03:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/4saiT+gOQoubtjMZje4Sp+iZeezssAyH8zv/jEvyKs=; b=2kYm3v49HvetAl+cy4hMFrLsVAIFcEPIcmtDBHj8V9zfozIt3dpz69caTvdrvr9GKTcc4UXKbRrdlju+8MEcs7fARSErN3W4L2hjxBzt+hbVgNF4AkavqwVMznf9gnK8TbmgZh6EzCc2mad573ryNNkcG2cMolj0XHToIMcgeRQ= Received: from AM0PR03CA0028.eurprd03.prod.outlook.com (2603:10a6:208:14::41) by AM0PR08MB4932.eurprd08.prod.outlook.com (2603:10a6:208:162::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Mon, 3 Aug 2020 10:04:59 +0000 Received: from AM5EUR03FT056.eop-EUR03.prod.protection.outlook.com (2603:10a6:208:14:cafe::69) by AM0PR03CA0028.outlook.office365.com (2603:10a6:208:14::41) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Mon, 3 Aug 2020 10:04:59 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by AM5EUR03FT056.mail.protection.outlook.com (10.152.17.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20 via Frontend Transport; Mon, 3 Aug 2020 10:04:59 +0000 Received: ("Tessian outbound 78bc8a1387f9:v63"); Mon, 03 Aug 2020 10:04:59 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 50167e98620d1939 X-CR-MTA-TID: 64aa7808 Received: from 32e2793c1274.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 5CF9E9A5-8712-42BC-AAA7-5AF0457B0A43.1; Mon, 03 Aug 2020 10:04:53 +0000 Received: from EUR04-DB3-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 32e2793c1274.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 03 Aug 2020 10:04:53 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=M2ygx0Qa0Sna/ONGrsUsDyQQm8l5Rh5hgOCI+sRu3m0PiP3WcVKEmPuuYH2LXyIkNvOD4/HKnhmjtCpqJEBDl9UjyGwwl9canMVTLPvooZzvA6Wwz4ytOj+0UJ0KOETU9OPZWrwgH3vwKv1MWBdkZh2dbv9hdaa2I1uEhiaLv/DuQHPuwgdIcSWLlTO/4PQ5U6bNCkw5f6lhzFDLPKcy7W4xXOgZTUthyQM6WNUvxiPl6RwcEzCx0ox5tF19nwUsJ5KNT9J/S3lU7LL1f/MkO7lwDUJnvCwn0kKAsCPOJK1TI0w/7LAEF6/wEMaARhxjDe7yRgHDYo+7HST2tEkgDw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/4saiT+gOQoubtjMZje4Sp+iZeezssAyH8zv/jEvyKs=; b=mg9v0/XZPhVSC1eDpTYs0pCRI/9RDgUtBaZ+orx0OTq54KiPl/Tc+Cg+nOTdKaxZcL4WuuOJbERy5B8c5qGMQc2AYbnzLMcQjj7kAKW/HP944KrC3Ye0P+alFy7gGUa2t68hjv4uvwMyMOBehQacRD1tYYADwll10FrXv9492jAhxyYdKUCO8R7Ic7QEUZLFTABRqDEvz6bh0wtalRv0kOoBXiA4WlFBnNUr2G5m1LFUZWg5u1MDRKYNGLQeq2sZ47ZC9wfoSPa+StoG2YjY8EQTFedCNsqsfoeL2UaXF6w+Z+jSHG8zLcQ9iayWMrKmd5AEyEieRsC1+C5GDAFVyQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/4saiT+gOQoubtjMZje4Sp+iZeezssAyH8zv/jEvyKs=; b=2kYm3v49HvetAl+cy4hMFrLsVAIFcEPIcmtDBHj8V9zfozIt3dpz69caTvdrvr9GKTcc4UXKbRrdlju+8MEcs7fARSErN3W4L2hjxBzt+hbVgNF4AkavqwVMznf9gnK8TbmgZh6EzCc2mad573ryNNkcG2cMolj0XHToIMcgeRQ= Received: from AM6PR08MB4738.eurprd08.prod.outlook.com (2603:10a6:20b:cf::10) by AM6PR08MB4868.eurprd08.prod.outlook.com (2603:10a6:20b:c5::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17; Mon, 3 Aug 2020 10:04:52 +0000 Received: from AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56]) by AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56%3]) with mapi id 15.20.3239.021; Mon, 3 Aug 2020 10:04:52 +0000 From: Brendan Moran To: Michael Richardson CC: suit Thread-Topic: [Suit] Review of draft-ietf-suit-manifest-09 Thread-Index: AdZiCUkrB1qNrZ3lS5i4ApAjr2sBOQCGs7sAAAKNB+AAAQI/MACZy6IAAABry6QAo/WJgAAUn3uA Date: Mon, 3 Aug 2020 10:04:52 +0000 Message-ID: <7D807988-6D37-4957-9528-32235E269C86@arm.com> References: <70453005-8DFA-4DBE-8C04-9882839D5005@arm.com> <13874.1596131258@localhost> <21C2CB5D-37E1-4C74-A0FD-36623F4CCD2E@arm.com> <22685.1596413661@localhost> In-Reply-To: <22685.1596413661@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) Authentication-Results-Original: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.20.19.206] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 70ee483d-eec8-41b0-2934-08d83794ae75 x-ms-traffictypediagnostic: AM6PR08MB4868:|AM0PR08MB4932: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: ZWPMJmpLQJatSOTKwbs3gfb5SuGFXhT7vSTwCcnORfuudwtt/DHePqS2M8hcUI7aaeQv5eAZMvRPF1tFq4uroG2cnHA9bzpoIH7MhtLsytnDBqvBt1XLpYGJuG56znM6MnZMZME85tV9VgUlMa4KAEq/tKAj8oykh8pAqRTy0RUMnVrs7cYp3aB5JqjCKbtoojm/Bs1ELaKWBBIs6LTTFXGx4C5qr4Y/k07oa/h7yUHzMj+evuzDTh0LYWsDlczD6V01VACKV+/xd4LTzhBlzKlzkzlmHTTkDaBwnDOEEJDnj334QqY1zpvb1FycJb95wcfn+ib/CyDEhX6dZ6SSiA== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4738.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(39860400002)(396003)(376002)(366004)(136003)(66446008)(66476007)(64756008)(66556008)(6512007)(66946007)(8936002)(5660300002)(4326008)(478600001)(91956017)(83380400001)(76116006)(33656002)(86362001)(71200400001)(186003)(8676002)(316002)(53546011)(6506007)(6486002)(36756003)(2906002)(2616005)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: m3oo9MAXljQv+esLIaoci3B0J1ZZ3CB/12U4OttC47jHWJx2i8K6gyUDif2h4r2vtzjWYfCvnRdsdnxFnbVTmltBPXuPa5vB8FzWX2/dOqnhnF4wdUJNK3ERYgW6Vs7lY0pgifwjkV7k0S3V4AU4bCLO7RiYmM3haGGv9uqLJrsfPZYK5kW5E49UvJJIyTnS0e/xLNd2vX1T1rHAz6afRLPaIcQSUM/UGG9ZrcGSlB1phOuE27Q6e7zsHP6pRNIwnWH1jgKpzpt6QSIT5hfS7Ub/Ekg5xX8631b0OzUbItWWIF94bd5eIGNStkgM7Uj/fBoPHIEknMGkwOCGpFx5SFqCjykBwhJyHOYhndfLMTPACpmYcXQ8vIHNxv2apG4qrCsAfiDtPnMlr/MqTjR9fw9LpwDNLt/Ec5qjaY6bXxcDvRKJQf1FcZtbx1GyI49Ni8/lzljeJ1ioQTXPZkE5Me/Ndrs3a/guNw+ZfAOVlLjftW91hnbQI6WXpljGa68lWap2NXjghnXCgHj/i3hrOJxmhKlpnQOwqOW1RMXuFIJ6lw0a0NVf9ieiiZQVvV7jaro5tZIkAaXpnX7zBNfsHW5SbStr5GrsvISns8xW8MdrfylOcO+K726qQwVT0y0Vj1r9s0nbvM5SeSITQpuE+w== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4868 Original-Authentication-Results: sandelman.ca; dkim=none (message not signed) header.d=none; sandelman.ca; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: AM5EUR03FT056.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: ee342465-3da5-4da5-80a9-08d83794aa41 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: Zikw5OQAOXtiyClz5cPD47qLkaP2U5FuFOxVbOifNpw5Vb5mIPaDoTAL95WkNMDU3uxQr0Du6JJelQtz9mQsvmhRZqF25XNNG+qGo0jv0U2wgBPMlku+jnnEjTYRPgrBYQeM0M+O4bdn0auGaQGFmnCPjyBVx9qLTDNdks0TFoQ1HbGF4wlxyKseVXxFJpDgVINxmC7nUoTlatqoL7Wj6o9pwKQm7TDFKNuLj+4K76HJxJcTlGPEaI5wmK6VTUb9hpcjS8Rpf3AkPFXr6cDd9GqWIZqxK1u0DAzbGnJIrsu48lvPzoS45ME9DxO/sPsyb609NpLiw1VzGBRZ6LUpsjerAVmPzgGXyNl9xtHKecDxfSol/Gi9ka8PVTCXI0eS3G3fqc+V8mrhmbNSh2ZqRw== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(346002)(376002)(396003)(136003)(39860400002)(46966005)(53546011)(6512007)(47076004)(478600001)(81166007)(26005)(2906002)(82310400002)(356005)(6486002)(186003)(82740400003)(2616005)(6506007)(86362001)(6862004)(36906005)(316002)(70206006)(336012)(5660300002)(70586007)(33656002)(36756003)(4326008)(8936002)(83380400001)(8676002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2020 10:04:59.3926 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 70ee483d-eec8-41b0-2934-08d83794ae75 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: AM5EUR03FT056.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4932 Archived-At: Subject: Re: [Suit] Review of draft-ietf-suit-manifest-09 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 10:05:05 -0000 SSByYWlzZWQgdHdvIG9ydGhvZ29uYWwgaXNzdWVzIHJlZ2FyZGluZyBQRU4uIEkgZG9u4oCZdCB0 aGluayB0aGF0IGVpdGhlciBvZiB0aGVtIGFyZSBibG9ja2Vycy4gSSBqdXN0IHdhbnQgdG8gbWFr ZSBzdXJlIHdlIGdldCB0aGVtIHJpZ2h0Lg0KDQoxKSBXZSBuZWVkIGEgd2F5IHRvIGRlY2xhcmUg c3ViLWFzc2lnbm1lbnRzIG9mIFBFTnMuDQoyKSBXZSBuZWVkIGEgd2F5IHRvIGNvbnN0cnVjdCBj bGFzcyBJRHMuDQoNCg0KT25lIGZhaXJseSBlYXN5IHdheSB0byBkZWFsIHdpdGggYWxsIG9mIHRo aXMgYXQgb25jZSBpcyB0byB1c2UgT0lEcy4gVGhlbiwgdGhlcmUgaXMgbm8gZGlmZmVyZW5jZSBi ZXR3ZWVuIHZlbmRvciBhbmQgY2xhc3M6IFRoZXkgYXJlIGFyYml0cmFyeSBzdWJkaXZpc2lvbnMg b2YgT0lEIHNwYWNlLiBXZSBjYW4gYWxzbyBzdGF0ZSB0aGF0IHRoZSBJQU5BIFBFTiBhcmMgb2Yg MS4zLjYuMS40LjEgaXMgYWx3YXlzIHByZXNlbnQsIGFuZCBvbWl0IGl0Lg0KDQpJbiB0aGlzIGNh c2UsIG15IHZlbmRvciBJRCBtaWdodCBiZSAxMzQ1Ny4zIGFuZCBteSBjbGFzcyBJRCBtaWdodCBi ZSAxLjcuOTkuIFRvZ2V0aGVyLCB0aGVzZSBjb3VsZCBmb3JtIGEgc2luZ2xlIE9JRDogMS4zLjYu MS40LjEuMTM0NTcuMy4xLjcuOTkuDQoNCk9ubHkgdGhlIFBFTiBhbmQgc3ViIGFzc2lnbm1lbnRz IHdvdWxkIGJlIGFjdHVhbGx5IGVuY29kZWQ6IDEzNDU3LjEuMS43LjMuIFRoZXNlIHdvdWxkIGRp dmlkZWQgaW50byB2ZW5kb3IgYW5kIGNsYXNzLg0KDQpJIGRvbuKAmXQgdGhpbmsgd2UgY2FuIHJl YXNvbmFibHkgbWFrZSBhcmd1bWVudHMgYWJvdXQgc2l6ZSBpZiB3ZSBsZWF2ZSB0aGUgMTYgYnl0 ZXMgb2YgQ2xhc3MgSUQgb24gdGhlIHRhYmxlLiBXaXRoIHRoYXQgaW4gbWluZCwgSSB0aGluayB3 ZSBzaG91bGQgcHJvYmFibHkgbG9vayBhdCBWZW5kb3IgSUQgYW5kIENsYXNzIElEIGFzIHJlbGF0 aXZlIE9JRHMuIFRoZXkgY2FuIGJlIHNlcmlhbGlzZWQgYXMgWC42OTAtZW5jb2RlZCBPSURzLCB3 cmFwcGVkIGluIGEgYnN0ci4NCg0KSSBzdGlsbCB3b3JyeSB0aGF0IHRoaXMgbGVhdmVzIGltcGxl bWVudG9ycyBsYXR0aXR1ZGUgdG8gYWJ1c2UgVmVuZG9yIElEIGFuZCBDbGFzcyBJRCwgaWdub3Jp bmcgcmVhbCBpbmNvbXBhdGliaWxpdGllcyBmb3IgdGhlIHNha2Ugb2YgY29uc2lzdGVudCBuYW1p bmcsIGJ1dCB0aGUgc2l6ZSBpcyBwcm9iYWJseSBtb3JlIGltcG9ydGFudCBvdmVyYWxsLg0KDQoN Cg0KQmVjYXVzZSBib3RoIE9JRHMgYW5kIFVVSURzIGFyZSBzZXJpYWxpc2VkIGFzIGJzdHIsIHRo aXMgd291bGQgbWVhbnQgdGhhdCwgaW4gb3JkZXIgdG8gdXNlIGEgVVVJRCwgaXQgd291bGQgbmVl ZCB0byBiZSB3cmFwcGVkIGluIGEgVGFnIDM3LCBzaW5jZSB0aGVyZSBpcyBub3QgeWV0IGFuIE9J RCBDQk9SIHRhZy4gQWx0ZXJuYXRpdmVseSwgYmVjYXVzZSBhIHJlY2lwaWVudCByZWFsbHkgZG9l c27igJl0IGNhcmXigJRpdCBqdXN0IG1hdGNoZXMgYSBic3RyIGV4cHJlc3NlZCBpbiB0aGUgbWFu aWZlc3QgdG8gYSBic3RyIGFzc2VydGVkIGJ5IHRoZSBNYW5pZmVzdCBQcm9jZXNzb3LigJR3ZSBj YW4gbGVhdmUgYm90aCB1bi10YWdnZWQuIEludGVybWVkaWFyaWVzIG1heSBjYXJlIGlmIHRoZXni gJlyZSB0cnlpbmcgdG8gcHJlc2VudCB0aGUgaW5mb3JtYXRpb24gdG8gYSB1c2VyLCB0aG91Z2gg dGhhdCBpcyBleHByZXNzbHkgbm90IHRoZSBwdXJwb3NlIG9mIGVpdGhlciB0aGUgdmVuZG9yIElE IG9yIHRoZSBjbGFzcyBJRC4NCg0KVGhpcyBpcyBhY3R1YWxseSBhIHJlYWxseSBuaWNlIHJlc3Vs dC4gSXQgbWVhbnMgdGhhdCB0aGVyZSBpcyBubyBjaGFuZ2UgdG8gdGhlIENEREwuIFRoZXJl4oCZ cyBhIChjb21wYXJhdGl2ZWx5IHNtYWxsKSBjaGFuZ2UgdG8gdGhlIHRleHQgdG8gZXhwbGFpbiB0 aGF0IGVpdGhlciBhIHJlbGF0aXZlIE9JRCBvciBhIFVVSUQgY2FuIGJlIHVzZWQgdG8gZXhwcmVz cyBhIHZlbmRvciBJRCBvciBhIGNsYXNzIElELg0KDQoNCg0KSeKAmW0gZmluZSB3aXRoIGRlZmlu aW5nIGEgUEVOIE5hbWUgU3BhY2UgSWRlbnRpZmllciBmb3IgVVVJRHMsIHByb3ZpZGVkIHRoYXQg dGhlIGlucHV0IGlzIGRlZmluZWQgdG8gYmUgYSBYLjY5MC1lbmNvZGVkIHJlbGF0aXZlIE9JRC4g VGhpcyBtZWFucyB0aGF0IGl0IGNhbiBoYW5kbGUgc3ViIGFzc2lnbm1lbnRzIGVhc2lseSwgYW5k IGl0IG1hdGNoZXMgdGhlIFZlbmRvciBJRCBwcm9wb3NhbCBhYm92ZS4gVGhpcyBpcyBvbmx5IG5l Y2Vzc2FyeSBpbiB0aGUgbWl4ZWQgY2FzZTogVmVuZG9yIElEIGlzIFBFTiwgQ2xhc3MgSUQgaXMg VVVJRC4NCg0KDQpBIGNvdXBsZSBtb3JlIGNvbW1lbnRzIGJlbG93Lg0KDQoNCj4gT24gMyBBdWcg MjAyMCwgYXQgMDE6MTQsIE1pY2hhZWwgUmljaGFyZHNvbiA8bWNyK2lldGZAc2FuZGVsbWFuLmNh PiB3cm90ZToNCj4gQnJlbmRhbiBNb3JhbiA8QnJlbmRhbi5Nb3JhbkBhcm0uY29tPiB3cm90ZToN Cj4+IENsYXNzSUQgPSB1dWlkNSh1dWlkNShPSURfTkFNRVNQQUNFX1VVSUQsIGVuY29kZV9vaWQo WzEsMyw2LDEsNCwxLFBFTl0pLCBDbGFzcy1TcGVjaWZpYy1JbmZvcm1hdGlvbikNCj4+IEJ1dCB0 aGVuIHdlIG5lZWQgdG8gZGVmaW5lIGVuY29kZV9vaWQgYmVjYXVzZSBSRkM0MTIyIGRvZXNu4oCZ dCBzcGVjaWZ5IHdoaWNoIE9JRCBlbmNvZGluZyB0byB1c2UuDQo+DQo+IFllYWgsIEkgc2VlIG5v IGFkdmFudGFnZSB0byBpbmNsdWRpbmcgdGhlIE9JRCBoZXJlLg0KDQpJIGRvbuKAmXQgaGF2ZSBh IHByb2JsZW0gd2l0aCBkZWNsYXJpbmcgYSBuZXcgTmFtZSBTcGFjZSBJZGVudGlmaWVyIGZvciBQ RU5zLCBwcm92aWRlZCB0aGF0IGl0IGNhbiBoYW5kbGUgc3ViLWFzc2lnbm1lbnRzLg0KDQo+PiBB bHNvLCB3ZSBuZWVkIHRvIHN1cHBvcnQgc3ViLWFzc2lnbm1lbnRzIGZyb20gYSBQRU4sIHNpbmNl IGxhcmdlDQo+PiBvcmdhbmlzYXRpb25zIG1heSBoYXZlIHBvbGljaWVzIHRoYXQgcmVxdWlyZSB0 aGUgdXNlIG9mIHNwZWNpZmljDQo+PiBzdWItYXNzaWdubWVudHMuDQo+DQo+IFNpbmNlIHRoaXMg aXMganVzdCB0byBwcm9kdWNlIGEgQ2xhc3NJRCwgaXQgc2VlbXMgdGhhdCB0aGVyZSBjb3VsZCBi ZSBhbg0KPiBpbnRlZ2VyIHRoYXQgY291bGQgYmUgaW5jcmVtZW50ZWQgdG8gZm9ybSBzdWItYXNz aWdubWVudHMuDQoNCkkgdGhpbmsgdGhhdCBDbGFzc0lEIGFuZCBzdWItYXNzaWdubWVudHMgYXJl IG9ydGhvZ29uYWwgaGVyZS4gT3JnYW5pc2F0aW9ucyBzaG91bGQgbm90IGJlIHJlc3RyaWN0ZWQg aW4gdGhlaXIgYWJpbGl0eSB0byBzcGVjaWZ5IHN1Yi1vcmdhbmlzYXRpb25zIGZvciB0aGUgcHVy cG9zZSBvZiBjb21wYXRpYmlsaXR5IGNoZWNraW5nLg0KDQo+IFNlY29uZCwgSSBiZWxpZXZlIHRo YXQgZm9yIGxhcmdlciBvcmdhbml6YXRpb25zLCBJQU5BIHdpbGwgYXNzaWduIG11bHRpcGxlDQo+ IFBFTnMgdG8gZS5nLiAiRXhhbXBsZUNPTSBDb25zdW1lciBEZXZpY2VzIiB2cyAiRXhhbXBsZUNP TSBUcmFuc3BvcnRhdGlvbiBTeXN0ZW1z4oCdDQoNClRoYXQgaXMgZ29vZCB0byBrbm93LCBob3dl dmVyIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHRoZSByZWx1Y3RhbmNlIHRvIHN1cHBvcnQgc3ViLWFz c2lnbm1lbnQuDQoNCkJyZW5kYW4NCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9m IHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkg YWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50 LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9z ZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9z ZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhhbmsg eW91Lg0K From nobody Mon Aug 3 04:02:02 2020 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 09E843A0E31 for ; Mon, 3 Aug 2020 04:02:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=BWi0gx9q; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=BWi0gx9q 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 3pcWw5B-yfKT for ; Mon, 3 Aug 2020 04:01:58 -0700 (PDT) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (mail-eopbgr10058.outbound.protection.outlook.com [40.107.1.58]) (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 EC09E3A0C95 for ; Mon, 3 Aug 2020 04:01:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R5fYBqXvPOibrUhsH6C/BLZL/523g4W1rheSEYGl4IY=; b=BWi0gx9qhLEH/UJ6rJS67sxgXpHza0AqvQnsIIjvJU1VYWVPwOWelX1xVhQ7v/DQPf25LEowYFxfL09EChVUnQStCVDR6njP7BbzhvNSOUfG2iNbl36AvDs1PEKibedQBpmR7Axk2GARthnRodP/9ZNfGnqY+nSreO4UTweEMIE= Received: from DB7PR05CA0056.eurprd05.prod.outlook.com (2603:10a6:10:2e::33) by DB7PR08MB3276.eurprd08.prod.outlook.com (2603:10a6:5:21::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Mon, 3 Aug 2020 11:01:50 +0000 Received: from DB5EUR03FT003.eop-EUR03.prod.protection.outlook.com (2603:10a6:10:2e:cafe::81) by DB7PR05CA0056.outlook.office365.com (2603:10a6:10:2e::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17 via Frontend Transport; Mon, 3 Aug 2020 11:01:50 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT003.mail.protection.outlook.com (10.152.20.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.17 via Frontend Transport; Mon, 3 Aug 2020 11:01:50 +0000 Received: ("Tessian outbound d7d79595a1cb:v63"); Mon, 03 Aug 2020 11:01:50 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: 0032afdf46beb340 X-CR-MTA-TID: 64aa7808 Received: from b5a8bc98a3a0.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 4192D0C2-B45A-453C-ABC2-609289763416.1; Mon, 03 Aug 2020 11:01:44 +0000 Received: from EUR03-DB5-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id b5a8bc98a3a0.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 03 Aug 2020 11:01:44 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N4OVKtQt9aN9JteWJtS/HUUaDbYRep3tw4EsAdVRn7eOavwGXBzhqdrbFCI1y5X/lGWQDhHHeXaI6LtSbve0XT0k903FlZopc1u8r77NncevAlIjxElj81feI3sklsCzI4wcz9wLfBh8oh8CwTwelpUucMs/dwR3zwVnoIIWJ4jOjInK21X9qUEnpCYs8zvR5I00zPaKeiEdoUlbOeO8hWEKHLod7aIVOyI1zoL955sP7q4n4WaB8ZK0r3AVTEX+qTkamWrgZr6tUi9zFQrD2OHPi8gm2GaAoICwf8NE63j+der2ahtzsR+lR0MKhyYHkcSKlKf7ai59L+FTfwqU3Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R5fYBqXvPOibrUhsH6C/BLZL/523g4W1rheSEYGl4IY=; b=R5wsx+5ha2EEo/XVRS4c/QGpGF4bhOPKsTFV9o9lfvZfNwwlj/AUZR9FEoxHvHwEi3bZ7t47jmvgXLqwLr9ZslLETW0Iqgmhx9K1NIoQSjQgV6XQJUWj+QEbDGJ06QDrTTCfdH8SmyMa20qPCaXdRUS3IhXCNq1Lq6YcPisuhcpRFUOZlzGMkOxP430Xt+82Yq/zuwm0ixEYbxBL+EHMlImphrnsuenK/jzIa2axH6hPdAcNlkyX8ErQcz6dKR6CmbBVP/fMZ2+TaBuUD7J8Y6SHg9tGVNG8mR9YkUnhsSWpVX/7Fumcv+yrYrFVQBNEwKKrLwqkdPeZWpn8F7Z/kg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=R5fYBqXvPOibrUhsH6C/BLZL/523g4W1rheSEYGl4IY=; b=BWi0gx9qhLEH/UJ6rJS67sxgXpHza0AqvQnsIIjvJU1VYWVPwOWelX1xVhQ7v/DQPf25LEowYFxfL09EChVUnQStCVDR6njP7BbzhvNSOUfG2iNbl36AvDs1PEKibedQBpmR7Axk2GARthnRodP/9ZNfGnqY+nSreO4UTweEMIE= Received: from AM6PR08MB4738.eurprd08.prod.outlook.com (2603:10a6:20b:cf::10) by AM6PR08MB5142.eurprd08.prod.outlook.com (2603:10a6:20b:d4::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16; Mon, 3 Aug 2020 11:01:43 +0000 Received: from AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56]) by AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56%3]) with mapi id 15.20.3239.021; Mon, 3 Aug 2020 11:01:43 +0000 From: Brendan Moran To: suit Thread-Topic: Boot vs. Invocation Thread-Index: AQHWaYV4nhWrUvTKa0uAzW/mc1pZHw== Date: Mon, 3 Aug 2020 11:01:43 +0000 Message-ID: <9CA92962-0D40-47CF-BB62-DE325D1D0869@arm.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) Authentication-Results-Original: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.20.19.206] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 461aec13-b3ae-4922-b9ae-08d8379c9f70 x-ms-traffictypediagnostic: AM6PR08MB5142:|DB7PR08MB3276: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:4941;OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: 4Sws3DvbnjmUNM9dfe3ursKnbr/rDPU9rJvThX666ZhpsG38BRnPrl3fkq3Sb4BUBHJedkvS2cwCjqMlx3fRamDpLE0xhgarwA84Vyq93WydB3pUJtptA/x7q0SkAwEJlH5ADUTbJXRcHPQ3pnhXfX4RDlAiJDRPSX3q8VkU1D/eqwFEIOWUudGTu08CTeW2riZ1Gyv9sx68KGfn3fVVLC8nF9nHAJ6hZyHkojtac8j13lVPrq3VNayz7UEuceNH3qYuODhY1ca6wWm7IqxGATV+gycU6gVz7ec+HtA2PaYUOK18zoBnwsbjnCkoDirX/Wlhzl4naJRYf+Iej3oODQ== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4738.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(136003)(366004)(346002)(39860400002)(396003)(5660300002)(83380400001)(66476007)(64756008)(66946007)(66556008)(86362001)(4744005)(66446008)(91956017)(76116006)(6512007)(2616005)(36756003)(186003)(2906002)(316002)(6916009)(6486002)(33656002)(26005)(71200400001)(478600001)(8936002)(8676002)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: wxkVTW/OnSPT7yJIOkVR/6xGa9vhz1UcA4rfWWYUV1OVrib+CCzzFZkd7RZgS9CY9+kL1UCgRCD9O3jv0m8Kv3wAtkAQkITWUj9v2OGyJYtXqDSm8QSMnp9d8c+3vrYoFgLRHqAlBg155cGaZkhBRGy4qTSeccVUT+hj8O3boj1RBXQVmFoXiwmZcmns3ITWzr4T7cbfbizv7qtA0BAyEssHbxI6fyn1aHkOsfG2tMOgifP3v7BiuBJHVrY0TQBt5J55SvjgGTk7pJH5esktTzmIDc9Nl2EiTjV0+4zI6EYe2VubWk9PuaYHV2QzkowHbjbtUaO2jiVft7NLKWuUAoDbQUNTvi140iEsAChYytAlsp18FXPfqNiudOUJj0tU5H0gOjjFDKullXA/Y/zh8NjHLxA4dW5uDNQO3tpHUaWV4sLipYIZmozJ6NoA+IZLVGkzPCvZ7W3eaAgAW3y7m0VrcbCrP+b/6hRtGt1v2RVhhCUBexV6hy/fl+tg5xguYRsD3jVL96wWfD7n40CyYKL4mUS93APWKKpYqroEQP+qggaFFXy0guocQOXreSj7pvwOs85JM/40QRPnE89KDSKIcYspVQj9rX0dErH9u0Xf5xfFgwAg3AjYq9jIP7c8/2u1d4mOXreNsEhcFIjWtA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB5142 Original-Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT003.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: d6a1b89b-91e0-43d0-0204-08d8379c9b71 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: eIx420vKfbyPK8FLr1DEzeanz+dLoo9c62R5vnPabItqg2PHoQkjp5k4cAozcGXmwvStQIfnrVwsUiUbWTLiOYCKvJRGybyFZUxDduLjO4uyDCRaZnvENN1NsBJ2NWrvEovN+fbih/bBLNiwqoO3Myp9C2qEKJQj2V+qarZPFwUK2Rs8regmG0BHUVjdtdWUTS5PhUtzjD+LixwM8nzNy+cW8iU9GAPBnZ4S3QxQHWkiCcPbYnLdYKVmUj6VKmdnntK5GbeZnp9LLvDnkRZ8FrK5Ej+TwDD4J0UDM2ray4qhptoTkkJveilPR2LmJ+waf93GSXEZeWtqK9/LEWbfXc0fCddUsa9zCo/BDZIctDGg3Husxw/YF7uVGAOcQeNpJiINPbx+9kTkYeo/5/JDBQ== X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(396003)(376002)(136003)(46966005)(336012)(8676002)(8936002)(2906002)(316002)(86362001)(33656002)(5660300002)(2616005)(82740400003)(4744005)(47076004)(70206006)(6506007)(81166007)(26005)(6512007)(6486002)(478600001)(186003)(356005)(6916009)(36756003)(70586007)(83380400001)(82310400002); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2020 11:01:50.2245 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 461aec13-b3ae-4922-b9ae-08d8379c9f70 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT003.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB7PR08MB3276 Archived-At: Subject: [Suit] Boot vs. Invocation X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 11:02:00 -0000 SW4gcmVzcG9uc2UgdG8gc29tZSBvZiBEYXZlIFTigJlzIGNvbW1lbnRzIChzcGVjaWZpY2FsbHks IFtEVDMyXSkgSSB3b3VsZCBsaWtlIHRvIHByb3Bvc2UgcmVwbGFjaW5nIGluc3RhbmNlcyBvZiDi gJxib2904oCdIHdpdGgg4oCcaW52b2NhdGlvbuKAnSBzbyB0aGF0ICJzZWN1cmUgYm9vdCIgYmVj b21lcyDigJxzZWN1cmUgaW52b2NhdGlvbi7igJ0gVGhpcyBpcyB0byBtYWtlIGl0IGNsZWFyZXIg dGhhdCBTVUlUIG1hbmlmZXN0cyBhcmUgYXBwcm9wcmlhdGUgZm9yIGludm9raW5nIFRBcyBmb3Ig VEVFUC4gQm9vdGluZyBhbiBJb1QgZGV2aWNlIHNlY3VyZWx5IGFuZCBydW5uaW5nIGEgVEEgc2Vj dXJlbHkgYXJlIGJvdGggY2xhc3NlcyBvZiBzZWN1cmUgaW52b2NhdGlvbiBhbmQgRGF2ZSBoYXMg cmFpc2VkIHRoYXQgaXQgaXMgbm90IG9idmlvdXMgdGhhdCBTVUlUIG1hbmlmZXN0cyBhcmUgYXBw cm9wcmlhdGUgZm9yIGJvdGguDQoNCkJlc3QgUmVnYXJkcywNCkJyZW5kYW4NCg0KDQpJTVBPUlRB TlQgTk9USUNFOiBUaGUgY29udGVudHMgb2YgdGhpcyBlbWFpbCBhbmQgYW55IGF0dGFjaG1lbnRz IGFyZSBjb25maWRlbnRpYWwgYW5kIG1heSBhbHNvIGJlIHByaXZpbGVnZWQuIElmIHlvdSBhcmUg bm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBpbW1l ZGlhdGVseSBhbmQgZG8gbm90IGRpc2Nsb3NlIHRoZSBjb250ZW50cyB0byBhbnkgb3RoZXIgcGVy c29uLCB1c2UgaXQgZm9yIGFueSBwdXJwb3NlLCBvciBzdG9yZSBvciBjb3B5IHRoZSBpbmZvcm1h dGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo= From nobody Mon Aug 3 04:06:27 2020 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 822C33A0E37 for ; Mon, 3 Aug 2020 04:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.948 X-Spam-Level: X-Spam-Status: No, score=-0.948 tagged_above=-999 required=5 tests=[NICE_REPLY_A=-0.949, 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 2uyh2bR9bDNl for ; Mon, 3 Aug 2020 04:06:22 -0700 (PDT) Received: from mail-edgeS23.fraunhofer.de (mail-edges23.fraunhofer.de [153.97.7.23]) (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 121AF3A0E34 for ; Mon, 3 Aug 2020 04:06:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2FXBQBH7idf/xmnZsBgHgEBCxIMQIM?= =?us-ascii?q?/BoEegTMKhCuRGpolgV0MCwEBAQEBAQEBAQYBARgLCgIEAQEChEoCgjkBJDg?= =?us-ascii?q?TAhABAQYBAQEBAQYEAgKGRQyDU4EDAQEBAQEBAQEBAQEBAQEBAQEBARYCQ1U?= =?us-ascii?q?SAR8BAQEDAQEhDwEFNgIZCxgCAiYCAicgEAYBDAYCAQGDIgGCfAQLsV6BMoV?= =?us-ascii?q?Sg0mBOgaBDiqGT4I6gmeBHg+BTD8maycPglo+glwBAYEqARIBTYJqgmAEjzy?= =?us-ascii?q?DNaJ0KQeBWoEKgQkEC5MPhVYFCh6CfDaJF4UCBo4pkiafJAIEAgkCFYFqgQt?= =?us-ascii?q?wTSRPgmlQFwINj0QBAoddhURyNwIGAQcBAQMJfI4jAYEQAQE?= X-IPAS-Result: =?us-ascii?q?A2FXBQBH7idf/xmnZsBgHgEBCxIMQIM/BoEegTMKhCuRG?= =?us-ascii?q?polgV0MCwEBAQEBAQEBAQYBARgLCgIEAQEChEoCgjkBJDgTAhABAQYBAQEBA?= =?us-ascii?q?QYEAgKGRQyDU4EDAQEBAQEBAQEBAQEBAQEBAQEBARYCQ1USAR8BAQEDAQEhD?= =?us-ascii?q?wEFNgIZCxgCAiYCAicgEAYBDAYCAQGDIgGCfAQLsV6BMoVSg0mBOgaBDiqGT?= =?us-ascii?q?4I6gmeBHg+BTD8maycPglo+glwBAYEqARIBTYJqgmAEjzyDNaJ0KQeBWoEKg?= =?us-ascii?q?QkEC5MPhVYFCh6CfDaJF4UCBo4pkiafJAIEAgkCFYFqgQtwTSRPgmlQFwINj?= =?us-ascii?q?0QBAoddhURyNwIGAQcBAQMJfI4jAYEQAQE?= X-IronPort-AV: E=Sophos;i="5.75,429,1589234400"; d="scan'208";a="19427687" Received: from mail-mtadd25.fraunhofer.de ([192.102.167.25]) by mail-edgeS23.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2020 13:06:19 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BKBgCH7idf/1lIDI1gHgEBCxIMQIM?= =?us-ascii?q?/Bi9vVzAsCoQrkRmaJYFpCwEDAQEBAQEGAQEYCwoCBAEBhEwCgjcCJDgTAhA?= =?us-ascii?q?BAQUBAQECAQYEbYVcDIVyAQEEAQEhDwEFNgIZCxgCAiYCAicgEAYBDAYCAQG?= =?us-ascii?q?DIgGDAAuxXoEyhVKDSYE6BoEOKoZPgjqCZ4EeD4FMPyZrJw+CWj6CXAEBgSo?= =?us-ascii?q?BEgFNgmqCYASPPIM1onQpB4FagQqBCQQLkw+FVgUKHoJ8NokXhQIGjimSJp8?= =?us-ascii?q?kAgQCCQIVgWojZ3BNJE+CaVAXAg2PRAECh12FREExNwIGAQcBAQMJfI4jAYE?= =?us-ascii?q?QAQE?= X-IronPort-AV: E=Sophos;i="5.75,429,1589234400"; d="scan'208";a="87486537" Received: from mailext.sit.fraunhofer.de ([141.12.72.89]) by mail-mtaDD25.fraunhofer.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2020 13:06:15 +0200 Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 073B6F0u017271 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Mon, 3 Aug 2020 13:06:15 +0200 Received: from [192.168.16.50] (79.206.156.41) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.487.0; Mon, 3 Aug 2020 13:06:10 +0200 To: Brendan Moran , suit References: <9CA92962-0D40-47CF-BB62-DE325D1D0869@arm.com> From: Henk Birkholz Message-ID: Date: Mon, 3 Aug 2020 13:06:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <9CA92962-0D40-47CF-BB62-DE325D1D0869@arm.com> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.206.156.41] Archived-At: Subject: Re: [Suit] Boot vs. Invocation X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 11:06:26 -0000 Hi Brendan, sounds like a quite targeted way forward (you all know what comes next...). We just have to make sure that this tweak is captured well prominently in the text, as a definition, so it can be referenced in a meaningful manner and reflects the superset of "authenticated boot" and "authenticated TA invocation" well. Cheers, Henk On 03.08.20 13:01, Brendan Moran wrote: > In response to some of Dave T’s comments (specifically, [DT32]) I would like to propose replacing instances of “boot” with “invocation” so that "secure boot" becomes “secure invocation.” This is to make it clearer that SUIT manifests are appropriate for invoking TAs for TEEP. Booting an IoT device securely and running a TA securely are both classes of secure invocation and Dave has raised that it is not obvious that SUIT manifests are appropriate for both. > > 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 > From nobody Mon Aug 3 05:38:29 2020 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 2359C3A07DB for ; Mon, 3 Aug 2020 05:38:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 header.b=onaKHeEI; dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com header.b=onaKHeEI 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 H8ffUNi8tPBO for ; Mon, 3 Aug 2020 05:38:26 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40064.outbound.protection.outlook.com [40.107.4.64]) (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 892CC3A07D4 for ; Mon, 3 Aug 2020 05:38:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uP0oAuNjJ2tpBmRpP9TtWHe7LsIKYUZGogiAn9PeNto=; b=onaKHeEIYvm+I3lICbxpG398zj17gXdhZVe+cPTi8e9Hv5how/aErexwAk5Su5G0YiahcyjImZ9grfGVQB4HM+hGkjgdl5ids8WFYQ1hkpGZaJ9SGv7DjeiatrtLR+G6n7wY0riSRsOSDIypp29AGGznxb4M2QLvP8vMXd9a0ME= Received: from DB6P18901CA0003.EURP189.PROD.OUTLOOK.COM (2603:10a6:4:16::13) by VE1PR08MB5805.eurprd08.prod.outlook.com (2603:10a6:800:1aa::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.21; Mon, 3 Aug 2020 12:38:22 +0000 Received: from DB5EUR03FT042.eop-EUR03.prod.protection.outlook.com (2603:10a6:4:16:cafe::8e) by DB6P18901CA0003.outlook.office365.com (2603:10a6:4:16::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.16 via Frontend Transport; Mon, 3 Aug 2020 12:38:22 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 63.35.35.123) smtp.mailfrom=arm.com; ietf.org; dkim=pass (signature was verified) header.d=armh.onmicrosoft.com;ietf.org; dmarc=bestguesspass action=none header.from=arm.com; Received-SPF: Pass (protection.outlook.com: domain of arm.com designates 63.35.35.123 as permitted sender) receiver=protection.outlook.com; client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com; Received: from 64aa7808-outbound-1.mta.getcheckrecipient.com (63.35.35.123) by DB5EUR03FT042.mail.protection.outlook.com (10.152.21.123) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20 via Frontend Transport; Mon, 3 Aug 2020 12:38:22 +0000 Received: ("Tessian outbound d778af23b2f9:v63"); Mon, 03 Aug 2020 12:38:22 +0000 X-CheckRecipientChecked: true X-CR-MTA-CID: d5701d5965013e79 X-CR-MTA-TID: 64aa7808 Received: from 3bca53f72680.1 by 64aa7808-outbound-1.mta.getcheckrecipient.com id 3FD6C0EB-4E3E-4EE0-90F2-EFBDC1FBDB4D.1; Mon, 03 Aug 2020 12:38:17 +0000 Received: from EUR05-AM6-obe.outbound.protection.outlook.com by 64aa7808-outbound-1.mta.getcheckrecipient.com with ESMTPS id 3bca53f72680.1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384); Mon, 03 Aug 2020 12:38:17 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=a3CZHXeelQobTTwCKwI4NHWMIIEL3y33vnwzR5XJEL2gJQ5rMnfAwDqWF1zmnG8lest1TaWHw72+zu3YpLDgZF5oLaNSKv/SJyM0n2XOE0J8auEiUOFd2FQGt7nNPB1F1PR/xso+1atLbXa/oiZW8zVlKNAyl8Pv8r2esvoHSscFyt6h7FUUg/i3K9ccJPLmQ0rnH1Nz2zddiE//5X01yQmx2lMb38yeei23Xu+SZFlqnez/Pm66tIwv2WmHpAQ6JdaMWsFX77MYMAqtNO0DRqfhY8IWLUuuUllXe78BYvwkDYm3ag9CKNuXcBfA+QAQulgEG/f/b//9qxZe7H4lDQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uP0oAuNjJ2tpBmRpP9TtWHe7LsIKYUZGogiAn9PeNto=; b=C0KQQ94f9g/r+1LrC3wQ/0TnsEHBYmh+WpXUoibLe6jgSblgNeBJE+cm09YGqpJgq64AANvoUAnhuQpHS4gMA+geTGiguNehWgZ4ATsZKulKmLn3M8X2xwdYaLoplfvb9eKkcYY0bWytgpYxRrEWoIbhutF+W138JaaQSFmhawEDd7VEhZdPnJuwMgedlG+KOOfexsXAd9hznnYJwPdH5QSK6WqSKDwYwXFJ7XouExROpqkzdhC73zUg4jnWgxaOlRcnq/v6U1JysUrBIEgYR6ghYdXRzwqvmh0oRik1miYR9/ngc58uPpWFnGv6KxTD9NCkrVJ7123foM57a1NHog== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=arm.com; dmarc=pass action=none header.from=arm.com; dkim=pass header.d=arm.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector2-armh-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=uP0oAuNjJ2tpBmRpP9TtWHe7LsIKYUZGogiAn9PeNto=; b=onaKHeEIYvm+I3lICbxpG398zj17gXdhZVe+cPTi8e9Hv5how/aErexwAk5Su5G0YiahcyjImZ9grfGVQB4HM+hGkjgdl5ids8WFYQ1hkpGZaJ9SGv7DjeiatrtLR+G6n7wY0riSRsOSDIypp29AGGznxb4M2QLvP8vMXd9a0ME= Received: from AM6PR08MB4738.eurprd08.prod.outlook.com (2603:10a6:20b:cf::10) by AM7PR08MB5528.eurprd08.prod.outlook.com (2603:10a6:20b:dd::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.20; Mon, 3 Aug 2020 12:38:16 +0000 Received: from AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56]) by AM6PR08MB4738.eurprd08.prod.outlook.com ([fe80::a98d:5ebe:dc1d:ea56%3]) with mapi id 15.20.3239.021; Mon, 3 Aug 2020 12:38:16 +0000 From: Brendan Moran To: Henk Birkholz CC: suit Thread-Topic: [Suit] Boot vs. Invocation Thread-Index: AQHWaYV5gHBlv0r4bkaadpuZshyF5KkmOSOAgAAZu4A= Date: Mon, 3 Aug 2020 12:38:16 +0000 Message-ID: <9CBF239B-32B1-4CAE-B680-C94AE7CD88B0@arm.com> References: <9CA92962-0D40-47CF-BB62-DE325D1D0869@arm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3608.80.23.2.2) Authentication-Results-Original: sit.fraunhofer.de; dkim=none (message not signed) header.d=none;sit.fraunhofer.de; dmarc=none action=none header.from=arm.com; x-originating-ip: [82.20.19.206] x-ms-publictraffictype: Email X-MS-Office365-Filtering-HT: Tenant X-MS-Office365-Filtering-Correlation-Id: 6f8008bf-3e74-4678-4e48-08d837aa1bd0 x-ms-traffictypediagnostic: AM7PR08MB5528:|VE1PR08MB5805: X-Microsoft-Antispam-PRVS: x-checkrecipientrouted: true nodisclaimer: true x-ms-oob-tlc-oobclassifiers: OLM:10000;OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Untrusted: BCL:0; X-Microsoft-Antispam-Message-Info-Original: hK7GZi9+lUvP2Ex4s2uXLVosQGFdbEu7AYjwKleBZRXW2ME8RccZ7FrkwjH9FrD6ZjmOV1rFzV4l6ISkDMz/mHX7kVkVxN22+1kXzHHpwR/SblifcObbbCS87OCdV5OdCQzCM7j6qvDlA6xHPgfgQom3NaGHBMdtB9LpKSEtJ79siTrb6OqcA3CrVFoRBjonoj9K8echNR3h0Pxx1xa9gChbYi259EqzxxHMATG4Lx61emMvPXd8be4SjJRn/aJKVf1RRp+YNE6Un6DxO6hap24Tgc6jIy1g/3+b6MGnVJmXG+XocpHUr8erDw127qN1z+y4KGUgPTpYKqZVBZWbkAatAVFRV8GC4rf52R7Po+tbN3ISehgoENa/mg2nCz6xjwnlT+U8BG1t3EdPZMFoMw== X-Forefront-Antispam-Report-Untrusted: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR08MB4738.eurprd08.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(376002)(346002)(366004)(39860400002)(396003)(6506007)(53546011)(83380400001)(64756008)(8676002)(66556008)(66946007)(66476007)(66446008)(91956017)(76116006)(2616005)(71200400001)(33656002)(186003)(26005)(966005)(478600001)(6486002)(316002)(36756003)(5660300002)(6916009)(86362001)(2906002)(8936002)(4326008)(6512007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: bAKtHknoVdk1B33ni5n7auzkWchBveGiNlSOI5qtgGc12fubwxVKWX4Lt4dfssg7EJ/QqEV1Rk22QEpFYypGG2JdypYO4g+EEQwMkGfydGNvDqxNPYjWdWqCSa26lruAPRnuQDguHRIoHp79joH3ot3gqb5EaUocRybsopvR0bhW5T13ya9uFInD6LQw32Cvf9asa46G2LsoT6NFJG+JV8tvFCDChX1soPTpj/lQM6/paFfZty5Cksrvcu62tqMgmJkw1+19QfASsAHFHa+Jmi4/PJWOxnkBRx7D0sWbK13XCNvD8g/tdiFziSZO1Xyd+C7uq8pe8ivL4UlATvfNWkt4bmsEpXqlNxfDK1H5kSULjuMwbg2CLQyDYbwQlwdT5KtLE+qiE9ACIQOgfHpVNQvMyiYsCHjhFL6qDLg3klJenblESnuYVDc7ckSvipLDB3c/T2/ObtzwdyNMcuWeJj7sC4rTlHfbUWVMf7CDfkiGRXebzCbpfPcUoYozhsPJB2qnH29+RV77br/Z7fOOSo/6+CjO7y3GoIaX3pNtwy7QPDCw1uqA/xxjJ0Zs+5115Hc/q6jh/1b4kLCm7/uXN91Rdt1hDTnLFQ71AT/hqHjwrqLGea1N7WBZSFq1UeKdmWhpfKZpa0SXAVqJo1vGiw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM7PR08MB5528 Original-Authentication-Results: sit.fraunhofer.de; dkim=none (message not signed) header.d=none;sit.fraunhofer.de; dmarc=none action=none header.from=arm.com; X-EOPAttributedMessage: 0 X-MS-Exchange-Transport-CrossTenantHeadersStripped: DB5EUR03FT042.eop-EUR03.prod.protection.outlook.com X-MS-Office365-Filtering-Correlation-Id-Prvs: 2e90b344-3b9a-4e26-5d23-08d837aa1825 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 2CQ/Nma7cjvxM5dvPwkVjQz12kt1978fEiucvJ/qB/smigvqtVPJ1XYKnLaeqRVBFcZhxwSs7SzO+ptOZD5UxP3B9nlR9xNL3kfiuSajEmHp+MZR2azbvj358meRkVY8GwLm6Q3dmy6IN6DXXYrtDgU33kALQJH3NzMZqbF7N7BGClAh+4HkQTfmUmMERF00+dV78CObDwmQIW6VMSfDDoeyBjigLwPmSGDARKZyqrIQCS93pKY79XZMF1HCjknkCYmKIMqHboKes884S+fcKXpPCpXCeAYgJS5ZPmC5jaZODP/3Ji3LnZJpsssxlNUbDGVnPEYVAXLeGa50uAvCaL+zAMX5lwikdW7DKD0bFus3o7l3n2uQAx5Fr8Mm7Q/F10Y4YNNJCAF3a6nJ+go6X/itpYhBPqOB/JsL5/pl1MV1URkZ+iRVn97XXAVhbaklI2cxoAAMrrmc8T843B81/3fIVETuhCtxEnVMhDddWcA= X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:64aa7808-outbound-1.mta.getcheckrecipient.com; PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(376002)(396003)(346002)(46966005)(336012)(70206006)(70586007)(81166007)(36756003)(86362001)(6506007)(356005)(6862004)(2616005)(8936002)(4326008)(82310400002)(53546011)(6486002)(2906002)(186003)(8676002)(478600001)(316002)(82740400003)(26005)(966005)(6512007)(33656002)(83380400001)(5660300002)(47076004); DIR:OUT; SFP:1101; X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 03 Aug 2020 12:38:22.3469 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 6f8008bf-3e74-4678-4e48-08d837aa1bd0 X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com] X-MS-Exchange-CrossTenant-AuthSource: DB5EUR03FT042.eop-EUR03.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5805 Archived-At: Subject: Re: [Suit] Boot vs. Invocation X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 12:38:28 -0000 SGkgSGVuaywNCg0KQXMgaXQgaGFwcGVucywgdGhlcmUgd2FzIGFscmVhZHkgYSBkZWZpbml0aW9u IGZvciDigJx0cnVzdGVkIGV4ZWN1dGlvbizigJ0gdW51c2VkIGluIHRoZSBzcGVjaWZpY2F0aW9u LCB0aGF0IGRlZmluZXMgaXRzZWxmIGFzIGEgc3VwZXJzZXQgb2YgYm9vdCAmIHJ1bi4gSSBjb3Vs ZCByZXBsYWNlIGl0IHdpdGggVHJ1c3RlZCBJbnZvY2F0aW9uLCBhbmQgdGhhdCB3b3VsZCBwcm92 aWRlIHRoZSBkZWZpbml0aW9uIHlvdSB3b3VsZCBsaWtlLg0KDQpCcmVuZGFuDQoNCj4gT24gMyBB dWcgMjAyMCwgYXQgMTI6MDYsIEhlbmsgQmlya2hvbHogPGhlbmsuYmlya2hvbHpAc2l0LmZyYXVu aG9mZXIuZGU+IHdyb3RlOg0KPg0KPiBIaSBCcmVuZGFuLA0KPg0KPiBzb3VuZHMgbGlrZSBhIHF1 aXRlIHRhcmdldGVkIHdheSBmb3J3YXJkICh5b3UgYWxsIGtub3cgd2hhdCBjb21lcyBuZXh0Li4u KS4gV2UganVzdCBoYXZlIHRvIG1ha2Ugc3VyZSB0aGF0IHRoaXMgdHdlYWsgaXMgY2FwdHVyZWQg d2VsbCBwcm9taW5lbnRseSBpbiB0aGUgdGV4dCwgYXMgYSBkZWZpbml0aW9uLCBzbyBpdCBjYW4g YmUgcmVmZXJlbmNlZCBpbiBhIG1lYW5pbmdmdWwgbWFubmVyIGFuZCByZWZsZWN0cyB0aGUgc3Vw ZXJzZXQgb2YgImF1dGhlbnRpY2F0ZWQgYm9vdCIgYW5kICJhdXRoZW50aWNhdGVkIFRBIGludm9j YXRpb24iIHdlbGwuDQo+DQo+IENoZWVycywNCj4NCj4gSGVuaw0KPg0KPiBPbiAwMy4wOC4yMCAx MzowMSwgQnJlbmRhbiBNb3JhbiB3cm90ZToNCj4+IEluIHJlc3BvbnNlIHRvIHNvbWUgb2YgRGF2 ZSBU4oCZcyBjb21tZW50cyAoc3BlY2lmaWNhbGx5LCBbRFQzMl0pIEkgd291bGQgbGlrZSB0byBw cm9wb3NlIHJlcGxhY2luZyBpbnN0YW5jZXMgb2Yg4oCcYm9vdOKAnSB3aXRoIOKAnGludm9jYXRp b27igJ0gc28gdGhhdCAic2VjdXJlIGJvb3QiIGJlY29tZXMg4oCcc2VjdXJlIGludm9jYXRpb24u 4oCdIFRoaXMgaXMgdG8gbWFrZSBpdCBjbGVhcmVyIHRoYXQgU1VJVCBtYW5pZmVzdHMgYXJlIGFw cHJvcHJpYXRlIGZvciBpbnZva2luZyBUQXMgZm9yIFRFRVAuIEJvb3RpbmcgYW4gSW9UIGRldmlj ZSBzZWN1cmVseSBhbmQgcnVubmluZyBhIFRBIHNlY3VyZWx5IGFyZSBib3RoIGNsYXNzZXMgb2Yg c2VjdXJlIGludm9jYXRpb24gYW5kIERhdmUgaGFzIHJhaXNlZCB0aGF0IGl0IGlzIG5vdCBvYnZp b3VzIHRoYXQgU1VJVCBtYW5pZmVzdHMgYXJlIGFwcHJvcHJpYXRlIGZvciBib3RoLg0KPj4gQmVz dCBSZWdhcmRzLA0KPj4gQnJlbmRhbg0KPj4gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRz IG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBt YXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNj bG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVy cG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhh bmsgeW91Lg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4+IFN1aXQgbWFpbGluZyBsaXN0DQo+PiBTdWl0QGlldGYub3JnDQo+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3N1aXQNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhl IGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50 aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRv IG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZv ciBhbnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1l ZGl1bS4gVGhhbmsgeW91Lg0K From nobody Mon Aug 3 12:32:48 2020 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 8CAD03A109E for ; Mon, 3 Aug 2020 12:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 ruxkcn7j8uy5 for ; Mon, 3 Aug 2020 12:32:45 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3ABC23A10AD for ; Mon, 3 Aug 2020 12:32:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 0E28A389A0; Mon, 3 Aug 2020 15:12:06 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dYiUEfivOO6Y; Mon, 3 Aug 2020 15:12:01 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id A74713899D; Mon, 3 Aug 2020 15:12:01 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 06A9463E; Mon, 3 Aug 2020 15:32:39 -0400 (EDT) From: Michael Richardson To: Brendan Moran cc: suit In-Reply-To: <9CA92962-0D40-47CF-BB62-DE325D1D0869@arm.com> References: <9CA92962-0D40-47CF-BB62-DE325D1D0869@arm.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Suit] Boot vs. Invocation X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 19:32:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brendan Moran wrote: > In response to some of Dave T=E2=80=99s comments (specifically, [DT32= ]) I would > like to propose replacing instances of =E2=80=9Cboot=E2=80=9D with = =E2=80=9Cinvocation=E2=80=9D so that > "secure boot" becomes =E2=80=9Csecure invocation.=E2=80=9D This is to= make it clearer I think that "secure invocation" is a bit jarring to the ear... more awkwar= d to read, but I don't object. Are there any other possible words? . o O ( KMAC(wingardim levioso!) ) =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8oZlYACgkQgItw+93Q 3WWEFwf/R6SR1cQ4ADDNTRgKiTLBMkEQ1a1oSJ61V1l+i6lRu9CT3xucjRtZWT2A 52Qjdw/bgREoUNJQLXXBmCjYbXY95enedN8cOniKSvI1wCI5XFoot7G4xSSJg5Gn 82NM4xxl94b7AJ7FJLTy95wjTMb4kDRrT66RMGCzQuaQ7QRIUGEB0NpQmsZ636v8 YjKHBM9q4m1280QdHJg16cHlkwDV1glpCJBtr6KwW7IAs8akWOmFXPp152aNfT/q AS7OYa/WJIzuHnwff1OApGKZk5yeeIU6Q5DQQicPlaxu6S70SH7yimcgT+QtdxJn CrvH0GtdezOgW/xX+v8ETX47jW/mYA== =u4fF -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Aug 3 13:05:23 2020 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 16EDC3A1020 for ; Mon, 3 Aug 2020 13:05:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 BrOxAVWZUnjH for ; Mon, 3 Aug 2020 13:05:20 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310B63A0EFD for ; Mon, 3 Aug 2020 13:05:20 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 6A08938996; Mon, 3 Aug 2020 15:44:41 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id aWg8lf9Jy3wb; Mon, 3 Aug 2020 15:44:40 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 81A1438995; Mon, 3 Aug 2020 15:44:40 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D761963E; Mon, 3 Aug 2020 16:05:17 -0400 (EDT) From: Michael Richardson To: Brendan Moran cc: suit In-Reply-To: <7D807988-6D37-4957-9528-32235E269C86@arm.com> References: <70453005-8DFA-4DBE-8C04-9882839D5005@arm.com> <13874.1596131258@localhost> <21C2CB5D-37E1-4C74-A0FD-36623F4CCD2E@arm.com> <22685.1596413661@localhost> <7D807988-6D37-4957-9528-32235E269C86@arm.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Suit] Review of draft-ietf-suit-manifest-09 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2020 20:05:22 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brendan Moran wrote: > Because both OIDs and UUIDs are serialised as bstr, this would meant > that, in order to use a UUID, it would need to be wrapped in a Tag 37, > since there is not yet an OID CBOR tag. Alternatively, because a > recipient really doesn=E2=80=99t care=E2=80=94it just matches a bstr = expressed in the > manifest to a bstr asserted by the Manifest Processor=E2=80=94we can = leave both > un-tagged. Intermediaries may care if they=E2=80=99re trying to prese= nt the > information to a user, though that is expressly not the purpose of > either the vendor ID or the class ID. The OID path is just a way to get a 128-bit thing in a somewhat predictable= way. > This is actually a really nice result. It means that there is no chan= ge > to the CDDL. There=E2=80=99s a (comparatively small) change to the te= xt to > explain that either a relative OID or a UUID can be used to express a > vendor ID or a class ID. But, it's just 128-bits. I'd suggest that the OID/UUID path to getting there just be advice. > I=E2=80=99m fine with defining a PEN Name Space Identifier for UUIDs,= provided > that the input is defined to be a X.690-encoded relative OID. This > means that it can handle sub assignments easily, and it matches the > Vendor ID proposal above. This is only necessary in the mixed case: > Vendor ID is PEN, Class ID is UUID. I'd rather no addional humans were harmed by having to read enough X.690 to figure out that they can just hand-assemble their classID. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8obf0ACgkQgItw+93Q 3WVn6Qf/aI8694lebRHf6Nc7l6G7cDKLpPSrKTsKxcKYB9vyz6E1atOvSFYmG7mM dofqVPyB8/W4mvzuRy5piqVg5aDbWePuzbVdPuvIrQrjf+mhDeGBLidLuAlNmRV/ iXTwlQ5WxwuKfPlsptgUe+GaGfwFOT0G9SC/WCoVS+fBTEE6t51Wza/U7d1fSjuD 0WGy6dd3nBNnlX6K67JNC/7eZ8fwKEKAdrYCxkrhj6nom24KuuPI/y0B5KSqn26M ZYBcmj7VuJOGjt72v2VHVl/JHOTs7qoQxLci5zGZZuPQLTSW493njzELkQmE4L1u CiZ7upczF7dMWNqwDbNsg1hT0eLdXQ== =J7NM -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Aug 5 09:58:15 2020 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 D578C3A0C4E for ; Wed, 5 Aug 2020 09:58:13 -0700 (PDT) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 4q_bfQjqbWUA for ; Wed, 5 Aug 2020 09:58:12 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2663A3A0C41 for ; Wed, 5 Aug 2020 09:58:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C7237300B5B for ; Wed, 5 Aug 2020 12:58:09 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id R_16IdBeAf6a for ; Wed, 5 Aug 2020 12:58:08 -0400 (EDT) Received: from [192.168.1.161] (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id 65179300AA4 for ; Wed, 5 Aug 2020 12:58:08 -0400 (EDT) From: Russ Housley Content-Type: multipart/alternative; boundary="Apple-Mail=_72D5B370-13D2-4CF0-9A51-CAC293BB1FA1" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Message-Id: References: <39C59343-D873-4282-8BD2-A5B6A659B3A0@ietf.org> To: suit Date: Wed, 5 Aug 2020 12:58:09 -0400 X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [Suit] IETF 108 meeting survey X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2020 16:58:14 -0000 --Apple-Mail=_72D5B370-13D2-4CF0-9A51-CAC293BB1FA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please fill out the survey if you participated in IETF 108. > From: IETF Executive Director > > Subject: [108all] Final reminder: IETF 108 meeting survey > Date: August 5, 2020 at 6:30:16 AM EDT > To: 108all@ietf.org >=20 > Thank you very much to the ~230 people who have filled in the IETF 108 = meeting survey as this data is crucial to helping us plan future = meetings. We could still use another 70 or so responses and so this is = a final reminder to please help us by taking a few minutes to complete = the survey: >=20 > https://www.surveymonkey.com/r/T3SL7JF = >=20 > Thanks in advance >=20 > --=20 > Jay Daley > IETF Executive Director > exec-director@ietf.org --Apple-Mail=_72D5B370-13D2-4CF0-9A51-CAC293BB1FA1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Please fill out the = survey if you participated in IETF 108.


From: IETF Executive Director <exec-director@ietf.org>
Subject: = [108all] Final = reminder: IETF 108 meeting survey
Date: = August 5, 2020 at 6:30:16 AM = EDT
To: = 108all@ietf.org

Thank you very much to the ~230 people who have filled in the = IETF 108 meeting survey as this data is crucial to helping us plan = future meetings.  We could still use another 70 or so responses and = so this is a final reminder to please help us by taking a few minutes to = complete the survey:

https://www.surveymonkey.com/r/T3SL7JF

Thanks in advance

--
Jay Daley
IETF Executive Director
exec-director@ietf.org

= --Apple-Mail=_72D5B370-13D2-4CF0-9A51-CAC293BB1FA1-- From nobody Sun Aug 9 10:49:48 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E90433A07AB; Sun, 9 Aug 2020 10:49:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Theresa Enghardt via Datatracker To: Cc: suit@ietf.org, draft-ietf-suit-architecture.all@ietf.org, last-call@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159699537789.3865.13936841170357877070@ietfa.amsl.com> Reply-To: Theresa Enghardt Date: Sun, 09 Aug 2020 10:49:37 -0700 Archived-At: Subject: [Suit] Genart last call review of draft-ietf-suit-architecture-11 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2020 17:49:38 -0000 Reviewer: Theresa Enghardt Review result: Almost Ready I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-suit-architecture-11 Reviewer: Theresa Enghardt Review Date: 2020-08-09 IETF LC End Date: 2020-08-14 IESG Telechat date: Not scheduled for a telechat Summary: Thank you for this work. This document is clear in the problem that it addresses and in specifying its approach. I just have a few minor clarification questions. Major issues: None. Minor issues: Section 1 I find the following paragraph a bit confusing: "While the standardization work has been informed by and optimised for firmware update use cases of Class 1 devices (according to the device class definitions in RFC 7228 [RFC7228]), there is nothing in the architecture that restricts its use to only these constrained IoT devices. Software update and delivery of arbitrary data, such as configuration information and keys, can equally be managed by manifests." The paragraph is about generalizing the work presented in this draft, but the first sentence suggests that it's about generalizing it to more devices, and the second sentence talks about different use cases, but indirectly: At this point, the reader does not yet know that this work is based on manifests, as this is the first occurence of the word "manifest" in the text. Therefore, it is not clear that "can be equally managed by manifests" refers to applying the architecture presented in this draft to other use cases. I suggest to change the second sentence to something like: "Moreover, this architecture is not limited to managing software updates, but can also be applied to managing the delivery of arbitrary data, such as configuration information and keys." Section 2 Status Tracker: Why does the IoT device itself "most likely not run a status tracker itself", even as the draft defines client-initiated updates? This sentence seems unnecessarily restrictive to me. This section introduces Trusted Execution Environments (TEEs) and points to draft-ietf-teep-architecture, but is not explicit about the relationship between SUIT and TEEP. I think it's worth adding one or two sentences explaining this relationship, i.e., does SUIT require TEEP, does TEEP require SUIT, do both complement each other but can be implemented independently, ...? Section 3.5. High reliability Here maybe it's worth adding another case to protect against, i.e., if the download is interrupted due to loss of network connectivity or if there's packet loss. It's not obvious to me where this case is included, as the "broadcast-friendly" requirement implies that these devices are not necessarily running TCP or another protocol that provides reliable in-order data delivery. Section 3.7. Small Parsers I think it's worth adding that this is about the parser of the manifest (if this is in fact the case), as this is not obvious from the context. Section 3.10. Operating modes This section presents steps a devices has to go through in the course of an update, while section 5 and section 9 also talk about different steps, and section 8 has additional steps, e.g., the bootloader has to check the integrity of a firmware image again before booting it. I think it's worth adding at least some cross-references, e.g., in Section 3.10, highlight that this is not an exhaustive list of steps, and that Section 9 has a more complete example including the the necessary checks. Section 4. Claims Why is this its own section? Isn't this just another term for Section 2, and/or just just another requirement for Section 3? Section 8. Bootloader I do not understand the following paragraph: "If the application image contains the firmware consumer functionality, as described above, then it is necessary that a working image is left on the device. This allows the bootloader to roll back to a working firmware image to execute a firmware download if the bootloader itself does not have enough functionality to fetch a firmware image plus manifest from a firmware server over the Internet." What is an application image? Is it different from a firmware image? And why does the firmware download have to be carried out from the bootloader here (with rollback to a previous image)? Hasn't the firmware already been downloaded at this point? There's probably some condition under which this needs to be done - please add it to the text. Nits/editorial comments: Section 7.4. Dual CPU, other bus "It is likely that one of the CPUs will be considered a master" s/master/primary/ From nobody Sun Aug 9 16:33:40 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7D453A0E70; Sun, 9 Aug 2020 16:33:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Bob Briscoe via Datatracker To: Cc: last-call@ietf.org, draft-ietf-suit-architecture.all@ietf.org, suit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159701600789.9734.7112047200124687933@ietfa.amsl.com> Reply-To: Bob Briscoe Date: Sun, 09 Aug 2020 16:33:27 -0700 Archived-At: Subject: [Suit] Tsvart last call review of draft-ietf-suit-architecture-11 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Aug 2020 23:33:28 -0000 Reviewer: Bob Briscoe Review result: Ready with Issues This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. This review is long. For the benefit of busy readers, it is structured with 7 important issues listed first (and tagged either as technical or editorial), followed by minor editorial comments for the authors. Altho' it is ostensibly from the Transport Area Review Team, this review identifies only one transport-related issue (see item #6a). Most of the major discussion points are offered with a security hat on. First I want to say that there's a lot of useful stuff in the draft. So I'd like to apologize that the review comments raise issues, and do not dwell on praising all the good stuff. == Important Issues == 1. Motivation for publication by the IETF [Editorial] Until I reached the summary of the recent IoT IAB workshop in the first para of the Security Considerations section, I was wondering why the IETF needed to publish this. It seemed to be a description of what is already done in the industry, but framed as an architecture. Most of this first para of the Security Considerations section motivates this work, and ought to be moved to the Introduction. Even then, a document that describes what the industry already does isn't a sufficient response to a security problem. Given (I believe) the intention is to encourage the industry to systematically cater for firmware updates, perhaps the draft needs to be a little more hard-hitting (without being patronizing of course). Rather than giving the impression (except in the abstract) that it is just describing current industry practice. For instance, see item #2 below about saying what not to do. I would also suggest that it should highlight the simplest architecture, only giving optional more complex extras later (see item #4 below). 2. Is Anything Not Allowed by this Architecture? [Technical+Editorial] a) A good architecture precludes as well as includes. Would it be useful to list some common practices that are insecure, and perhaps some common misconceptions about secure firmware update? b) I could hardly find anything in this draft that did not equally apply to firmware update of "Non-Things". It would indeed be useful to define a 'Thing' (at least what this document means by it). I suggest: * unattended operation * not within the operator's physical security control c) On the subject of ruling things out, I felt the list of items ruled out of scope in the Security Considerations include some items that are so central to IoT that they should not have been ruled out of scope, and in the first two cases quoted below, they didn't need to be ruled out of scope, because the document addresses them: " - installing firmware updates in a robust fashion so that the update does not break the device functionality of the environment this device operates in. - the distribution of the actual firmware update, potentially in an efficient manner to a large number of devices without human involvement - energy efficiency and battery lifetime considerations. " And, wouldn't it be better to move scoping statements to just after the Intro, rather than in Security Considerations? (And, yes, I know that not all Things are energy-challenged, but the size of the subset that are is significant.) 3. Relying on Software with Security Vulnerabilities to Patch Security Vulnerabilities [Technical] The Intro only mentions 'software updates' generally, and doesn't explicitly mention patching security vulnerabilities (altho the abstract does). Only having read the Security Considerations section, do I discover that the draft is primarily meant to be about patching firmware vulnerabilities. That raises the question of how secure it is to download new firmware from a device booted from firmware that is potentially already compromised. As a minimum, surely the draft needs to mention this point. And preferably: * whether anything can be trusted once firmware is compromised, and if so what. * whether it is still worth updating firmware, even once a vulnerability in the firmware update process has been identified, given: o identification of a vulnerability does not necessarily imply it has been exploited, or not prevalently exploited o a vulnerability might not make the firmware update process itself vulnerable (with an explanation of how to tell) * describe which aspects of the firmware update process need to be run within a TEE (and which not if any) * should the TEE lock the device against booting if a firmware authentication or integrity check fails o how to prevent tampering with firmware integrity from itself being used as an attack, e.g. - by ensuring that, once a device is locked against booting, firmware re-update is never completely disabled - by ensuring firmware updates are not immediately retried without an exponentially increasing timer back-off, otherwise retries could lead to the devices flooding their own network with fruitless update traffic. 4. Please Focus More on the Simplest Architecture [Technical] All the following increase system complexity, but are not /essential/ for strong security: a) Status Tracking Per Device b) Confidentiality of the firmware binary c) Robustness against rendering the device unbootable d) Supporting both Message Authentication and Object Authentication (see item #5) e) Broadcast Friendly (see item #6) This draft is meant to be persuading the 'industry of Things' to provide built-in secure firmware update. It tends to fall into the common trap of setting the security bar so high that practitioners might give up in despair. a) Per-device status tracking certainly might be preferred by many operators, but the alternative of the operator not knowing the status of each individual device might be acceptable (as in the example in Figure 5). Per-device status tracking introduces the following complexity: * a need to separately identify each device, both on each device, and in the status tracker. * a need to securely identify each separate device (to prevent compromised devices masquerading as all the other devices to give a false sense of security), requiring management of separate public or shared keys b) Confidentiality certainly might provide defence in depth against reverse engineering the binaries, but it is ultimately security by obscurity, and so ultimately optional. By definition (see item #2b) 'Things' are not in a physically secure environment. So, unless all devices decrypt all downloaded binaries within a TEE and store them in tamper-proof memory, once the binaries are stored on each device, they will be accessible to external inspection anyway. So the document should be less dogmatic about confidentiality protection (3rd para of Intro), and at least explain that, with IoT, confidentiality on the wire is moot unless there is also confidential device storage as well. c) Robustness against rendering the device unbootable Often, when I initiate an (attended) firmware update, the OS warns me that this is a sensitive process that could render the device useless if the power fails part-way through. So clearly, this is a cost-tradeoff that device designers are willing to compromise on. Therefore, I don't think the IETF is entitled to pronounce a requirement against this practice. I would rather see this text moved from Requirements to somewhere else in the doc, as a commentary on the implementation issues, rather than stating it as a requirement. Climbing down a bit at the end by saying it is only an implementation requirement doesn't help. 5. Both Message Authentication and Whole Object Authentication? [Technical] Message authentication codes aren't specifically mentioned, until sections 7 & 8, where they are mentioned as if they might be used, without saying why or how. The document needs to discuss the merits of MACs vs. authentication of the whole manifest and/or the whole firmware binary. Ultimately, if an object's authenticity and integrity will be verified once it is fully delivered, there is no need for MACs as well. However, using message authentication reduces the risk that the device is talking with an imposter at an early stage in the transmission, rather than having to wait until it is complete. And it is easy to arrange message authentication to cumulatively authenticate the whole object, without additional infrastructure for whole-object verification. Therefore using MACs could avoid the need to provide enough storage for a complete update of the firmware as well as the current version - after verifying the manifest and the first message, the device could even start to overwrite the firmware it is currently booted from. The above strategy would not be without risk, but my point is not just to suggest this particular strategy. The document ought to at least discuss the trade-offs between MACs and whole-objection authentication, and whether both are really necessary. 6. Friendly to Broadcast Delivery? [Technical] Section 3. states this as one of the "Requirements", although the text softens it to "may be desirable for some networks". However, broadcast delivery introduces the three significant problems below, wrt a) reliable transport; b) device energy efficiency; and c) broadcast message authentication. a) Reliable Broadcast Transport Delivery of binary objects needs to recover lost or corrupt packets. Reliable broadcast delivery at scale is extremely challenging. It needs either fountain coding [1] or reliable multicast. * Fountain coding delivers an object in a continually repeating stream and ensures that the data in any missing packet can be reconstructed from data in a subsequent different packet. But this would increase device complexity. * For broadcast delivery, per-packet acknowledgements (ACKs) from each device do not scale. Negative ACKs (NACKs) can be used but they also do not scale. If a loss is experienced close to the root of the broadcast/multicast, it still causes an implosion of negative ACKs (NACKs) on the sender. Reliable multicast (e.g. PGM [RFC3208]) arranges a spreading tree of delivery nodes each of which handles NACKs solely from its next-degree downstream neighbours. Clearly this increases network or CDN complexity. b) Broadcast Energy Efficiency If the IoT device is wireless and needs to take care with its energy consumption, it will need to initiate all communications, rather than have to sit with its radio powered up listening for an incoming message. However, of course, it is not possible for each device to independently initiate an incoming broadcast. It would be possible for a broadcast to be scheduled, and for each device to poll for the schedule. But this would add complexity, particularly because all the device clocks would have to be fairly closely synchronized. c) Broadcast Message Authentication Message authentication has potential advantages over whole-object authentication (see #5). When MACs are used over unicast, typically the cost of asymmetric crypto for each message is avoided by using asymmetric crypto just once to transmit a shared key, which is then used to verify each MAC. However, that process is only secure for unicast. For broadcast or multicast delivery, the sender only sends each message once, using one key for the MAC that would therefore have to be shared with every receiver. Then any receiver could masquerade as the genuine sender. TESLA is a solution to this [RFC4082], but it would again increase the complexity of each device and the servers, not least because it requires loose clock synch (nonetheless, uTESLA has been implemented for challenged devices [2]). Aside regarding broadcast encryption: In section 3.3. "Use state-of-the-art security mechanisms", it says: "The information that is encrypted individually for each device must maintain friendliness to Content Distribution Networks, bulk storage, and broadcast protocols." That implies a magic encyption scheme that is beyond any state-of-the-art that I am aware of! If information is encrypted individually for each device, surely by definition it will not be friendly to broadcast protocols. Actually, I suspect the authors did not mean to say "encrypted individually for each device", because a shared group key is adequate for confidentiality - a shared group key is only problematic for message or source authentication (see above). 7. Missing Security Concerns [Technical] a) Avoiding Reliance on the Device's System Clock I suggest that the document makes the point that it is preferable for the firmware update process not to rely on the device's system clock. Reasoning: Even if the TEE maintains the system clock, protection against attacks on this clock rely on voting between multiple time sources. No amount of authentication provides any proof of message timing. So, it is hard for a TEE to protect against tampering with the timing of its messages, given they pass via the untrusted execution environment of the rest of the device, similar to the problem of a secure time source for virtualized functions [3]. I think IoT developers can be reassured that none of the requirements for firmware update need to rely on the system clock. For instance roll-back attack prevention (section 3.4) only requires comparison between version numbers, not comparison between a release time and the clock. However, I think not relying on the clock is worth mentioning, because key expiry and key revocation have to be designed carefully to avoid relying on secure time, and this is a subtle point that might not be appreciated by IoT device designers. b) Key revocation When keys are in tamper-resistant storage but otherwise not within a physically secure site, the question of revocation surely has to be addressed. In particular, there should be a discussion about the advisability or otherwise of pre-loading the same keys into multiple devices. == Minor Editorial Issues == 1. Intro "Updates to the firmware of an IoT device are done to fix bugs in software..." This would be a good place to highlight the focus on patching security vulnerabilities. "This version of the document assumes... Future versions may also describe..." I assume this aspiration needs to be deleted now? 2. Terminology There are ~22 occurrences of lower case 'must' in this document, and one 'should' (excluding multiple uses in rhetorical questions). I'm not sure whether it is intentional to make it seem like this is an RFC that is mandating behaviour, perhaps for readers who don't understand the subtleties of the IETF informational track. I would prefer it to be clear that this document is not mandating anything, by using alternatives to 'must' like 'ought to' or 'has to'. Otherwise it could be considered disingenuous. "The term ’system on chip (SoC)’ is often used for these types of devices." Perhaps more useful: "The term ’system on chip (SoC)’ is often used interchangeably with MCU, but MCU tends to imply more limited peripheral functions." "The following entities are used:" The list is a mix of stakeholders and functions, which tends to show that the authors themselves might not be clear about the distinction. It would be useful to split into two lists. "The terms device and firmware consumer are used interchangeably since the firmware consumer is one software component running on an MCU on the device." I didn't notice them being used interchangeably. If they are anywhere, why not just edit to use whichever term is more appropriate and delete this sentence? Status Tracker "While the IoT device itself runs the client- side of the status tracker it will most likely not run a status tracker itself unless it acts as a proxy for other IoT devices in a protocol translation or edge computing device node." The client-side of a status tracker surely does run a status tracker itself (the clue is in the name). I know what is intended, but the writer was clearly in two minds as to whether a status tracker is the combination of client and server or just the server. 3. Requirements 3.5 "High reliability" -> 'Robust against becoming unbootable'. The title for this requirement otherwise implies a much more general requirement than the description under it. 3.6 Small bootloader "...again using firmware updates over serial, USB or even wireless connectivity like a limited version of Bluetooth Smart." Don't see why it has to be "...a limited version of...". Suggest these words are deleted. s/poses a risk in reliability/ /poses a reliability risk/ s/must fit in the available RAM/ /must fit in the available memory/ (not necessarily RAM) s|there are not other task/processing running| |there are not other tasks/processes running| s/unlike it may be the case/ /unlike that which may be the case/ s/Note: This is an implementation requirement./ /Note: This last paragraph is an implementation requirement./ (Otherwise, 'this' could ambiguously refer to the whole requirement) 3.7 Small Parsers "Since parsers are known sources of bugs they must be minimal." To be honest, I suspect the target audience will find this sentence and others like it rather pious. Given the purpose of this document is meant to be to encourage implementers to provide secure firmware update, I think these peripheral "requirements" will just serve to make any implementers reading this feel they are being patronized. As with the earlier requirement about 'robustness against becoming unbootable', I think many of these 'requirements' would be easier to stomach within a discussion of tradeoffs, rather than as a list of pronouncements that demand perfection. 3.8 s/Minimal impact on existing firmware formats/ /No impact on existing firmware formats/ Reason: This is what the text underneath says. 3.9 Robust permissions "...the authorization policy is separated from the underlying communication architecture. This is accomplished by separating the entities from their permissions." I'm not sure whether either of these sentences makes much sense (at least not to me). Perhaps the first sentence means to say that "...the authorization policy is separated from the firmware it applies to" And then the second sentence could be deleted. I'm not sure the second sentence would ever be necessary, because entities are always separate from their permissions (otherwise you would have to access an entity to find out you weren't allowed to access it). To be honest, I don't really see the point of the whole requirement. So if it is important, maybe its meaning needs to be clarified for people like me. Otherwise, if it's just stating the obvious, maybe it's not necessary at all. 3.10. Operating modes Later, in S.5. the term 'delivery modes' is used. If these are meant to mean the same thing, then the same term should be used consistently. In my experience, the term 'interaction model' is used to describe things like polled request-reply, push, publish-subscribe, etc. "The pre-authorisation step involves verifying..." When describing a distributed system, pls avoid passive sentences like this, which don't specify which entity is performing the action. It is followed up later by "...the firmware consumer must also...", which implies the subject is the firmware consumer, but it's best not to rely on implication, especially not if it requires two passes to understand. "Pushing a manifest and firmware image to the transfer to the Package resource of the LwM2M Firmware Update object" Garbled? "...it may need to wait for a trigger from the status tracker to initiate the installation, may trigger the update automatically, or may go through a more complex decision making process to determine the appropriate timing for an update" I had to read this a few times before realizing it was a list. How about: "... to initiate the installation, it may either need to wait for a trigger from the status tracker; or trigger the update automatically; or go through a more complex decision making process to determine the appropriate timing for an update" 3.11. s/Suitability to software and personalization data/ /Suitability for software and personalization data/ The document suddenly jumps into a different style at the start of 3.11, more like an log of WG activity than a requirement. Pls consider making the style consistent, especially given it switches back after the first sentence of the 2nd para. 4. Claims s/Only install firmware with a matching vendor/ /Only install firmware with a matching author/ ? 5. Communication Architecture The document often repeats that it's agnostic to the communication architecture, then this section starts with the phrase: "Figure 1 shows the communication architecture..." Perhaps it means 'firmware update architecture'? Or, possibly this implies that the authors are in two minds as to what 'communications architecture' means. Or the heading was intended to be 'Communications Architectures' (plural) and the first phrase was meant to say "Figure 1 shows an example communication architecture..." The text needs to make it clear that a status tracker is optional in the client pull case but not in the server push case (see item #4a earlier). It would be useful for the doc to say what it means for an operator circle to enclose a function. For instance the 'Device Operator' in Fig 1 encloses the status tracker, which to me implies it controls the status tracker. However, the network operator encloses the device, which probably doesn't imply it operates the device. Perhaps an enclosing circle means 'within the physical security control of'? The network operator isn't mentioned in the text - why is it in the diagram, given it has no role in the firmware update, other than as a common carrier of opaque bits? "The following assumptions are made to allow the firmware consumer to verify the received firmware image and manifest before updating software:" The following three bullets aren't really assumptions. Perhaps 'statements about the verification process' would be a better phrase. Would another reference to suit-information-model here be useful, to explain why the details are not given here? See item #4b) above about highlighting that confidentiality is optional, not just 'deployment specific'. "There are different types of delivery modes, which are illustrated based on examples below." Shouldn't this sentence start section 5? (Also see my earlier point about 'operating modes' / 'interaction modes' terminology). Fig 3 is inconsistent with Fig 1, in that it omits the firmware consumer function. Fig 4 is inconsistent with Figs 1 & 3, in that there is also an arrow from the status tracker to the author. What does this imply? "This architecture does not mandate a specific delivery mode but a solution must support both types. Whatever for? This requirement surely over-plays the IETF's hand, which is not in a position to make such a demand? Is the intention really that being agnostic to the delivery mode means every solution must support all delivery modes? 6. Manifest Given each of the items in the second bullet list addresses one of the questions in the first bullet list, it would be useful to tabulate them side-by-side and to put them in a more meaningful order, e.g. in the order they occur during firmware update. Also, the the first question bullet (author trust) is not specifically addressed in the second list - implied within the last bullet, but not explicitly stated. 7.1 s/Combined with the non-relocatable nature of the code/ /Due to the non-relocatable nature of the code/ 7.3 "This configuration has two or more CPUs in a single SoC that share memory (flash and RAM). Generally, they will be a protection mechanism to prevent one CPU from accessing the other’s memory." I know what is intended, but it reads as if line 1 contradicts line 3. Perhaps: "... mechanism to prevent one CPU from unintentionally accessing memory currently allocated to the other." 9. Example In at least one example figure, it would be useful to show the initial pre-loading of keys, policy logic and trust anchor into the firmware consumer / bootloader. s/starting with an author uploading the new firmware to firmware server/ /starting with an author uploading the new firmware to the firmware server/ "This setup does not use a status tracker and the firmware consumer component is therefore responsible for periodically checking whether a new firmware image is available for download." It needs to be much clearer that the status tracker has both a monitoring function and an update triggering function. So, altho it is essential in the server push model - to trigger updates, it's monitoring function means it is not ruled out for the client pull model. Fig 5 & 6 are inconsistent, in that the former omits the IoT device box around the Firmware consumer and bootloader. s/Figure 6 shows an example follow with the device using a status tracker./ /Figure 6 shows an example with the device using a status tracker./ "For editorial reasons the author publishing the manifest at the status tracker and the firmware image at the firmware server is not shown." How about: "Depiction of the author publishing the manifest at the status tracker and the firmware image at the firmware server would be the same as in Figure 5. So for brevity they are not shown." 11. Security Considerations Between "A report about this workshop can be found at [RFC8240]." and "A standardized firmware manifest format..." there either needs to be some glue text to explain that the initial manifest format was an output of the workshop (if it was), or a new para if the second sentence really doesn't follow from the first. Note also that I suggest (item #1) that the motivating text about the workshop should be moved to the introduction. I also say (in item 2c) that the scoping bullets would be better at the end of the Intro too. However, I can also see a case for them remaining under Security Considerations; to admit that the document does not fully address all possible security concerns. Given this could leave nothing in the Security Considerations section, it would be appropriate to merely point to all the sections of the document that already cover security matters. == References == [1] Byers, J.; Luby, M.; Mitzenmacher, M. & Rege, A. A Digital Fountain Approach to Reliable Distribution of Bulk Data Proc. ACM SIGCOMM'98, Computer Communication Review, 1998, 28 [2] Perrig, A.; Szewczyk, R.; Wen, V.; Culler, D. E. & Tygar, J. D. SPINS: Security Protocols for Sensor Networks Proc. ACM International Conference on Mobile Computing and Networks (Mobicom'01), 2001, 189-199 [3] Briscoe (Ed.), B. & others Network Functions Virtualisation; Security; Problem Statement ETSI NFV Industry Specification Group (ISG), ETSI NFV Industry Specification Group (ISG), 2014 From nobody Mon Aug 10 09:14:26 2020 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 DE59D3A0854 for ; Mon, 10 Aug 2020 09:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PI1MWEseuEcV for ; Mon, 10 Aug 2020 09:14:22 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A0A3A084A for ; Mon, 10 Aug 2020 09:14:22 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id DF101389DC; Mon, 10 Aug 2020 11:53:35 -0400 (EDT) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RVbZyDU1vJyS; Mon, 10 Aug 2020 11:53:34 -0400 (EDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 68EB0389DB; Mon, 10 Aug 2020 11:53:34 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E4479724; Mon, 10 Aug 2020 12:14:17 -0400 (EDT) From: Michael Richardson To: Brendan Moran cc: suit In-Reply-To: <7C066E44-8C55-4229-993A-28FD0572992B@arm.com> References: <7C066E44-8C55-4229-993A-28FD0572992B@arm.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Suit] Packed CBOR X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2020 16:14:25 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Brendan Moran wrote: > On Monday, Carsten presented Packed CBOR (draft-bormann-cbor-packed-0= 0) > at the CBOR working group, which adopted it. This is an extension to > the CBOR standard (RFC7049) that enables =E2=80=9Cpacking=E2=80=9D of= CBOR objects > using a CBOR-based dictionary compression scheme. ... given 10 days since this discussion started... I am enthusiastic about Packed CBOR. But! > If we were to adopt it now, this would cause two substantial changes = in SUIT: > 1. Removing several existing SUIT deduplication mechanisms. > 2. Placing a dependency on draft-ietf-cbor-packed-00. > Both of these would delay SUIT. And the delay would be hard to predict at this point. The architecture is up for the call this Thursday, and it seems that the Information Model ought to follow "suit" (pun intended) very soon. I believe that we pretty close to done? And I think the market is waiting. > It would have benefits: > 1. Simplify the manifest structure (complexity moved to packed cbor) > 2. Make the manifest smaller Given that the network impact of firmware is likely dominated by the firmwa= re itself, saving bytes on the wire does not seem worth the hassle. As we have a partial solution, how much savings in the manifest itself woul= d occur? The major benefit in my opinion is really (1). We get the benefit of research into better compression mechanisms. This also simplifies the effort on the part of auditing entities to comprehend the variety of manifests they get. From=20the point of view of the third party entities, the out-of-band dictionary is the archilles of this proposal: will we (SUIT) have a standard dictionary? Will it be vendor specific? Will specific verticals (TEEP) adopt a dictionary? Should the SUIT manifest establish a specific CBOR version which it expects full support for? I think so. > I see several options ahead of us: > 1. Make no change, apply packed CBOR as and when it makes sense. > 2. Make no change now, but plan for a v2 SUIT manifest draft > 3. Adopt packed CBOR & simplify manifest now. > Option 1 is somewhat problematic in that it splits the ecosystem we= =E2=80=99re > trying to create. Option 2 does the same, but provides more benefits.= 2 > is arguably more detectable, since it=E2=80=99s easier to report mani= fest v2 > support, than to report support for a specific CBOR tag within the SU= IT > Manifest Processor. Option 2 is the best. When you say we have re-invented things, do you speak only about Common (5.4.2 and 8.7.2)? In the current document, it could be worth adding some text like: Future evolution of CBOR may include generic mechanisms to do compression, such as [non-normative-reference-to-CBOR-Packed]. Manufacturers can decide to leverage new mechanisms as soon as the devices for which they are providing updates implement the appropriate decoders in their update process. Or maybe we do not say this, but rather this is a reason to bump suit-manifest-version in the future. It might be worth some text in 8.6.1 about what to do if you see Version 2. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl8xclkACgkQgItw+93Q 3WWUhQgAgTRapF+Vdrh5YdynsFgtdMuWgT+gx1j1mmY38ZuXjWq4QAkFGI5d/UPb jKEDI9WF95UMXGonhyKAe/K4g+xrF1mTLx/oVYt6mtNizpkpYY4VugT/pl+25N1L z5CImVehlZ2EpKImhNu48XW7Kc6nFb0dcXSMNht1sXnCyypltXLGb5GWnj6xAy70 7sbS/JD+zNnIqYJKpH0AggZOaWvwB5KnGDl9reWYYDv9PqoSCOmAByJuJ3Qwbgue CLo+VMbd8eCI316rS4fxGYAMC0nO+q9bqzavWiisEM3cMlTkcBEdmcO7QLC8fOQ9 gXb+VceqfxkJ1I2p/XPezlCO2C5tQg== =qwhx -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Aug 11 05:50:41 2020 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 B12013A1045; Tue, 11 Aug 2020 05:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.048 X-Spam-Level: X-Spam-Status: No, score=-3.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.949, SPF_HELO_FAIL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=bobbriscoe.net 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 YTTb7fHzQ7eX; Tue, 11 Aug 2020 05:50:35 -0700 (PDT) Received: from cl3.bcs-hosting.net (cl3.bcs-hosting.net [3.11.37.202]) (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 7C7F23A1044; Tue, 11 Aug 2020 05:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bobbriscoe.net; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=irfW56tut+wjI19OT1d2iipJNqmNrvWUHMdoxCqpetM=; b=2GdEJp78q1NqFF45otniabAmMU 3swAtxLFZ0g+WVdW679Fzz+cXLJ4la+dzc0CNt0QVS7gDqKxCZ9vFi3kzbASLpYn4qNl19Rgojoc/ NmCcbWZ8ZWjHLroG1gvIo6lV239rGPnvATN2yrF1jjt+rzFaZ2BiEzxkmHUiu3xAldQDycgXIBJ/3 PdmQNqTi1Yb5EGh6ekMpqtGg0BN9G6K05xEkZhDnP8TwelkrwsWqUXPZalE03y3VwUYC9AOfKyeFP YS5Ln03P/NsJGAQ+W4ZdwHXKEok1vlkpcG+BK/wADO61R1KZ462tT58JMg9Utyp4adNLf2pJL6sAO DIsEoPWg==; Received: from [31.185.135.177] (port=49332 helo=[192.168.0.6]) by cl3.bcs-hosting.net with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from ) id 1k5Tjc-004S31-3k; Tue, 11 Aug 2020 13:50:32 +0100 To: Bob Briscoe , tsv-art@ietf.org Cc: last-call@ietf.org, draft-ietf-suit-architecture.all@ietf.org, suit@ietf.org References: <159701600789.9734.7112047200124687933@ietfa.amsl.com> From: Bob Briscoe Message-ID: <214f0c65-8d04-a168-3781-d2c38e6b0477@bobbriscoe.net> Date: Tue, 11 Aug 2020 13:50:31 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <159701600789.9734.7112047200124687933@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - cl3.bcs-hosting.net X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: cl3.bcs-hosting.net: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: cl3.bcs-hosting.net: in@bobbriscoe.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Suit] [Tsv-art] Tsvart last call review of draft-ietf-suit-architecture-11 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2020 12:50:39 -0000 I notice that the review upload process has munged some of the line wrap. I've re-instated it below. On 10/08/2020 00:33, Bob Briscoe via Datatracker wrote: > Reviewer: Bob Briscoe > Review result: Ready with Issues > > This document has been reviewed as part of the transport area review team's > ongoing effort to review key IETF documents. These comments were written > primarily for the transport area directors, but are copied to the document's > authors and WG to allow them to address any issues raised and also to the IETF > discussion list for information. > > When done at the time of IETF Last Call, the authors should consider this > review as part of the last-call comments they receive. Please always CC > tsv-art@ietf.org if you reply to or forward this review. > > This review is long. For the benefit of busy readers, it is structured with 7 > important issues listed first (and tagged either as technical or editorial), > followed by minor editorial comments for the authors. > > Altho' it is ostensibly from the Transport Area Review Team, this review > identifies only one transport-related issue (see item #6a). Most of the major > discussion points are offered with a security hat on. > > First I want to say that there's a lot of useful stuff in the draft. So I'd > like to apologize that the review comments raise issues, and do not dwell on > praising all the good stuff. > > == Important Issues == > > 1. Motivation for publication by the IETF [Editorial] > > Until I reached the summary of the recent IoT IAB workshop in the first para of > the Security Considerations section, I was wondering why the IETF needed to > publish this. It seemed to be a description of what is already done in the > industry, but framed as an architecture. Most of this first para of the > Security Considerations section motivates this work, and ought to be moved to > the Introduction. > > Even then, a document that describes what the industry already does isn't a > sufficient response to a security problem. Given (I believe) the intention is > to encourage the industry to systematically cater for firmware updates, perhaps > the draft needs to be a little more hard-hitting (without being patronizing of > course). Rather than giving the impression (except in the abstract) that it is > just describing current industry practice. For instance, see item #2 below > about saying what not to do. I would also suggest that it should highlight the > simplest architecture, only giving optional more complex extras later (see item > #4 below). > > 2. Is Anything Not Allowed by this Architecture? [Technical+Editorial] > > a) A good architecture precludes as well as includes. Would it be useful to > list some common practices that are insecure, and perhaps some common > misconceptions about secure firmware update? > > b) I could hardly find anything in this draft that did not equally apply to > firmware update of "Non-Things". It would indeed be useful to define a 'Thing' > (at least what this document means by it). I suggest: > * unattended operation > * not within the operator's physical security control > > c) On the subject of ruling things out, I felt the list of items ruled out of > scope in the Security Considerations include some items that are so central to > IoT that they should not have been ruled out of scope, and in the first two > cases quoted below, they didn't need to be ruled out of scope, because the > document addresses them: > " > - installing firmware updates in a robust fashion so that the update > does not break the device functionality of the environment this > device operates in. > - the distribution of the actual firmware update, potentially in an > efficient manner to a large number of devices without human > involvement > - energy efficiency and battery lifetime considerations. > " > And, wouldn't it be better to move scoping statements to just after the Intro, > rather than in Security Considerations? (And, yes, I know that not all Things > are energy-challenged, but the size of the subset that are is significant.) > > 3. Relying on Software with Security Vulnerabilities to Patch Security > Vulnerabilities [Technical] > > The Intro only mentions 'software updates' generally, and doesn't explicitly > mention patching security vulnerabilities (altho the abstract does). Only > having read the Security Considerations section, do I discover that the draft > is primarily meant to be about patching firmware vulnerabilities. > > That raises the question of how secure it is to download new firmware from a > device booted from firmware that is potentially already compromised. As a > minimum, surely the draft needs to mention this point. And preferably: > * whether anything can be trusted once firmware is compromised, and if so what. > * whether it is still worth updating firmware, even once a vulnerability in the > firmware update process has been identified, given: > o identification of a vulnerability does not necessarily imply it has been > exploited, or not prevalently exploited > o a vulnerability might not make the firmware update process itself > vulnerable (with an explanation of how to tell) > * describe which aspects of the firmware update process need to be run within a > TEE (and which not if any) > * should the TEE lock the device against booting if a firmware authentication > or integrity check fails > o how to prevent tampering with firmware integrity from itself being used as > an attack, e.g. > - by ensuring that, once a device is locked against booting, firmware > re-update is never completely disabled > - by ensuring firmware updates are not immediately retried without an > exponentially increasing timer back-off, otherwise retries could lead to > the devices flooding their own network with fruitless update traffic. > > 4. Please Focus More on the Simplest Architecture [Technical] > > All the following increase system complexity, but are not /essential/ for > strong security: > a) Status Tracking Per Device > b) Confidentiality of the firmware binary > c) Robustness against rendering the device unbootable > d) Supporting both Message Authentication and Object Authentication (see item > #5) > e) Broadcast Friendly (see item #6) > > This draft is meant to be persuading the 'industry of Things' to provide > built-in secure firmware update. It tends to fall into the common trap of > setting the security bar so high that practitioners might give up in despair. > > a) Per-device status tracking certainly might be preferred by many operators, > but the alternative of the operator not knowing the status of each individual > device might be acceptable (as in the example in Figure 5). Per-device status > tracking introduces the following complexity: > * a need to separately identify each device, both on each device, and in the > status tracker. > * a need to securely identify each separate device (to prevent compromised > devices masquerading as all the other devices to give a false sense of > security), requiring management of separate public or shared keys > > b) Confidentiality certainly might provide defence in depth against reverse > engineering the binaries, but it is ultimately security by obscurity, and so > ultimately optional. By definition (see item #2b) 'Things' are not in a > physically secure environment. So, unless all devices decrypt all downloaded > binaries within a TEE and store them in tamper-proof memory, once the binaries > are stored on each device, they will be accessible to external inspection > anyway. So the document should be less dogmatic about confidentiality > protection (3rd para of Intro), and at least explain that, with IoT, > confidentiality on the wire is moot unless there is also confidential device > storage as well. > > c) Robustness against rendering the device unbootable > Often, when I initiate an (attended) firmware update, the OS warns me that this > is a sensitive process that could render the device useless if the power fails > part-way through. So clearly, this is a cost-tradeoff that device designers are > willing to compromise on. Therefore, I don't think the IETF is entitled to > pronounce a requirement against this practice. I would rather see this text > moved from Requirements to somewhere else in the doc, as a commentary on the > implementation issues, rather than stating it as a requirement. Climbing down a > bit at the end by saying it is only an implementation requirement doesn't help. > > 5. Both Message Authentication and Whole Object Authentication? [Technical] > > Message authentication codes aren't specifically mentioned, until sections 7 & > 8, where they are mentioned as if they might be used, without saying why or > how. The document needs to discuss the merits of MACs vs. authentication of the > whole manifest and/or the whole firmware binary. > > Ultimately, if an object's authenticity and integrity will be verified once it > is fully delivered, there is no need for MACs as well. However, using message > authentication reduces the risk that the device is talking with an imposter at > an early stage in the transmission, rather than having to wait until it is > complete. And it is easy to arrange message authentication to cumulatively > authenticate the whole object, without additional infrastructure for > whole-object verification. Therefore using MACs could avoid the need to provide > enough storage for a complete update of the firmware as well as the current > version - after verifying the manifest and the first message, the device could > even start to overwrite the firmware it is currently booted from. > > The above strategy would not be without risk, but my point is not just to > suggest this particular strategy. The document ought to at least discuss the > trade-offs between MACs and whole-objection authentication, and whether both > are really necessary. > > 6. Friendly to Broadcast Delivery? [Technical] > > Section 3. states this as one of the "Requirements", although the text softens > it to "may be desirable for some networks". However, broadcast delivery > introduces the three significant problems below, wrt a) reliable transport; b) > device energy efficiency; and c) broadcast message authentication. > > a) Reliable Broadcast Transport > Delivery of binary objects needs to recover lost or corrupt packets. Reliable > broadcast delivery at scale is extremely challenging. It needs either fountain > coding [1] or reliable multicast. > * Fountain coding delivers an object in a continually repeating stream and > ensures that the data in any missing packet can be reconstructed from data in > a subsequent different packet. But this would increase device complexity. > * For broadcast delivery, per-packet acknowledgements (ACKs) from each device > do not scale. Negative ACKs (NACKs) can be used but they also do not scale. If > a loss is experienced close to the root of the broadcast/multicast, it still > causes an implosion of negative ACKs (NACKs) on the sender. Reliable multicast > (e.g. PGM [RFC3208]) arranges a spreading tree of delivery nodes each of which > handles NACKs solely from its next-degree downstream neighbours. Clearly this > increases network or CDN complexity. > > b) Broadcast Energy Efficiency > If the IoT device is wireless and needs to take care with its energy > consumption, it will need to initiate all communications, rather than have to > sit with its radio powered up listening for an incoming message. However, of > course, it is not possible for each device to independently initiate an > incoming broadcast. It would be possible for a broadcast to be scheduled, and > for each device to poll for the schedule. But this would add complexity, > particularly because all the device clocks would have to be fairly closely > synchronized. > > c) Broadcast Message Authentication > Message authentication has potential advantages over whole-object > authentication (see #5). When MACs are used over unicast, typically the cost of > asymmetric crypto for each message is avoided by using asymmetric crypto just > once to transmit a shared key, which is then used to verify each MAC. However, > that process is only secure for unicast. For broadcast or multicast delivery, > the sender only sends each message once, using one key for the MAC that would > therefore have to be shared with every receiver. Then any receiver could > masquerade as the genuine sender. TESLA is a solution to this [RFC4082], but it > would again increase the complexity of each device and the servers, not least > because it requires loose clock synch (nonetheless, uTESLA has been implemented > for challenged devices [2]). > > Aside regarding broadcast encryption: > In section 3.3. "Use state-of-the-art security mechanisms", it says: > "The information that is encrypted individually for each device must > maintain friendliness to Content Distribution Networks, bulk storage, > and broadcast protocols." > That implies a magic encyption scheme that is beyond any state-of-the-art that > I am aware of! If information is encrypted individually for each device, surely > by definition it will not be friendly to broadcast protocols. Actually, I > suspect the authors did not mean to say "encrypted individually for each > device", because a shared group key is adequate for confidentiality - a shared > group key is only problematic for message or source authentication (see above). > > 7. Missing Security Concerns [Technical] > > a) Avoiding Reliance on the Device's System Clock > > I suggest that the document makes the point that it is preferable for the > firmware update process not to rely on the device's system clock. > > Reasoning: Even if the TEE maintains the system clock, protection against > attacks on this clock rely on voting between multiple time sources. No amount > of authentication provides any proof of message timing. So, it is hard for a > TEE to protect against tampering with the timing of its messages, given they > pass via the untrusted execution environment of the rest of the device, similar > to the problem of a secure time source for virtualized functions [3]. > > I think IoT developers can be reassured that none of the requirements for > firmware update need to rely on the system clock. For instance roll-back attack > prevention (section 3.4) only requires comparison between version numbers, not > comparison between a release time and the clock. > > However, I think not relying on the clock is worth mentioning, because key > expiry and key revocation have to be designed carefully to avoid relying on > secure time, and this is a subtle point that might not be appreciated by IoT > device designers. > > b) Key revocation > > When keys are in tamper-resistant storage but otherwise not within a physically > secure site, the question of revocation surely has to be addressed. In > particular, there should be a discussion about the advisability or otherwise of > pre-loading the same keys into multiple devices. > > == Minor Editorial Issues == > > 1. Intro > "Updates to the firmware of an IoT device are done to fix bugs in software..." > This would be a good place to highlight the focus on patching security > vulnerabilities. > > "This version of the document assumes... Future versions may also describe..." > I assume this aspiration needs to be deleted now? > > 2. Terminology > > There are ~22 occurrences of lower case 'must' in this document, and one > 'should' (excluding multiple uses in rhetorical questions). I'm not sure > whether it is intentional to make it seem like this is an RFC that is mandating > behaviour, perhaps for readers who don't understand the subtleties of the IETF > informational track. I would prefer it to be clear that this document is not > mandating anything, by using alternatives to 'must' like 'ought to' or 'has > to'. Otherwise it could be considered disingenuous. > > "The term ’system on chip (SoC)’ is often used for these types of devices." > Perhaps more useful: > "The term ’system on chip (SoC)’ is often used interchangeably with MCU, but > MCU tends to imply more limited peripheral functions." > > "The following entities are used:" > The list is a mix of stakeholders and functions, which tends to show that the > authors themselves might not be clear about the distinction. It would be useful > to split into two lists. > > "The terms device and > firmware consumer are used interchangeably since the firmware > consumer is one software component running on an MCU on the > device." > I didn't notice them being used interchangeably. If they are anywhere, why not > just edit to use whichever term is more appropriate and delete this sentence? > > Status Tracker > "While the IoT device itself runs the client- > side of the status tracker it will most likely not run a status > tracker itself unless it acts as a proxy for other IoT devices in > a protocol translation or edge computing device node." > The client-side of a status tracker surely does run a status tracker itself > (the clue is in the name). I know what is intended, but the writer was clearly > in two minds as to whether a status tracker is the combination of client and > server or just the server. > > 3. Requirements > > 3.5 "High reliability" -> 'Robust against becoming unbootable'. > The title for this requirement otherwise implies a much more general > requirement than the description under it. > > 3.6 Small bootloader > "...again using firmware updates over serial, > USB or even wireless connectivity like a limited version of > Bluetooth Smart." > Don't see why it has to be "...a limited version of...". Suggest these words > are deleted. > > s/poses a risk in reliability/ > /poses a reliability risk/ > > s/must fit in the available RAM/ > /must fit in the available memory/ > (not necessarily RAM) > > s|there are not other task/processing running| > |there are not other tasks/processes running| > > s/unlike it may be the case/ > /unlike that which may be the case/ > > s/Note: This is an implementation requirement./ > /Note: This last paragraph is an implementation requirement./ > (Otherwise, 'this' could ambiguously refer to the whole requirement) > > 3.7 Small Parsers > "Since parsers are known sources of bugs they must be minimal." > To be honest, I suspect the target audience will find this sentence and others > like it rather pious. Given the purpose of this document is meant to be to > encourage implementers to provide secure firmware update, I think these > peripheral "requirements" will just serve to make any implementers reading this > feel they are being patronized. > > As with the earlier requirement about 'robustness against becoming unbootable', > I think many of these 'requirements' would be easier to stomach within a > discussion of tradeoffs, rather than as a list of pronouncements that demand > perfection. > > 3.8 > s/Minimal impact on existing firmware formats/ > /No impact on existing firmware formats/ > Reason: This is what the text underneath says. > > 3.9 Robust permissions > > "...the authorization policy is separated from the > underlying communication architecture. This is accomplished by > separating the entities from their permissions." > I'm not sure whether either of these sentences makes much sense (at least not > to me). Perhaps the first sentence means to say that > "...the authorization policy is separated from the > firmware it applies to" > And then the second sentence could be deleted. I'm not sure the second sentence > would ever be necessary, because entities are always separate from their > permissions (otherwise you would have to access an entity to find out you > weren't allowed to access it). To be honest, I don't really see the point of > the whole requirement. So if it is important, maybe its meaning needs to be > clarified for people like me. Otherwise, if it's just stating the obvious, > maybe it's not necessary at all. > > 3.10. Operating modes > Later, in S.5. the term 'delivery modes' is used. If these are meant to mean > the same thing, then the same term should be used consistently. In my > experience, the term 'interaction model' is used to describe things like polled > request-reply, push, publish-subscribe, etc. > > "The pre-authorisation step involves verifying..." > When describing a distributed system, pls avoid passive sentences like this, > which don't specify which entity is performing the action. It is followed up > later by "...the firmware consumer must also...", which implies the subject is > the firmware consumer, but it's best not to rely on implication, especially not > if it requires two passes to understand. > > "Pushing a manifest and firmware image to the transfer to > the Package resource of the LwM2M Firmware Update object" > Garbled? > > "...it may need to wait for a trigger from the > status tracker to initiate the installation, may trigger the update > automatically, or may go through a more complex decision making > process to determine the appropriate timing for an update" > I had to read this a few times before realizing it was a list. > How about: > "... to initiate the installation, it may either need to wait for a trigger > from the status tracker; or trigger the update automatically; or go through a > more complex decision making process to determine the appropriate timing for > an update" > > 3.11. > s/Suitability to software and personalization data/ > /Suitability for software and personalization data/ > > The document suddenly jumps into a different style at the start of 3.11, more > like an log of WG activity than a requirement. Pls consider making the style > consistent, especially given it switches back after the first sentence of the > 2nd para. > > 4. Claims > s/Only install firmware with a matching vendor/ > /Only install firmware with a matching author/ ? > > 5. Communication Architecture > > The document often repeats that it's agnostic to the communication > architecture, then this section starts with the phrase: > "Figure 1 shows the communication architecture..." > Perhaps it means 'firmware update architecture'? > Or, possibly this implies that the authors are in two minds as to what > 'communications architecture' means. Or the heading was intended to be > 'Communications Architectures' (plural) and the first phrase was meant to say > "Figure 1 shows an example communication architecture..." > > The text needs to make it clear that a status tracker is optional in the client > pull case but not in the server push case (see item #4a earlier). > > It would be useful for the doc to say what it means for an operator circle to > enclose a function. For instance the 'Device Operator' in Fig 1 encloses the > status tracker, which to me implies it controls the status tracker. However, > the network operator encloses the device, which probably doesn't imply it > operates the device. Perhaps an enclosing circle means 'within the physical > security control of'? The network operator isn't mentioned in the text - why is > it in the diagram, given it has no role in the firmware update, other than as a > common carrier of opaque bits? > > "The following assumptions are made to allow the firmware consumer to > verify the received firmware image and manifest before updating > software:" > The following three bullets aren't really assumptions. Perhaps 'statements > about the verification process' would be a better phrase. Would another > reference to suit-information-model here be useful, to explain why the details > are not given here? > > See item #4b) above about highlighting that confidentiality is optional, not > just 'deployment specific'. > > "There are different types of delivery modes, which are illustrated > based on examples below." > Shouldn't this sentence start section 5? (Also see my earlier point about > 'operating modes' / 'interaction modes' terminology). > > Fig 3 is inconsistent with Fig 1, in that it omits the firmware consumer > function. > > Fig 4 is inconsistent with Figs 1 & 3, in that there is also an arrow from the > status tracker to the author. What does this imply? > > "This architecture does not mandate a specific delivery mode but a > solution must support both types. > Whatever for? This requirement surely over-plays the IETF's hand, which is not > in a position to make such a demand? Is the intention really that being > agnostic to the delivery mode means every solution must support all delivery > modes? > > 6. Manifest > > Given each of the items in the second bullet list addresses one of the > questions in the first bullet list, it would be useful to tabulate them > side-by-side and to put them in a more meaningful order, e.g. in the order they > occur during firmware update. Also, the the first question bullet (author > trust) is not specifically addressed in the second list - implied within the > last bullet, but not explicitly stated. > > 7.1 > s/Combined with the non-relocatable nature of the code/ > /Due to the non-relocatable nature of the code/ > > 7.3 > "This configuration has two or more CPUs in a single SoC that share > memory (flash and RAM). Generally, they will be a protection > mechanism to prevent one CPU from accessing the other’s memory." > I know what is intended, but it reads as if line 1 contradicts line 3. Perhaps: > "... > mechanism to prevent one CPU from unintentionally accessing memory currently > allocated to the other." > > 9. Example > > In at least one example figure, it would be useful to show the initial > pre-loading of keys, policy logic and trust anchor into the firmware consumer / > bootloader. > > s/starting with an author uploading the new firmware to firmware server/ > /starting with an author uploading the new firmware to the firmware server/ > > "This setup does > not use a status tracker and the firmware consumer component is > therefore responsible for periodically checking whether a new > firmware image is available for download." > It needs to be much clearer that the status tracker has both a monitoring > function and an update triggering function. So, altho it is essential in the > server push model - to trigger updates, it's monitoring function means it is > not ruled out for the client pull model. > > Fig 5 & 6 are inconsistent, in that the former omits the IoT device box around > the Firmware consumer and bootloader. > > s/Figure 6 shows an example follow with the device using a status tracker./ > /Figure 6 shows an example with the device using a status tracker./ > > "For editorial reasons the author publishing the manifest at > the status tracker and the firmware image at the firmware server is > not shown." > How about: > "Depiction of the author publishing the manifest at > the status tracker and the firmware image at the firmware server would > be the same as in Figure 5. So for brevity they are not shown." > > 11. Security Considerations > > Between > "A report about this workshop can be found at [RFC8240]." > and > "A standardized firmware manifest format..." > there either needs to be some glue text to explain that the initial manifest > format was an output of the workshop (if it was), or a new para if the second > sentence really doesn't follow from the first. > > Note also that I suggest (item #1) that the motivating text about the workshop > should be moved to the introduction. I also say (in item 2c) that the scoping > bullets would be better at the end of the Intro too. However, I can also see a > case for them remaining under Security Considerations; to admit that the > document does not fully address all possible security concerns. > > Given this could leave nothing in the Security Considerations section, it would > be appropriate to merely point to all the sections of the document that already > cover security matters. > > == References == > [1] Byers, J.; Luby, M.; Mitzenmacher, M. & Rege, A. A Digital Fountain > Approach to Reliable Distribution of Bulk Data Proc. ACM SIGCOMM'98, Computer > Communication Review, 1998, 28 > > [2] Perrig, A.; Szewczyk, R.; Wen, V.; Culler, D. E. & Tygar, J. D. SPINS: > Security Protocols for Sensor Networks Proc. ACM International Conference on > Mobile Computing and Networks (Mobicom'01), 2001, 189-199 > > [3] Briscoe (Ed.), B. & others Network Functions Virtualisation; Security; > Problem Statement ETSI NFV Industry Specification Group (ISG), ETSI NFV > Industry Specification Group (ISG), 2014 > > > > _______________________________________________ > Tsv-art mailing list > Tsv-art@ietf.org > https://www.ietf.org/mailman/listinfo/tsv-art -- ________________________________________________________________ Bob Briscoe http://bobbriscoe.net/ From nobody Thu Aug 13 08:13:16 2020 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 488ED3A0CD3 for ; Thu, 13 Aug 2020 08:13:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.899 X-Spam-Level: X-Spam-Status: No, score=-0.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PDS_TONAME_EQ_TOLOCAL_VSHORT=0.998, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 JDE1gAMe2TW8 for ; Thu, 13 Aug 2020 08:13:14 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E36D83A0CD0 for ; Thu, 13 Aug 2020 08:13:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 8A30D300B39 for ; Thu, 13 Aug 2020 11:13:11 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7iHgFeKxI3d0 for ; Thu, 13 Aug 2020 11:13:10 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-141-156-161-153.washdc.fios.verizon.net [141.156.161.153]) by mail.smeinc.net (Postfix) with ESMTPSA id AA12430009A for ; Thu, 13 Aug 2020 11:13:10 -0400 (EDT) From: Russ Housley Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\)) Message-Id: <8E3F2920-824B-4007-9183-3F63FAF2A6C3@vigilsec.com> Date: Thu, 13 Aug 2020 11:13:12 -0400 To: suit X-Mailer: Apple Mail (2.3445.104.15) Archived-At: Subject: [Suit] Minutes for SUIT Session at IETF 108 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 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, 13 Aug 2020 15:13:15 -0000 https://www.ietf.org/proceedings/108/minutes/minutes-108-suit-00 Please post any corrections to the mail list. Russ From nobody Thu Aug 27 09:11:27 2020 Return-Path: X-Original-To: suit@ietf.org Delivered-To: suit@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D29E3A0FE9; Thu, 27 Aug 2020 09:11:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz via Datatracker To: Cc: last-call@ietf.org, draft-ietf-suit-architecture.all@ietf.org, suit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.14.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <159854468417.31349.14137152546699566319@ietfa.amsl.com> Reply-To: Rich Salz Date: Thu, 27 Aug 2020 09:11:24 -0700 Archived-At: Subject: [Suit] Secdir last call review of draft-ietf-suit-architecture-11 X-BeenThere: suit@ietf.org X-Mailman-Version: 2.1.29 List-Id: Software Updates for Internet of Things List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2020 16:11:25 -0000 Reviewer: Rich Salz Review result: Ready The security directorate tries to review all IETF documents prior to IESG review. This should be considered as input to the security AD's, or otherwise general Last Call comments. I apologize for the lateness of this review. Hopefully since a new draft is expected, this might be useful anyway. This is READY (reasonable folks may disagree of course). There are no nits that aren't already covered. I have some suggestions: - I wish the terminology were in alphabetical order. - The requirements list should say "each is covered in more detail in the following subsections" or similar. The topic, updating firmware on IoT devices, is very important. The document defines requirements, explains why, and then describes an architecture that could meet those requirements. Examples cover a variety of instantiations. I think this is the first time I have seen a ladder diagram for processing steps, as opposed to protocol interchanges. This is a very well-written document.