[OPSAWG] how to increase trust in MUD URL

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 22 January 2020 01:03 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 B51121200C4; Tue, 21 Jan 2020 17:03:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id hVbN9GjL6Mii; Tue, 21 Jan 2020 17:03:07 -0800 (PST)
Received: from tuna.sandelman.ca (tuna.sandelman.ca []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9301200C3; Tue, 21 Jan 2020 17:03:07 -0800 (PST)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C70E13897E; Tue, 21 Jan 2020 20:02:33 -0500 (EST)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A1FF9E99; Tue, 21 Jan 2020 20:03:05 -0500 (EST)
From: Michael Richardson <mcr+ietf@sandelman.ca>
to: opsawg@ietf.org, mud@ietf.org
In-Reply-To: <20570.1579314460@localhost>
References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> <CAFpG3gehp98VB2RpL6LenRJsV=RRQ=1jCTX7mcrmd27pzkYqfg@mail.gmail.com> <CAFpG3gek8qrHjN5LNQUrRrS9+zFuVQQ4y+XorRrr5xySs2fP1g@mail.gmail.com> <20570.1579314460@localhost>
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<nPbLgmtKK-5dC@#:k
X-Attribution: mcr
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature"
Date: Tue, 21 Jan 2020 20:03:05 -0500
Message-ID: <30267.1579654985@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/opsawg/pxAth_60aKdKzLOf7LXT98otDZo>
Subject: [OPSAWG] how to increase trust in MUD URL
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, 22 Jan 2020 01:03:10 -0000

draft-reddy-opsawg-mud-tls-02 proposes to describe TLS profile options in a
MUD file in order to help middle boxes (Intrusion Detection Systems) to
identify malware.

I wrote an email about issues related to the idea, but this email is about
the way in which MUD files become trusted, and how they should be updated.

Michael Richardson <mcr+ietf@sandelman.ca> wrote:
    > I see two advantages of this work, which mitigates my concern slightly.
    > (but, only slightly)
    > 1) if it's gonna get done by IDS vendors, then IoT device manufacturers
    > might as well provide a way to help them *get it right*

A tussle that I thought I put into a document, but it seems that I did not
yet do that, is whether to update the MUD URL to a firmware specific value,
or whether to update the MUD file place.

I thought I was going to cover that in draft-richardson-opsawg-securehomegateway-mud-02
and I said so in the introduction, and I thought I decided that was a poor
place to put that discussion, and I wrote some text in some document, but it
seems that was a delusion :-)

I guess I wrote this in email to mud@ actually.

The issue is that if you update the MUD file in place without changing the
URL then it will apply to older firmware revisions as well as new ones.

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.

Updating the URL that the firmware emits via DHCP or LLDP is relatively easy,
but not very secure.   An IDS system should *not* trust updates to that URL
as malware could trivially update the URL as well.

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.

If relatively ephemeral things like a TLS profile are going to go into a MUD
file, then I think that we need to think again about the update issue.

[this draft sits in outbox for a week]

I've now written:

]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [