Re: [Suit] Review of draft-ietf-suit-manifest-09

Dave Thaler <dthaler@microsoft.com> Mon, 27 July 2020 16:13 UTC

Return-Path: <dthaler@microsoft.com>
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 E6B5B3A1C93 for <suit@ietfa.amsl.com>; Mon, 27 Jul 2020 09:13:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 5Ss5irjGMNS5 for <suit@ietfa.amsl.com>; Mon, 27 Jul 2020 09:13:11 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770137.outbound.protection.outlook.com [40.107.77.137]) (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 EE5163A255E for <suit@ietf.org>; Mon, 27 Jul 2020 09:09:53 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JgzcbROC4R9WX86+WxD84nlRrsch/E/zNw4Uw1SwP9GmkgT14/AHhvZxbMYAFODtgEbL9KlHgP+XGZCJAaQ/A2IL9gBxBAbXah+V3amDN+J5Z1L7jRFjNfDP1DQYB4dnT8ZGHXix1+ezmxejs82pbUByMGMxW362OmzWo8VpXWwoI0ckou7feLXmlTIdKhYVvy7XApR5JJ76Sylv+kc1ShUmWUVnPMkxeTefAs7G/j4paKkzu8Yk6r4uP0KoKJFnsZ6kpMq8xvva0i8yeYGFF2RTPOb8vmqQy/4ON5N/nLenKkxyBwzyfu2FDI0VPOM7QJ57bucNfyrZgcc2sRBJIw==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Jc8hzZgEJfrqGrcnzIOK1WGdYIbI0FOlrxH/jdhJSPQ=; b=kqNOe9kNG5GrO29/PTDfsl7fLukuic//PV0AR73+mxNosHIoCXbRBUOJU8gYS/wXQ1wGPAME9spUJ1MX0UuUIHkDFVdBbr0fPJzVvaFQM9KbWp2k64syCiu1PDjYvQlDUDIRPAdcPUFeCjWeNJmhymwnNTRTcMErJf6cWH94So1Jwh/UJNCAbycepVFcLbABPwDwE9kjM2pb6las52g76OPfQxjK3q4j27kf10reK2KfeYSsDPPZr97OGbaggSTbTXseMENNVaANqJ1OiVo0wE5gzZ6XoOUi8p0PLbJh2FJqlK8UIGdNZHE2OyhfHNAbxMXF33c48G/+d+cTDOh+/Q==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Jc8hzZgEJfrqGrcnzIOK1WGdYIbI0FOlrxH/jdhJSPQ=; b=Aezg38Pp6/HRpqwvw/CPVT9T10HY63YR5mgMR3uYeA/VGRDc1KEO5s9mT2RKNbuqi0QhBqj3sQee/hXksg4umV4mqQLm3cVEH8MPL2vJgo6AyuZs3Aa9G2Xp/7aN5dyuQLaskUIpFche689fnByBo0ZuFBzNhi5mHCVyG9Sy778=
Received: from BL0PR2101MB1027.namprd21.prod.outlook.com (2603:10b6:207:30::33) by MN2PR21MB1503.namprd21.prod.outlook.com (2603:10b6:208:1f7::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3239.1; Mon, 27 Jul 2020 16:09:47 +0000
Received: from BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::f9ee:91d4:b4ce:9ee4]) by BL0PR2101MB1027.namprd21.prod.outlook.com ([fe80::f9ee:91d4:b4ce:9ee4%6]) with mapi id 15.20.3239.015; Mon, 27 Jul 2020 16:09:46 +0000
From: Dave Thaler <dthaler@microsoft.com>
To: Brendan Moran <Brendan.Moran@arm.com>, Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>
CC: suit <suit@ietf.org>
Thread-Topic: [Suit] Review of draft-ietf-suit-manifest-09
Thread-Index: AdZiCUkrB1qNrZ3lS5i4ApAjr2sBOQCGs7sAAAKNB+A=
Date: Mon, 27 Jul 2020 16:09:46 +0000
Message-ID: <BL0PR2101MB1027CB46179113E5AFF5CC3BA3720@BL0PR2101MB1027.namprd21.prod.outlook.com>
References: <BL0PR2101MB1027152EC8DAD9B3847C3E89A3770@BL0PR2101MB1027.namprd21.prod.outlook.com> <70453005-8DFA-4DBE-8C04-9882839D5005@arm.com>
In-Reply-To: <70453005-8DFA-4DBE-8C04-9882839D5005@arm.com>
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_SetDate=2020-07-27T16:09:45Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=524c0516-99b7-4afd-99cb-ab547ecd6b4f; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0
authentication-results: arm.com; dkim=none (message not signed) header.d=none;arm.com; dmarc=none action=none header.from=microsoft.com;
x-originating-ip: [2601:600:9780:16f0:55e6:9884:b77a:7caf]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 3a8ae5ff-4516-461d-9522-08d832477b88
x-ms-traffictypediagnostic: MN2PR21MB1503:
x-microsoft-antispam-prvs: <MN2PR21MB15034B8E2D6134F89CCBEFE7A3720@MN2PR21MB1503.namprd21.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 02UlhCafETjWF4in+pZU/s/cUaDbDnjF9cCdvijAeaSktb0eB8g7XTjddLfSXV0HThtHeHkN2K+VxF/c2sNZz2waigSF7twNZrda65SlRRZ/5KQ4IH5lSUGbh5oo9SK2PGPA8c3SPErdISuv/MwTyqvpPcRLO3L5kPqnoVSNXJlW38XC312Mp9HEjvC8hVMkcyCiEaJdmsPX8Bpp4HEfEdl3P4IAhc+yj6G4jmwLRbiwyXCJSpg17S5lpuko8bguurqGJ0BYdoeaLHrI3QVWbfk0TgPtn/hPBKwa9tPJ+OZcpPMyymqsZMGdui6VVod99d0LONNdnd7mNUhd1vLnIA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BL0PR2101MB1027.namprd21.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(396003)(39860400002)(366004)(136003)(376002)(346002)(10290500003)(110136005)(82960400001)(9686003)(7696005)(66476007)(33656002)(64756008)(66556008)(5660300002)(66446008)(86362001)(82950400001)(55016002)(186003)(71200400001)(6506007)(66946007)(8936002)(76116006)(52536014)(8990500004)(2906002)(4326008)(83380400001)(8676002)(478600001)(316002)(53546011); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: hKRUoeimGA56GsnJzVHXDz7Y4rLXWG6HJ+lXs8xREHn1BB3K3aO5QU1G4ei7bktoul4M2a4OZ0vEHvS0bngfKNuc7a9/ndQqIMwTySGK24aYYuTg3NjQ1HnjQGntsv6tylS4jeplVES7m0l1qwQCYcSlFlF+x17fWYFW8sGEeXXUoTQ9ENBV17PlfT4nFDpPl3dLk7mVjybiBIDUEbkDQs9yIsk4K9BwbQI86lHJdrCHrlajR888FOGSU8vp8d/dv4livqhDy0l2Oie0ci9wEbffmkAahSNg4j4NjSoYku+6Afgk/Sse7aG4uXOARtGlv6Hb+Giob3xCuayGKNVbyx2KCkxeq2ZmzoWTDlvh2jJUOtq+Ae7fzN5lft6ECEOdJlpwicSW9TbiSru2tyaLg5D1NemjxijMJBodh7R8fsTgyzAjjwU1c5ZRBdxEDWWkFIqD2UJbNgsQGE7fQ8Tkj7EAl9jx+nrrd0MHHZz1+TFk0YN1t9XCqBUtWD2zWFl6oxG+ki6xKFiaN3TF9gRRqpTNeq69clgpKh7J7DpoSyYtbitdPK8cWTvHIy/flJQEdQtJOp+OEWlkSz+zoFO/HsImuGABLf8UHjqGYJWZXIoj9rtjpEG+pIvgZ1U31aoLU/bWybcL06XJHTu6QfuX/uQ3LWNpCSDCa5MXmqvlA0DJ59UgB4cl/V1cT8v7ioYkmy5TA7K+T8oyLS6B1/GjuQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_BL0PR2101MB1027CB46179113E5AFF5CC3BA3720BL0PR2101MB1027_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BL0PR2101MB1027.namprd21.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3a8ae5ff-4516-461d-9522-08d832477b88
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jul 2020 16:09:46.8251 (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-CrossTenant-userprincipalname: dCEi7r54S3pG5E4A1uzdjEhvXm4Hh50rbN3i/Ik9wrTkctx0iKd4N+4f1xzwz6/E7Dt0RxyCZ63pdXsI72nfC7Rgnci+Y6dmqF8+mnxla4M=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR21MB1503
Archived-At: <https://mailarchive.ietf.org/arch/msg/suit/rXwwiT3iXSMs03ky0HEcSYJDNIM>
Subject: Re: [Suit] Review of draft-ietf-suit-manifest-09
X-BeenThere: suit@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Software Updates for Internet of Things <suit.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/suit>, <mailto:suit-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/suit/>
List-Post: <mailto:suit@ietf.org>
List-Help: <mailto:suit-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/suit>, <mailto:suit-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Jul 2020 16:13:14 -0000

Thanks Brendan, initial responses below.
Looking forward to a discussion on Friday.

From: Suit <suit-bounces@ietf.org> On Behalf Of Brendan Moran
Sent: Monday, July 27, 2020 7:42 AM
To: Dave Thaler <dthaler=40microsoft.com@dmarc.ietf.org>
Cc: suit <suit@ietf.org>
Subject: Re: [Suit] Review of draft-ietf-suit-manifest-09

Hi Dave,

Thank you very much for your very detailed review! Of course, it will take me some time to work through this review. I will do my best to clarify these technical comments as I work through. In general, the issues you’ve listed look to me like the “right” answer is fairly obvious, so I will straighten them out. There are several comments that I think deserve a little more clarification.

6. SUIT_Report

SUIT_Report and Reporting Engine text is added but does not appear to be about what goes in a SUIT manifest, so I argue that it doesn’t belong in this spec (and is arguable as to whether it’s in scope for SUIT at all)

You’re right. This has not been raised on the list. If it’s more appropriate to put it in a new draft, I’m happy to do that.

That’s what I’m arguing, yes.

However, it’s a natural consequence of adding the SUIT_Reporting_Policy, which was discussed at the virtual interim. It seemed to me that if a reporting policy was specified, then an implementor would naturally want to know how to report that information.

Part of my point is there are multiple existing reporting standards (e.g., in the Behave WG we had drafts on both syslog and IPFIX).
Creating yet another one is not necessarily wrong, but does mean there’s more complexity in dealing with multiple ways, and in explaining why a new one is competing with existing standards, and which one to use in what circumstance, especially if the device is already implementing one of the others for a reason unrelated to SUIT.   That adds complexity and delay into the SUIT manifest document which I would prefer to avoid.

If there is a need for logging SUIT commands, along with their arguments and results, this seems very specific to SUIT in general and the SUIT manifest in specific. I struggle to see what document would be more appropriate than the SUIT manifest for the SUIT_Report.

A new one, so that you can use the SUIT manifest without some new reporting format, if someone is already using IPFIX or syslog or whatever else.  And so that the SUIT manifest can progress sooner without blocking on this discussion (which from my experience in Behave is never simple once you have people in the room familiar with existing mechanisms).

Furthermore, it says SUIT_Report can go in an attestation report.  What’s the rationale for that as opposed to some more typical logging/reporting mechanism that might integrate with existing error reporting mechanisms and trouble ticketing?

SUIT_Reporting_Policy has two output channels: “system information,” that is the “actual” values compared against in conditions, and “command records” which are effectively logs of command execution. For an update case, these are adequately served by logging infrastructure. However, in a bootloader case, this is inadequate because the bootloader and the booted application are different security domains. This means that any system information or command records need to be protected from modification by the application. Typically, this would be done with a signature; I don’t see how this is different from attestation.

Well often you have existing logging/reporting standards that have signatures and are not considered as “attestation”.  In theory they are similar.  My point is about the ability to integrate with existing standards and implementations that devices and networks might be already using.

The discussion of a Reporting Engine seems necessary: it’s the thing that consumes reporting policy.

7.      Defining a new identifier space (UUIDs) for vendors is not motivated.  So a vendor can’t use an existing OUI or IANA private enterprise number that can be easily looked up? You have to instead use an opaque identifier with no way to directly look up its meaning? What is the rationale for inventing a new space rather than being able to reuse an existing one that can be looked up to get an org name, contact info, etc.? (Yes there is suit-text-vendor-domain but that’s severable and optional to implement at all.) And a UUID takes up more bytes than either an OUI or a PEN, so is worse for constrained devices, so why not use an existing space that is shorter and hence more applicable to constrained devices?
7. Vendor IDs
I’d argue that I have not defined a new identifier space. It was defined in RFC4122. That said, I think that PEN could be beneficial if we can work around some of the complexities associated with it.

RFC 4122 defined a way to create identifiers, but using them to identify vendors, or classes, or whatever else, is a new identifier space in the sense I mean.

OUIs may be prohibitive for small manufacturers (US $2,995). For example, I have seen small manufacturers avoid building USB devices due to the cost of obtaining a USB VID. Class IDs still require a UUID Name Space Identifier. There is no rule I can find for constructing an OUI UUID, so it cannot be used as a UUID Name Space Identifier.

I don’t understand any requirement to constrict a UUID for vendors.   I agree that OUIs are harder than PENs, my point is about the ability to reuse shorter IDs out of an existing number space without having to put long UUIDs in messages just to identify the vendor.  (I like PENs better.)

Private Enterprise Numbers seem manageable by small manufacturers.

Agree.

There is a UUID Name Space Identifier for OIDs, however this gets a bit confusing. You would need to construct a class ID as follows:

Vendor_UUID = uuid.uuid5(uuid.NAMESPACE_OID, EncodeOID(‘1.3.6.1.4.1.’ + PEN))

I fail to see why “EncodeOID” is relevant here.  You can just use the PEN.
(And of course the Vendor_UUID need not appear in any message if the PEN appears instead.)

Class_UUID = uuid.uuid5(Vendor_UUID, Class_Information)

The problem here is that EncodeOID() is not specified at all in RFC4122. The closest we get is:

For example, some name spaces are the

   domain name system, URLs, ISO Object IDs (OIDs), X.500 Distinguished

   Names (DNs), and reserved words in a programming language.
So Class IDs become unpredictable because OID encoding is underspecified in RFC4122. I can see the Vendor_UUID being computed with several different versions of EncodeOID:

I didn’t follow why OID encoding is relevant to this discussion.

- Encode as dotted-integer string
- Encode as DER OID
- Encode as value of DER OID (no tag/length)
- Lots of other ASN.1 encodings possible.
- Future CBOR OID?

I do not believe we should specify the use of OUIs because 1) they cost $3000, 2) there is no UUID namespace for OUIs

I’m not against using a PEN, but we would also need to provide extremely strict encoding guidelines for constructing Vendor UUIDs, since the Vendor UUID is needed as the Name Space ID for the Class UUID.

For encoding in the manifest I think we should insist on using the PEN directly rather than the full OID. But what would we do with a PEN sub-assignment?

Can you elaborate on what you mean?   I’m suggesting we simply use the PEN numbering space itself (no “sub-assignments” or whatever)
as what goes in the CBOR, and what is used to construct the namespace ID for the class id.

Dave

There’s a lot more complexity here than just “use a PEN.”


Best Regards,
Brendan