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

Ben Schwartz <> Mon, 14 September 2020 14:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EC5E43A0A70 for <>; Mon, 14 Sep 2020 07:30:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pPumgkWdgfLf for <>; Mon, 14 Sep 2020 07:30:27 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0CE653A0A6C for <>; Mon, 14 Sep 2020 07:30:27 -0700 (PDT)
Received: by with SMTP id g128so218178iof.11 for <>; Mon, 14 Sep 2020 07:30:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OJS1LQMNJChmk3lXMwv2iv9c08ufJNh7hbcCdIta0Wc=; b=GNhlP3dwvvIKRvPxJ4SX8OWt+KutU2Rlag3paMvkviSukRDrUEQ3k3OyJ/R3hvkdcd 2t39sZQbQkEXdSxq/QFbQXvfqFyXjGjgnG4cxlOC++dhO1t5Gs7k1sMJHZtq5evYO28p TnIkabPGI9aXxrtRtODBQ7AP59eFGCcobBSakCRHzy/9KVLakdyrpG1wb//KPbc7hNYY TzxBWrqZ2cC+3mh+LCYKC14qrqIHt9pzwrj8lNZ9zQyC0OQN1oDsAd6FcvBRpfVbxtoF kQyF6hx4WvGo8ckn72uhW3Mf646DdaWHTt2BrcOHnOuM8qIpiiKrFjB6InTc5A0Li7UB x50g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OJS1LQMNJChmk3lXMwv2iv9c08ufJNh7hbcCdIta0Wc=; b=NTwbLX3cuO1K9ODU51LqvAkDRN+5HNiNbJV1qA2Sf4A3XQA0oTpptD4cRwPGAMULXl 1bk5SE1NuPWG8r8E4lOvuZA+t2wop/O9NlcqxeAoeCyQwRRXfNz2iT5PLZ14gN/U6lGE K3RMSfLPPvVZLtJFc9U3/sH+TqsqtJN9lf2Hd1glmsxSGidzvzsu43NwOHg0TSd6eyOQ wY2W4VMCrxXu+veXG71DORc3Kba5Fsf+u6+gmQHgrYUOTqc8ypLs8DpXeG6eSWE0m8i9 w3lZ77NB2lCo0Gt2b/7gNbSBam8D7gQ10YESAYZ+YRr0bkYK+5akbPITFO6Lmaj9eFJp dIhQ==
X-Gm-Message-State: AOAM5339vCeMUCaHecvyiTrHIYyge942TSyPjhT/ODJMP3GI4Q6/wU/L uCOORaCdWiYwWt+uIVYH5UmjQHOpoU6z5Az2IA27ug==
X-Google-Smtp-Source: ABdhPJzH8LGSlp5VpKIS1MpxB0YWzqPZMVPj8Tu8vAQezcpEy6aiHQmXmqW3Zt0MZI/pgJBRPCtWyejLDc9NU9rPaLQ=
X-Received: by 2002:a05:6638:ec5:: with SMTP id q5mr13565368jas.13.1600093826080; Mon, 14 Sep 2020 07:30:26 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Mon, 14 Sep 2020 10:30:13 -0400
Message-ID: <>
To: tirumal reddy <>
Cc: Nick Lamb <>, opsawg <>, "<>" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000234e9005af46e08b"
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: Mon, 14 Sep 2020 14:30:29 -0000

On Fri, Sep 11, 2020 at 7:53 AM tirumal reddy <> wrote:

> On Fri, 11 Sep 2020 at 16:11, 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.
> RFC 8520 allows other means (see sections 1.5 and 1.8) like 802.1X (for
> example, TEAP (it does not allow TLS cipher suites without encryption).
> The client identity (certificate carrying the MUD URL) is encrypted and not
> visible to eavesdroppers. Further, RFC8520 discusses IoT devices may not
> even omit the URL. It recommends to use a proxy to retrieve the MUD file
> for privacy reasons.

These protections are difficult to deploy (representing a minority of
devices), and do not appear to change the dynamic significantly, given the
draft's assumption that the IoT device has already been compromised.  If
the malware can read the MUD URL out of the IoT device's local storage, or
any unit of this model ever contacts an attacker-controlled MUD Manager,
the attacker can access the MUD file, monitor it for updates, etc.

This design treats the MUD file as a "widely shared secret", which is a
fragile arrangement.  It does not appear to match the main conceptual model
of MUD, which describes MUD files as being "published", i.e. generally

I also think this proposal is likely to seriously impede the ability of IoT
vendors to adopt new versions of TLS, or new protocols such as QUIC.  Such
updates would be delayed by (1) the need to add entries to this YANG model,
and then (2) the time for MUD gateways to develop and deploy the new
entries.  Delaying protocol upgrades reduces security, contrary to the
goals of this draft.