Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls

Eliot Lear <> Sun, 20 September 2020 08:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BC1603A0803; Sun, 20 Sep 2020 01:35:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -11.901
X-Spam-Status: No, score=-11.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TM7sP26nx0M0; Sun, 20 Sep 2020 01:35:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C41F63A1167; Sun, 20 Sep 2020 01:35:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=1453; q=dns/txt; s=iport; t=1600590952; x=1601800552; h=mime-version:subject:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=oVOh2hfPttU698daQXzPMAJmYBaZfX70oBkjcivn8TM=; b=ZFMg/PYQuvy5sd4X1pIXn+lac2nnQGW/3+66/j6itEe79CyE88pg33er 0pFg0hk+qmlYrOrjojJBp8DC/jgCn1mLfwkiK2MIC9EI6y/HVLKhW8ZiO H7K6+59Qq4ePseLtzH7vNLfL2gvsGSPARYQ+XX8gpANIVaCgbM1PXiHys k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.77,282,1596499200"; d="scan'208";a="29703055"
Received: from (HELO ([]) by with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Sep 2020 08:35:47 +0000
Received: from [] ([]) by (8.15.2/8.15.2) with ESMTPS id 08K8Zl6d018165 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 20 Sep 2020 08:35:47 GMT
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
From: Eliot Lear <>
In-Reply-To: <>
Date: Sun, 20 Sep 2020 10:35:46 +0200
Cc: tirumal reddy <>, opsawg <>, "<>" <>
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <>
To: Nick Lamb <>
X-Mailer: Apple Mail (2.3608.
X-Outbound-SMTP-Client:, []
Archived-At: <>
Subject: Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 20 Sep 2020 08:35:54 -0000

> On 11 Sep 2020, at 12:40, Nick Lamb <> wrote:
> On Fri, 11 Sep 2020 12:32:03 +0530
> tirumal reddy <> wrote:
>> The MUD URL is encrypted and shared only with the authorized
>> components in the network. An  attacker cannot read the MUD URL and
>> identify the IoT device. Otherwise, it provides the attacker with
>> guidance on what vulnerabilities may be present on the IoT device.
> RFC 8520 envisions that the MUD URL is broadcast as a DHCP option and
> over LLDP without - so far as I was able to see - any mechanism by which
> it should be meaningfully "encrypted" as to prevent an attacker on your
> network from reading it.

That’s a bit of an overstatement.  RFC 8520 specifies a component architecture.  It names three ways of emitting a URL (DHCP, LLDP, 802.1X w/ certificate).  Two other mechanisms have already been developed (QR code, Device Provisioning Protocol), and a 3rd new method is on the way for cellular devices.

I would not universally claim that a MUD URL is secret but neither would I claim it is not.  The management tooling will know which is which, as will the manufacturer, and can make decisions accordingly.

This having been said, it seems to me we are off on the wrong foot here.  The serious argument that needs to be addressed is Ben’s and EKR's.  We have to be careful about ossification.