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

Ben Schwartz <> Mon, 14 September 2020 17:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A811A3A046A for <>; Mon, 14 Sep 2020 10:43:51 -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 BewhB2yhWNJB for <>; Mon, 14 Sep 2020 10:43:50 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C01973A0D9E for <>; Mon, 14 Sep 2020 10:43:49 -0700 (PDT)
Received: by with SMTP id s88so381040ilb.6 for <>; Mon, 14 Sep 2020 10:43:49 -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=uiOCsGsf4ICziR7DyBiHaKmOcbML8dsxstGahQHIqPM=; b=TZ3gQH6ArIeVX7Sw36vejNY8nQRZVrIXSAglyTI6R8i5NOGHzSLmEc41MHgpbAupD/ a7UsFw9lpjN5nTAVFBUTisZ7i1j0BDUB2++8Xw3q11ydBD+Wqk8D111l4LMd0PL9gYZ6 B4LOxvsgwaniFB0ojww3V2Bx8zO8M6ItPuc0lA/C9qaRjspCPxRqe3YWZeFQjxbIAki9 S3B0pQLQmpopDUUXeM5W6FEZ1VvpRQtEXQQdbkNrURf2h0kUDJdK1m8Z/GyQ98iz6VOJ viq60Qf52JbemeSVLBumoZEIwkC4bnpoY6T5r28+ozm7PeDUfCbJxf54GzWulyc5q2Zj JtJw==
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=uiOCsGsf4ICziR7DyBiHaKmOcbML8dsxstGahQHIqPM=; b=UCd3FJ53I7W0RVtjudBvZkAE+kdfvLT2auGy0OIYvbyoPhGnpI+N4SCWhjZ9V+1Dsq hmxS/MjvU7UlL6nzW5yhuIWby7oUDFs/r/3v7f2cY2Hwov7mnYdEWFtiD34Cvj9ga0xR QdvI6/eHny0+Dw8BwWxLVwMfRlnp0XJAv/J5kWOIkflAdX+c4K5RzTkoWBbwSOwLJWA/ Jb7IdLW1GbjR5knJEgansvaj4iTGiFHJu5tajXJc4biDkc4zQGQKsLRbyhsKJLRUxCmY TFO4Q1d8ofTfRrYdxfBn569d2z0sSqP5h5TUEIuFVeAfJHFj0aDX1ep9/D6phdpzr8LL ekwg==
X-Gm-Message-State: AOAM532waYhYy9ZgN05L1nERB3zQgUCqAF7IQJTayG9j+V1XcxaKkMzf qd/Sz9YL5d5PlHYXj3JFdV/oYk/c3Xx0um5om01uVQ==
X-Google-Smtp-Source: ABdhPJzyTtX5uFROvspOUDZLKfLEfwZhmVmPma53i5GUvWy6zlIiaG6bbUghe6Zajpxt9qNCkaYKHA7HG16BBvyzEKY=
X-Received: by 2002:a92:d347:: with SMTP id a7mr13954599ilh.263.1600105428680; Mon, 14 Sep 2020 10:43:48 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Mon, 14 Sep 2020 13:43:36 -0400
Message-ID: <>
To: Eliot Lear <>
Cc: tirumal reddy <>, Nick Lamb <>, opsawg <>, "<>" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="000000000000b574ef05af499309"
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 17:43:52 -0000

On Mon, Sep 14, 2020 at 11:09 AM Eliot Lear <>

> Hi Ben,
> Much of this relitigates RFC 8520, but IMHO it is worth reviewing
> assumptions from time to time.  Remember, the purpose of MUD is to identify
> an authorization profile for a device to a network so that either access
> can be granted based on that profile or an anomaly can be detected.  The
> primary, but not exclusive, focus is on IOT.
> Please see below.
> 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
> public.
> We should separate the MUD URL from the MUD file.  The MUD file is
> absolutely 100% public, and consists of information that is observable –
> or should be observable – from the device.  So if you are a Meddler In The
> Middle (;-) (MITM) you get this information *anyway*.

Agreed ... but this proposal appears to be predicated on a contrary
assumption.  It assumes that it is difficult for malware to learn the TLS
profile of the device, and then proceeds to place this profile information
in the (public) MUD file, where malware can easily retrieve it.

The MUD URL gives up device type information.  This is different in
> character, but *often* but not *always* easily gotten.  I would say that
> if a manufacturer is taking steps to prevent fingerprinting, then they
> should take steps to protect the MUD URL.  That’s an active area of
> interest for some.
> 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.
> One can deploy a MUD file update in advance of a code update.  The latter
> takes a whole lot longer than the former.  No IoT manufacturer is going to
> put out something in less than the default time of 48 hours, lest they
> brick millions of devices.

I'm not thinking of the hours-days timescale of MUD file updates; I'm
thinking of the months-years timescale of updating standards to support new
features.  How long does a device have to wait after a new protocol
revision comes out before it can start using the new protocol?  First,
we'll need a new draft to update this YANG model with parameters for the
new protocol.  Then, we'll need all the world's MUD vendors to write new
firmware that can parse the new protocol and compare it to the model.  Then
we'll need all the MUD gateways to update to the new firmware.

Of course, the device can unilaterally "back out" of this arrangement by
issuing a reduced MUD file, but if this feature is advertised to customers,
transitioning to a new protocol may not be an option for many years.
(Consider, for example, the impact on QUIC deployment.)

 Is this more work for an IoT manufacturer?  Sure.  One thing the draft
> might do is discuss how to incorporate something into unit testing to write
> out the change.
> Eliot