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

Eliot Lear <lear@cisco.com> Mon, 14 September 2020 15:09 UTC

Return-Path: <lear@cisco.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0267F3A0B52; Mon, 14 Sep 2020 08:09:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 pnjv9MGkSM25; Mon, 14 Sep 2020 08:09:11 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E152E3A0B2D; Mon, 14 Sep 2020 08:08:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7347; q=dns/txt; s=iport; t=1600096133; x=1601305733; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=qABoPbcHK6r/F+Gbmu5O0xq6yKiVXbt08FUZ5aQFvKI=; b=DstEvdLrmCQyu4EZ+ZqHJWaFwp16GVgfuSbsh0Oc8CUzuyIhbUR2D4JW xK24vYayA9YH+YdOIT1ymVfxfN8suUrcKcnQmaGYWwzUb5quPCLYM+g34 xdnPdy4nWRhlY0zEGn8dEvvmgZqD+9cczsJQ+/E4goUNcYEuq1BIJAVho 0=;
X-Files: signature.asc : 488
X-IPAS-Result: =?us-ascii?q?A0DPAgDUhl9f/xbLJq1WChwBAQEBAQEHAQESAQEEBAEBg?= =?us-ascii?q?g+BI1I1gUUBIBKEZYkCiDSHYYwjiBkEBwEBAQoDAQEvBAEBhEsCgiglOBMCA?= =?us-ascii?q?wEBAQMCAwEBAQEFAQEBAgEGBG2FaIVzAQQBHQZWBQsLQgICVwaDOQGCXCC1I?= =?us-ascii?q?naBMoVThHgQgTiBU4t0ggCBESccgk0+hBAegyYzgi0EkBqCTAGIa4ozkQGCb?= =?us-ascii?q?4MRgS+VfQMegwmJdY4shUKUT5oZg1kCBAYFAhWBayOBVzMaCBsVZQGCPz0SG?= =?us-ascii?q?Q1YnBA/A2cCBgEJAQEDCY4MgkQBAQ?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.76,426,1592870400"; d="asc'?scan'208,217";a="27157491"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 14 Sep 2020 15:08:48 +0000
Received: from dhcp-10-61-105-148.cisco.com (dhcp-10-61-105-148.cisco.com [10.61.105.148]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 08EF8lpM018639 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Sep 2020 15:08:48 GMT
From: Eliot Lear <lear@cisco.com>
Message-Id: <7207C73E-FB80-4BD3-AE68-627355B10708@cisco.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_817C7DD1-5A82-491A-ADB4-2E944A071C03"; protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Mon, 14 Sep 2020 17:08:45 +0200
In-Reply-To: <CAHbrMsD=BOxYLaJyOkv-t9p+Cm4cEpOui7sQdL9Mmfi=Ufh3mA@mail.gmail.com>
Cc: tirumal reddy <kondtir@gmail.com>, Nick Lamb <njl@tlrmx.org>, opsawg <opsawg@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
References: <21BA8D05-DD83-44DE-81B9-457692484CAD@cisco.com> <053b286e-4780-1818-a79d-71b9c967bbd2@sandelman.ca> <CAHbrMsANEA4omTm5dPYLN9zGde2YdT_71ujpBcCEer_xSkPhbw@mail.gmail.com> <CAFpG3gepojPJoK8W+o9Qr66gPSUqHY+sDX-v+-fuwcM9Y56C_g@mail.gmail.com> <20200911114054.184988dc@totoro.tlrmx.org> <CAFpG3gdRUAAYmvV1+m=+4_0GUd_SDS0hZHhpSXa2qQ6Civtf-g@mail.gmail.com> <CAHbrMsD=BOxYLaJyOkv-t9p+Cm4cEpOui7sQdL9Mmfi=Ufh3mA@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-Outbound-SMTP-Client: 10.61.105.148, dhcp-10-61-105-148.cisco.com
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/IOx7K2-rDRw1MaCRaptW7EJ0Qz0>
Subject: Re: [TLS] [OPSAWG] CALL FOR ADOPTION: draft-reddy-opsawg-mud-tls
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Sep 2020 15:09:16 -0000

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.

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.  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