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

tangtianqing <tangtianqing@huawei.com> Wed, 20 January 2021 12:34 UTC

Return-Path: <tangtianqing@huawei.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 659483A11B9 for <opsawg@ietfa.amsl.com>; Wed, 20 Jan 2021 04:34:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kxwgUpg0cDEg for <opsawg@ietfa.amsl.com>; Wed, 20 Jan 2021 04:34:23 -0800 (PST)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EF983A11B8 for <opsawg@ietf.org>; Wed, 20 Jan 2021 04:34:23 -0800 (PST)
Received: from fraeml709-chm.china.huawei.com (unknown []) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4DLPyP3NRQz67dNV for <opsawg@ietf.org>; Wed, 20 Jan 2021 20:31:09 +0800 (CST)
Received: from fraeml709-chm.china.huawei.com ( by fraeml709-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Wed, 20 Jan 2021 13:34:18 +0100
Received: from DGGEMM401-HUB.china.huawei.com ( by fraeml709-chm.china.huawei.com ( with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.2106.2 via Frontend Transport; Wed, 20 Jan 2021 13:34:18 +0100
Received: from DGGEMM506-MBX.china.huawei.com ([]) by DGGEMM401-HUB.china.huawei.com ([]) with mapi id 14.03.0509.000; Wed, 20 Jan 2021 20:34:13 +0800
From: tangtianqing <tangtianqing@huawei.com>
To: "opsawg@ietf.org" <opsawg@ietf.org>
Thread-Topic: =?utf-8?B?W09QU0FXR10g8J+UlCBXRyBBZG9wdGlvbiBDYWxsIG9uIGRyYWZ0LWxlYXIt?= =?utf-8?Q?opsawg-sbom-access-00?=
Thread-Index: AQHW4rQ/sXnF/p0fh0WTpUiSKojPN6owiyHwgAAAGwA=
Date: Wed, 20 Jan 2021 12:34:13 +0000
Message-ID: <A1F0E2C12E82F44D91F2A1FCEB0F12DACC7803@DGGEMM506-MBX.china.huawei.com>
References: <0682b5b8-63a1-6e79-6f70-d255f04d8013@sit.fraunhofer.de> <469b82a99fca4efd9afa73f97e6c5e87@huawei.com>
In-Reply-To: <469b82a99fca4efd9afa73f97e6c5e87@huawei.com>
Accept-Language: en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/VuQu08l9Zei-F3dsNf89WnXUVAw>
Subject: [OPSAWG] =?utf-8?b?562U5aSNOiAg8J+UlCBXRyBBZG9wdGlvbiBDYWxsIG9u?= =?utf-8?q?_draft-lear-opsawg-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: Wed, 20 Jan 2021 12:34:25 -0000


I’ve read this draft and I support the adoption. Besides that, I have some comments below:


1.  Introduction
While MUD files may include signatures, it is not mandatory to check them, and there is not a clear way to connect the entity which signed the MUD file to the device itself. A malicious device does not need to make up a MUD file if there is already an available, and already trusted MUD file which it can use to impersonate the device.
Comment > I think not checking signatures will cause significant vulnerability, and I also find RFC8520 doesn’t mention whether it’s mandatory to check signatures. Therefore, I am confused that if there is any special purpose or consideration not to check signatures of MUD files.


1.	Introduction 
One defense against this is to not trust MUD URLs which are different from the one that was placed in an IDevID. Or if the initial MUD URL was not taken from an IDevID, it could be trusted on first use.

Comment > What does "this" mean? Does it refer to the problem that a device is unable to verify if the MUD URL belongs to itself, or the method above that cannot connect the MUD file signer with the device itself?

Comment > If IDevID mechanism is applied, why other MUD URLs exist? Or is it better here to say “MUD controller shouldn’t trust other MUD URLs than the one placed in an IDevID”?


2.1.2. Removing capabilities
In this case the old device will be performing unwanted connections,
and the MUD controller when be alerting the device owner that the
device is mis-behaving. This causes a false positive situation (see
[boycrieswolf]), leading to real security issues being ignored. This
is a serious issue as documented also in [boywolfinfosec], and

Comment > What does “real security issues” mean? Does it means that the device owner mistakenly judge that the device is not upgraded as misbehaving?


2.1.3. Significant changes to protocols
[I-D.reddy-opsawg-mud-tls] suggests MUD definitions to allow examination of TLS protocol details. Such a profile may be very specific to the TLS library which is shipped in a device. Changes to the library (including bug fixes) may cause significant changes to the profile, requiring changes to the profile described in the MUD file. Such changes are likely neither forward nor backward compatible with other versions, and in place updates to MUD files are therefore not indicated.
Comment > In my understanding, I think version updates should take compatibility into consideration, even for bug fixes. So why do you think they are likely not compatible with other versions?

3. Threat model for MUD URLs
Only the DHCP and LLDP MUD URL mechanisms are sufficiently close to the firmware version that they can be easily updated when the firmware is updated.

Comment > There is no need to limit this draft to DHCP and LLDP mechanisms.
Although the IDvID mechanism makes the MUD URL in the IDvID certificate unchangeable, it can be assumed that a new MUD URL is carried in the firmware when the device is updated. If the new MUD URL matches the rules defined in this draft, then it can be considered reasonable.


3.2. Concerns about same-signer mechanism
It is possible to invent policy mechanisms that would link the EE certificate to a value that is in the MUD file.

Comment > What is the function of linking the EE certificate to a value that is in the MUD file? How can it solve the problems brought by pinning the CA certificate or pinning the EE certificate?


5. Changes to RFC8520
MUD files contain a self-referential MUD-URL attribute that point to a MUD file located on the vendor’s web site.
Comment > This sentence may be mistaken as that the MUD-URL attribute in multiple MUD files points to the same MUD file. However, in fact, the MUD-URL attribute in a certain MUD file points to the MUD file itself.


5. Changes to RFC8520
The URL found in the MUD-URL attribute is to be called the canonical 
MUD URL for the device.

Comment > How to understand the meaning of “canonical MUD URL”?


5. Changes to RFC8520
The MUD-SIGNATURE attribute in the MUD file SHOULD be a relative URI (see [RFC3986] section 4.2) with the (hierarchical) base URL for this reference being the MUD-URL attribute.

Comment > Does this sentence mean that The MUD-SIGNATURE attribute in the MUD file includes base URI?
Comment > Does “base URL” here has the same meaning with “Base-URI” mentioned in the draft?


5. Changes to RFC8520
Once the new MUD file is accepted, then it becomes the new "root" MUD file, and any subsequent updates must be relative to the MUD-URL in the new file.

Comment > I feel that it’s better to make this requirement normative here. Is it appropriate to use “MUST” or “SHOULD”?

6. Privacy Considerations
The MUD URL contains sensitive model and even firmware revision numbers. Thus the MUD URL identifies the make, model and revision of a device.

Comment > It may be recommended that MUD URLs use a random character string instead of the plaintext information, because the plaintext information is easy to guess (i.e. “The MUD URL contains sensitive model…”)


5. Changes to RFC8520
Subsequent MUD files are considered valid if:
* have the same initial Base-URI as the MUD-URL, but may have a different final part…

Comment > I suggest that describe “MUD URL”, “MUD-URL”, and “mud-url” in advance due to their different meanings.


7. Security Considerations
…depend upon the MUD-manager either not checking signatures, or…

Comment > I suggest that replace “MUD-manager” with MUD controller for consistency.

Best wishes,
Tianqing Tang

> -----Original Message-----
> From: OPSAWG [mailto:opsawg-bounces@ietf.org] On Behalf Of Henk 
> Birkholz
> Sent: Tuesday, January 5, 2021 12:10 AM
> To: opsawg <opsawg@ietf.org>
> Subject: [OPSAWG] 🔔 WG Adoption Call on
> draft-lear-opsawg-sbom-access-00
> Dear OPSAWG members,
> this starts a call for Working Group Adoption on
> https://tools.ietf.org/html/draft-lear-opsawg-sbom-access-00 ending on 
> Monday, January 25.
> As a reminder, this I-D describes different ways to acquire Software 
> Bills of Material (SBOM) about distinguishable managed entities. The 
> work was updated by the authors on October 13th and now elaborates on 
> three ways SBOM can be found, including a MUD URI as one of the options.
> Please reply with your support and especially any substantive comments 
> you may have.
> For the OPSAWG co-chairs,
> Henk
> _______________________________________________
> OPSAWG mailing list
> OPSAWG@ietf.org
> https://www.ietf.org/mailman/listinfo/opsawg