From nobody Tue Apr 9 14:52:09 2019 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 8CDC2120454; Tue, 9 Apr 2019 14:52:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: suit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: suit@ietf.org Message-ID: <155484672749.19570.11675950479604491890@ietfa.amsl.com> Date: Tue, 09 Apr 2019 14:52:07 -0700 Archived-At: Subject: [Suit] I-D Action: draft-ietf-suit-architecture-05.txt 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: Tue, 09 Apr 2019 21:52:08 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Software Updates for Internet of Things WG of the IETF. Title : A Firmware Update Architecture for Internet of Things Devices Authors : Brendan Moran Milosch Meriac Hannes Tschofenig David Brown Filename : draft-ietf-suit-architecture-05.txt Pages : 25 Date : 2019-04-09 Abstract: Vulnerabilities with Internet of Things (IoT) devices have raised the need for a solid and secure firmware update mechanism that is also suitable for constrained devices. Incorporating such update mechanism to fix vulnerabilities, to update configuration settings as well as adding new functionality is recommended by security experts. This document lists requirements and describes an architecture for a firmware update mechanism suitable for IoT devices. The architecture is agnostic to the transport of the firmware images and associated meta-data. This version of the document assumes asymmetric cryptography and a public key infrastructure. Future versions may also describe a symmetric key approach for very constrained devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-suit-architecture/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-suit-architecture-05 https://datatracker.ietf.org/doc/html/draft-ietf-suit-architecture-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-suit-architecture-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Apr 9 15:02:46 2019 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 6B03112045E for ; Tue, 9 Apr 2019 15:02:44 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s6wcLDNkjWX4 for ; Tue, 9 Apr 2019 15:02:42 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140047.outbound.protection.outlook.com [40.107.14.47]) (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 0346A12010E for ; Tue, 9 Apr 2019 15:02:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OqA+s0AeDdB9m+acWZxM6FBuxyI0tCKnlQlnufdm4RU=; b=Fx4M9NWrvy+iRboIIUPuWEyaPJVG9mH6QhehDorx061eCDcy8QrFDbzU2oQ694qWz2dN/okRylN4gIzsZNCDVRJVYS8nW9X8kawg0WFr72RcMGrHr0IyU1GLwjYUzl1zkEw3+pUYZchKcdorbBCjTSULp77Tyb/fwK4gzKqcApo= Received: from AM6PR08MB3686.eurprd08.prod.outlook.com (20.178.91.22) by AM6PR08MB4486.eurprd08.prod.outlook.com (20.179.18.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.14; Tue, 9 Apr 2019 22:02:39 +0000 Received: from AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91]) by AM6PR08MB3686.eurprd08.prod.outlook.com ([fe80::7025:fc8a:7d0a:cb91%3]) with mapi id 15.20.1792.009; Tue, 9 Apr 2019 22:02:39 +0000 From: Hannes Tschofenig To: "suit@ietf.org" CC: Jacob Beningo Thread-Topic: draft-ietf-suit-architecture-05 Thread-Index: AdTvH4l9E+UjpakNQX+rbFxf3hNt7A== Date: Tue, 9 Apr 2019 22:02:39 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [31.221.80.98] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bbf9db61-8289-4c76-5f2e-08d6bd37150d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(7168020)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:AM6PR08MB4486; x-ms-traffictypediagnostic: AM6PR08MB4486: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 000227DA0C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(39860400002)(376002)(366004)(396003)(40434004)(199004)(189003)(2906002)(86362001)(476003)(4744005)(26005)(6506007)(186003)(2351001)(2501003)(7736002)(55236004)(256004)(5660300002)(3846002)(6116002)(102836004)(5024004)(790700001)(14444005)(9686003)(6306002)(54896002)(55016002)(236005)(4326008)(52536014)(6916009)(53936002)(486006)(966005)(316002)(8936002)(72206003)(14454004)(66066001)(478600001)(8676002)(81156014)(33656002)(1730700003)(81166006)(71200400001)(97736004)(71190400001)(5640700003)(106356001)(68736007)(74316002)(6436002)(606006)(99286004)(7696005)(25786009)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR08MB4486; H:AM6PR08MB3686.eurprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: JUmZWOMHVMoxe92utCvhjWmB+T6l8OJRkn9wCYFzxAmf65cTiQ5cQS60tVthRUCoxbaFG/o7avEL1GMt2Xxz661lJ3qZulPxmy+FTyVlXUD3rmKhhisALRZqrmMjVJ2RWO4lF3uoz/JX18hZTTYQuQsainxNQrtm62knhBGIN33q0eD+GwYOifSe0b2NNL7W/pXfexNZy2qmOo8BzMfaSgtUO8pl2V1TH4ji5DD2nC3/zEOkCzf9qIRb36sw9jDTJsqIIqvK9xqM36mWhZ4Fd9KTZmVdyh+bDTvQP2HhNTzgQHKgkuWio/2IRl6H8fPZvcBY9yhkU3/fnCEVE7tMg2TDgCywq0MDC1HVXmyTIyiyUciOi2ey53fgCu5k+PaQ3IPXrK32OtqgQQ9Ag4RRTTI/94uijYG+1rcNe99IIy8= Content-Type: multipart/alternative; boundary="_000_AM6PR08MB36867F8E8EBF5DC0801A8D85FA2D0AM6PR08MB3686eurp_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: bbf9db61-8289-4c76-5f2e-08d6bd37150d X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Apr 2019 22:02:39.2581 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4486 Archived-At: Subject: [Suit] draft-ietf-suit-architecture-05 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, 09 Apr 2019 22:02:44 -0000 --_000_AM6PR08MB36867F8E8EBF5DC0801A8D85FA2D0AM6PR08MB3686eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I have just submitted version -05 of the architecture draft and you can fin= d it here: https://tools.ietf.org/html/draft-ietf-suit-architecture-05 Jacob Beningo, on CC, provided a review of the bootloader section of the dr= aft and I updated the text accordingly. Thank you for the review, Jacob. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. --_000_AM6PR08MB36867F8E8EBF5DC0801A8D85FA2D0AM6PR08MB3686eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I have just submitted version -= 05 of the architecture draft and you can find it here:

https://tools.ietf.org/html/draft-ietf-suit-architectur= e-05

 

Jacob Beningo, on CC, provided = a review of the bootloader section of the draft and I updated the text acco= rdingly.

Thank you for the review, Jacob= .

 

Ciao

Hannes

 

IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in any medium. Thank you. --_000_AM6PR08MB36867F8E8EBF5DC0801A8D85FA2D0AM6PR08MB3686eurp_-- From nobody Wed Apr 10 12:37:04 2019 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 66E6D1205F5 for ; Wed, 10 Apr 2019 12:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJ6KrfxpCg6r for ; Wed, 10 Apr 2019 12:36:54 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00046.outbound.protection.outlook.com [40.107.0.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96CF9120621 for ; Wed, 10 Apr 2019 12:36:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ulGj59zE16wMv1HyzkvDByROGJWngdl5dUfnBs2Kw8Q=; b=J0Y4pb9Y4TvM6NGPTYVkVu+quBQiQlOv3aHs4cLgApxgbA7d/8f9PEF7W3Ia5APRJKkYjM5/KIHQYHoP6jeRgjkco+4uYk9pc6LX+vxetqDbEgXD+uiVl8oTeO/sqPA7r8ZK4KPV/6nmm9U6LZCWmxuuQtALGicRvgrMJyUVF/I= Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com (10.168.98.146) by HE1PR0701MB2524.eurprd07.prod.outlook.com (10.168.128.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.12; Wed, 10 Apr 2019 19:36:51 +0000 Received: from HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::c9fc:ff6d:5b43:f6e2]) by HE1PR0701MB2905.eurprd07.prod.outlook.com ([fe80::c9fc:ff6d:5b43:f6e2%7]) with mapi id 15.20.1792.009; Wed, 10 Apr 2019 19:36:50 +0000 From: Mohit Sethi M To: suit Thread-Topic: [Suit] WG Last Call for draft-ietf-suit-architecture-04 Thread-Index: AQHU79S+Dl7hhI6fI0mITWGu3u/VsQ== Date: Wed, 10 Apr 2019 19:36:50 +0000 Message-ID: <1177e4f7-906a-5fe0-0e7f-09b8eed9fd64@ericsson.com> References: <5D5FB80B-10A5-4DDE-B030-C9F667E8229C@vigilsec.com> In-Reply-To: <5D5FB80B-10A5-4DDE-B030-C9F667E8229C@vigilsec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 x-originating-ip: [89.166.49.243] x-clientproxiedby: HE1PR0202CA0025.eurprd02.prod.outlook.com (2603:10a6:3:e4::11) To HE1PR0701MB2905.eurprd07.prod.outlook.com (2603:10a6:3:57::18) authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0d45713d-2c73-4ed1-fc15-08d6bdebe0a2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR0701MB2524; x-ms-traffictypediagnostic: HE1PR0701MB2524: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 00032065B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(346002)(366004)(396003)(376002)(189003)(199004)(72854002)(54094003)(81156014)(6486002)(66066001)(99286004)(65956001)(65806001)(76176011)(97736004)(71200400001)(71190400001)(229853002)(53546011)(6506007)(64126003)(6116002)(52116002)(102836004)(2906002)(25786009)(6436002)(386003)(3846002)(7736002)(36756003)(305945005)(66574012)(6246003)(316002)(86362001)(5660300002)(8936002)(81166006)(58126008)(14454004)(966005)(31696002)(8676002)(14444005)(256004)(476003)(105586002)(478600001)(31686004)(106356001)(53936002)(446003)(11346002)(2616005)(6916009)(6512007)(186003)(65826007)(6306002)(486006)(68736007)(26005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0701MB2524; H:HE1PR0701MB2905.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: qP/JXOm5gpr+NIOxh81yldwRF+OBzlMzxLKQ2pqf1+qy85TEPrAsEVOeVmHkN/a44u4vlzum41JoUXYmOTQQ2mkfwn+I0k9Kw7TMT3sVwuZYrRhF6xSDnPeds5XT8OuoBBTsCsN9qGqYjfz3YW3847S1I5+Idtc3VMoZZuQhT0x68nWpKSVroPfjZxyFtfeEAd6mnJH5t2euS4DntmMeWmlzw6oJ5kIfCoQSDCKedVXTKfzcTiliLqTNB8cdPw9+o/wQ47e1y1TABoUW1JLNL0UUI/G5RvpqjiM87u3Me7TnGbNosaIpGiyDQkMq7O5pWnbVZPCkQMA9hH+SWX6brESSwrmZcyxFx5yIzFYdK86ZtOPLmlM1LbDgXHgwNUECW4x0e7kqQvTdz/jIrAgsegKPNl4+D4gCouKau832z4I= Content-Type: text/plain; charset="utf-8" Content-ID: <7DA73FBA7AD2F545ADEDC9079C946ECB@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0d45713d-2c73-4ed1-fc15-08d6bdebe0a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Apr 2019 19:36:50.8109 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2524 Archived-At: Subject: Re: [Suit] WG Last Call for draft-ietf-suit-architecture-04 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, 10 Apr 2019 19:37:02 -0000 UmV2aWV3IG9mIGRyYWZ0LWlldGYtc3VpdC1hcmNoaXRlY3R1cmUtMDQNCg0KT3ZlcmFsbCBjb21t ZW50czoNCg0KSW4gU2VjdGlvbiAyLCB0aGUgdGV4dCBzYXlzICJGaXJtd2FyZSBpcyB0aGUgbW9y ZSB1bml2ZXJzYWwgdGVybS4gQm90aCANCnRlcm1zIGFyZSB1c2VkIGluIHRoaXMgZG9jdW1lbnQg YW5kIGFyZSBpbnRlcmNoYW5nZWFibGUuIiBXaGljaCBpcyB0aGUgDQpvdGhlciB0ZXJtIHlvdSBh cmUgcmVmZXJyaW5nIHRvPyBJdCBpcyBub3Qgc3RhdGVkIGluIHRoZSB0ZXh0PyBBbHNvLCB0aGUg DQp3b3JraW5nIGdyb3VwIGlzIGNhbGxlZCBTb2Z0d2FyZSBVcGRhdGUgZm9yIEludGVybmV0IG9m IFRoaW5ncyAoU1VJVCksIA0KYnV0IHRoZSBkb2N1bWVudCB0YWxrcyBhYm91dCBmaXJtd2FyZS4g SXQgaXMgZmluZSB0byBmb2N1cywgYnV0IHdvdWxkbid0IA0KaXQgbWFrZSBzZW5zZSB0byBhZGQg c29tZSBpbmZvcm1hdGlvbiBvbiBob3cgdGhleSBhcmUgZGlmZmVyZW50IGFuZCB3aGF0IA0KZXhh Y3RseSB0aGlzIGRvY3VtZW50IGNvdmVycy4gKEkgYW0gc3VyZSB0aGVyZSB3YXMgZGlzY3Vzc2lv biBvbiB0aGUgDQp0ZXJtIHNvZnR3YXJlIHZzLiBmaXJtd2FyZS4gQWZ0ZXIgYWxsLCB0aGUgbWFp bGluZyBsaXN0IHdhcyBwcmV2aW91c2x5IA0KY2FsbGVkIEZpcm13YXJlIFVwZGF0ZSAoRlVEKS4N Cg0KVGhlbiB0aGUgZG9jdW1lbnRzIG1lbnRpb25zIG1hbnkgcmVxdWlyZW1lbnRzIGFib3V0IGJl aW5nIGFibGUgdG8gd29yayANCndpdGggc21hbGwgcGFyc2VycywgYmVpbmcgZnJpZW5kbHkgdG8g YnJvYWRjYXN0IGRlbGl2ZXJ5IGV0Yy4gV291bGRuJ3QgDQppdCBoZWxwIHRvIGFsc28gc2F5IGhv dyB0aGlzIGFyY2hpdGVjdHVyZSB3b3VsZCBhaWQgdGhhdC4gSSBhbSBzdXJlIHRoYXQgDQpzb21l IHRoaXMgd291bGQgYmUgaW4gdGhlIG1hbmlmZXN0IGRvY3VtZW50IGJ1dCBpdCB3b3VsZCBoZWxw IHRvIGhhdmUgDQpzb21lIHJlbGF0aW9uIGJldHdlZW4gdGhlIHJlcXVpcmVtZW50cyBhbmQgYXJj aGl0ZWN0dXJlLg0KDQpTZWN0aW9uIDcgdGFsa3MgYWJvdXQgaG93IHRoaXMgYXJjaGl0ZWN0dXJl IGlzIGFwcGxpY2FibGUgdG8gZXhpc3RpbmcgDQpzeXN0ZW1zLCBidXQgdGhlIGRvY3VtZW50IGRv ZXNuJ3QgZGVzY3JpYmUgaG93IGFyZSBmaXJtd2FyZXMgYW5kIA0KbWFuaWZlc3RzIGFyZSBjdXJy ZW50bHkgZGlzdHJpYnV0ZWQuIEV2ZW4gdGhvdWdoIHRoZSBjaGFydGVyIHNheXMgIlRoaXMgDQpn cm91cCB3aWxsIGZvY3VzIG9uIGRlZmluaW5nIGEgZmlybXdhcmUgdXBkYXRlIHNvbHV0aW9uICh0 YWtpbmcgaW50byANCmFjY291bnQgcGFzdCBsZWFybmluZ3MgZnJvbSBSRkMgNDEwOCBhbmQgb3Ro ZXIgZmlybXdhcmUgdXBkYXRlIA0Kc29sdXRpb25zKSIsIEkgZG9uJ3Qgc2VlIGFueSB0ZXh0IGV4 cGxhaW5pbmcgdGhlIHJlbGF0aW9uc2hpcCB0byBjdXJyZW50IA0KbWVjaGFuaXNtcy4gSSBkb24n dCBleHBlY3Qgc29tZSBsb25nIHN1cnZleSBvZiB0aGUgcHJlc2VudCBkZXBsb3ltZW50LCANCmJ1 dCBqdXN0IGEgZmV3IGxpbmVzIGV4cGxhaW5pbmcgaG93IGFyZSBmaXJtd2FyZSB1cGRhdGVzIGRv bmUgdG9kYXksIGFuZCANCmhvdyB0aGlzIGFyY2hpdGVjdHVyZSBpcyBzYW1lL2RpZmZlcmVudCBh bmQgbW9yZSBsaWdodC13ZWlnaHQ/DQoNCk1pbm9yIHN1Z2dlc3Rpb25zOg0KDQpBYnN0cmFjdDoN Cg0KVGhlIHRlcm0gInNvbGlkIiBpcyB0b28gbXVjaCBvZiBhIHNsYW5nIGZvciBtZS4gSG93IGFi b3V0IHJvYnVzdD8NCg0KMTogSW50cm9kdWN0aW9uOg0KDQpJIHdvbmRlciBpZiB5b3Ugd291bGQg Y29uc2lkZXIgYWRkaW5nIGEgcmVmZXJlbmNlIHRvIA0KZHJhZnQtaXJ0Zi10MnRyZy1pb3Qtc2Vj Y29ucy0xNj8gUGVyaGFwcyB0aGUgaW50cm9kdWN0aW9uIGNvdWxkIGJlZ2luIA0Kd2l0aCAiQXMg bm90ZWQgaW4gW2lvdC1zZWNjb25zXSzCoCB3aGVuIGRldmVsb3BpbmcgSW9UIGRldmljZXMsIG9u ZSBvZiANCnRoZSBtb3N0IGRpZmZpY3VsdCBwcm9ibGVtcyB0byBzb2x2ZSBpcyBob3cgdG8gdXBk YXRlIHRoZSBmaXJtd2FyZSBvbiANCnRoZSBkZXZpY2UuIiBGb3IgZnVsbCBkaXNjbG9zdXJlLCBJ IGFtIGFuIGF1dGhvciBvZiB0aGF0IGRvY3VtZW50LiBCdXQgSSANCmRvIHRoaW5rIGl0IG1ha2Vz IHNlbnNlIHRvIGhhdmUgaXQgYXMgYSByZWZlcmVuY2UuDQoNCjI6IENvbnZlbnRpb25zIGFuZCBU ZXJtaW5vbG9neQ0KDQoiVGhlIG1hbmlmZXN0IGlzIHByb3RlY3RlZCBhZ2FpbnN0IG1vZGlmaWNh dGlvbiBhbmQgcHJvdmlkZXMgaW5mb3JtYXRpb24gDQphYm91dCB0aGUgYXV0aG9yLiIgVGhlIGVu dGl0eSBhdXRob3IgaXMgZGVmaW5lZCBsYXRlci4gUGVyaGFwcyB0aGlzIA0Kc2VudGVuY2UgY291 bGQgYmUgbWFkZSBzZWxmLWNvbnRhaW5lZCBieSByZXBocmFzaW5nIGFzICJUaGUgbWFuaWZlc3Qg aXMgDQpwcm90ZWN0ZWQgYWdhaW5zdCBtb2RpZmljYXRpb24gYW5kIHByb3ZpZGVzIGluZm9ybWF0 aW9uIGFib3V0IHRoZSBhdXRob3IgDQpvZiB0aGUgZmlybXdhcmUgYmVpbmcgdXBkYXRlZC4iDQoN CkZvciBoYXJkd2FyZSBub29icyBsaWtlIG1lLCBjYW4geW91IHBsZWFzZSBleHBsYWluIHRoZSBk aWZmZXJlbmNlIA0KYmV0d2VlbiBST00gYW5kIGZsYXNoIG1lbW9yeS4gVGhlIHRleHQgc2F5cyB0 aGF0IHBhcnRzIG9mIGJvb3Rsb2FkZXIgbWF5IA0KcmVzaWRlIGluIFJPTSBhbmQgaW4gZmxhc2gg bWVtb3J5Lg0KDQpUaGUgdGV4dCBzYXlzIGluIHRoZSBiZWdpbm5pbmcgb2YgdGhlIHNlY3Rpb24g IlRoaXMgZG9jdW1lbnQgdXNlcyB0aGUgDQpmb2xsb3dpbmcgdGVybXM6IiBidXQgdGhlbiBuZXZl ciB1c2VzIHRlcm1zIHN1Y2ggYXMgSG9TQS9IZVNBIGluIHRoZSANCnJlc3Qgb2YgdGhlIGRvY3Vt ZW50PyBBcmUgdGhleSBuZWVkZWQ/DQoNCiJGb3IgZXhhbXBsZSwgaW4gc29tZSBjYXNlcywgdGhl IE9yaWdpbmFsIERlc2lnbiBNYW51ZmFjdHVyZXIgKE9ETSksIiANClRoaXMgaXMgYSBuZXcgdGVy bSBmb3IgbWUgKGFuZCBob3BlZnVsbHkgZm9yIHNvbWUgb3RoZXJzKS4gSSBhbSBtb3JlIA0KdXNl ZCB0byB0aGUgdGVybSBPcmlnaW5hbCBFcXVpcG1lbnQgTWFudWZhY3R1cmVyIChPRU0pLiBBcmUg dGhleSBkaWZmZXJlbnQ/DQoNCjM6IFJlcXVpcmVtZW50cw0KDQoiIEVuZC10by1lbmQgc2VjdXJp dHkgYmV0d2VlbiB0aGUgYXV0aG9yIGFuZCB0aGUgZGV2aWNlIi4gRm9yIG1lIA0KZW5kLXRvLWVu ZCBzZWN1cml0eSBpcyBiZXR3ZWVuIG1hY2hpbmVzL2RldmljZXMuIFNob3VsZG4ndCBpdCBiZSAN CmVuZC10by1lbmQgc2VjdXJpdHkgYmV0d2VlbiB0aGUgZmlybXdhcmUgc2VydmVyIGFuZCB0aGUg ZGV2aWNlPw0KDQpUaGlzIHNlbnRlbmNlIGNvdWxkIGJlIHJlLXBocmFzZWQgIk9uZSB3YXkgdG8g YWNoaWV2ZSB0aGlzIGZ1bmN0aW9uYWxpdHkgDQppcyB0byBwcm92aWRlIGEgbWluaW11bSBvZiB0 d28gc3RvcmFnZSBsb2NhdGlvbnMgZm9yIGZpcm13YXJlIGFuZCBvbmUgDQpib290YWJsZcKgIGxv Y2F0aW9uIGZvciBmaXJtd2FyZSINCg0KU3BlbGxpbmcgYW5kIHR5cG9zOg0KDQpTZWN0aW9uIDI6 DQoNCnN1Y2Nlc2Z1bGx5IHZzIHN1Y2Nlc3NmdWxseQ0KDQppbnRlcmNoYW5nYWJseSB2cyBpbnRl cmNoYW5nZWFibHkNCg0KU2VjdGlvbiA4Og0KDQppbXBsZW1lbnRpb24tc3BlY2lmaWMgdnMgaW1w bGVtZW50YXRpb24tc3BlY2lmaWMNCg0KRmlndXJlIDUgY2FwdGlvbiAiRmlybXdhcmUgVXBhdGUi IHZzICJGaXJtd2FyZSBVcGRhdGUiDQoNClRoZXJlIGFyZSBtdWx0aXBsZSB1c2VzIG9mIEJyaXRp c2ggRW5nbGlzaDogImF1dGhvcmlzYXRpb24iLCBldGMuIEkgDQpkb24ndCBoYXZlIGFueSBvcGlu aW9uIG9uIHRoaXMgYW5kIGxlYXZlIGl0IHRvIHRoZSBhdXRob3JzIGFuZCB0aGUgUkZDIA0KZWRp dG9yLg0KDQotLU1vaGl0DQoNCk9uIDMvMjcvMTkgMTE6MDMgQU0sIFJ1c3MgSG91c2xleSB3cm90 ZToNCj4gVGhpcyBpcyB0aGUgU1VJVCBXRyBMYXN0IENhbGwgZm9yICJBIEZpcm13YXJlIFVwZGF0 ZSBBcmNoaXRlY3R1cmUgZm9yIEludGVybmV0IG9mIFRoaW5ncyBEZXZpY2Vz4oCdIDxkcmFmdC1p ZXRmLXN1aXQtYXJjaGl0ZWN0dXJlLTA0Pi4gIFBsZWFzZSByZXZpZXcgdGhlIGRvY3VtZW50IGFu ZCBzZW5kIHlvdXIgY29tbWVudHMgdG8gdGhlIGxpc3QgYnkgMTMgQXByaWwgMjAxOS4NCj4NCj4g VGhlIGRhdGF0cmFja2VyIHBhZ2UgZm9yIHRoZSBkb2N1bWVudCBpcyBodHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXN1aXQtYXJjaGl0ZWN0dXJlLw0KPg0KPiBUaGFu a3MsDQo+IFJ1c3MgJiBEYXZlICYgRGF2ZQ0KPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPiBTdWl0IG1haWxpbmcgbGlzdA0KPiBTdWl0QGlldGYu b3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc3VpdA0K From nobody Thu Apr 11 08:03:27 2019 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 2C6C01203A8 for ; Thu, 11 Apr 2019 08:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordicsemi.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saDNKfHwbCUi for ; Thu, 11 Apr 2019 08:03:14 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30062.outbound.protection.outlook.com [40.107.3.62]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B44A412038D for ; Thu, 11 Apr 2019 08:03:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nordicsemi.onmicrosoft.com; s=selector1-nordicsemi-no; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9h4DND+cCwJYHVTdGIkrUM+1jHWmy4GXVW71JxumvRw=; b=GzGBdR0/dzECEt2w/2zw9+r/ZU3uxBVmPZ7y9X+zvIsXU7v/EKSNzkinbyF+Yz9Y5eXl62cD1IBhokDAD3hclbsSF3u3BpE5qGdFyI7GEqZTx3GldcnzR2I3t/M7ttkxYA+nR/yM64pB2ZIkgDN31fuHrHGBuh70RqL/no8BVoU= Received: from HE1PR05MB3228.eurprd05.prod.outlook.com (10.170.243.14) by HE1PR05MB3131.eurprd05.prod.outlook.com (10.170.242.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.21; Thu, 11 Apr 2019 15:02:57 +0000 Received: from HE1PR05MB3228.eurprd05.prod.outlook.com ([fe80::d913:f7c4:f82:e58e]) by HE1PR05MB3228.eurprd05.prod.outlook.com ([fe80::d913:f7c4:f82:e58e%4]) with mapi id 15.20.1771.021; Thu, 11 Apr 2019 15:02:57 +0000 From: =?iso-8859-1?Q?R=F8nningstad=2C_=D8yvind?= To: Brendan Moran , "suit@ietf.org" CC: =?iso-8859-1?Q?Kvamtr=F8=2C_Frank_Audun?= Thread-Topic: Introducing draft-moran-suit-manifest-04 Thread-Index: AQHU2L81dzELNCQKcEaCHfQ8cPehA6Y2x2+wgABw2OA= Date: Thu, 11 Apr 2019 15:02:57 +0000 Message-ID: References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Oyvind.Ronningstad@nordicsemi.no; x-originating-ip: [2001:8c0:5140:12:b5e7:e1e6:a6e9:8320] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4eac77f4-ed4b-4556-9bf9-08d6be8ec889 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR05MB3131; x-ms-traffictypediagnostic: HE1PR05MB3131: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39850400004)(396003)(346002)(136003)(366004)(199004)(189003)(13464003)(40434004)(33656002)(966005)(106356001)(5024004)(229853002)(53546011)(305945005)(68736007)(186003)(8936002)(478600001)(6506007)(11346002)(25786009)(2940100002)(105586002)(446003)(256004)(107886003)(99286004)(14454004)(93156006)(2501003)(72206003)(476003)(14444005)(74482002)(46003)(8676002)(7696005)(9686003)(6436002)(52536014)(102836004)(7736002)(2473003)(76176011)(74316002)(110136005)(5660300002)(4326008)(71190400001)(2906002)(71200400001)(53936002)(486006)(97736004)(86362001)(81166006)(6116002)(81156014)(45776006)(316002)(55016002)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR05MB3131; H:HE1PR05MB3228.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nordicsemi.no does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 02k6MljjUeN3X/O0Eunp945Y+qh63qZ121c5nigEErXBip/rYaXBh+PewUDuD1F8+aVU1Q47bxSoRYzHZ1K3cYgjbUk06pK057IM64D1x/IFQilP9iLaJrEFitxJ9Sx7t/quZy5YW0PMdXvsg8iPGMitr4dLnRGNk8fQGF4d5AOZ5/ta6LfUBd6M+Y1yNkd9QyaNSAodOcVZMBDHUzRi+1yGGrks46WFbS1gteEYQDW8bBfeV6sq62qE7MV/KHjkg/jNoAPxk5PL2LovzFF/Lqu1GRZy2Tlz3+svbfXtzs+nibRHY1vu7YtuZ6ukqXXDcSQw6MUKtFSAxeAl0Tfu6sGFZgp8Zdvx017YwWUtSEdSnCysi0QPcPDy3ZUMF2T/QEiW5qdfhJTcWUjBUwH33/caYY3OzC2V0RkG4zpxC/A= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nordicsemi.no X-MS-Exchange-CrossTenant-Network-Message-Id: 4eac77f4-ed4b-4556-9bf9-08d6be8ec889 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 15:02:57.7548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 28e5afa2-bf6f-419a-8cf6-b31c6e9e5e8d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR05MB3131 Archived-At: Subject: [Suit] FW: Introducing draft-moran-suit-manifest-04 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, 11 Apr 2019 15:03:19 -0000 I did a full pass through the document today, and wrote down (quite a few) = comments, see below. I think this document is very exciting! - =D8yvind The digest-algorithm-ids list is missing the following SHA-2 family functio= ns: - SHA224 - SHA512/224 - SHA512/256 Also, the functions that are truncated to 128 and fewer bits will not be se= cure against brute-force attacks, so I question their inclusion here. The requirement that all manifests must have a sequence number higher than = their dependencies might be inconvenient when dependencies are validated by= version ranges, since a dependency might be updated to something that is c= reated after the root manifest, but still fulfills the check. Comparing seq= uence number dependency<->dependent might be superfluous, since the depende= ncy is already referenced quite specifically in other ways. Alternatively, = the requirement can be valid only up to and including installation. Also, the text should probably mention that if a manifest is replaced by an= update, the new manifest must have a higher sequence number. What directives/conditions can apply to components in suit-dependency-compo= nents? I don't quite understand the purpose of the suit-dependency-componen= ts list. I read it many times now, but I don't really understand the last paragraph = of "8.4. SUIT_Component". Can you elaborate on the assumptions? How are th= e values dependent on installation offset? Who updates the parameters to ma= tch what? What does "defining a component" mean? I might have missed something, but can you elaborate on how scoping of para= meters work, specifically when are they unset? For example Encryption Info,= does it become unset after being used once? Which parameters are inherited= into a Run_Sequence or Process_Dependency? Does a Set_Component_Index/Set_= Manifest_Index effectively unset all parameters that have scope "Component"= /"Dependency". How does scoping affect parallell processing (how to keep tr= ack of the value of a parameter for a given Directive/Conditition if they a= re executed out of order)?=09 SUIT_Unpack_Algorithm_Delta should be split into individual IDs for algorit= hms like SUIT_Unpack_Algorithm_VCDIFF. I think there's a quirk with the versions where comparisons can be subverte= d. If you have a dependency on version 1.x of something, it's hard (impossi= ble in the general sense) to express those bounds with the greater/lesser c= omparisons. This is because there is no well-defined highest or lowest vers= ion with a given prefix such as "1." (unless the version list has bounded l= ength). If you have a bound on the length of the version list, you could e= xpress the upper bound e.g. as "Lesser or equal than 1.INTMAX.INTMAX..." et= c. which isn't very pretty. Can we find some better way? I'm assuming 1.1 i= s equivalent (equal) to 1.1.0 etc. If SUIT_Directive_Set_Component_Index is set to ALL components, is the orde= r in which it applies to the components well-defined? Same question for SUI= T_Directive_Set_Manifest_Index.=20 Can you give an example of providing an argument to SUIT_Directive_Fetch? The CDDL for Condition, Directive and Parameters should have the name as pa= rt of the CDDL (i.e. as a label/type, not a comment) to make it more amenab= le to machine parsing. *The rest is nitpicking* The SUIT_Manifest CDDL references Digest instead of SUIT_Digest. Should suit-install be MANDATORY if suit-payload-fetch is present? I suggest being more specific about suit-validate. Something to the effect = of: "suit-validate is a SUIT_Command_Sequence to execute in order to valida= te that the result of applying the update (i.e. the state of the device aft= er suit-install) is correct." When forwarding a dependency to a component that is capable of parsing its = own manifests, the dependency manifest might not be SUIT-formatted, so it s= hould not need to be interpreted. This could be elaborated on in the text. This sentence should probably be fixed (typo etc.): "It consists of three e= lemnts: the component identifier that represents a component that will be a= ffected by this manifest." Can a SUIT_Component_Reference refer to a component in a dependency of a de= pendency? For readability, I suggest placing the "name" column (of the manifest param= eters table) further to the left. Can you elaborate on the "Skip" flag for parameters? Even just mentioning t= hat it is TBD. This could be more specific: "This index is a numeric index into the compon= ent ID tables defined at the beginning of the document." SUIT_Directive_Set_Parameter_State_Append is not mentioned in the table. Should "dependent-components" be "dependency-components" instead? For the sake of completeness: In "Access Control Lists" I envision another = situation, where ACL is implemented as a function that e.g. takes the Compo= nent ID and returns the identities that can manipulate it. This is for when= Component IDs can alias each other, or the component ID contains a flash a= ddress, so it doesn't make sense to store every conceivable component ID in= a list. The names in the example in "Creating conditional sequences" don't look rig= ht, are they outdated? An example with dependencies would of course be useful. -----Original Message----- From: Suit On Behalf Of Brendan Moran Sent: Tuesday, March 12, 2019 11:35 To: suit@ietf.org Subject: [Suit] Introducing draft-moran-suit-manifest-04 draft-moran-suit-manifest-04 has now been published. https://tools.ietf.org/html/draft-moran-suit-manifest-04 This draft is the result of combining the information model in draft-moran-= suit-behavioural-manifests-00 (the 01 version fixes example formatting only= ) with that in draft-ietf-suit-information-model, then serialising the resu= lt in CBOR. This is a significant departure from previous drafts. It attemp= ts to preserve flexibility, fully define the behaviour of recipient, simpli= fy the manifest structure, reduce code-size of the recipient, and reduce th= e size of the manifest. This ambitious set of goals required a significant = change in approach as compared to draft-moran-suit-manifest-03 and before. = In order to outline the approach clearly, we have separately published draf= t-moran-suit-behavioural-manifests-00. draft-moran-suit-manifest-04 focuses= more on the serialisation of the manifest. I look forward to discussing this draft in more detail. Best Regards, Brendan IMPORTANT NOTICE: The contents of this email and any attachments are confid= ential and may also be privileged. If you are not the intended recipient, p= lease notify the sender immediately and do not disclose the contents to any= other person, use it for any purpose, or store or copy the information in = any medium. Thank you. _______________________________________________ Suit mailing list Suit@ietf.org https://www.ietf.org/mailman/listinfo/suit From nobody Thu Apr 11 08:17:06 2019 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 37B0A1200F6 for ; Thu, 11 Apr 2019 08:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TVD_SPACE_RATIO=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OhWlRrl63HXF for ; Thu, 11 Apr 2019 08:17:01 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750091.outbound.protection.outlook.com [40.107.75.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D8491207D1 for ; Thu, 11 Apr 2019 08:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=VfT4fJLj+DmcoLvouup4ipETIHGywlX+Cz/+7LdeuqI=; b=SYaU4LntHpJgqnMUnmqPn6A2LMo+IgoudsmBoUOF7MwtmH/uotCyq2hjH0q5eFnYKhIlO6wMoNHUq4fiEt3sQwPFMVBeJ+AhgwrfXjDu6cHVQmdnUY6BQUnM/ELQeCcd+PIledC4SatWy7JLlt9lyjhYMNhnMNO3bqYHnMzFNGA= Received: from CY4PR21MB0168.namprd21.prod.outlook.com (10.173.192.150) by CY4PR21MB0151.namprd21.prod.outlook.com (10.173.189.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.1; Thu, 11 Apr 2019 15:16:42 +0000 Received: from CY4PR21MB0168.namprd21.prod.outlook.com ([fe80::19ea:53d7:612a:6630]) by CY4PR21MB0168.namprd21.prod.outlook.com ([fe80::19ea:53d7:612a:6630%13]) with mapi id 15.20.1813.001; Thu, 11 Apr 2019 15:16:41 +0000 From: Dave Thaler To: suit Thread-Topic: Feedback on draft-ietf-suit-architecture-05 Thread-Index: AdTweT6m6pVFnUUQRiGE1oQ8uPIbtg== Date: Thu, 11 Apr 2019 15:16:41 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=dthaler@ntdev.microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-04-11T15:16:43.9697539Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=f2b366af-0383-47f9-b65f-9eef1101eebd; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic authentication-results: spf=none (sender IP is ) smtp.mailfrom=dthaler@microsoft.com; x-originating-ip: [73.59.106.235] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1e15c1f2-157b-49f8-2500-08d6be90b3c1 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:CY4PR21MB0151; x-ms-traffictypediagnostic: CY4PR21MB0151: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4303; x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39860400002)(376002)(136003)(366004)(189003)(199004)(478600001)(8676002)(8990500004)(53936002)(25786009)(6436002)(2906002)(99286004)(14454004)(10290500003)(71190400001)(7696005)(71200400001)(305945005)(55016002)(7736002)(6916009)(86612001)(6506007)(6116002)(9686003)(5660300002)(26005)(256004)(102836004)(186003)(6306002)(74316002)(3846002)(476003)(486006)(966005)(558084003)(105586002)(316002)(52536014)(81156014)(22452003)(86362001)(97736004)(81166006)(66066001)(8936002)(68736007)(33656002)(106356001)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0151; H:CY4PR21MB0168.namprd21.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: wXa9+X3VE546EjJEjhu8p+o1h13ZqjOx8MnJxPLi7nwfYVP3qWWqzid8fxHjiJp9VDEQL/1GxVEU6zZX2AXub0VovvS9YgVLRKZIzXwdU7dLPWs8gUdt1Cfo1sTzEy/a4f/ZapvVL/X4KkgqcbqPsipa3sQuetPc9XT4vB8h1NKynsaV2xazGjasol1st7DFcskNMUdxX/zTN3rZBCWc5IAEckL7drEf3vWUEvZbhg/Zqx4i/zFbkhBJ5+kCWIxO8DPUwfpjw/2YeH9tBolB1wJKK308fxvGfGUDiZ57PsYI7NbdQKEDxzujL7ZbzTP7r9rQGD3HSydwSa8WQsGij/aOBE8Yh0/9pAjUOVrI3GCKhKODogfrOA1eLrH+7N3Eld9677qnsMgfNzG6uDPmxccKMRISUMjlXfhxZ2lGmQg= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1e15c1f2-157b-49f8-2500-08d6be90b3c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 15:16:41.8730 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0151 Archived-At: Subject: [Suit] Feedback on draft-ietf-suit-architecture-05 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, 11 Apr 2019 15:17:04 -0000 SSByZXZpZXdlZCBkcmFmdC1pZXRmLXN1aXQtYXJjaGl0ZWN0dXJlLTA1Lg0KTXkgY29tbWVudHMg KGluY2x1ZGluZyBtYW55IGVkaXRvcmlhbCBuaXRzIGFuZCBjb21tZW50cykgYXJlIGluIHRoZSBt YXJrZWQgdXAgY29weSBhdA0KaHR0cHM6Ly93d3cubWljcm9zb2Z0LmNvbS9lbi11cy9yZXNlYXJj aC91cGxvYWRzL3Byb2QvMjAxNy8wNS9kcmFmdC1pZXRmLXN1aXQtYXJjaGl0ZWN0dXJlLTA1LnBk Zg0KDQpEYXZlDQo= From nobody Thu Apr 11 08:49:05 2019 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 0298B120669 for ; Thu, 11 Apr 2019 08:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 u_GpNEwAb8bb for ; Thu, 11 Apr 2019 08:48:52 -0700 (PDT) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0722.outbound.protection.outlook.com [IPv6:2a01:111:f400:fd01::722]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5948212065F for ; Thu, 11 Apr 2019 08:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1tpZtOfCVpub/B276kE5YHyOxlBKosATucRbPwL5zWI=; b=qr/O7IghQAVOFpG1vqcMrSSTgyTK7rfj8JNNGFSSvPNyfRvt58WqfCVMcHUmZbYkL4ql1pMozKASRlOgh5LlJhZGWMOCyx12Qp72Xtm3/emy5cJTMPlVVz1aEyMem7HZ/FgEZ0NjyTl6oQhROEQQWnstyUZ1V0ZDN6SDrJ8zyWM= Received: from SN6PR09MB3264.namprd09.prod.outlook.com (20.177.251.21) by SN6PR09MB3262.namprd09.prod.outlook.com (20.177.251.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.16; Thu, 11 Apr 2019 15:48:50 +0000 Received: from SN6PR09MB3264.namprd09.prod.outlook.com ([fe80::d40a:9312:f1f:9048]) by SN6PR09MB3264.namprd09.prod.outlook.com ([fe80::d40a:9312:f1f:9048%5]) with mapi id 15.20.1792.016; Thu, 11 Apr 2019 15:48:50 +0000 From: "Waltermire, David A. (Fed)" To: =?iso-8859-1?Q?R=F8nningstad=2C_=D8yvind?= , Brendan Moran , "suit@ietf.org" CC: =?iso-8859-1?Q?Kvamtr=F8=2C_Frank_Audun?= Thread-Topic: Introducing draft-moran-suit-manifest-04 Thread-Index: AQHU2L81dzELNCQKcEaCHfQ8cPehA6Y2x2+wgABw2OCAAAtb8A== Date: Thu, 11 Apr 2019 15:48:50 +0000 Message-ID: References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.222.129] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 659e705e-b286-4035-7b4f-08d6be95311d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:SN6PR09MB3262; x-ms-traffictypediagnostic: SN6PR09MB3262: x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39860400002)(396003)(346002)(136003)(376002)(13464003)(189003)(199004)(7736002)(305945005)(6116002)(8936002)(486006)(26005)(476003)(446003)(6506007)(478600001)(76176011)(53546011)(5660300002)(11346002)(105586002)(106356001)(7696005)(74316002)(6246003)(81156014)(99286004)(81166006)(25786009)(186003)(3846002)(8676002)(4326008)(2906002)(86362001)(9686003)(97736004)(14444005)(52536014)(53936002)(55016002)(256004)(6436002)(102836004)(14454004)(66574012)(229853002)(71190400001)(71200400001)(66066001)(33656002)(2501003)(68736007)(316002)(110136005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR09MB3262; H:SN6PR09MB3264.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: bOBoslpVWRbwdbUqwQXzifmTLMwAOsXCvrR0AzHngRUE6NLoBV4PmMox9VGxkDcyzYSCeIJpfy6j1EF5M77il3GZ0AJKqLW5xqec2nkHmkdkRN5UFT7JkTCKA6xV3Wwmciqgu+iTy/G0qNL4Td38nZZzRui+aXp6dfEmWlyZqYALlg13MF+nHfTtwxb6kMdSLB2tYCucwJ9/Kua0BrsN8KrGnpD3jjiZSWSpVW6kK74krx3LvLjqhy5cOkakzja8Ws5Ag5XuEOM3jdsyoiaebM08hypJdlpY42ee3QcnZr3e7VIQWg9ba5faZch/653sTnRj8wBjFw4DC4y8zphv6PXgdcZq+RUpzbJ9ezLdKhFwJrO+/aEmLqGR5SoyB2/BIAY2KNaCJjEELPtkpXE1OImwxrJwJo8fw3hxoEkCPHQ= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 659e705e-b286-4035-7b4f-08d6be95311d X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 15:48:50.1413 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR09MB3262 Archived-At: Subject: Re: [Suit] Introducing draft-moran-suit-manifest-04 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, 11 Apr 2019 15:48:57 -0000 Some comments on =D8yvind's comments below as a WG participant. > -----Original Message----- > From: Suit On Behalf Of R=F8nningstad, =D8yvind > Sent: Thursday, April 11, 2019 11:03 AM > To: Brendan Moran ; suit@ietf.org > Cc: Kvamtr=F8, Frank Audun > Subject: [Suit] FW: Introducing draft-moran-suit-manifest-04 >=20 > I did a full pass through the document today, and wrote down (quite a few= ) > comments, see below. I think this document is very exciting! >=20 > - =D8yvind >=20 >=20 > The digest-algorithm-ids list is missing the following SHA-2 family funct= ions: > - SHA224 > - SHA512/224 > - SHA512/256 > Also, the functions that are truncated to 128 and fewer bits will not be > secure against brute-force attacks, so I question their inclusion here. RFC 6920, which this draft references, defines the IANA "Named Information = Hash Algorithm Registry". It would be good if this draft directly reference= s the "Named Information Hash Algorithm Registry" directly to provide for f= uture agility as new algorithms are added and use of specific algorithms fa= ll out of practice. The "status" field of the registry provides guidance fo= r the later. Algorithm agility should also be discussed in the security con= siderations. It would also be useful to allow non-enumerated integer values to be used i= n the format to ensure that new entries added to the "Named Information Has= h Algorithm Registry" are also allowed to be used in the format. Regards, Dave From nobody Thu Apr 11 10:10:56 2019 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 4A93A1205F8 for ; Thu, 11 Apr 2019 10:10:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 Z3Y1rIYGkNTn for ; Thu, 11 Apr 2019 10:10: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 DA2541206BC for ; Thu, 11 Apr 2019 10:10:44 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 53A8C3826B; Thu, 11 Apr 2019 13:09:42 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 54FF0708; Thu, 11 Apr 2019 13:10:42 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 52836479; Thu, 11 Apr 2019 13:10:42 -0400 (EDT) From: Michael Richardson To: David Brown cc: Brendan Moran , "suit\@ietf.org" In-Reply-To: <20190315163402.GA25574@davidb.org> References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com> <20190315163402.GA25574@davidb.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] Introducing draft-moran-suit-manifest-04 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, 11 Apr 2019 17:10:56 -0000 --=-=-= Content-Type: text/plain {catching up on the thread, having read the documents} David Brown wrote: > - The download part of an upgrade happens while the application is > running, and this code is contained within the code currently > running in the primary image. It downloads the upgrade into the > "secondary" slot. This new code cannot execute at this address, > but is placed here as the image is downloaded. The assumption is > that their isn't sufficient RAM to hold the entire image, and that > a download may be interrupted. Are there systems that you target where the minimal MMU could actually remap things? > - Using the scratch area exchange the images in the primary and > secondary slot ... > This is designed in such a way that it can resume after any > untimely interruption. I guess the scratch area is not big enough for the entire image, but if there is an interruption, then the bootloader simply continues to do the swap? > Within either the primary or secondary slot, the image has a format > similar to: > +------------+ > | Header | > +------------+ > | Executable | > +------------+ > | Manifest | > +------------+ > there is no real separate place to store the manifest. This does mean > that during an upgrade the manifest for both the old and the new image > are present in flash. It seems that maybe there is an opportunity here, but I don't know what it is yet. > I'm curious what thoughts people have on how to apply the draft 4 > manifest to the above scenario. Operations such as "load" aren't > really meaningful, but apply-image would certainly make sense. > However, the installation of a new image is partially initiated by a > different piece of code than the bootloader which is responsible for > actually installing the image. This state has to be managed carefully > in a way that works with NOR flash, and therefore will probably live > outside of the manifest. I see your point. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlyvdRIACgkQgItw+93Q 3WWXvQgAlWKwMIYWSKauJqUekDLgMqcuqf96argcIw9V7Xod9jYaeev6guMu9TH/ ungeGQgqTxWB1DYSLgzwfBDc8rJVqXIcDx7HVD0WpkuoMTKnrf4wZ0RGIlXl4goW tOOLLypghwwg6l9HK6qyNR5OhzXFrtQVEiyaRPdKTWkH8lQG1ipUwsKSWKpEOlS1 W0NCb63+jF1S7fLPD6mtFu1ToV4AGs92QcXf5jMVY03M8J/Ts9ieDx9QuUIHZWWa vcThYspsa0rTeoZGoobJwN4ZPmwNAcJUhQFdz8jHsELrgLnpIw1sThL/zb9JelZQ KvQon9zrPHn2Im6r3wFwu/p5LZntCw== =Dor5 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Apr 11 10:17:41 2019 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 E5BBC12038B for ; Thu, 11 Apr 2019 10:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 w-cWQLypt3Cz for ; Thu, 11 Apr 2019 10:17:37 -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 CEF2F1202E1 for ; Thu, 11 Apr 2019 10:17:36 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 6A8463826B; Thu, 11 Apr 2019 13:16:35 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 67DF0708; Thu, 11 Apr 2019 13:17:35 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 655BA479; Thu, 11 Apr 2019 13:17:35 -0400 (EDT) From: Michael Richardson To: David Brown cc: Brendan Moran , "suit\@ietf.org" In-Reply-To: <20190322173908.GA17361@davidb.org> References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com> <20190315163402.GA25574@davidb.org> <59F62162-578C-4975-A25B-EC261A7F4F7D@arm.com> <20190322173908.GA17361@davidb.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] Introducing draft-moran-suit-manifest-04 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, 11 Apr 2019 17:17:40 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable David Brown wrote: >> Reboot resilience for =E2=80=9Cswap=E2=80=9D is probably outside the= scope of this draft. >> Adding a condition to check the success marker might be useful. > I'm not sure it really even makes sense to describe the reboot > resilience in the manifest. At least for swap, it is a large number > of steps that have to be done carefully, along with a lot of extra > state that is written every step. I would think this intermediate > state is beyond the scape of the manifest. > For those interested, I've thrown together a bit of an amination > describing how the swap operation works in MCUboot, including at least > part of its state. > https://www.youtube.com/watch?v=3DTvXjw2l0Cd0 > I'm not actually sure it is even going to make very much sense for > MCUboot to follow steps in the manifest, rather than just verifying > that they are present. The steps make sense for the download > application. Very nice animation. It really seems like the swap operation does by MCUboot ought to be below t= he level of the manifest instructions. > One difficulty I see following steps in the manifest is that the code > currently maintains state out-of-band from the manifest. The current > state is: That suggests to me that maybe we need to make the state explicit in the information model associated with the manifest. > Any thoughts on what is appropriate to even represent in the manifest? > The two instructions that the bootloader would follow would be "swap" > or "apply" (depending on configuration), and "run". Right now, we > distinguish swap vs copy by whether the new image contains the "image > ok" marker, but having two instructions could distinguish this as > well. =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlyvdq8ACgkQgItw+93Q 3WWsZwf/QOXV3RKOEz1zTJXmf9OjAXltAr/7fm3YjHzCPvlXAuWNNLXJK1nVYN3M x27IJnLZdYKVOwh4tJTQQTnrNkkS/6Cscd39IktVd2UzvGIDMpdfWMGSlSrbhbY7 aqxKfueldEFKdx1Po8xm+UpIe97NCMKjS0o6Nht41tDmQlwTV1Gye8BEO6UqfNkg e6CbzHGFIV3gYI60M+bs+I3wMxhFBNQj0PjqO4ShcjJSxmSCuJrVhBYgFf5Dd53A Ngu7OtG3S3bKvF91Lu21EKGQWYS6lOBbTnebu/1qGya0z0s3XS+q3y3dwJ/E+djN aXey9pAK4ZaRhLZIfgt9IqKjn8aPaQ== =dWr1 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Apr 12 02:48:28 2019 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 3699612022B for ; Fri, 12 Apr 2019 02:48:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordicsemi.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1-oNQQbZ0pGl for ; Fri, 12 Apr 2019 02:48:23 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40063.outbound.protection.outlook.com [40.107.4.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 205A812022A for ; Fri, 12 Apr 2019 02:48:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nordicsemi.onmicrosoft.com; s=selector1-nordicsemi-no; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZZYpr37kAOUoFMLowIYdF47seZG4JH0HetkqfeTc+pE=; b=Xift9LlHViNJu78y66lbor62YUazhOo4vrpS1MY/d+M0UJbGKi96pVyuBZ1v5EsATtz5hE8J13+NcmYHxsjVTQdl/ZeVLO32Y5GLeT+EzVpa0FpiAAFb66nXachb2OnlmokuLvRT+VsSXay+iIsMAsejuT+giTS7xCjqxio1fo8= Received: from AM6PR05MB6375.eurprd05.prod.outlook.com (20.179.5.214) by AM6PR05MB6406.eurprd05.prod.outlook.com (20.179.6.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.14; Fri, 12 Apr 2019 09:48:20 +0000 Received: from AM6PR05MB6375.eurprd05.prod.outlook.com ([fe80::98d9:6e05:1b71:2090]) by AM6PR05MB6375.eurprd05.prod.outlook.com ([fe80::98d9:6e05:1b71:2090%4]) with mapi id 15.20.1792.009; Fri, 12 Apr 2019 09:48:20 +0000 From: =?iso-8859-1?Q?Kvamtr=F8=2C_Frank_Audun?= To: "Waltermire, David A. (Fed)" , =?iso-8859-1?Q?R=F8nningstad=2C_=D8yvind?= , Brendan Moran , "suit@ietf.org" Thread-Topic: Introducing draft-moran-suit-manifest-04 Thread-Index: AQHU2L81dzELNCQKcEaCHfQ8cPehA6Y2x2+wgABw2OCAAAtb8IABCyQg Date: Fri, 12 Apr 2019 09:48:20 +0000 Message-ID: References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com> In-Reply-To: Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=frank.kvamtro@nordicsemi.no; x-originating-ip: [194.19.86.146] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ebd6fa7b-a427-427f-3f2d-08d6bf2bff38 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:AM6PR05MB6406; x-ms-traffictypediagnostic: AM6PR05MB6406: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39850400004)(136003)(346002)(396003)(366004)(199004)(13464003)(189003)(26005)(6116002)(71200400001)(446003)(33656002)(11346002)(305945005)(14454004)(76176011)(2501003)(25786009)(186003)(102836004)(74316002)(5660300002)(99286004)(106356001)(105586002)(45776006)(966005)(478600001)(6506007)(53546011)(93886005)(68736007)(7696005)(97736004)(7736002)(3846002)(6436002)(81156014)(9686003)(316002)(110136005)(8936002)(6246003)(8676002)(14444005)(55016002)(6306002)(486006)(229853002)(52536014)(53936002)(256004)(74482002)(2906002)(66066001)(71190400001)(66574012)(476003)(86362001)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR05MB6406; H:AM6PR05MB6375.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nordicsemi.no does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: n2xNWKYSQFzzEyr/8n4Rv/4kdjoj+21FBo+elzoDjs49VNzqNhOgSURAS3aJMqyr/RA/Auqz6ANEXoyxhMfMAM31TteFwiCluR1uOsqEYCmnozZm7wImCWEYfu45Ql3ss/mjJzatkhtC3S8mXO8+J7cE6aytqdZGB27zWxjO3qWG9YHEBCycr56F2Ogs+OW3HgEIPewJfgf4HQ8iKdMHC6O4oxM3o8AM/QReg1A4AGJ0h65KNy/GueD69vUdTYwGoGrKt6N89JBRJQOzVMqMpO8xG7VNvq7cQSwwefi0s10QP2HQfYNxLPOv+Ax5Jx2Ib1syj4bAhtpTNk6RfR07ivCLppnEfS93y+uL/6Id/a79ZpmpNPwD0uUqiK5lNK7fRfKimom6DV8jCW0wpqd46m5eWRhdLiCXEbkEekT9twY= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nordicsemi.no X-MS-Exchange-CrossTenant-Network-Message-Id: ebd6fa7b-a427-427f-3f2d-08d6bf2bff38 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 09:48:20.4017 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 28e5afa2-bf6f-419a-8cf6-b31c6e9e5e8d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR05MB6406 Archived-At: Subject: Re: [Suit] Introducing draft-moran-suit-manifest-04 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: Fri, 12 Apr 2019 09:48:27 -0000 Do note that there are no valid use-cases for heavily truncated hashes in our information model. All hashes are exclusively used for security. This makes me want to limit non-standard definitions that can be misused and/or misunderstood. When the RFC talks about the truncated hash they mention security specifica= lly: "... Therefore, we use different hash algorithm strings in these cases,=20 such as sha-256-32 for a 32-bit truncation of a sha-256 output. A 32-bit= =20 truncated hash is essentially useless for security in almost all cases bu= t=20 might be useful for naming." Where we source the list to use in manifest of the hash types is the big=20 question... I often times go to the following web-page to find the latest on recommende= d hashes etc: https://www.keylength.com/en/4/ This page lists the approved hashes as sourced from NIST specs: >From FIPS 180-4: SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256 (Where SHA-384 is essentially SHA-512/384) >From FIPS 202: SHA3-224,SHA3-256, SHA3-384,SHA3-512, SHAKE128, SHAKE256. I would like to reference the Cryptographic Algorithm Object Registration from NIST for the ASN.1 encoding of approved cryptographic algorithms. https://csrc.nist.rip/groups/ST/crypto_apps_infra/csor/algorithms.html SHA-1 (Externally assigned) SHA-2 family id-sha256 OBJECT IDENTIFIER ::=3D { hashAlgs 1 } id-sha384 OBJECT IDENTIFIER ::=3D { hashAlgs 2 } id-sha512 OBJECT IDENTIFIER ::=3D { hashAlgs 3 } id-sha224 OBJECT IDENTIFIER ::=3D { hashAlgs 4 } id-sha512-224 OBJECT IDENTIFIER ::=3D { hashAlgs 5 } id-sha512-256 OBJECT IDENTIFIER ::=3D { hashAlgs 6 } SHA-3 family id-sha3-224 OBJECT IDENTIFIER ::=3D { hashAlgs 7 } id-sha3-256 OBJECT IDENTIFIER ::=3D { hashAlgs 8 } id-sha3-384 OBJECT IDENTIFIER ::=3D { hashAlgs 9 } id-sha3-512 OBJECT IDENTIFIER ::=3D { hashAlgs 10 } id-shake128 OBJECT IDENTIFIER ::=3D { hashAlgs 11 } id-shake256 OBJECT IDENTIFIER ::=3D { hashAlgs 12 } id-shake128-len OBJECT IDENTIFIER ::=3D { hashAlgs 17 } id-shake256-len OBJECT IDENTIFIER ::=3D { hashAlgs 18 } Using this should provide the complete list of recommended and approved hashes, formatted as the IETF SUIT spec, semi-conformant to the=20 "Named Information Hash Algorithm Registry": algorithm-id-sha-256 =3D 1 algorithm-id-sha-384 =3D 2 algorithm-id-sha-512 =3D 3 algorithm-id-sha-224 =3D 4 algorithm-id-sha-512-224 =3D 5 algorithm-id-sha-512-256 =3D 6 algorithm-id-sha3-224 =3D 7 algorithm-id-sha3-256 =3D 8 algorithm-id-sha3-384 =3D 9 algorithm-id-sha3-512 =3D 10 digest-algorithm-ids /=3D algorithm-id-sha-256 =20 digest-algorithm-ids /=3D algorithm-id-sha-384 =20 digest-algorithm-ids /=3D algorithm-id-sha-512 =20 digest-algorithm-ids /=3D algorithm-id-sha-224 =20 digest-algorithm-ids /=3D algorithm-id-sha-512-224 digest-algorithm-ids /=3D algorithm-id-sha-512-256 digest-algorithm-ids /=3D algorithm-id-sha3-224 digest-algorithm-ids /=3D algorithm-id-sha3-256 digest-algorithm-ids /=3D algorithm-id-sha3-384 digest-algorithm-ids /=3D algorithm-id-sha3-512 Note that SHA-1 is removed from this list due to being a "legacy" type hash (known to be broken). SHAKE is also removed as it isn't directly approved due to the complexity of use. Note that I've added a dash between "sha" and "256" according to spec and consistent with "Named Information Hash Algorithm Registry". Additional hashes may also be easy to add, like KECCAC. I recommend reusing the algorithm IDs from ASN.1 in lack of any meaningful listing, elsewhere. -Frank Audun > -----Original Message----- > From: Waltermire, David A. (Fed) > Sent: 11. april 2019 17:49 > To: R=F8nningstad, =D8yvind ; Brendan M= oran > ; suit@ietf.org > Cc: Kvamtr=F8, Frank Audun > Subject: RE: Introducing draft-moran-suit-manifest-04 >=20 > Some comments on =D8yvind's comments below as a WG participant. >=20 > > -----Original Message----- > > From: Suit On Behalf Of R=F8nningstad, =D8yvind > > Sent: Thursday, April 11, 2019 11:03 AM > > To: Brendan Moran ; suit@ietf.org > > Cc: Kvamtr=F8, Frank Audun > > Subject: [Suit] FW: Introducing draft-moran-suit-manifest-04 > > > > I did a full pass through the document today, and wrote down (quite a > > few) comments, see below. I think this document is very exciting! > > > > - =D8yvind > > > > > > The digest-algorithm-ids list is missing the following SHA-2 family > functions: > > - SHA224 > > - SHA512/224 > > - SHA512/256 > > Also, the functions that are truncated to 128 and fewer bits will not > > be secure against brute-force attacks, so I question their inclusion he= re. >=20 > RFC 6920, which this draft references, defines the IANA "Named Informatio= n > Hash Algorithm Registry". It would be good if this draft directly referen= ces > the "Named Information Hash Algorithm Registry" directly to provide for > future agility as new algorithms are added and use of specific algorithms > fall out of practice. The "status" field of the registry provides guidanc= e > for the later. Algorithm agility should also be discussed in the security > considerations. >=20 > It would also be useful to allow non-enumerated integer values to be used= in > the format to ensure that new entries added to the "Named Information Has= h > Algorithm Registry" are also allowed to be used in the format. >=20 > Regards, > Dave From nobody Fri Apr 12 07:00:21 2019 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 14BC9120297 for ; Fri, 12 Apr 2019 07:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordicsemi.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IT4olpVMONaw for ; Fri, 12 Apr 2019 07:00:15 -0700 (PDT) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-eopbgr150055.outbound.protection.outlook.com [40.107.15.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A696D120646 for ; Fri, 12 Apr 2019 07:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nordicsemi.onmicrosoft.com; s=selector1-nordicsemi-no; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jgBCpKdzdzxtJCm8qm5q3kEim+4FSznGmxMHPdvOuVo=; b=Dz+d0Nm+YVDVO8WggKhKZFnVmabtMp0ad1GTvU9cFjDHcCmDRJB/yON+mgVkkqnJW9EQzOSy6sWrwpoHNeMtnWTKJehmb5x4R8GEZlrE+u9/H1/F5vpFO2Z5QdeUdhbJrMJEZ9Eemjw0A6b64BMBRjVGFfI2fhYXPXfPUYMCL/c= Received: from HE1PR05MB3228.eurprd05.prod.outlook.com (10.170.243.14) by HE1PR05MB3161.eurprd05.prod.outlook.com (10.170.242.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.19; Fri, 12 Apr 2019 14:00:11 +0000 Received: from HE1PR05MB3228.eurprd05.prod.outlook.com ([fe80::d913:f7c4:f82:e58e]) by HE1PR05MB3228.eurprd05.prod.outlook.com ([fe80::d913:f7c4:f82:e58e%4]) with mapi id 15.20.1771.021; Fri, 12 Apr 2019 14:00:11 +0000 From: =?iso-8859-1?Q?R=F8nningstad=2C_=D8yvind?= To: Russ Housley , suit Thread-Topic: [Suit] DRAFT SUIT Agenda for IETF 104 Thread-Index: AQHUzS0RwG7wnjAe2kqI1gcEhG+bv6Y41McQ Date: Fri, 12 Apr 2019 14:00:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Oyvind.Ronningstad@nordicsemi.no; x-originating-ip: [2001:8c0:5140:12:b5e7:e1e6:a6e9:8320] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f98f6991-0ac7-4240-efde-08d6bf4f2dc7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:HE1PR05MB3161; x-ms-traffictypediagnostic: HE1PR05MB3161: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(396003)(366004)(346002)(136003)(376002)(189003)(199004)(13464003)(33656002)(74482002)(14454004)(966005)(72206003)(478600001)(4744005)(25786009)(71200400001)(71190400001)(316002)(99286004)(55016002)(6306002)(6246003)(53936002)(9686003)(86362001)(110136005)(45776006)(97736004)(229853002)(6436002)(6116002)(8676002)(81156014)(81166006)(8936002)(2906002)(105586002)(186003)(76176011)(68736007)(74316002)(7696005)(52536014)(6506007)(53546011)(7736002)(256004)(305945005)(106356001)(446003)(476003)(486006)(5660300002)(11346002)(102836004)(46003); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR05MB3161; H:HE1PR05MB3228.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nordicsemi.no does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: sNRYZY+U2/yJTxOyS0sZwPxRXtp9spJ8h3cCaoKgnR9/FRDrMGm6pKDP5tXQ1HDG+cyfnclVJmygKyQvzNtsP/bcGrGt1PWHYYu90qhs/4uaJKVY8b3Y7snPuGneNl6jwq0O+VK2dlRAHs3s7isrbNDNstSVolomaRrH+2c05rITgZJMI5DcHvQlxjvnNDPpzM6aI9j7CSLsO4ALgOCzMFvyS0k4xSSP/+8btBnUUZExAVmKdukgaofnmmnihZn5bf0vPKKD/LKo7efzb3eS1FNcb5Wt2bbMfBJw9G9EX517VY1geUhAz0E7TK9tVkY9vATHyRTWnOPbEw1Qky+fMgC7NRn5CHYqRK3cwOsex8Glg6842SvS5BEMd+ZIcwtjKmOBVVBIYTSPQ7s+Z/ZX4c4KqpqiOkjD583Efgc0494= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nordicsemi.no X-MS-Exchange-CrossTenant-Network-Message-Id: f98f6991-0ac7-4240-efde-08d6bf4f2dc7 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 14:00:10.8961 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 28e5afa2-bf6f-419a-8cf6-b31c6e9e5e8d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR05MB3161 Archived-At: Subject: Re: [Suit] DRAFT SUIT Agenda for IETF 104 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: Fri, 12 Apr 2019 14:00:18 -0000 Hi guys, will there be minutes posted from this? =D8yvind -----Original Message----- From: Suit On Behalf Of Russ Housley Sent: Monday, February 25, 2019 18:11 To: suit Subject: [Suit] DRAFT SUIT Agenda for IETF 104 These are the topics that the WG Chairs envision for the agenda in Prague. = Any others? Please reach out to the WG Chairs if you want to make a presentation. Russ & Dave & Dave =3D =3D =3D =3D =3D 0) Blue sheets, jabber scribe, minutes 1) Agenda bashing, Logistics 2) Liaison Statement from ITU-T SG17 3) Hackathon Report 4) Suit Architecture 5) Suit Information Model 6) Suit Manifest Format 7) Next Steps _______________________________________________ Suit mailing list Suit@ietf.org https://www.ietf.org/mailman/listinfo/suit From nobody Fri Apr 12 07:06:23 2019 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 E7BF01205D6 for ; Fri, 12 Apr 2019 07:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 YGS0d2-3yOYG for ; Fri, 12 Apr 2019 07:06:16 -0700 (PDT) Received: from GCC01-CY1-obe.outbound.protection.outlook.com (mail-eopbgr830104.outbound.protection.outlook.com [40.107.83.104]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7283120419 for ; Fri, 12 Apr 2019 07:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=btdL/dqjh5dvR24J9fMAxD9c0sIOMTnJ6J+1FjDzb5A=; b=oFK6wp+7nNFJ8Ey9i+0ngQoB6g5KwCeLE2yGG9aaOAwvnHY18LgEIirwBqZR7JCH+wOjZ7eRQsZ4GcJ8I8s4SZsFD1bmrYDgLy4P8CAuLycJ6JZC+S5YewMfJjkJNRzhdsulX8Ekje0jEh3y+Usjt2mVCLEdnjECvSJ21TZMWZY= Received: from SN6PR09MB3264.namprd09.prod.outlook.com (20.177.251.21) by SN6PR09MB3261.namprd09.prod.outlook.com (20.177.251.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.17; Fri, 12 Apr 2019 14:06:14 +0000 Received: from SN6PR09MB3264.namprd09.prod.outlook.com ([fe80::d40a:9312:f1f:9048]) by SN6PR09MB3264.namprd09.prod.outlook.com ([fe80::d40a:9312:f1f:9048%5]) with mapi id 15.20.1792.016; Fri, 12 Apr 2019 14:06:14 +0000 From: "Waltermire, David A. (Fed)" To: =?iso-8859-1?Q?Kvamtr=F8=2C_Frank_Audun?= , =?iso-8859-1?Q?R=F8nningstad=2C_=D8yvind?= , Brendan Moran , "suit@ietf.org" Thread-Topic: Introducing draft-moran-suit-manifest-04 Thread-Index: AQHU2L81dzELNCQKcEaCHfQ8cPehA6Y2x2+wgABw2OCAAAtb8IABCyQggABunaA= Date: Fri, 12 Apr 2019 14:06:13 +0000 Message-ID: References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.225.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dadb3927-77dc-442e-06cf-08d6bf500620 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:SN6PR09MB3261; x-ms-traffictypediagnostic: SN6PR09MB3261: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39850400004)(346002)(376002)(136003)(13464003)(199004)(189003)(110136005)(6246003)(3846002)(6436002)(86362001)(93886005)(6116002)(486006)(105586002)(68736007)(97736004)(71200400001)(476003)(316002)(33656002)(106356001)(99286004)(305945005)(446003)(71190400001)(8936002)(45080400002)(55016002)(478600001)(52536014)(74316002)(11346002)(229853002)(7736002)(5660300002)(6306002)(966005)(25786009)(102836004)(53546011)(6506007)(2906002)(81156014)(81166006)(26005)(14454004)(66574012)(7696005)(9686003)(76176011)(53936002)(14444005)(186003)(8676002)(2501003)(66066001)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR09MB3261; H:SN6PR09MB3264.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 9lPfIFVECbDFoGLMlJJHpe8Jtz7kzQOakkZsY6iaL35xt/Jwh8ugAd1TFoC/Jr+VHwmFyRzE6OLjukCVy2hu9d5H6UE252ivCoH24vffQ66iLPxB3Ua1vmFSfrBeFjf0aTko9jf2as38akiRu9/kCkHC+V7FM3UxgeFC/XvdkBGVIhgW8xwo0+0IIz7DPLvxkEj++OG+822GidVaziC0aRL4SJr++2ewz+m3GZ/gonO3r8i7ZfY2e844yNBLUuk44C+TmsdUfd8xoZfkvcg7X68DRQT1G87B0jWv5XFwegVEeiZ8XlxZ/gdmb/Suq2WpZ0Zh8XwZkCWTXxcIN2OGkxODvOwE9po/3af+nyUsDW8rXWPmWzKJstO3N8YO9+C46zNURBPbr3LrWpJ730QUjx3vwYpPe9AtgWNDSMwuT90= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: dadb3927-77dc-442e-06cf-08d6bf500620 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 14:06:13.9624 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR09MB3261 Archived-At: Subject: Re: [Suit] Introducing draft-moran-suit-manifest-04 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: Fri, 12 Apr 2019 14:06:21 -0000 Do we know anything about the permanence of and the process used to curate = https://www.keylength.com/en/4/? The advantage of using IANA is that we can= have confidence that the registry will exist and a known set of processes = for managing it. Alternately, could we write a small draft to add any missing hash algorithm= s (SHAKE128, SHAKE256, etc) to the Named Information Hash Algorithm Registr= y? This would allow the manifest to use the index values from the registry = instead of defining a new enumeration. Could we then say something in security considerations about the truncated = hashes and their security properties referencing RFC6920? Regards, Dave > -----Original Message----- > From: Kvamtr=F8, Frank Audun > Sent: Friday, April 12, 2019 5:48 AM > To: Waltermire, David A. (Fed) ; R=F8nningstad= , > =D8yvind ; Brendan Moran > ; suit@ietf.org > Subject: RE: Introducing draft-moran-suit-manifest-04 >=20 > Do note that there are no valid use-cases for heavily truncated hashes in= our > information model. All hashes are exclusively used for security. > This makes me want to limit non-standard definitions that can be misused > and/or misunderstood. >=20 > When the RFC talks about the truncated hash they mention security > specifically: >=20 > "... Therefore, we use different hash algorithm strings in these cases, > such as sha-256-32 for a 32-bit truncation of a sha-256 output. A 32-b= it > truncated hash is essentially useless for security in almost all cases = but > might be useful for naming." >=20 >=20 > Where we source the list to use in manifest of the hash types is the big > question... >=20 > I often times go to the following web-page to find the latest on > recommended hashes etc: > https://gcc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > keylength.com%2Fen%2F4%2F&data=3D02%7C01%7Cdavid.waltermire% > 40nist.gov%7C4a660097d25a453e13e208d6bf2c06ff%7C2ab5d82fd8fa4797a > 93e054655c61dec%7C1%7C0%7C636906593156044698&sdata=3DPGgJTO > l48DmN9onJtbkogKWAGB%2FJ9omRAeZDX2OOobA%3D&reserved=3D0 >=20 > This page lists the approved hashes as sourced from NIST specs: >=20 > From FIPS 180-4: > SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256 >=20 > (Where SHA-384 is essentially SHA-512/384) >=20 > From FIPS 202: > SHA3-224,SHA3-256, SHA3-384,SHA3-512, SHAKE128, SHAKE256. >=20 >=20 > I would like to reference the Cryptographic Algorithm Object Registration > from NIST for the ASN.1 encoding of approved cryptographic algorithms. >=20 > https://gcc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fcsrc.= n > ist.rip%2Fgroups%2FST%2Fcrypto_apps_infra%2Fcsor%2Falgorithms.html&a > mp;data=3D02%7C01%7Cdavid.waltermire%40nist.gov%7C4a660097d25a453e > 13e208d6bf2c06ff%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C > 636906593156044698&sdata=3DVPHEv850i7bKsIbUsdx7Pc8o8j7xnTPDKsv > R%2B4qeEaE%3D&reserved=3D0 >=20 > SHA-1 (Externally assigned) > SHA-2 family > id-sha256 OBJECT IDENTIFIER ::=3D { hashAlgs 1 } > id-sha384 OBJECT IDENTIFIER ::=3D { hashAlgs 2 } > id-sha512 OBJECT IDENTIFIER ::=3D { hashAlgs 3 } > id-sha224 OBJECT IDENTIFIER ::=3D { hashAlgs 4 } > id-sha512-224 OBJECT IDENTIFIER ::=3D { hashAlgs 5 } > id-sha512-256 OBJECT IDENTIFIER ::=3D { hashAlgs 6 } >=20 > SHA-3 family > id-sha3-224 OBJECT IDENTIFIER ::=3D { hashAlgs 7 } > id-sha3-256 OBJECT IDENTIFIER ::=3D { hashAlgs 8 } > id-sha3-384 OBJECT IDENTIFIER ::=3D { hashAlgs 9 } > id-sha3-512 OBJECT IDENTIFIER ::=3D { hashAlgs 10 } > id-shake128 OBJECT IDENTIFIER ::=3D { hashAlgs 11 } > id-shake256 OBJECT IDENTIFIER ::=3D { hashAlgs 12 } id-shake128-len OBJEC= T > IDENTIFIER ::=3D { hashAlgs 17 } id-shake256-len OBJECT IDENTIFIER ::=3D = { > hashAlgs 18 } >=20 >=20 > Using this should provide the complete list of recommended and approved > hashes, formatted as the IETF SUIT spec, semi-conformant to the "Named > Information Hash Algorithm Registry": >=20 > algorithm-id-sha-256 =3D 1 > algorithm-id-sha-384 =3D 2 > algorithm-id-sha-512 =3D 3 > algorithm-id-sha-224 =3D 4 > algorithm-id-sha-512-224 =3D 5 > algorithm-id-sha-512-256 =3D 6 > algorithm-id-sha3-224 =3D 7 > algorithm-id-sha3-256 =3D 8 > algorithm-id-sha3-384 =3D 9 > algorithm-id-sha3-512 =3D 10 >=20 > digest-algorithm-ids /=3D algorithm-id-sha-256 > digest-algorithm-ids /=3D algorithm-id-sha-384 > digest-algorithm-ids /=3D algorithm-id-sha-512 > digest-algorithm-ids /=3D algorithm-id-sha-224 > digest-algorithm-ids /=3D algorithm-id-sha-512-224 digest-algorithm-ids /= =3D > algorithm-id-sha-512-256 digest-algorithm-ids /=3D algorithm-id-sha3-224 > digest-algorithm-ids /=3D algorithm-id-sha3-256 digest-algorithm-ids /=3D > algorithm-id-sha3-384 digest-algorithm-ids /=3D algorithm-id-sha3-512 >=20 > Note that SHA-1 is removed from this list due to being a "legacy" type ha= sh > (known to be broken). SHAKE is also removed as it isn't directly approved > due to the complexity of use. >=20 > Note that I've added a dash between "sha" and "256" according to spec and > consistent with "Named Information Hash Algorithm Registry". >=20 > Additional hashes may also be easy to add, like KECCAC. >=20 > I recommend reusing the algorithm IDs from ASN.1 in lack of any meaningfu= l > listing, elsewhere. >=20 > -Frank Audun >=20 > > -----Original Message----- > > From: Waltermire, David A. (Fed) > > Sent: 11. april 2019 17:49 > > To: R=F8nningstad, =D8yvind ; Brendan > > Moran ; suit@ietf.org > > Cc: Kvamtr=F8, Frank Audun > > Subject: RE: Introducing draft-moran-suit-manifest-04 > > > > Some comments on =D8yvind's comments below as a WG participant. > > > > > -----Original Message----- > > > From: Suit On Behalf Of R=F8nningstad, =D8yvi= nd > > > Sent: Thursday, April 11, 2019 11:03 AM > > > To: Brendan Moran ; suit@ietf.org > > > Cc: Kvamtr=F8, Frank Audun > > > Subject: [Suit] FW: Introducing draft-moran-suit-manifest-04 > > > > > > I did a full pass through the document today, and wrote down (quite > > > a > > > few) comments, see below. I think this document is very exciting! > > > > > > - =D8yvind > > > > > > > > > The digest-algorithm-ids list is missing the following SHA-2 family > > functions: > > > - SHA224 > > > - SHA512/224 > > > - SHA512/256 > > > Also, the functions that are truncated to 128 and fewer bits will > > > not be secure against brute-force attacks, so I question their inclus= ion > here. > > > > RFC 6920, which this draft references, defines the IANA "Named > > Information Hash Algorithm Registry". It would be good if this draft > > directly references the "Named Information Hash Algorithm Registry" > > directly to provide for future agility as new algorithms are added and > > use of specific algorithms fall out of practice. The "status" field of > > the registry provides guidance for the later. Algorithm agility should > > also be discussed in the security considerations. > > > > It would also be useful to allow non-enumerated integer values to be > > used in the format to ensure that new entries added to the "Named > > Information Hash Algorithm Registry" are also allowed to be used in the > format. > > > > Regards, > > Dave From nobody Fri Apr 12 07:36:50 2019 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 ABABA1207AE for ; Fri, 12 Apr 2019 07:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordicsemi.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJM9WTPj3oJq for ; Fri, 12 Apr 2019 07:36:38 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0628.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::628]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6346312077D for ; Fri, 12 Apr 2019 07:36:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nordicsemi.onmicrosoft.com; s=selector1-nordicsemi-no; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iwK9ZzO2aOs4oWrQOyVXaIPosLFu8ODVhBmTriKorkE=; b=hbakG3DJlhdVnPk9F2p8o6s7UEp+j6pN3FDKr0ZL+IgNLX+4zJy/IOL3bKkiftuYL6rn2TC/EqynAjYUP5WLQqk2/WHwn78qtEfZtdqEpnmIrO1XYOGA5HfB18pQK9snL6jfRNbmXQkCmJHJzS5s05y4wS3cj+SFqQfunGwVTG4= Received: from AM6PR05MB6375.eurprd05.prod.outlook.com (20.179.5.214) by AM6PR05MB6136.eurprd05.prod.outlook.com (20.179.3.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.21; Fri, 12 Apr 2019 14:36:32 +0000 Received: from AM6PR05MB6375.eurprd05.prod.outlook.com ([fe80::98d9:6e05:1b71:2090]) by AM6PR05MB6375.eurprd05.prod.outlook.com ([fe80::98d9:6e05:1b71:2090%4]) with mapi id 15.20.1792.009; Fri, 12 Apr 2019 14:36:32 +0000 From: =?iso-8859-1?Q?Kvamtr=F8=2C_Frank_Audun?= To: "Waltermire, David A. (Fed)" , =?iso-8859-1?Q?R=F8nningstad=2C_=D8yvind?= , Brendan Moran , "suit@ietf.org" Thread-Topic: Introducing draft-moran-suit-manifest-04 Thread-Index: AQHU2L81dzELNCQKcEaCHfQ8cPehA6Y2x2+wgABw2OCAAAtb8IABCyQggABunaCAAAQtoA== Date: Fri, 12 Apr 2019 14:36:31 +0000 Message-ID: References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com> In-Reply-To: Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=frank.kvamtro@nordicsemi.no; x-originating-ip: [194.19.86.146] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dbeb0a51-ad1e-488e-1e8c-08d6bf5441c1 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:AM6PR05MB6136; x-ms-traffictypediagnostic: AM6PR05MB6136: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(346002)(376002)(39850400004)(366004)(136003)(396003)(189003)(199004)(13464003)(476003)(26005)(11346002)(5660300002)(66066001)(9686003)(446003)(8936002)(6306002)(229853002)(99286004)(97736004)(7696005)(106356001)(3846002)(6506007)(105586002)(486006)(110136005)(966005)(478600001)(186003)(6246003)(81156014)(102836004)(6116002)(33656002)(53546011)(81166006)(76176011)(316002)(8676002)(71190400001)(53936002)(93886005)(45080400002)(68736007)(6436002)(74482002)(74316002)(71200400001)(45776006)(52536014)(14444005)(7736002)(2906002)(86362001)(55016002)(305945005)(14454004)(2501003)(66574012)(25786009)(256004)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR05MB6136; H:AM6PR05MB6375.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nordicsemi.no does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: mbP+sCt3B4SkDmTKcTWJwBJ443r/qsmAhJU2km1jTgAslJEXOESQWAMPnJd1STXWa224kyinZExutalZbNklcv0KoCOI03SLXKZmYDIhKs3eqj+dt62b48IameQNoAJqckXSPcBXpnV6juARsP/pB7MjJD6ge93tY6dbq4AyYQlUIZkJpTBpCejl/OLUhFeqC97moAt327sho9Hep6NMlgYESUytucRH0fY9OlGVj1HRNcCFWUOoP1rSebn1HBPbXOAsbDbvXaRxEMUpu/cceDUw+GR4b8gUQKCYXdbkWf0ZNUPpHixJo3mIAXRl/e+WMFFY4ZHynGmbnV1duWQ2D7lxewLo5e0JbZKhsJzpWQwDM+oFsail0dRwhAT78ETqKzafCoEcDKqB/UMNMj64nLAd/kiugb4cscZnx4qqxWU= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nordicsemi.no X-MS-Exchange-CrossTenant-Network-Message-Id: dbeb0a51-ad1e-488e-1e8c-08d6bf5441c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 14:36:31.9646 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 28e5afa2-bf6f-419a-8cf6-b31c6e9e5e8d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR05MB6136 Archived-At: Subject: Re: [Suit] Introducing draft-moran-suit-manifest-04 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: Fri, 12 Apr 2019 14:36:49 -0000 Total agreement on finding stable curated list, and hopefully this is a lis= t that can be one named "secure hashes" corresponding to active standards. The Cryptographic Algorithm Object Registration from NIST seems to do exact= ly that, with Object IDs that are stable. I know this is ASN.1 but it seems easy to convert to pure integer Object IDs. https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorithm= -Registration#Hash -Frank Audun > -----Original Message----- > From: Waltermire, David A. (Fed) > Sent: 12. april 2019 16:06 > To: Kvamtr=F8, Frank Audun ; R=F8nningstad, = =D8yvind > ; Brendan Moran = ; > suit@ietf.org > Subject: RE: Introducing draft-moran-suit-manifest-04 >=20 > Do we know anything about the permanence of and the process used to curat= e > https://www.keylength.com/en/4/? The advantage of using IANA is that we c= an > have confidence that the registry will exist and a known set of processes > for managing it. >=20 > Alternately, could we write a small draft to add any missing hash algorit= hms > (SHAKE128, SHAKE256, etc) to the Named Information Hash Algorithm Registr= y? > This would allow the manifest to use the index values from the registry > instead of defining a new enumeration. >=20 > Could we then say something in security considerations about the truncate= d > hashes and their security properties referencing RFC6920? >=20 > Regards, > Dave >=20 > > -----Original Message----- > > From: Kvamtr=F8, Frank Audun > > Sent: Friday, April 12, 2019 5:48 AM > > To: Waltermire, David A. (Fed) ; > > R=F8nningstad, =D8yvind ; Brendan Mor= an > > ; suit@ietf.org > > Subject: RE: Introducing draft-moran-suit-manifest-04 > > > > Do note that there are no valid use-cases for heavily truncated hashes > > in our information model. All hashes are exclusively used for security. > > This makes me want to limit non-standard definitions that can be > > misused and/or misunderstood. > > > > When the RFC talks about the truncated hash they mention security > > specifically: > > > > "... Therefore, we use different hash algorithm strings in these case= s, > > such as sha-256-32 for a 32-bit truncation of a sha-256 output. A 32= - > bit > > truncated hash is essentially useless for security in almost all case= s > but > > might be useful for naming." > > > > > > Where we source the list to use in manifest of the hash types is the > > big question... > > > > I often times go to the following web-page to find the latest on > > recommended hashes etc: > > https://gcc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > keylength.com%2Fen%2F4%2F&data=3D02%7C01%7Cdavid.waltermire% > > 40nist.gov%7C4a660097d25a453e13e208d6bf2c06ff%7C2ab5d82fd8fa4797a > > 93e054655c61dec%7C1%7C0%7C636906593156044698&sdata=3DPGgJTO > > l48DmN9onJtbkogKWAGB%2FJ9omRAeZDX2OOobA%3D&reserved=3D0 > > > > This page lists the approved hashes as sourced from NIST specs: > > > > From FIPS 180-4: > > SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and SHA-512/256 > > > > (Where SHA-384 is essentially SHA-512/384) > > > > From FIPS 202: > > SHA3-224,SHA3-256, SHA3-384,SHA3-512, SHAKE128, SHAKE256. > > > > > > I would like to reference the Cryptographic Algorithm Object > > Registration from NIST for the ASN.1 encoding of approved cryptographic > algorithms. > > > > https://gcc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fcsr= c > > .n > > ist.rip%2Fgroups%2FST%2Fcrypto_apps_infra%2Fcsor%2Falgorithms.html&a > > mp;data=3D02%7C01%7Cdavid.waltermire%40nist.gov%7C4a660097d25a453e > > 13e208d6bf2c06ff%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C > > 636906593156044698&sdata=3DVPHEv850i7bKsIbUsdx7Pc8o8j7xnTPDKsv > > R%2B4qeEaE%3D&reserved=3D0 > > > > SHA-1 (Externally assigned) > > SHA-2 family > > id-sha256 OBJECT IDENTIFIER ::=3D { hashAlgs 1 } > > id-sha384 OBJECT IDENTIFIER ::=3D { hashAlgs 2 } > > id-sha512 OBJECT IDENTIFIER ::=3D { hashAlgs 3 } > > id-sha224 OBJECT IDENTIFIER ::=3D { hashAlgs 4 } > > id-sha512-224 OBJECT IDENTIFIER ::=3D { hashAlgs 5 } > > id-sha512-256 OBJECT IDENTIFIER ::=3D { hashAlgs 6 } > > > > SHA-3 family > > id-sha3-224 OBJECT IDENTIFIER ::=3D { hashAlgs 7 } > > id-sha3-256 OBJECT IDENTIFIER ::=3D { hashAlgs 8 } > > id-sha3-384 OBJECT IDENTIFIER ::=3D { hashAlgs 9 } > > id-sha3-512 OBJECT IDENTIFIER ::=3D { hashAlgs 10 } > > id-shake128 OBJECT IDENTIFIER ::=3D { hashAlgs 11 } > > id-shake256 OBJECT IDENTIFIER ::=3D { hashAlgs 12 } id-shake128-len > > OBJECT IDENTIFIER ::=3D { hashAlgs 17 } id-shake256-len OBJECT > > IDENTIFIER ::=3D { hashAlgs 18 } > > > > > > Using this should provide the complete list of recommended and > > approved hashes, formatted as the IETF SUIT spec, semi-conformant to > > the "Named Information Hash Algorithm Registry": > > > > algorithm-id-sha-256 =3D 1 > > algorithm-id-sha-384 =3D 2 > > algorithm-id-sha-512 =3D 3 > > algorithm-id-sha-224 =3D 4 > > algorithm-id-sha-512-224 =3D 5 > > algorithm-id-sha-512-256 =3D 6 > > algorithm-id-sha3-224 =3D 7 > > algorithm-id-sha3-256 =3D 8 > > algorithm-id-sha3-384 =3D 9 > > algorithm-id-sha3-512 =3D 10 > > > > digest-algorithm-ids /=3D algorithm-id-sha-256 digest-algorithm-ids /= =3D > > algorithm-id-sha-384 digest-algorithm-ids /=3D algorithm-id-sha-512 > > digest-algorithm-ids /=3D algorithm-id-sha-224 digest-algorithm-ids /= =3D > > algorithm-id-sha-512-224 digest-algorithm-ids /=3D > > algorithm-id-sha-512-256 digest-algorithm-ids /=3D algorithm-id-sha3-22= 4 > > digest-algorithm-ids /=3D algorithm-id-sha3-256 digest-algorithm-ids /= =3D > > algorithm-id-sha3-384 digest-algorithm-ids /=3D algorithm-id-sha3-512 > > > > Note that SHA-1 is removed from this list due to being a "legacy" type > > hash (known to be broken). SHAKE is also removed as it isn't directly > > approved due to the complexity of use. > > > > Note that I've added a dash between "sha" and "256" according to spec > > and consistent with "Named Information Hash Algorithm Registry". > > > > Additional hashes may also be easy to add, like KECCAC. > > > > I recommend reusing the algorithm IDs from ASN.1 in lack of any > > meaningful listing, elsewhere. > > > > -Frank Audun > > > > > -----Original Message----- > > > From: Waltermire, David A. (Fed) > > > Sent: 11. april 2019 17:49 > > > To: R=F8nningstad, =D8yvind ; Brend= an > > > Moran ; suit@ietf.org > > > Cc: Kvamtr=F8, Frank Audun > > > Subject: RE: Introducing draft-moran-suit-manifest-04 > > > > > > Some comments on =D8yvind's comments below as a WG participant. > > > > > > > -----Original Message----- > > > > From: Suit On Behalf Of R=F8nningstad, > > > > =D8yvind > > > > Sent: Thursday, April 11, 2019 11:03 AM > > > > To: Brendan Moran ; suit@ietf.org > > > > Cc: Kvamtr=F8, Frank Audun > > > > Subject: [Suit] FW: Introducing draft-moran-suit-manifest-04 > > > > > > > > I did a full pass through the document today, and wrote down > > > > (quite a > > > > few) comments, see below. I think this document is very exciting! > > > > > > > > - =D8yvind > > > > > > > > > > > > The digest-algorithm-ids list is missing the following SHA-2 > > > > family > > > functions: > > > > - SHA224 > > > > - SHA512/224 > > > > - SHA512/256 > > > > Also, the functions that are truncated to 128 and fewer bits will > > > > not be secure against brute-force attacks, so I question their > > > > inclusion > > here. > > > > > > RFC 6920, which this draft references, defines the IANA "Named > > > Information Hash Algorithm Registry". It would be good if this draft > > > directly references the "Named Information Hash Algorithm Registry" > > > directly to provide for future agility as new algorithms are added > > > and use of specific algorithms fall out of practice. The "status" > > > field of the registry provides guidance for the later. Algorithm > > > agility should also be discussed in the security considerations. > > > > > > It would also be useful to allow non-enumerated integer values to be > > > used in the format to ensure that new entries added to the "Named > > > Information Hash Algorithm Registry" are also allowed to be used in > > > the > > format. > > > > > > Regards, > > > Dave From nobody Fri Apr 12 07:55:35 2019 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 A55161207DF for ; Fri, 12 Apr 2019 07:55:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nist.gov 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 BVhLa-DIE7Tq for ; Fri, 12 Apr 2019 07:55:30 -0700 (PDT) Received: from GCC01-DM2-obe.outbound.protection.outlook.com (mail-eopbgr840118.outbound.protection.outlook.com [40.107.84.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBA451207DE for ; Fri, 12 Apr 2019 07:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nist.gov; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=N1nsZ4U7o+n7QKzNTSa/TDaSPm7KQ5ni1JASd8SeFo8=; b=1VHVDxTM1kgeNO5pbTqznego5tcCMJ8eB+sV5iruMSYI2eCpttbu/P8o9RVuBRNkDRGu1KYVjLnjXs9XNOweaR315BBbK+tV3ZZMFNpqGzDxBb/5htlEtuz2bqpopXAUYCJbIN1+ixfoul85hc9sefcHs1mmBHYSh9gvj+8vIp8= Received: from SN6PR09MB3264.namprd09.prod.outlook.com (20.177.251.21) by SN6PR09MB3263.namprd09.prod.outlook.com (20.177.251.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.17; Fri, 12 Apr 2019 14:55:27 +0000 Received: from SN6PR09MB3264.namprd09.prod.outlook.com ([fe80::d40a:9312:f1f:9048]) by SN6PR09MB3264.namprd09.prod.outlook.com ([fe80::d40a:9312:f1f:9048%5]) with mapi id 15.20.1792.016; Fri, 12 Apr 2019 14:55:27 +0000 From: "Waltermire, David A. (Fed)" To: =?iso-8859-1?Q?Kvamtr=F8=2C_Frank_Audun?= , =?iso-8859-1?Q?R=F8nningstad=2C_=D8yvind?= , Brendan Moran , "suit@ietf.org" Thread-Topic: Introducing draft-moran-suit-manifest-04 Thread-Index: AQHU2L81dzELNCQKcEaCHfQ8cPehA6Y2x2+wgABw2OCAAAtb8IABCyQggABunaCAAAQtoIAACtpA Date: Fri, 12 Apr 2019 14:55:26 +0000 Message-ID: References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.waltermire@nist.gov; x-originating-ip: [129.6.225.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 774704ed-b3d1-4a71-1a99-08d6bf56e642 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:SN6PR09MB3263; x-ms-traffictypediagnostic: SN6PR09MB3263: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(366004)(136003)(39860400002)(13464003)(189003)(199004)(68736007)(71200400001)(102836004)(81166006)(74316002)(81156014)(66574012)(966005)(7736002)(66066001)(71190400001)(305945005)(14454004)(6116002)(3846002)(33656002)(2906002)(52536014)(45080400002)(6436002)(478600001)(5660300002)(6246003)(476003)(110136005)(486006)(53936002)(446003)(256004)(316002)(97736004)(99286004)(11346002)(7696005)(229853002)(2501003)(9686003)(76176011)(53546011)(8676002)(55016002)(6306002)(186003)(6506007)(26005)(105586002)(106356001)(86362001)(8936002)(25786009)(93886005)(14444005); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR09MB3263; H:SN6PR09MB3264.namprd09.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: MUEkEoFQGem5Xo0tEC+6pJSVlo0Iwrm+SewJmep/kXPL/svK3dWK78szuxdfbPkh8XFHY/rEfIWgl31eXtD8sloGpb1y0M9x1U3Yxr88XkeuYWYG+nm1VgI93afaB9HabfIWNsF23CGGASazNcuGc2njRHid52DemGEghR1HWECtzBp+M5PSeaYMn56WDqnnS3IpyOnmZesN7JRA82rIJjvCABzMkNkPcNsfBJcd0CJMIAns1HFfxffmJyJpfWk8DF2qlAdIDq0CuGNFGYgTtuZRXoz8dNO46F5VpIL2pOjsIS4WsVrgGP1mELhoKtwVrMM/ov9VHFTph0kUgW5rxq/V+YcL7yHNiGyE8t2+fkJPEOAlMl7fWq38n/xx2E0ZRg0P6NdvT3p4pTImS0yopjgw7K9el0DJLcqrLMbfulo= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 774704ed-b3d1-4a71-1a99-08d6bf56e642 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 14:55:26.8907 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR09MB3263 Archived-At: Subject: Re: [Suit] Introducing draft-moran-suit-manifest-04 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: Fri, 12 Apr 2019 14:55:34 -0000 True. My concern is that the NIST list contains only NIST approved algorith= ms.=20 The IETF may want to include a larger scope of hash algorithms that go beyo= nd those supported by NIST. Keeping this list in IANA provides for that lar= ger scope. Regards, Dave > -----Original Message----- > From: Kvamtr=F8, Frank Audun > Sent: Friday, April 12, 2019 10:37 AM > To: Waltermire, David A. (Fed) ; R=F8nningstad= , > =D8yvind ; Brendan Moran > ; suit@ietf.org > Subject: RE: Introducing draft-moran-suit-manifest-04 >=20 > Total agreement on finding stable curated list, and hopefully this is a l= ist that > can be one named "secure hashes" corresponding to active standards. >=20 > The Cryptographic Algorithm Object Registration from NIST seems to do > exactly that, with Object IDs that are stable. I know this is ASN.1 but i= t seems > easy to convert to pure integer Object IDs. >=20 > https://csrc.nist.gov/Projects/Computer-Security-Objects- > Register/Algorithm-Registration#Hash >=20 > -Frank Audun >=20 > > -----Original Message----- > > From: Waltermire, David A. (Fed) > > Sent: 12. april 2019 16:06 > > To: Kvamtr=F8, Frank Audun ; R=F8nningstad= , > > =D8yvind ; Brendan Moran > > ; suit@ietf.org > > Subject: RE: Introducing draft-moran-suit-manifest-04 > > > > Do we know anything about the permanence of and the process used to > > curate https://www.keylength.com/en/4/? The advantage of using IANA is > > that we can have confidence that the registry will exist and a known > > set of processes for managing it. > > > > Alternately, could we write a small draft to add any missing hash > > algorithms (SHAKE128, SHAKE256, etc) to the Named Information Hash > Algorithm Registry? > > This would allow the manifest to use the index values from the > > registry instead of defining a new enumeration. > > > > Could we then say something in security considerations about the > > truncated hashes and their security properties referencing RFC6920? > > > > Regards, > > Dave > > > > > -----Original Message----- > > > From: Kvamtr=F8, Frank Audun > > > Sent: Friday, April 12, 2019 5:48 AM > > > To: Waltermire, David A. (Fed) ; > > > R=F8nningstad, =D8yvind ; Brendan > > > Moran ; suit@ietf.org > > > Subject: RE: Introducing draft-moran-suit-manifest-04 > > > > > > Do note that there are no valid use-cases for heavily truncated > > > hashes in our information model. All hashes are exclusively used for > security. > > > This makes me want to limit non-standard definitions that can be > > > misused and/or misunderstood. > > > > > > When the RFC talks about the truncated hash they mention security > > > specifically: > > > > > > "... Therefore, we use different hash algorithm strings in these ca= ses, > > > such as sha-256-32 for a 32-bit truncation of a sha-256 output. A > > > 32- > > bit > > > truncated hash is essentially useless for security in almost all > > > cases > > but > > > might be useful for naming." > > > > > > > > > Where we source the list to use in manifest of the hash types is the > > > big question... > > > > > > I often times go to the following web-page to find the latest on > > > recommended hashes etc: > > > > https://gcc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. > > > > keylength.com%2Fen%2F4%2F&data=3D02%7C01%7Cdavid.waltermire% > > > > 40nist.gov%7C4a660097d25a453e13e208d6bf2c06ff%7C2ab5d82fd8fa4797a > > > > 93e054655c61dec%7C1%7C0%7C636906593156044698&sdata=3DPGgJTO > > > > l48DmN9onJtbkogKWAGB%2FJ9omRAeZDX2OOobA%3D&reserved=3D0 > > > > > > This page lists the approved hashes as sourced from NIST specs: > > > > > > From FIPS 180-4: > > > SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and > > > SHA-512/256 > > > > > > (Where SHA-384 is essentially SHA-512/384) > > > > > > From FIPS 202: > > > SHA3-224,SHA3-256, SHA3-384,SHA3-512, SHAKE128, SHAKE256. > > > > > > > > > I would like to reference the Cryptographic Algorithm Object > > > Registration from NIST for the ASN.1 encoding of approved > > > cryptographic > > algorithms. > > > > > > https://gcc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fc= s > > > rc > > > .n > > > > ist.rip%2Fgroups%2FST%2Fcrypto_apps_infra%2Fcsor%2Falgorithms.html&a > > > > mp;data=3D02%7C01%7Cdavid.waltermire%40nist.gov%7C4a660097d25a453e > > > > 13e208d6bf2c06ff%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C > > > > 636906593156044698&sdata=3DVPHEv850i7bKsIbUsdx7Pc8o8j7xnTPDKsv > > > R%2B4qeEaE%3D&reserved=3D0 > > > > > > SHA-1 (Externally assigned) > > > SHA-2 family > > > id-sha256 OBJECT IDENTIFIER ::=3D { hashAlgs 1 } > > > id-sha384 OBJECT IDENTIFIER ::=3D { hashAlgs 2 } > > > id-sha512 OBJECT IDENTIFIER ::=3D { hashAlgs 3 } > > > id-sha224 OBJECT IDENTIFIER ::=3D { hashAlgs 4 } > > > id-sha512-224 OBJECT IDENTIFIER ::=3D { hashAlgs 5 } > > > id-sha512-256 OBJECT IDENTIFIER ::=3D { hashAlgs 6 } > > > > > > SHA-3 family > > > id-sha3-224 OBJECT IDENTIFIER ::=3D { hashAlgs 7 } > > > id-sha3-256 OBJECT IDENTIFIER ::=3D { hashAlgs 8 } > > > id-sha3-384 OBJECT IDENTIFIER ::=3D { hashAlgs 9 } > > > id-sha3-512 OBJECT IDENTIFIER ::=3D { hashAlgs 10 } > > > id-shake128 OBJECT IDENTIFIER ::=3D { hashAlgs 11 } > > > id-shake256 OBJECT IDENTIFIER ::=3D { hashAlgs 12 } id-shake128-len > > > OBJECT IDENTIFIER ::=3D { hashAlgs 17 } id-shake256-len OBJECT > > > IDENTIFIER ::=3D { hashAlgs 18 } > > > > > > > > > Using this should provide the complete list of recommended and > > > approved hashes, formatted as the IETF SUIT spec, semi-conformant to > > > the "Named Information Hash Algorithm Registry": > > > > > > algorithm-id-sha-256 =3D 1 > > > algorithm-id-sha-384 =3D 2 > > > algorithm-id-sha-512 =3D 3 > > > algorithm-id-sha-224 =3D 4 > > > algorithm-id-sha-512-224 =3D 5 > > > algorithm-id-sha-512-256 =3D 6 > > > algorithm-id-sha3-224 =3D 7 > > > algorithm-id-sha3-256 =3D 8 > > > algorithm-id-sha3-384 =3D 9 > > > algorithm-id-sha3-512 =3D 10 > > > > > > digest-algorithm-ids /=3D algorithm-id-sha-256 digest-algorithm-ids /= =3D > > > algorithm-id-sha-384 digest-algorithm-ids /=3D algorithm-id-sha-512 > > > digest-algorithm-ids /=3D algorithm-id-sha-224 digest-algorithm-ids /= =3D > > > algorithm-id-sha-512-224 digest-algorithm-ids /=3D > > > algorithm-id-sha-512-256 digest-algorithm-ids /=3D > > > algorithm-id-sha3-224 digest-algorithm-ids /=3D algorithm-id-sha3-256 > > > digest-algorithm-ids /=3D > > > algorithm-id-sha3-384 digest-algorithm-ids /=3D algorithm-id-sha3-512 > > > > > > Note that SHA-1 is removed from this list due to being a "legacy" > > > type hash (known to be broken). SHAKE is also removed as it isn't > > > directly approved due to the complexity of use. > > > > > > Note that I've added a dash between "sha" and "256" according to > > > spec and consistent with "Named Information Hash Algorithm Registry". > > > > > > Additional hashes may also be easy to add, like KECCAC. > > > > > > I recommend reusing the algorithm IDs from ASN.1 in lack of any > > > meaningful listing, elsewhere. > > > > > > -Frank Audun > > > > > > > -----Original Message----- > > > > From: Waltermire, David A. (Fed) > > > > Sent: 11. april 2019 17:49 > > > > To: R=F8nningstad, =D8yvind ; > > > > Brendan Moran ; suit@ietf.org > > > > Cc: Kvamtr=F8, Frank Audun > > > > Subject: RE: Introducing draft-moran-suit-manifest-04 > > > > > > > > Some comments on =D8yvind's comments below as a WG participant. > > > > > > > > > -----Original Message----- > > > > > From: Suit On Behalf Of R=F8nningstad, > > > > > =D8yvind > > > > > Sent: Thursday, April 11, 2019 11:03 AM > > > > > To: Brendan Moran ; suit@ietf.org > > > > > Cc: Kvamtr=F8, Frank Audun > > > > > Subject: [Suit] FW: Introducing draft-moran-suit-manifest-04 > > > > > > > > > > I did a full pass through the document today, and wrote down > > > > > (quite a > > > > > few) comments, see below. I think this document is very exciting! > > > > > > > > > > - =D8yvind > > > > > > > > > > > > > > > The digest-algorithm-ids list is missing the following SHA-2 > > > > > family > > > > functions: > > > > > - SHA224 > > > > > - SHA512/224 > > > > > - SHA512/256 > > > > > Also, the functions that are truncated to 128 and fewer bits > > > > > will not be secure against brute-force attacks, so I question > > > > > their inclusion > > > here. > > > > > > > > RFC 6920, which this draft references, defines the IANA "Named > > > > Information Hash Algorithm Registry". It would be good if this > > > > draft directly references the "Named Information Hash Algorithm > Registry" > > > > directly to provide for future agility as new algorithms are added > > > > and use of specific algorithms fall out of practice. The "status" > > > > field of the registry provides guidance for the later. Algorithm > > > > agility should also be discussed in the security considerations. > > > > > > > > It would also be useful to allow non-enumerated integer values to > > > > be used in the format to ensure that new entries added to the > > > > "Named Information Hash Algorithm Registry" are also allowed to be > > > > used in the > > > format. > > > > > > > > Regards, > > > > Dave From nobody Mon Apr 15 00:43:44 2019 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 0C7B3120389 for ; Mon, 15 Apr 2019 00:43:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nordicsemi.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k_0A62-COlbU for ; Mon, 15 Apr 2019 00:43:32 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00065.outbound.protection.outlook.com [40.107.0.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 267E21202F3 for ; Mon, 15 Apr 2019 00:43:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nordicsemi.onmicrosoft.com; s=selector1-nordicsemi-no; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ML2uIx2m+sgW/vbN8++9qzaPcNPnuuzpG8QhIEfp8Hw=; b=ZbJq81PWf31WeHM9HesYSjY7xytfL7rJDEomM8QxQXfjhPhCNHHVwX7jHjq+88dj0magPBwYfYthgoWk86298bEL6gr/amvUOYNlzJCaa1SvcJa/IjVVte/WL8x6gBDf+I5Iquw1Mm2M5VjHcOoHmtz8ShQz+qTOYnSjBuFmRuY= Received: from AM6PR05MB6375.eurprd05.prod.outlook.com (20.179.5.214) by AM6PR05MB5719.eurprd05.prod.outlook.com (20.178.92.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.14; Mon, 15 Apr 2019 07:43:29 +0000 Received: from AM6PR05MB6375.eurprd05.prod.outlook.com ([fe80::98d9:6e05:1b71:2090]) by AM6PR05MB6375.eurprd05.prod.outlook.com ([fe80::98d9:6e05:1b71:2090%4]) with mapi id 15.20.1792.018; Mon, 15 Apr 2019 07:43:29 +0000 From: =?iso-8859-1?Q?Kvamtr=F8=2C_Frank_Audun?= To: "Waltermire, David A. (Fed)" , =?iso-8859-1?Q?R=F8nningstad=2C_=D8yvind?= , Brendan Moran , "suit@ietf.org" Thread-Topic: Introducing draft-moran-suit-manifest-04 Thread-Index: AQHU2L81dzELNCQKcEaCHfQ8cPehA6Y2x2+wgABw2OCAAAtb8IABCyQggABunaCAAAQtoIAACtpAgAQyYXA= Date: Mon, 15 Apr 2019 07:43:28 +0000 Message-ID: References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com> In-Reply-To: Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=frank.kvamtro@nordicsemi.no; x-originating-ip: [194.19.86.146] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 011e7144-bdaa-43fd-2872-08d6c1760d2d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600140)(711020)(4605104)(2017052603328)(7193020); SRVR:AM6PR05MB5719; x-ms-traffictypediagnostic: AM6PR05MB5719: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(39850400004)(366004)(396003)(376002)(51444003)(13464003)(189003)(199004)(2906002)(6246003)(74316002)(71200400001)(76176011)(71190400001)(7696005)(25786009)(6506007)(476003)(305945005)(446003)(33656002)(11346002)(26005)(53546011)(53936002)(486006)(186003)(9686003)(55016002)(6306002)(105586002)(30864003)(66066001)(74482002)(102836004)(106356001)(66574012)(52536014)(14444005)(256004)(93886005)(7736002)(68736007)(5660300002)(14454004)(97736004)(966005)(316002)(86362001)(8676002)(99286004)(81166006)(81156014)(110136005)(229853002)(8936002)(45080400002)(2501003)(6436002)(478600001)(3846002)(6116002)(45776006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR05MB5719; H:AM6PR05MB6375.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: nordicsemi.no does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: w5FXQjKgAQdzNvy3GrDXQBeNu7WgGrEPzgb1biZ4pn4+yFIDDyrbKtCrghZ6Dzc8pdZ3tX3UcTxJQv7VYm9I9RXfgg3behD7gbpk0NI2exOk5VBYkhnY+YarpCB3H/1olk+RrxC7XdqgiDQ7ojmNPhKJMvIWC4tTTkEy2iEDCdYJ6RZkGKQU3fS6Xpo88Mt8beSRJ6mZEeNmZRCnvYMVYax5yPJNcnKJocHB4GkR/rK5Ty3dnwbMXsaW5jUHxtuBCWK4lirTXNcXOAWNSNH2KsXfoDcRc+klHxkCjzi0RLn6RTFvxKKYZIGSWqpwfjXZNh4cADwN1T1bauRlms7D03s8XONPDJIJGSz9p1e6roIo+37kUT39k/0WwBVjoK2or+WheXAvDG1wMqO4ZvJLHLc661+p8h6P7h6Cge899MA= Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nordicsemi.no X-MS-Exchange-CrossTenant-Network-Message-Id: 011e7144-bdaa-43fd-2872-08d6c1760d2d X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 07:43:28.9597 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 28e5afa2-bf6f-419a-8cf6-b31c6e9e5e8d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR05MB5719 Archived-At: Subject: Re: [Suit] Introducing draft-moran-suit-manifest-04 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, 15 Apr 2019 07:43:42 -0000 That is true, but here are my 2 cents. I am open for a secure hash RFC with stable algorithm IDs that work both for CBOR and ASN.1 encoded formats. I do believe that the IDs that are currently defined in ASN.1 should suffice for 99%+ implementations. We can get something for free by adopting standardized algorithm IDs. For the emerging hash algorithms outside of what is standardized I think th= at in the short term we could rely on the flexibility in the SUIT standard=20 of allowing non-standard type IDs for work that goes besides standardized=20 implementation. We can designate user-customizable negative numbers or=20 reserved ranges for any hash algorithm that is not in the current approved= =20 secure cryptographic hash algorithms.=20 The NIST/FIPS and CAVP (Cryptographic Algorithm Validation Program) is the only option at this moment that gives a consistency in standardization and validation. Selecting something beyond what is standardized and testabl= e moves the security aspects and the sensitivity into the hands of the design= er,=20 which is not something we should recommend for an out-of-the-box experience= =20 IMO. Anyone wanting to use "something else" should be extremely aware of what th= ey are doing. Allowing a SUIT_Digest in a pure form in any portions of the=20 standard doesn't accurately represent a "policy" of what should be allowed or not. Making sure that only cryptographically sound algorithms are allowe= d=20 limits the misuse. It doesn't remove the need for said "policy", but at lea= st it doesn't open up for a broad misuse in a generic reference-design=20 implementation that is designed as an "allow all, support all". It would be fairly simple to limit the hash-sizes in your implementation just by stating that you will only accept e.g. SHA-2/SHA-3 of 256 bits or=20 higher, but that is still just an implementer-decision. If you want to make= a=20 reference-design that "accepts everything" because you want it to be=20 conformant with the standard, then the lack of a real "policy" concept gets= =20 trickier. People may make the wrong choices influencing their security. I don't want to make this a viable problem, just because we made the=20 use of a hash in the standard too open for interpretation. 2 cents mode off! -Frank Audun. > -----Original Message----- > From: Waltermire, David A. (Fed) > Sent: 12. april 2019 16:55 > To: Kvamtr=F8, Frank Audun ; R=F8nningstad, = =D8yvind > ; Brendan Moran = ; > suit@ietf.org > Subject: RE: Introducing draft-moran-suit-manifest-04 >=20 > True. My concern is that the NIST list contains only NIST approved > algorithms. >=20 > The IETF may want to include a larger scope of hash algorithms that go > beyond those supported by NIST. Keeping this list in IANA provides for th= at > larger scope. >=20 > Regards, > Dave >=20 >=20 >=20 > > -----Original Message----- > > From: Kvamtr=F8, Frank Audun > > Sent: Friday, April 12, 2019 10:37 AM > > To: Waltermire, David A. (Fed) ; > > R=F8nningstad, =D8yvind ; Brendan Mor= an > > ; suit@ietf.org > > Subject: RE: Introducing draft-moran-suit-manifest-04 > > > > Total agreement on finding stable curated list, and hopefully this is > > a list that can be one named "secure hashes" corresponding to active > standards. > > > > The Cryptographic Algorithm Object Registration from NIST seems to do > > exactly that, with Object IDs that are stable. I know this is ASN.1 > > but it seems easy to convert to pure integer Object IDs. > > > > https://csrc.nist.gov/Projects/Computer-Security-Objects- > > Register/Algorithm-Registration#Hash > > > > -Frank Audun > > > > > -----Original Message----- > > > From: Waltermire, David A. (Fed) > > > Sent: 12. april 2019 16:06 > > > To: Kvamtr=F8, Frank Audun ; R=F8nningst= ad, > > > =D8yvind ; Brendan Moran > > > ; suit@ietf.org > > > Subject: RE: Introducing draft-moran-suit-manifest-04 > > > > > > Do we know anything about the permanence of and the process used to > > > curate https://www.keylength.com/en/4/? The advantage of using IANA > > > is that we can have confidence that the registry will exist and a > > > known set of processes for managing it. > > > > > > Alternately, could we write a small draft to add any missing hash > > > algorithms (SHAKE128, SHAKE256, etc) to the Named Information Hash > > Algorithm Registry? > > > This would allow the manifest to use the index values from the > > > registry instead of defining a new enumeration. > > > > > > Could we then say something in security considerations about the > > > truncated hashes and their security properties referencing RFC6920? > > > > > > Regards, > > > Dave > > > > > > > -----Original Message----- > > > > From: Kvamtr=F8, Frank Audun > > > > Sent: Friday, April 12, 2019 5:48 AM > > > > To: Waltermire, David A. (Fed) ; > > > > R=F8nningstad, =D8yvind ; Brendan > > > > Moran ; suit@ietf.org > > > > Subject: RE: Introducing draft-moran-suit-manifest-04 > > > > > > > > Do note that there are no valid use-cases for heavily truncated > > > > hashes in our information model. All hashes are exclusively used > > > > for > > security. > > > > This makes me want to limit non-standard definitions that can be > > > > misused and/or misunderstood. > > > > > > > > When the RFC talks about the truncated hash they mention security > > > > specifically: > > > > > > > > "... Therefore, we use different hash algorithm strings in these > cases, > > > > such as sha-256-32 for a 32-bit truncation of a sha-256 output. > > > > A > > > > 32- > > > bit > > > > truncated hash is essentially useless for security in almost all > > > > cases > > > but > > > > might be useful for naming." > > > > > > > > > > > > Where we source the list to use in manifest of the hash types is > > > > the big question... > > > > > > > > I often times go to the following web-page to find the latest on > > > > recommended hashes etc: > > > > > > https://gcc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww= . > > > > > > keylength.com%2Fen%2F4%2F&data=3D02%7C01%7Cdavid.waltermire% > > > > > > 40nist.gov%7C4a660097d25a453e13e208d6bf2c06ff%7C2ab5d82fd8fa4797a > > > > > > 93e054655c61dec%7C1%7C0%7C636906593156044698&sdata=3DPGgJTO > > > > > > l48DmN9onJtbkogKWAGB%2FJ9omRAeZDX2OOobA%3D&reserved=3D0 > > > > > > > > This page lists the approved hashes as sourced from NIST specs: > > > > > > > > From FIPS 180-4: > > > > SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and > > > > SHA-512/256 > > > > > > > > (Where SHA-384 is essentially SHA-512/384) > > > > > > > > From FIPS 202: > > > > SHA3-224,SHA3-256, SHA3-384,SHA3-512, SHAKE128, SHAKE256. > > > > > > > > > > > > I would like to reference the Cryptographic Algorithm Object > > > > Registration from NIST for the ASN.1 encoding of approved > > > > cryptographic > > > algorithms. > > > > > > > > https://gcc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2= F > > > > cs > > > > rc > > > > .n > > > > > > ist.rip%2Fgroups%2FST%2Fcrypto_apps_infra%2Fcsor%2Falgorithms.html&a > > > > > > mp;data=3D02%7C01%7Cdavid.waltermire%40nist.gov%7C4a660097d25a453e > > > > > > 13e208d6bf2c06ff%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C > > > > > > 636906593156044698&sdata=3DVPHEv850i7bKsIbUsdx7Pc8o8j7xnTPDKsv > > > > R%2B4qeEaE%3D&reserved=3D0 > > > > > > > > SHA-1 (Externally assigned) > > > > SHA-2 family > > > > id-sha256 OBJECT IDENTIFIER ::=3D { hashAlgs 1 } > > > > id-sha384 OBJECT IDENTIFIER ::=3D { hashAlgs 2 } > > > > id-sha512 OBJECT IDENTIFIER ::=3D { hashAlgs 3 } > > > > id-sha224 OBJECT IDENTIFIER ::=3D { hashAlgs 4 } > > > > id-sha512-224 OBJECT IDENTIFIER ::=3D { hashAlgs 5 } > > > > id-sha512-256 OBJECT IDENTIFIER ::=3D { hashAlgs 6 } > > > > > > > > SHA-3 family > > > > id-sha3-224 OBJECT IDENTIFIER ::=3D { hashAlgs 7 } > > > > id-sha3-256 OBJECT IDENTIFIER ::=3D { hashAlgs 8 } > > > > id-sha3-384 OBJECT IDENTIFIER ::=3D { hashAlgs 9 } > > > > id-sha3-512 OBJECT IDENTIFIER ::=3D { hashAlgs 10 } > > > > id-shake128 OBJECT IDENTIFIER ::=3D { hashAlgs 11 } > > > > id-shake256 OBJECT IDENTIFIER ::=3D { hashAlgs 12 } id-shake128-len > > > > OBJECT IDENTIFIER ::=3D { hashAlgs 17 } id-shake256-len OBJECT > > > > IDENTIFIER ::=3D { hashAlgs 18 } > > > > > > > > > > > > Using this should provide the complete list of recommended and > > > > approved hashes, formatted as the IETF SUIT spec, semi-conformant > > > > to the "Named Information Hash Algorithm Registry": > > > > > > > > algorithm-id-sha-256 =3D 1 > > > > algorithm-id-sha-384 =3D 2 > > > > algorithm-id-sha-512 =3D 3 > > > > algorithm-id-sha-224 =3D 4 > > > > algorithm-id-sha-512-224 =3D 5 > > > > algorithm-id-sha-512-256 =3D 6 > > > > algorithm-id-sha3-224 =3D 7 > > > > algorithm-id-sha3-256 =3D 8 > > > > algorithm-id-sha3-384 =3D 9 > > > > algorithm-id-sha3-512 =3D 10 > > > > > > > > digest-algorithm-ids /=3D algorithm-id-sha-256 digest-algorithm-ids > > > > /=3D > > > > algorithm-id-sha-384 digest-algorithm-ids /=3D algorithm-id-sha-512 > > > > digest-algorithm-ids /=3D algorithm-id-sha-224 digest-algorithm-ids > > > > /=3D > > > > algorithm-id-sha-512-224 digest-algorithm-ids /=3D > > > > algorithm-id-sha-512-256 digest-algorithm-ids /=3D > > > > algorithm-id-sha3-224 digest-algorithm-ids /=3D > > > > algorithm-id-sha3-256 digest-algorithm-ids /=3D > > > > algorithm-id-sha3-384 digest-algorithm-ids /=3D > > > > algorithm-id-sha3-512 > > > > > > > > Note that SHA-1 is removed from this list due to being a "legacy" > > > > type hash (known to be broken). SHAKE is also removed as it isn't > > > > directly approved due to the complexity of use. > > > > > > > > Note that I've added a dash between "sha" and "256" according to > > > > spec and consistent with "Named Information Hash Algorithm Registry= ". > > > > > > > > Additional hashes may also be easy to add, like KECCAC. > > > > > > > > I recommend reusing the algorithm IDs from ASN.1 in lack of any > > > > meaningful listing, elsewhere. > > > > > > > > -Frank Audun > > > > > > > > > -----Original Message----- > > > > > From: Waltermire, David A. (Fed) > > > > > Sent: 11. april 2019 17:49 > > > > > To: R=F8nningstad, =D8yvind ; > > > > > Brendan Moran ; suit@ietf.org > > > > > Cc: Kvamtr=F8, Frank Audun > > > > > Subject: RE: Introducing draft-moran-suit-manifest-04 > > > > > > > > > > Some comments on =D8yvind's comments below as a WG participant. > > > > > > > > > > > -----Original Message----- > > > > > > From: Suit On Behalf Of R=F8nningstad, > > > > > > =D8yvind > > > > > > Sent: Thursday, April 11, 2019 11:03 AM > > > > > > To: Brendan Moran ; suit@ietf.org > > > > > > Cc: Kvamtr=F8, Frank Audun > > > > > > Subject: [Suit] FW: Introducing draft-moran-suit-manifest-04 > > > > > > > > > > > > I did a full pass through the document today, and wrote down > > > > > > (quite a > > > > > > few) comments, see below. I think this document is very excitin= g! > > > > > > > > > > > > - =D8yvind > > > > > > > > > > > > > > > > > > The digest-algorithm-ids list is missing the following SHA-2 > > > > > > family > > > > > functions: > > > > > > - SHA224 > > > > > > - SHA512/224 > > > > > > - SHA512/256 > > > > > > Also, the functions that are truncated to 128 and fewer bits > > > > > > will not be secure against brute-force attacks, so I question > > > > > > their inclusion > > > > here. > > > > > > > > > > RFC 6920, which this draft references, defines the IANA "Named > > > > > Information Hash Algorithm Registry". It would be good if this > > > > > draft directly references the "Named Information Hash Algorithm > > Registry" > > > > > directly to provide for future agility as new algorithms are > > > > > added and use of specific algorithms fall out of practice. The > "status" > > > > > field of the registry provides guidance for the later. Algorithm > > > > > agility should also be discussed in the security considerations. > > > > > > > > > > It would also be useful to allow non-enumerated integer values > > > > > to be used in the format to ensure that new entries added to the > > > > > "Named Information Hash Algorithm Registry" are also allowed to > > > > > be used in the > > > > format. > > > > > > > > > > Regards, > > > > > Dave From nobody Tue Apr 16 08:51:54 2019 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 EDA4812064E for ; Tue, 16 Apr 2019 08:51:38 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 UTk5ZVjAEsER for ; Tue, 16 Apr 2019 08:51:35 -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 3760C1206DF for ; Tue, 16 Apr 2019 07:31:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3712F300AE7 for ; Tue, 16 Apr 2019 10:12:56 -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 WTMA9XC9fetx for ; Tue, 16 Apr 2019 10:12:53 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id B32CD300201; Tue, 16 Apr 2019 10:12:53 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Russ Housley In-Reply-To: Date: Tue, 16 Apr 2019 10:31:10 -0400 Cc: "suit@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com> To: =?utf-8?B?Ikt2YW10csO4LCBGcmFuayBBdWR1biI=?= X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [Suit] Introducing draft-moran-suit-manifest-04 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, 16 Apr 2019 15:51:44 -0000 Different security protocols use different techniques for naming = algorithms. X.509 Certificates and CMS use ASN.1 object identifiers. COSE uses = short text strings in text and integers on the wire. TLS uses positive = integer values. All of these approaches can point to the same = algorithm. Since SUIT has selected the COSE format, that seems like a natural fit. = See https://www.iana.org/assignments/cose/cose.xhtml Russ > On Apr 12, 2019, at 10:36 AM, Kvamtr=C3=B8, Frank Audun = wrote: >=20 > Total agreement on finding stable curated list, and hopefully this is = a list > that can be one named "secure hashes" corresponding to active = standards. >=20 > The Cryptographic Algorithm Object Registration from NIST seems to do = exactly > that, with Object IDs that are stable. I know this is ASN.1 but it = seems > easy to convert to pure integer Object IDs. >=20 > = https://csrc.nist.gov/Projects/Computer-Security-Objects-Register/Algorith= m-Registration#Hash >=20 > -Frank Audun >=20 >> -----Original Message----- >> From: Waltermire, David A. (Fed) >> Sent: 12. april 2019 16:06 >> To: Kvamtr=C3=B8, Frank Audun ; = R=C3=B8nningstad, =C3=98yvind >> ; Brendan Moran = ; >> suit@ietf.org >> Subject: RE: Introducing draft-moran-suit-manifest-04 >>=20 >> Do we know anything about the permanence of and the process used to = curate >> https://www.keylength.com/en/4/? The advantage of using IANA is that = we can >> have confidence that the registry will exist and a known set of = processes >> for managing it. >>=20 >> Alternately, could we write a small draft to add any missing hash = algorithms >> (SHAKE128, SHAKE256, etc) to the Named Information Hash Algorithm = Registry? >> This would allow the manifest to use the index values from the = registry >> instead of defining a new enumeration. >>=20 >> Could we then say something in security considerations about the = truncated >> hashes and their security properties referencing RFC6920? >>=20 >> Regards, >> Dave >>=20 >>> -----Original Message----- >>> From: Kvamtr=C3=B8, Frank Audun >>> Sent: Friday, April 12, 2019 5:48 AM >>> To: Waltermire, David A. (Fed) ; >>> R=C3=B8nningstad, =C3=98yvind ; = Brendan Moran >>> ; suit@ietf.org >>> Subject: RE: Introducing draft-moran-suit-manifest-04 >>>=20 >>> Do note that there are no valid use-cases for heavily truncated = hashes >>> in our information model. All hashes are exclusively used for = security. >>> This makes me want to limit non-standard definitions that can be >>> misused and/or misunderstood. >>>=20 >>> When the RFC talks about the truncated hash they mention security >>> specifically: >>>=20 >>> "... Therefore, we use different hash algorithm strings in these = cases, >>> such as sha-256-32 for a 32-bit truncation of a sha-256 output. A = 32- >> bit >>> truncated hash is essentially useless for security in almost all = cases >> but >>> might be useful for naming." >>>=20 >>>=20 >>> Where we source the list to use in manifest of the hash types is the >>> big question... >>>=20 >>> I often times go to the following web-page to find the latest on >>> recommended hashes etc: >>> = https://gcc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww. >>> keylength.com%2Fen%2F4%2F&data=3D02%7C01%7Cdavid.waltermire% >>> 40nist.gov%7C4a660097d25a453e13e208d6bf2c06ff%7C2ab5d82fd8fa4797a >>> 93e054655c61dec%7C1%7C0%7C636906593156044698&sdata=3DPGgJTO >>> l48DmN9onJtbkogKWAGB%2FJ9omRAeZDX2OOobA%3D&reserved=3D0 >>>=20 >>> This page lists the approved hashes as sourced from NIST specs: >>>=20 >>> =46rom FIPS 180-4: >>> SHA-1, SHA-224, SHA-256, SHA-384, SHA-512, SHA-512/224 and = SHA-512/256 >>>=20 >>> (Where SHA-384 is essentially SHA-512/384) >>>=20 >>> =46rom FIPS 202: >>> SHA3-224,SHA3-256, SHA3-384,SHA3-512, SHAKE128, SHAKE256. >>>=20 >>>=20 >>> I would like to reference the Cryptographic Algorithm Object >>> Registration from NIST for the ASN.1 encoding of approved = cryptographic >> algorithms. >>>=20 >>> = https://gcc01.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fcsrc >>> .n >>> ist.rip%2Fgroups%2FST%2Fcrypto_apps_infra%2Fcsor%2Falgorithms.html&a >>> mp;data=3D02%7C01%7Cdavid.waltermire%40nist.gov%7C4a660097d25a453e >>> 13e208d6bf2c06ff%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C >>> 636906593156044698&sdata=3DVPHEv850i7bKsIbUsdx7Pc8o8j7xnTPDKsv >>> R%2B4qeEaE%3D&reserved=3D0 >>>=20 >>> SHA-1 (Externally assigned) >>> SHA-2 family >>> id-sha256 OBJECT IDENTIFIER ::=3D { hashAlgs 1 } >>> id-sha384 OBJECT IDENTIFIER ::=3D { hashAlgs 2 } >>> id-sha512 OBJECT IDENTIFIER ::=3D { hashAlgs 3 } >>> id-sha224 OBJECT IDENTIFIER ::=3D { hashAlgs 4 } >>> id-sha512-224 OBJECT IDENTIFIER ::=3D { hashAlgs 5 } >>> id-sha512-256 OBJECT IDENTIFIER ::=3D { hashAlgs 6 } >>>=20 >>> SHA-3 family >>> id-sha3-224 OBJECT IDENTIFIER ::=3D { hashAlgs 7 } >>> id-sha3-256 OBJECT IDENTIFIER ::=3D { hashAlgs 8 } >>> id-sha3-384 OBJECT IDENTIFIER ::=3D { hashAlgs 9 } >>> id-sha3-512 OBJECT IDENTIFIER ::=3D { hashAlgs 10 } >>> id-shake128 OBJECT IDENTIFIER ::=3D { hashAlgs 11 } >>> id-shake256 OBJECT IDENTIFIER ::=3D { hashAlgs 12 } id-shake128-len >>> OBJECT IDENTIFIER ::=3D { hashAlgs 17 } id-shake256-len OBJECT >>> IDENTIFIER ::=3D { hashAlgs 18 } >>>=20 >>>=20 >>> Using this should provide the complete list of recommended and >>> approved hashes, formatted as the IETF SUIT spec, semi-conformant to >>> the "Named Information Hash Algorithm Registry": >>>=20 >>> algorithm-id-sha-256 =3D 1 >>> algorithm-id-sha-384 =3D 2 >>> algorithm-id-sha-512 =3D 3 >>> algorithm-id-sha-224 =3D 4 >>> algorithm-id-sha-512-224 =3D 5 >>> algorithm-id-sha-512-256 =3D 6 >>> algorithm-id-sha3-224 =3D 7 >>> algorithm-id-sha3-256 =3D 8 >>> algorithm-id-sha3-384 =3D 9 >>> algorithm-id-sha3-512 =3D 10 >>>=20 >>> digest-algorithm-ids /=3D algorithm-id-sha-256 digest-algorithm-ids = /=3D >>> algorithm-id-sha-384 digest-algorithm-ids /=3D algorithm-id-sha-512 >>> digest-algorithm-ids /=3D algorithm-id-sha-224 digest-algorithm-ids = /=3D >>> algorithm-id-sha-512-224 digest-algorithm-ids /=3D >>> algorithm-id-sha-512-256 digest-algorithm-ids /=3D = algorithm-id-sha3-224 >>> digest-algorithm-ids /=3D algorithm-id-sha3-256 digest-algorithm-ids = /=3D >>> algorithm-id-sha3-384 digest-algorithm-ids /=3D = algorithm-id-sha3-512 >>>=20 >>> Note that SHA-1 is removed from this list due to being a "legacy" = type >>> hash (known to be broken). SHAKE is also removed as it isn't = directly >>> approved due to the complexity of use. >>>=20 >>> Note that I've added a dash between "sha" and "256" according to = spec >>> and consistent with "Named Information Hash Algorithm Registry". >>>=20 >>> Additional hashes may also be easy to add, like KECCAC. >>>=20 >>> I recommend reusing the algorithm IDs from ASN.1 in lack of any >>> meaningful listing, elsewhere. >>>=20 >>> -Frank Audun >>>=20 >>>> -----Original Message----- >>>> From: Waltermire, David A. (Fed) >>>> Sent: 11. april 2019 17:49 >>>> To: R=C3=B8nningstad, =C3=98yvind = ; Brendan >>>> Moran ; suit@ietf.org >>>> Cc: Kvamtr=C3=B8, Frank Audun >>>> Subject: RE: Introducing draft-moran-suit-manifest-04 >>>>=20 >>>> Some comments on =C3=98yvind's comments below as a WG participant. >>>>=20 >>>>> -----Original Message----- >>>>> From: Suit On Behalf Of R=C3=B8nningstad, >>>>> =C3=98yvind >>>>> Sent: Thursday, April 11, 2019 11:03 AM >>>>> To: Brendan Moran ; suit@ietf.org >>>>> Cc: Kvamtr=C3=B8, Frank Audun >>>>> Subject: [Suit] FW: Introducing draft-moran-suit-manifest-04 >>>>>=20 >>>>> I did a full pass through the document today, and wrote down >>>>> (quite a >>>>> few) comments, see below. I think this document is very exciting! >>>>>=20 >>>>> - =C3=98yvind >>>>>=20 >>>>>=20 >>>>> The digest-algorithm-ids list is missing the following SHA-2 >>>>> family >>>> functions: >>>>> - SHA224 >>>>> - SHA512/224 >>>>> - SHA512/256 >>>>> Also, the functions that are truncated to 128 and fewer bits will >>>>> not be secure against brute-force attacks, so I question their >>>>> inclusion >>> here. >>>>=20 >>>> RFC 6920, which this draft references, defines the IANA "Named >>>> Information Hash Algorithm Registry". It would be good if this = draft >>>> directly references the "Named Information Hash Algorithm Registry" >>>> directly to provide for future agility as new algorithms are added >>>> and use of specific algorithms fall out of practice. The "status" >>>> field of the registry provides guidance for the later. Algorithm >>>> agility should also be discussed in the security considerations. >>>>=20 >>>> It would also be useful to allow non-enumerated integer values to = be >>>> used in the format to ensure that new entries added to the "Named >>>> Information Hash Algorithm Registry" are also allowed to be used in >>>> the >>> format. >>>>=20 >>>> Regards, >>>> Dave >=20 > _______________________________________________ > Suit mailing list > Suit@ietf.org > https://www.ietf.org/mailman/listinfo/suit From nobody Tue Apr 16 08:56:36 2019 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 9C846120786 for ; Tue, 16 Apr 2019 08:56:32 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 p5aXOucR6rzu for ; Tue, 16 Apr 2019 08:56:29 -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 14F161207AF for ; Tue, 16 Apr 2019 07:54:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id DAD08300AAA for ; Tue, 16 Apr 2019 10:36:27 -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 esNHj3WVr64l for ; Tue, 16 Apr 2019 10:36:26 -0400 (EDT) Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id AD09E300A11 for ; Tue, 16 Apr 2019 10:36:26 -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.8\)) Message-Id: Date: Tue, 16 Apr 2019 10:54:43 -0400 To: suit X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [Suit] Minutes for SUIT at IETF 104 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, 16 Apr 2019 15:56:33 -0000 https://datatracker.ietf.org/meeting/104/materials/minutes-104-suit-00 Please review and send any corrections to the mail list. Russ From nobody Fri Apr 19 22:48:20 2019 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 9EA2A12010E for ; Fri, 19 Apr 2019 22:48:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 n1Vn0EoDoy4F for ; Fri, 19 Apr 2019 22:48:17 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 114D712000E for ; Fri, 19 Apr 2019 22:48:16 -0700 (PDT) Received: from kduck.mit.edu (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x3K5lntA020224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 20 Apr 2019 01:47:51 -0400 Date: Sat, 20 Apr 2019 00:47:49 -0500 From: Benjamin Kaduk To: "Waltermire, David A. (Fed)" Cc: =?iso-8859-1?Q?Kvamtr=F8=2C?= Frank Audun , =?iso-8859-1?Q?R=F8nningstad=2C_=D8yvind?= , Brendan Moran , "suit@ietf.org" Message-ID: <20190420054748.GT51586@kduck.mit.edu> References: <16EC7DB9-1649-4A86-A370-F77CB03305AC@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [Suit] Introducing draft-moran-suit-manifest-04 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: Sat, 20 Apr 2019 05:48:19 -0000 On Fri, Apr 12, 2019 at 02:06:13PM +0000, Waltermire, David A. (Fed) wrote: > Do we know anything about the permanence of and the process used to curate https://www.keylength.com/en/4/? The advantage of using IANA is that we can have confidence that the registry will exist and a known set of processes for managing it. > > Alternately, could we write a small draft to add any missing hash algorithms (SHAKE128, SHAKE256, etc) to the Named Information Hash Algorithm Registry? This would allow the manifest to use the index values from the registry instead of defining a new enumeration. Jumping in late, but this is basically what's going on in draft-housley-hkdf-oids. If we need to do it, it can be done. -Ben From nobody Sat Apr 20 12:37:23 2019 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 B2B991201BC for ; Sat, 20 Apr 2019 12:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 ryPKCtMYkifX for ; Sat, 20 Apr 2019 12:37:18 -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 5C5B41201A5 for ; Sat, 20 Apr 2019 12:37:17 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id B511838263 for ; Sat, 20 Apr 2019 15:37:04 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D4FFB1861; Sat, 20 Apr 2019 15:37:15 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D292EDE2 for ; Sat, 20 Apr 2019 15:37:15 -0400 (EDT) From: Michael Richardson To: "suit\@ietf.org" In-Reply-To: <9941AE75-5071-4F3E-ABDD-A35C4EDFD714@tzi.org> References: <64367D8F-3B10-46D4-B133-74E4E056804A@arm.com> <9941AE75-5071-4F3E-ABDD-A35C4EDFD714@tzi.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] Introducing draft-moran-suit-behavioural-manifests-00 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: Sat, 20 Apr 2019 19:37:21 -0000 --=-=-= Content-Type: text/plain I've been through the document and I've read the thread, and I watched the IETF104 video (I had a conflict). I have a number of concerns. I find some of the conversation about the details of the operations indicative that coming to agreement for an proceedural mechanism may be rather difficult to get consensus on; but I could be wrong here. I feel that this proposal brings us away from a declarative manifest that can be reasoned about without regard to time. I'm not exactly sure I understand the rational for the flexibility that is presented. It could be that I just don't understand this well enough; I tend to understand things by writing code, and I haven't written any code around this. Is there an example (maybe in the draft that I mis-understood) that would provide a pair of use cases where being able to do things in different orders, *at the control of the firmware update author* would make sense? If product A always needs to do action-1 before action-2, and product B always needs to do action-2 before action-1, I see no value in a behaviour manifest. It's when product A sometimes should do action-1 before action-2, and sometimes action-2 before action-1 that the behaviour makes sense. Again, maybe I just don't understand the proposal. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAly7dOsACgkQgItw+93Q 3WVXJAf/Zys945BZ44PRK7b3Sn2soWydQ09ugy804gXry8OmYlj+KXyaFCzy9RV5 u6SEdKv4CUTfhLGB/9MNDgENWok/UMBWi0OVohTqiAChT6w5Q3cXSQpYi3wcLVdP ceJRP9PLSgqAYVUqoh5qp1aYBGDzz0mhYTrLjUa9ohltBMdYrii+fCx42btQk83s dBFCFY3KrV9cUEtYVy1PyCbOM4gnW2Hh+j2Pca1TIz/opn+qEzucGua4B7vLuE0R zAjL9c5GgV7FsylCYyS4uEj4Yi/nZ5i5QesKcHhEnDd+YfnuEZttNLtqCRNfqfpA +v3/NrnEm9w9ka/LFPalBnjJT8nkDQ== =zFi3 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Apr 23 12:49:37 2019 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 3B0671200E9; Tue, 23 Apr 2019 12:49:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: rdd@cert.org, housley@vigilsec.com, suit-chairs@ietf.org, suit@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155604897416.32517.5907613095033570872.idtracker@ietfa.amsl.com> Date: Tue, 23 Apr 2019 12:49:34 -0700 Archived-At: Subject: [Suit] suit - New Meeting Session Request for IETF 105 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: Tue, 23 Apr 2019 19:49:34 -0000 A new meeting session request has just been submitted by Russ Housley, a Chair of the suit working group. --------------------------------------------------------- Working Group Name: Software Updates for Internet of Things Area Name: Security Area Session Requester: Russ Housley Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: ipwave lamps stir ipsecme tls sipbrandy curdle sacm mile teep core ace acme mls saag Second Priority: t2trg lwig 6lo cfrg perc cbor dprive secdispatch sidrops tcpinc Third Priority: v6ops 6man intarea uta People who must be present: Russ Housley Dave Thaler Roman Danyliw Hannes Tschofenig David Waltermire Resources Requested: Special Requests: Due to travel to a family wedding, please do not schedule this session on Friday. ---------------------------------------------------------