Re: [Mud] how to increase trust in MUD URL

Henk Birkholz <henk.birkholz@sit.fraunhofer.de> Wed, 22 January 2020 07:32 UTC

Return-Path: <henk.birkholz@sit.fraunhofer.de>
X-Original-To: mud@ietfa.amsl.com
Delivered-To: mud@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A89B0120052 for <mud@ietfa.amsl.com>; Tue, 21 Jan 2020 23:32:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.898
X-Spam-Level:
X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, 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 KNFDMW7kzkCY for <mud@ietfa.amsl.com>; Tue, 21 Jan 2020 23:32:08 -0800 (PST)
Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 D2201120013 for <mud@ietf.org>; Tue, 21 Jan 2020 23:32:06 -0800 (PST)
Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 00M7W4Vj003406 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT) for <mud@ietf.org>; Wed, 22 Jan 2020 08:32:05 +0100
Received: from [192.168.16.50] (79.234.120.240) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 22 Jan 2020 08:31:59 +0100
To: mud@ietf.org
References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> <CAFpG3gehp98VB2RpL6LenRJsV=RRQ=1jCTX7mcrmd27pzkYqfg@mail.gmail.com> <CAFpG3gek8qrHjN5LNQUrRrS9+zFuVQQ4y+XorRrr5xySs2fP1g@mail.gmail.com> <20570.1579314460@localhost> <30267.1579654985@localhost>
From: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Message-ID: <9b50e4ca-d516-3f3b-5992-1695f8147d18@sit.fraunhofer.de>
Date: Wed, 22 Jan 2020 08:31:58 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2
MIME-Version: 1.0
In-Reply-To: <30267.1579654985@localhost>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Originating-IP: [79.234.120.240]
Archived-At: <https://mailarchive.ietf.org/arch/msg/mud/3NIZiS22yl3TnnfDBu9m4M6x8U4>
Subject: Re: [Mud] how to increase trust in MUD URL
X-BeenThere: mud@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Discussion of Manufacturer Ussage Descriptions <mud.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mud>, <mailto:mud-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mud/>
List-Post: <mailto:mud@ietf.org>
List-Help: <mailto:mud-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mud>, <mailto:mud-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Jan 2020 07:32:10 -0000

Hi mud'ler,

On 22.01.20 02:03, Michael Richardson wrote:
> But, updating the URL in IDevID is difficult to do. Quite reasonably it might
> be impossible without a device recall.  The IDevID version is much easier to
> invest trust into.  And it clearly links back to the manufacturer.

This is one of the biggest issues that came to my mind ad-hoc. Is 
changing the URI really an option? I would assume this type of 
encapsulation is trustworthy, I think.

On 22.01.20 02:03, Michael Richardson wrote:
> If a vendor is going to put very specific information relating to TLS
> libraries into a MUD file, then it is going to be critical that any updates
> to the firmware (such as BUG FIXES) result in updates to the MUD TLS profile.

Hm. I always assumed that either a MUD file or the parameters to a MUD 
URI would take care of "versions" or "composition" of the requester (so 
the requester appends information about that in the URI). Is that not 
how other people think about it? The idea of a canonical composition of 
the segments in the URI did not fly IIRC (due to rfc7320 I assume).

Viele Grüße,

Henk