Re: [OPSAWG] 🔔 WG Adoption Call on draft-lear-opsawg-sbom-access-00

Eliot Lear <lear@cisco.com> Sun, 24 January 2021 15:22 UTC

Return-Path: <lear@cisco.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D88873A0D86 for <opsawg@ietfa.amsl.com>; Sun, 24 Jan 2021 07:22:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.973
X-Spam-Level:
X-Spam-Status: No, score=-9.973 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.373, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 Vyd1cw9CcnUC for <opsawg@ietfa.amsl.com>; Sun, 24 Jan 2021 07:22:46 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B643A0D85 for <opsawg@ietf.org>; Sun, 24 Jan 2021 07:22:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5489; q=dns/txt; s=iport; t=1611501766; x=1612711366; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=GD5qL+XKf/F9Jchltem8foPcUi4lk9OcSHnNYrglqdI=; b=CnrmQ7gDE2A5XCbhvJ3+xtBvZzwyIv1faT+WSexvLYAZFEZRCrOUhnOs ZZTwgTuCNrV1oXO7nIl8FFGKQkvzFAMQGAtL7sJgPsawW4QdL/6WC3Dhg F8pYTq0kEG+vbSZWnT0olaW60WfOK4qPAFvJzhph3ZU1CfnLnu+PmzcIV 0=;
X-Files: signature.asc : 488
X-IPAS-Result: =?us-ascii?q?A0DSAQBjkA1glxbLJq1iHQEBAQEJARIBBQUBgX4FAQsBg?= =?us-ascii?q?iCBAFcBIBIvhECJBIhUA5xBBAcBAQEKAwEBLwQBAYFVgnUCgXkmNwYOAgMBA?= =?us-ascii?q?QEDAgMBAQEBBQEBAQIBBgQUAQEBAQEBAQGGQoVzAQEBAwEjVgULCQIYKgICV?= =?us-ascii?q?wYTH4MHAYJmIJdImxJ2gTKFWYRnEIE4AYFSh1uEEEGCAIERJxyCVj6EJgmDK?= =?us-ascii?q?DSCLASBVRBZbicBChEPgV0NEgYQGQYNnCyKc5AugRGDAYMpgTeLTotBAx+DK?= =?us-ascii?q?4o0hTsriUOFcJYlmlMtX4NwAgQGBQIWgWwigVkzGggbFTsqAYI+PhIZDY4tD?= =?us-ascii?q?gmOJ0ADMDcCBgEJAQEDCQGJTgIFIYIeAQE?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.79,371,1602547200"; d="asc'?scan'208";a="32898865"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jan 2021 15:22:36 +0000
Received: from [10.61.248.209] ([10.61.248.209]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 10OFMZcl016118 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 24 Jan 2021 15:22:35 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <11F3A6D9-426C-4A8F-983F-0CB6F53F03E0@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_4177674A-092C-4BD0-8570-74BD7150B26D"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
Date: Sun, 24 Jan 2021 16:22:34 +0100
In-Reply-To: <f2377d643f834831b0ed94e87c3e832c@huawei.com>
Cc: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>, opsawg <opsawg@ietf.org>
To: "Panwei (William)" <william.panwei@huawei.com>
References: <0682b5b8-63a1-6e79-6f70-d255f04d8013@sit.fraunhofer.de> <f2377d643f834831b0ed94e87c3e832c@huawei.com>
X-Mailer: Apple Mail (2.3654.40.0.2.32)
X-Outbound-SMTP-Client: 10.61.248.209, [10.61.248.209]
X-Outbound-Node: aer-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/M5AQPr1uJFezQrJGyOhoMKUVSK8>
Subject: Re: [OPSAWG] =?utf-8?q?=F0=9F=94=94_WG_Adoption_Call_on_draft-lear-o?= =?utf-8?q?psawg-sbom-access-00?=
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/opsawg/>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Jan 2021 15:22:48 -0000

Hi Wei Pan,

Thanks for this excellent review.  Please see below.

> On 24 Jan 2021, at 15:14, Panwei (William) <william.panwei@huawei.com> wrote:
> 
> I've read the draft and I support the adoption. In addition, I have the following comments:
> 
> 1)
> 1. Introduction
> An application-layer management system retrieving an SBOM in order
> to evaluate the posture of an application server of some form.
> These application servers may themselves be containers or
> hypervisors. Discovery of the topology of a server is beyond the
> scope of this memo.
> 
> Comment> I know there are application-layer firewalls, but I don't think it's also appropriate to use "application-layer" to describe the management system. The management system manages the application server, but should not be specific to "application-layer".

I think your concern is with the term “application server”.  If so, I agree with you, the intent here is not to address application layer matters, but at the layer below.  Perhaps we could reword this to be a bit more clear.


> 
> Comment> For an application server which doesn't support MUD before, if it wants to advertise its SBOM info, it needs to send a MUD URL and the related MUD file contains a SBOM URL, why doesn't it just send a SBOM URL?

Actually, the intent is to not require certain application servers to send any URL ;-). Rather, to have a well known URI prefix so that the SBOM can be discovered through a query.

> 
> 2)
> 1. Introduction
> A network-layer management system retrieving an SBOM from an IoT
> device as part of its ongoing lifecycle. Such devices may or may
> not have interfaces available to query SBOM information.
> 
> Comment> I also suggest not using "network-layer" to describe the management system, but saying that the management system evaluates the network behavior of the IoT devices.

I am happy to remove the word “network-layer”, but I would rather not get into behavioral evaluation, as these are two different functions.

> 
> Comment> For disambiguation, in the last sentence, it's better to say "to be queried for SBOM information".
> 

Ok.

> 3)
> 1.3. Discussion points
> Are there other retrieval mechanisms that need to be specified?
> 
> Comment> Can the SBOM info be directly stored/written in the MUD file?

Not in this design.  MUD is intended only for discovery, and is certainly not intended to be the only discovery mechanism.

> 
> 4)
> 3. The mud-sbom augmentation to the MUD YANG model
> In the description of "leaf-list sbom-local", it is said:
> "The choice of sbom-local means that the SBOM resides at
> a location indicated by an indicted scheme for the
> device in question, at well known location
> ’/.well-known/sbom’. For example, if the MUD file
> indicates that coaps is to be used and the host is
> located at address 10.1.2.3, the SBOM could be retrieved
> at ’coaps://10.1.2.3/.well-known/sbom’. N.B., coap and
> http schemes are NOT RECOMMENDED.";
> 
> Comment> The leaf-list "sbom-local" only indicates the transport Protocol, how can the MUD controller know the host address?

This has to be known by the MUD Manager.  I think it’s a good idea to say a bit more about this, though, since that may not be the case for all previous MUD Managers.  Do you agree?

> 
> 5)
> 4. Examples
> The first MUD file demonstrates how to get the SBOM
> without ACLs, and the second has ACLs.
> 
> Comment> Here should be "The first three MUD files demonstrate ..., and the forth has ACLs."

Yes indeed.

> 
> 6)
> 5. Security Considerations
> Another risk is a skew in the SBOM listing and the actual software
> inventory of a device/container. For example, a manufactuer may
> update the SBOM on its server, but an individual device has not be
> upgraded yet. This may result in an incorrect policy being applied
> to a device. A unique mapping of a device’s firmware version and its
> SBOM can minimize this risk.
> 
> Comment> Can we add the firmware version info in the MUD file? So that there will be the mapping of firmware version and SBOM.

Indeed that is available, but a caution: MUD files that are tied to X.509-based MUD-URLs won’t show latest and greatest firmware.  This draft actually could heal that deficiency - to a point.

Eliot