From nobody Thu Nov 28 01:05:54 2019 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4BC120018; Thu, 28 Nov 2019 01:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WOL-aljwTHu1; Thu, 28 Nov 2019 01:05:46 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DE2712008C; Thu, 28 Nov 2019 01:05:46 -0800 (PST) Received: from dooku.sandelman.ca (unknown [185.201.63.254]) by relay.sandelman.ca (Postfix) with ESMTPS id 6DE1B1F47D; Thu, 28 Nov 2019 09:05:44 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id C3876E3B; Thu, 28 Nov 2019 17:05:47 +0800 (+08) From: Michael Richardson To: =?us-ascii?Q?=3D=3Futf-8=3FQ=3FJaime=3D20Jim=3DC3=3DA9nez=3F=3D?= , mud@ietf.org, opsawg@ietf.org In-reply-to: <20191122015716.mvcwq7g4hnwopjue@EMB-918HFH01> References: <20191122015716.mvcwq7g4hnwopjue@EMB-918HFH01> Comments: In-reply-to =?us-ascii?Q?=3D=3Futf-8=3FQ=3FJaime=3D20Jim=3DC3=3D?= =?us-ascii?Q?A9nez=3F=3D?= message dated "Fri, 22 Nov 2019 09:57:16 +0800." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Thu, 28 Nov 2019 10:05:47 +0100 Message-ID: <21818.1574931947@dooku.sandelman.ca> Archived-At: Subject: Re: [Mud] CoAP and MUD X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2019 09:05:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jaime Jim=C3=A9nez wrote: > here is the draft in case you wanna have a look, it's just 8 pages. > https://jaime.win/draft-coap-mud/ Thank you for pointing me at it. I'm replying to the opsawg list. > Overall a MUD is emitted as a URL using DHCP, LLDP or through 802.1X, then > a Switch or Router will send the URI to some IoT Controlling Entity. That > Entity will fetch the MUD file from a Server on the Internet over HTTP > [RFC8576]. It might be worth adding that it can be emitted in an IDevID using BRSKI. That uses the same certificate extension as in 802.1X. draft-ietf-anima-constrained-voucher/draft-ietf-6tisch-dtsecurity-zerotouch is more likely to have been used if we are getting to CoAP. There is an open question in the MUD space as to whether the MUD signature URL is absolute or if it can be relative. This affects how the signature file will be found when using a self-hosted MUD file as you have described. The signature should NOT be signed by the Thing itself, as that provides no security against malware. So that also gets in the way of the device providing any kind of dynamic capability by changing it's MUD. The device *could* select from a palate of MUD files which the manufacturer has signed. That would be very interesting. 4.1. Serialization TBD write about SenML/CBOR MUDs. Are you thinking that we could serialize the YANG to CBOR instead of JSON? I'm mostly for that, but I think that in general, since the ACLs will get enforced by a non-constrained device, and we can host the MUD files on a manufacturer resource, that it might be enough that it's JSON+CMS. on the other hand... CMS. Ick. Also using udf:// URLs from mathmesh would mean that the MUD file could be found via any cachable mechanism, with the communication with the manufacturer only if no other way is fine. This also authenticates the fil= e, but not quite in the same way that the signature does. =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl3fjesACgkQlUzhVv38 QpDTtgf+M44VCmG4oZ67Tse4EsrknNQk+9JbIF6ulDK3uYwCZxCAEnxV0d0ttHCN Y0+Q2whQrRuReBeXCB6nEYPprkqIPb3OobAkBgr1T00pHueyvhU4bXEVU0q/L+q3 WaHPL2Zk1NtvAYcGSFhNrcSwUfnO/OElobYjZ0tzOQDNvrzTeKrfWGC+y2zEL/dE WqtdWk4mv3sxpnx+W83GNWrTOIK8kNwcroCagIt9CEn5K1p229eWyaXYrG12qIIj j4fX60uIxWTeTg7eJpkCgPZ9EIII0ieZQfwJtrz5/nY6HvUppw/e6va7O+d//qXl HNlakQDpm5KXdUjLy2WFNWtecyX3uw== =1Hba -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Nov 28 01:15:02 2019 Return-Path: X-Original-To: mud@ietfa.amsl.com Delivered-To: mud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63F41120088; Thu, 28 Nov 2019 01:14:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.82 X-Spam-Level: X-Spam-Status: No, score=-1.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 i_qMdtG2i_RV; Thu, 28 Nov 2019 01:14:50 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB3D1120018; Thu, 28 Nov 2019 01:14:49 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 4D523712; Thu, 28 Nov 2019 04:14:49 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Thu, 28 Nov 2019 04:14:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ZP7195R1UbcwpQ/FPMEh8/tLwrTeilClX7SrQBmxa Kw=; b=OiVRCq184mqtXfWp8poDP2U/aXiod1qGBMW0UJS/80H4F+nxk1sw8M4OV BJL6s7ejtGU7IO5+jzgNFomXC974UTrh0WF3+BDdReBl4RWUZ5xXZeiTDgBnQgo7 rNxOuDBCBSaMGIDVZNr0GHzSFkXHetWNBFDqizFXgChg5i9uDahbLKmtXvAqGf/Q bv0es5A4kwCnZdnDG3tMYOHg9jpW0pIVSTCHgFmJavxb6ZlprEeBbQQUjA8vH1Mi iCJgeaqT6CcQJfi2VFs6SGhKyL8hxg6v5jNNP3bMUhAM3sJMz7BgWvf88wzhJ2YE gx7b0+e/jzsiEgXk6VOn7ULQLhxtA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeijecutefuodetggdotefrodftvfcurf hrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecuuegr ihhlohhuthemuceftddtnecunecujfgurhepfffhvffukfhfgggtugfgjgesthekredttd dtudenucfhrhhomheplfgrihhmvgculfhimhornhgviicuoehjrghimhgvsehikhhirdhf iheqnecuffhomhgrihhnpehjrghimhgvrdifihhnpdhhthhtphhrfhgtkeehjeeirdhith enucfkphepkeelrdduieeirdegledrvdegfeenucfrrghrrghmpehmrghilhhfrhhomhep jhgrihhmvgesihhkihdrfhhinecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from EMB-918HFH01 (89-166-49-243.co.dnainternet.fi [89.166.49.243]) by mail.messagingengine.com (Postfix) with ESMTPA id 073D38005C; Thu, 28 Nov 2019 04:14:45 -0500 (EST) Date: Thu, 28 Nov 2019 11:14:44 +0200 From: =?utf-8?Q?Jaime=20Jim=C3=A9nez?= To: Michael Richardson Cc: mud@ietf.org, opsawg@ietf.org Message-ID: <20191128091444.6uwuzh7m4pi6if7a@EMB-918HFH01> References: <20191122015716.mvcwq7g4hnwopjue@EMB-918HFH01> <21818.1574931947@dooku.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <21818.1574931947@dooku.sandelman.ca> Archived-At: Subject: Re: [Mud] CoAP and MUD X-BeenThere: mud@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion of Manufacturer Ussage Descriptions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Nov 2019 09:14:53 -0000 On Thu, Nov 28, 2019 at 10:05:47AM +0100, Michael Richardson wrote: > > Jaime Jiménez wrote: > > here is the draft in case you wanna have a look, it's just 8 pages. > > https://jaime.win/draft-coap-mud/ > > Thank you for pointing me at it. > I'm replying to the opsawg list. Thanks, the draft is still work in progress and I have not yet submitted it to T2TRG, which is its final intended destination. As per the feedback I have gotten so far, it seems like an interesting topic but might require a bit more "cooking". Specially the justification as to why this is needed, the motives I explain so far do not seem to be sufficiently convincing. > > > Overall a MUD is emitted as a URL using DHCP, LLDP or through 802.1X, then > > a Switch or Router will send the URI to some IoT Controlling Entity. That > > Entity will fetch the MUD file from a Server on the Internet over HTTP > > [RFC8576]. > > It might be worth adding that it can be emitted in an IDevID using BRSKI. > That uses the same certificate extension as in 802.1X. > draft-ietf-anima-constrained-voucher/draft-ietf-6tisch-dtsecurity-zerotouch > is more likely to have been used if we are getting to CoAP. Yes, that is something that should be considered. I was also discussing with others on how Neighbor Discovery (ND) would apply, as it is more common than DHCP in the very constrained space. > > There is an open question in the MUD space as to whether the MUD signature > URL is absolute or if it can be relative. This affects how the signature > file will be found when using a self-hosted MUD file as you have described. > > The signature should NOT be signed by the Thing itself, as that provides no > security against malware. So that also gets in the way of the device > providing any kind of dynamic capability by changing it's MUD. > The device *could* select from a palate of MUD files which the manufacturer > has signed. That would be very interesting. The whole security part is very raw at the moment, I have not thought in detail how that would work in practice. > > 4.1. Serialization > TBD write about SenML/CBOR MUDs. > > Are you thinking that we could serialize the YANG to CBOR instead of JSON? > I'm mostly for that, but I think that in general, since the ACLs will get > enforced by a non-constrained device, and we can host the MUD files on a > manufacturer resource, that it might be enough that it's JSON+CMS. on the > other hand... CMS. Ick. I am just assuming that the device will serialize everything in SenML/CBOR and not use YANG at all. > > Also using udf:// URLs from mathmesh would mean that the MUD file could be > found via any cachable mechanism, with the communication with the > manufacturer only if no other way is fine. This also authenticates the file, > but not quite in the same way that the signature does. Very interesitng, I am not familiar with udf:// either, I guess it does still require an IP address to be usable, right? > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > >