From nobody Fri Dec 24 09:29:24 2021 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 2A7933A0E35; Fri, 24 Dec 2021 09:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca 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 h0WaRREnwcwb; Fri, 24 Dec 2021 09:29:06 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 959033A0E32; Fri, 24 Dec 2021 09:29:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 57EC938BDF; Fri, 24 Dec 2021 12:33:48 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id DsrK5nLWq4VE; Fri, 24 Dec 2021 12:33:45 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CD2C638AFD; Fri, 24 Dec 2021 12:33:45 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1640367225; bh=ZAHXII+Q6QbqTZLDMCCkY/GbOapNthE9GRNpokdXhEU=; h=From:To:cc:Subject:Date:From; b=3gCiEnKy5zoQujWck0z3LRy5RKrkQsCZEw1T54h6ivU3r6/1aibZRbUkIG/n0SfjZ nfPeeYwEt1qnP28OZv+nb3QeInSOA2FRwZZdBa1GsikBJTOGjIIC/y3rk/7vRVK08y 1rAC0+WZFT6YgBqGt7wudUUaJHan1svfgavPwfaZZlI+QeJKPoBgTU/2E6AmrW7lz6 wv+7d0JwRHO+UjfoodAw4o/wIGdndVo/xTzG8Lk2hR+jMTFfxkk5KIj0qsaOBQf7Gv l7/Ev86bT8DnCTR7BTXXP+/ThB7H+DW8puLbmqXyGl58a0O7DzaH/6Y7KjJ1QitEC6 Xuf+jIMSddLZA== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id D9F3248F; Fri, 24 Dec 2021 12:29:00 -0500 (EST) From: Michael Richardson To: iot-directorate@ietf.org, draft-richardson-mud-qrcode.all@ietf.org, rfc-ise@rfc-editor.org cc: joelja@gmail.com, jaime@iki.fi, mud@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: [Mud] [Iot-directorate] Iotdir reviews of draft-richardson-mud-qrcode-02 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: Fri, 24 Dec 2021 17:29:11 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This is a public reponses to reviews of draft-richardson-mud-qrcode. The document is in the ISE queue and has received IOT-Direcorate reviews by Jaime Jimenez and Marco Tiloca. An OPSAWG review by Joel has been received, and I include my replies below = as well. I'll post a new revision once I'm sure that I've dealt with all the concern= s. Marco's comments were unicast, but I've saved them at: https://www.sandelman.ca/SSW/ietf/mud/qrcode/marco-review-01.txt Changes from Marco's review are at: https://github.com/mcr/mud-qrcode/pull/2 Jaime's comments: https://mailarchive.ietf.org/arch/msg/iot-directorate/jB7C-IzhLPAMD-bY-K2= I8it9TeE/ Edits from Jaime's review are at: https://github.com/mcr/mud-qrcode/pull/3 and my replies are below: Jaime> When the MAC is not included on the MUD URL then the assumption is t= hat the Jaime> network administrator is the one with physical access to the devices= and Jaime> can create the relevant policies. This comes with the caveat of what= is Jaime> then the purpose of the QR code if manual configuration is needed an= yways. There are two points to RFC8520 MUD files: a) it is true, RFC8520 just encodes rules that the network operator could i= nput themselves. If only they knew all the intricate details of the device, were well enough trained to input those rules accurately into the variety of firewalls and IDS systems they own without error. So RFC8520 files remove many opportunities for mistakes. b) by indirecting through a MUD file hosted by the manufacturer, and signed by the manufacturer, the manufacturer of the device has the opportunity = to fix errors or omissions in the ACLs, as well as communicate other meta-data about the device, such as the SBOM info, etc. Additionally, a person installing devices on a campus network does not need to be trusted with super-user access to the entire campus ACLs, just with amending a database of MAC-address -> MUD file mappings in a database. I have added a section 4, Applicability, which I think maybe will address your concerns by putting this activity into a better context. Please see: https://github.com/mcr/mud-qrcode/pull/3 Jaime> A naive attacker could read the QR code that contains the MAC, change Jaime> its own MAC to that of the QR code and then impersonate the device Jaime> effectively blacklisting that MAC address and preventing the actual Jaime> device from attaching to the network in the future. I agree that this could be done. In order to do it, one needs physical access to the network (or ESSID w/cre= dential). If one has that, one could just listen to the network for broadcasts, and then do the attack. 802.1x is designed to deal with such things already. Reviewer: Joel Jaeggli Review result: Has Nits Joel> I reviewed this document on the behalf of the operations and mana= gement Joel> directorate. Joel> While this document is adequately evocative of the risks associat= ed with Joel> essentially unsecured information being ingested via QR codes it'= s fairly Joel> unsatisfying with respect to mitigitations offered. Joel> this is a much a property Joel> of operating in the real world as it is a question of protocol im= plementation. Joel> While this is described as social engineering, it's a more deeply= engineered Joel> falsehood that extends outside the realm of human decision-making. okay. Joel> If I were to nitpick the described security issues it is that ope= ration of or Joel> decision making over a device on the basis of qr code embedded i= n a sticker Joel> can never provide a degree of certainty that the device is what i= t says it is Joel> that powering the device up and interrogating it's mud profile ca= n achieve, Joel> that without some transitive trust property that can be extended = to the device Joel> on the basis of the security of it's internals (e.g. protected Joel> cryptoghric If I understand you, the sticker has very little value compared to a secured boot process as being described by RATS, TCG, etc. I can't disagree with you.... but I'm hearing: "it's not perfect, so don't even bother" Yet, I'm pretty sure that millions of devices have actually been deployed over the past fourty years, building the Internet as we know it. Yes, some of them have turned out to be trojans. Joel> secrets that the manufacturer or owner have embedded) that the i= nformation Joel> embedded in the online formation cannot be trusted to map to that= device. so Joel> for example if as part of lifecycle management one decides how to= dispose of Joel> something broken or unpowered based on a mud profile sticker that= information Joel> is not trustworthy on the basis of anything other than common sen= se or external Joel> validation. e.g. is this transformer full of dioxin or in fact mi= neral oil as Joel> the documentation behind the sticker claims. So, I can't say anything about the other contents of the QRcode that RLA.org wishes to put on the devices. These might not be stickers, but would likely be laser etched into the "case". I'm not sure the containers that transformers live in are called cases, but whatever. There are indeed ma= ny concerns here. Should these transformers have IP connectable micro-controllers (perhaps to tell the operator that the dioxin is leaking...), my goal is simply that a MUD profile could be associated with these controllers. rseadrian> So the point would be (and this applies to stickers randomly rseadrian> placed by an attacker as much as it does to anything else) that rseadrian> it would be good if the information accessed through the QR code rseadrian> was verifiable back to its origin. MUD files have associated signatures. This is in RFC8520 section 13: https://datatracker.ietf.org/doc/html/rfc8520#section-13 whether or not a MUD controller should trust the resulting file is outside = of the scope of this document. RFC8520 does not say a lot about who to trus= t, although section 16 of that document does say a fair bit about rogue manufacturers. Adrian further asked me: rseadrian> I decided to get ahead and had another scout through the draft.= I rseadrian> think I don't quite know what the purpose of the document is. It rseadrian> is clear that, if it came out of (e.g.) the OPSAWG then it would rseadrian> be the IETF's consensus opinion on how to do QR codes in MUD. B= ut rseadrian> in the Independent Stream I think it is one of three things: > 1. If it is documenting a specific implementation (which is hinted at by > "to allow interoperability") then it should name the implementation so > people know what they are interoperating with. > 2. If this is documenting a speculative approach, it should be > experimental and describe how to assess the experiment. > 3. If this is "just" the author's musings about how this might be done, > then it should be caveated accordingly as an opinion. I take your point. I could add an Implementary Summary to the document if that would helpful, but the answer is unfortunately... all of the above. 1. There was a specific implementation which we did do as a proof of concep= t. http://www.sandelman.ca/SSW/talks/isoc-ca-multistakeholder4-2018/ 2. Based upon experience we gained, we decided that we should have a more mainstream QRcode format, and after some research, it was suggested that rla.org was the right place to converge to. Alas, many other things got in the way of getting this done, some of whi= ch is the inevitable chicken-and-egg problem. 3. The document is, yes, "musings" about how we think RFC8520 should be don= e. This is being done in an RFC, because like, "IP-over-FOO" documents, it seemed best to do this in the IETF. This is a "MUD-over-RLA" documen= t. {I think that this proposal is signficantly more concrete (and less experimental) than many other 100-page Informational RFCs produced by WGs which wind up going nowhere.} =2D- ] Never tell me the odds! | ipv6 mesh network= s [ ] Michael Richardson, Sandelman Software Works | IoT architect = [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmHGA1wACgkQgItw+93Q 3WWpRQf/Xd93j45eYjimgibYDTgYNsTEMX4Uc5uKViM1WWjRgoxf1tCPsmFW1Lwg JjnPu5dEeDupjsvWiv2iqSLhKMiM671K0qRAnsfEQrKlr1NzkLNhP5ysQWKjMMJa lMKlG5RQhGVyHZuXZDhSeK+AJM47E/Zy9WahA8suSdSPm9TfDwS6OH2v0MIVzeyS 4lp4IBVRS3EmgONYsw4Ofq9hIUEV3w5soCIkcLGEdtnB8Ks/yGtOsQ4ZaEaAA6tJ SdyR0y1OfhdYWGLwpgUBCoKWByVVE5YQWUjrbmAr6kMoLcWm2JWYl7G0iyeubCjB RF1Q8T5aVCjydCvc3xOiGaCti5BcSg== =99Jh -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 24 09:37:59 2021 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 A34A53A0E52; Fri, 24 Dec 2021 09:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca 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 WWQQhnxtJa56; Fri, 24 Dec 2021 09:37:52 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D11D3A0E53; Fri, 24 Dec 2021 09:37:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 5476338B8A; Fri, 24 Dec 2021 12:42:35 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id BPZyaquY-Oc6; Fri, 24 Dec 2021 12:42:31 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 6FD3738B88; Fri, 24 Dec 2021 12:42:31 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1640367751; bh=t2uDWMrMhEzwqAGV7sGY2K9aDNGGw7oKW4ht7JZyoBE=; h=From:To:cc:Subject:In-Reply-To:References:Date:From; b=7iUS1SG6zDnibXUmuMdzSXPBQ23hdmUD82j4XFETiZIeLmRZhSzDBm/IcxmQobeAL mtPv+4r8ACemmfN1k6AE2TUWc+XkK3CnmlKB/4uHWICOp9Q0ThBvKIIPmjf9hRtdEk e/FHG8Pqf3K8/S2vIHrDIJWX2V9q3yU+ZQ7LQP3eMgs+JswnsjcuhIt+r6QTCfKSBm iJwkjuyy0ByMulRZcuNEY9gHR9/SloMqd+NfXYPWWGkTRh3D8kQJhnJ2j2ELYlxpUY zBzco4JDbqgR2iBCmHZltZBkW08UEir/cnHVtu41sqFxibBI6NpRrfOeJUc0ntFhiu 28wnwp7U3N5jw== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 772F748F; Fri, 24 Dec 2021 12:37:46 -0500 (EST) From: Michael Richardson To: Marco Tiloca cc: draft-richardson-mud-qrcode@ietf.org, rfc-ise@rfc-editor.org, mud@ietf.org In-Reply-To: <0bb1fcee-6746-597b-0ecd-eefe31b863aa@ri.se> References: <2b0346cd-1243-5056-8162-d29107da66cd@ri.se> <29479.1639340699@localhost> <0bb1fcee-6746-597b-0ecd-eefe31b863aa@ri.se> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Mud] Review of draft-richardson-mud-qrcode-02 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: Fri, 24 Dec 2021 17:37:58 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Marco Tiloca wrote: > On the second point, it may just fit as a short paragraph in Section 6 > "Privacy Considerations". For instance: > "The use of URL shorting services discussed in Section 3.2.4 may resu= lt in > trading convenience and efficiency with privacy, since the service pr= ovider > might leverage per-device or per-customer short URLs to track and cor= relate > requests." I've added this to https://github.com/mcr/mud-qrcode/pull/4 > Thanks, I guess these points are also covered in the cited > mud-acceptable-urls . I think it would be good have them briefly incl= uded in > this document too, along the same lines in your reply above. Added above too. >> > * I think it would be good to add considerations on the security o= f the >> > (access to the) physical premises, and on the trust required on th= e network >> > operators performing device deployment and QRcode scanning on those >> > premises. >> >> Are you thinking about a situation where the devices are deployed on= a >> campus, and employees or students could attach new stickers to the d= evice? > =3D=3D>MT > Yes, and to possible active actions from QRcode examiners as hinted i= n the > review at [1]. > [1] > https://datatracker.ietf.org/doc/review-richardson-mud-qrcode-02-iotd= ir-early-jimenez-2021-11-25/ okay, so I think that I've added text about this already. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmHGBWoACgkQgItw+93Q 3WW+lwgAqPGQMfl299KG+us7HRY/lsrF9J+kH2SEkMod2wWNqy3Z55f0BO0PKetV xzN/g5axRccfog1YzFwxSZa/FjIw+w1KNHxc8LH14chalEsbCE8AZH/IJedj0rrp TSfz99FSZWcP9knSe8XvDJ3Zjg5HGX2/cChzYD5r9Wums4mPbMfr9jDqzYH1Ah+a 4CarclWuQziBctYwXwRHHOSstwSn7BaJoIUvWpGBXnokall5tQQx73m737+DlDBZ GLnMZn6HBLfvOi+PTPmJ5Be0udwLjq3FAJDyoMoDLcKzotOWLwZyVXwuzx2Yh1ei bxkeq6pgOc2RukP+nq7eD9lr/B4IAA== =VAsI -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Dec 24 10:48:43 2021 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 15EE73A0EE4; Fri, 24 Dec 2021 10:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ri.se 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 net8q3i5zMOi; Fri, 24 Dec 2021 10:48:35 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-eopbgr130042.outbound.protection.outlook.com [40.107.13.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D7513A0EE2; Fri, 24 Dec 2021 10:48:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Zicc2H6lHDvDonL073u2/pHvrISRZIRiOLprI/vNZy+kICmPD/DM53n/MdIhr/si/sTlV/4TdIzGcLwC9YpJhGTCaaJzDCZKjUfii93Qh2iidLvXR3zde/+9Oj7ixyMJINVJbEHsPcp5Kbi7toxKOTWsAq0jDfZcLLI23SLYr7yX4HSKbmKpLBqSTe7HQLqDANLPPgqBb2ojGU+2RARb2cyECqdO2f9L/A8pHaQMOS4DMsZ0Kz33NTH6zVh1PUdWvgbmg0Se/hzXGmTp6OBx75/5IcwbjzsQT+0LkDFbPuJr+NDVm3Bn6WMQdedb8cInCQxEyqe1NTRwIsGTQcVIwA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Tg1XC3anHbUrL1WvFsdQnuGgCcWN0R8SAVQG49K6Dy4=; b=X9yMRDYX31/0W8MS07wDwDA1WtZ6+7R8Dfbj7q+Wq2z5gnHT9brLe/8E2XOd1yoUH1QFPTRcDqwyKVo3v6FwiSzAeL/UUbfzeJInEqs9WsVV6xan9XvPEbVPHZIod9XrYqgkoPHmkyagrATcrYvzC0sV9dqQjYAOXA6ZpRrEZYM0+AUlieYg61ErTq9zk6I19WQ2rwI5CR2Ns+cRRL4Wj7GEV1LfhvPBdSWwIrHvd+H7qNkXUVwdGm31No5vCaVTkxVC1xUs19kURFxf85BzWwhQKzGb4MzyCkzQ58Ifo3t9FKSlnzuQtfqs0hsBOlUFz4WpUJgyTLy94ms51ZZDHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ri.se; dmarc=pass action=none header.from=ri.se; dkim=pass header.d=ri.se; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ri.se; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Tg1XC3anHbUrL1WvFsdQnuGgCcWN0R8SAVQG49K6Dy4=; b=cxfYI9XgDkMUVcYmfzYmP9pmS4s4K07/ay0PvxeHNx5zJNAHr6HRCygvzwLOPc/zU5J40ps/4fdoJcsDPRUdYKBcPkHT9VwwWuF1a663omC5kc/fGHQwiGVKMsqhUL7L1iiBrtkSlnDo2TPPXJGNsJ+TAP6AL6SFaTG9dnbajys= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ri.se; Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) by DB8P189MB0763.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:fc::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4823.21; Fri, 24 Dec 2021 18:48:31 +0000 Received: from DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::6800:bc0b:ccc:3a69]) by DB8P189MB1032.EURP189.PROD.OUTLOOK.COM ([fe80::6800:bc0b:ccc:3a69%3]) with mapi id 15.20.4823.021; Fri, 24 Dec 2021 18:48:30 +0000 To: Michael Richardson Cc: draft-richardson-mud-qrcode@ietf.org, rfc-ise@rfc-editor.org, mud@ietf.org References: <2b0346cd-1243-5056-8162-d29107da66cd@ri.se> <29479.1639340699@localhost> <0bb1fcee-6746-597b-0ecd-eefe31b863aa@ri.se> <25998.1640367466@localhost> From: Marco Tiloca Message-ID: Date: Fri, 24 Dec 2021 19:48:28 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 In-Reply-To: <25998.1640367466@localhost> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9OeHKhgNkMZzj6OkVzZPpabrKIFTTddTS" X-ClientProxiedBy: MR1P264CA0135.FRAP264.PROD.OUTLOOK.COM (2603:10a6:501:51::12) To DB8P189MB1032.EURP189.PROD.OUTLOOK.COM (2603:10a6:10:16e::14) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1d610ff8-1cd2-4a3f-93a5-08d9c70dfab7 X-MS-TrafficTypeDiagnostic: DB8P189MB0763:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:9508; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: iOPdD7O+JssaaiFiu61HjPPtCEHNrPAMyCPL+6YuPx7rZfJE7XUUWfLZFBshYmib+IG5sp3HTzM+pzgh2Nk1/QXJzj8z7BPMFQYKsnjpvCzsbnpSzo4/cKC6LlozeFAkDrlqKSQq5Z22Y8pe/oeb92PTfAt1MjtXLhDYWolgigBPLcYaFoVxgjwBlENAHCTeBxcySp1/vKTMFfQ7cMYMTGHxYOrvs2blUhztVqxGewmmkP4AxVZTrj6YnKAnkOI+qi1qW5kRlILm+w/R36oECdAxXqkW2FtAIlDT1YuhcCypu3yOKKiemc40ce3/T47zLyBbEE6RvriMoHRNF7z6iMEgkef7xnG3tFanzRFBSWs6yQRDqGvJs6WFHQL4K9C8pqCzuZPnVB6lu3AGMZiUf0YQHBpiWXovc1Xe9E+Vbni8r0xTFRkZmmqX/auvz7Reaz0gmb/fbUHQKxdaRYreWa2xeqb1ZvN2lO8mQII5qdZz1R1aFhZ3iEKBOWR9a03SS0z1+zN2RiDw0E0ydckSzkT0McUDPOOLuTYPVkSh/D/twGPbL3t9V4n79WQY2BG+q+sDjq51gVxzZOY7IGdf7UY1cNEnJblFn/6nLJj61xgUECjAjTlRGKXVoFHHrewCBT4TfwfkE4VXy7HExSviEOuBLzzEPPnKOso4PnMkjhlukmkTs72WE0aJ62seW+yR4yEpbBx4RjAjPPHSewZRM/Lp88KvQ1RMudUmKvG4ub27gGCx7rR2EQrcvDYAWgQBHPajOT/XScVhr+YOftT0cNeOc+UIgoLZLw6ivJemJtc= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB8P189MB1032.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(366004)(6486002)(4001150100001)(8936002)(53546011)(6506007)(6512007)(31686004)(26005)(186003)(31696002)(316002)(44832011)(83380400001)(66946007)(5660300002)(66476007)(86362001)(33964004)(66574015)(38100700002)(235185007)(508600001)(36756003)(2906002)(966005)(4326008)(2616005)(21480400003)(8676002)(66556008)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?V05tbXhhV2tKYlBmRWk3L3hBMXZmamRZbVN3alhTOVVWUGppaUhhczY1MTFQ?= =?utf-8?B?bFlYQ0IycE9FYktYYTBjZXhzaytVbTlHd1hZYU5CRkltQkZ6VWgzRHJzdjFm?= =?utf-8?B?SjgvNU9TbEtVSk9TT3p2cFc3N2I5TlY0R20wNFZHODRGNG14Q0c5YVpGVmM1?= =?utf-8?B?cWptYk5QYk5QMXZPNU15NmZXZ2FHWkQrUXJETk8xSGpPTFU0RVRZNzdVQkhX?= =?utf-8?B?aGJEWGFva3Z3aEgzb1Z0am9oaTRVek14VWlLWTZzcmNNSWExSWVkNHdGV1k0?= =?utf-8?B?SGpVenVDWmh0cm0xcDUwenJGaXJ2MGxieHkyekVHS1A4U2JreDZPZUFIMjQx?= =?utf-8?B?M3V6bkVOQUMxWWViQ3VHaWJpTVljZENEK29nb01LV0VIekhLWFFSbW4vUDEr?= =?utf-8?B?Zmt5NWFsaDdiTTlka0pBQjl2dXBKa1VDcDJLZjNmS0xLckdkV0JoUGVBOWFu?= =?utf-8?B?czdJQTRPcFlOaWhKWFpCcTREN29CN0pQTG9UbDBkR2xyNmMxY1pRSlYrekJF?= =?utf-8?B?KzZJM0Ridno0YmZYaTMrSDNuR2tmdEFIUURwLzB6NTlNMkNxUjhROGF5eTFK?= =?utf-8?B?elkrMEdnSGlKaHB4cllKSWtXOTBaUEdBc2UyMDBtL0huOVlua1ZxYUVoNU9p?= =?utf-8?B?WVFkOVg0c1BqWWNqd25RUWdZVWQvSDlMYzRVaGpEVGg4MW8xQ1RseUlyVy9j?= =?utf-8?B?YUhzcWJiUjJGZVVDcEtxV0tCUmo4aEg0Q1J1ZXRTalFBR0RDQ25JakYyaGQ4?= =?utf-8?B?YTcyb1hJSm8zYkNiQnU3MkpwWmxRaVFoNmRORTVKb08reXN5b1JSU3QvbnRt?= =?utf-8?B?S2NKRGY2TW9SSk9OYWc2YzFUSXhPMmdZdDIxUCtyaXpSQ1FiLy9lQzNwRzBt?= =?utf-8?B?S0V4VmU0bXRaYnZEWXQ0ciswVSthakMrSlBPZVJOZFVnUnRPRnZpZnRDNW9F?= =?utf-8?B?aWlVa2t1RmxZU0tWOWhpRXREdHhKK2JtZzB4WGpTeWlvUzdWRERicE5RRTdC?= =?utf-8?B?cTdUMDFkZEI2Vm1MTEd3SVlNQUp0Q0xxem9lQUdwSUlaeDlSL2Q4ZnBnNk0y?= =?utf-8?B?bWpPVmF3WS9aSjBIN2k4SDVTeFdhY2ZiVk1oYXo3UEJuMkJmNnBna2RQK0ZP?= =?utf-8?B?ek1jTGg0cm43UUdNdDhwOGxSdmVNemhGaE5tTXRybC9TNEx6K0hDYzNWbURa?= =?utf-8?B?OUg3TjVIV3V1MkJSbGE2b3czT0RoU0lSeDhVSlBiSGxxTXlqUkxkb2w1ZVN4?= =?utf-8?B?Ym4zc2FTbW9IMFdtYytrcG1nQXc4M0dZRmFtTjN6Q2NKNFIzMzRwVU9wMGtK?= =?utf-8?B?d0RjeXpQbmdDZWpEWUJJUzRrbVZyQ01MS1NzNk9pVjFzOXRmSEk4b3NZYWJa?= =?utf-8?B?aW9Jd1d5ZmppRlhrazRDd1docS9QSGd5bXY3Nk9EeXhlbVh1amRRYnFrWC9P?= =?utf-8?B?SjhpalNDaU1tUHpSNEI1bkhXeFc3cmtsQVI1V1l1N2NCbklkRzJqbnBmdDI3?= =?utf-8?B?M2VIU1RDUVJlcUJiYWtPSWF2MmhLRDhPU29TajZvYzlpNXpFMnNPV2ZtOGlh?= =?utf-8?B?VmIyTkE0b21NWnJ3azVTS3lXU0FRM1d4RjhrQ09GUWJPQzBNcGYxSTNxR29R?= =?utf-8?B?SXJYNGIvVE00dzE5TXlPV2RncHJVcmg1MGpleTFUdmdrUm94dStHSFpJMlR2?= =?utf-8?B?Z2N5bGtrYXJidTcrejVnNDE4aGJwb09BajZHT0hPM2wxSXNBZlFaUVI5V29M?= =?utf-8?B?R3FFZGIzdTMxS0VFVUhyZ3pTclpzcllnS1pOUGs2YmxxTHFCSzNDQmdQSk1Y?= =?utf-8?B?b1JpcWEzcWxuRnZ3bU1raXZuM0FtWUdLSzZ3b1ZNWW4yN1p0OE9JRmdDVHIr?= =?utf-8?B?eW5IcHN1SFBtZXUwWURnS1ladzBoMXJkSkFObjI5T2pjeWROdlRCVkxaR0ZZ?= =?utf-8?B?bU5Nekw0V2ZCUHVjMERubkhqemtXWUFianNqd0R5aDVrbVpFS0hTV3NuVEFH?= =?utf-8?B?NDFJS2RqS3hCb1hzWlBtUHN4aGZscTJrVWxtZEVjVmoyU1JjdDUycGo5V2ZH?= =?utf-8?B?SVg5b01WcjMydWFRRFhNRGY5VHNsVUZtZlhqcG4rblFIZTVkSkJTMW95Rnls?= =?utf-8?B?QklIYmE3bjFFUUNLcGFGY2JDRFRNN0JTN0pEUlA3d04wNGtBWjZ3Q2JZVCtD?= =?utf-8?Q?skihvruaokfi+EXOxxQxi0s=3D?= X-OriginatorOrg: ri.se X-MS-Exchange-CrossTenant-Network-Message-Id: 1d610ff8-1cd2-4a3f-93a5-08d9c70dfab7 X-MS-Exchange-CrossTenant-AuthSource: DB8P189MB1032.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Dec 2021 18:48:30.7141 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 5a9809cf-0bcb-413a-838a-09ecc40cc9e8 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: bLlL1mrZSg0XFcE4W6ZqSh1gc7ebR+cAPZcT0gDzvJN4iuzngoedD1Y3jQlM7RgJolWv6VY6sbENfYEXkYWxFg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB8P189MB0763 Archived-At: Subject: Re: [Mud] Review of draft-richardson-mud-qrcode-02 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: Fri, 24 Dec 2021 18:48:41 -0000 --9OeHKhgNkMZzj6OkVzZPpabrKIFTTddTS Content-Type: multipart/mixed; boundary="RMFn2tlkIZPKcViyuqTCn4YpnTAUwIirU"; protected-headers="v1" From: Marco Tiloca To: Michael Richardson Cc: draft-richardson-mud-qrcode@ietf.org, rfc-ise@rfc-editor.org, mud@ietf.org Message-ID: Subject: Re: Review of draft-richardson-mud-qrcode-02 References: <2b0346cd-1243-5056-8162-d29107da66cd@ri.se> <29479.1639340699@localhost> <0bb1fcee-6746-597b-0ecd-eefe31b863aa@ri.se> <25998.1640367466@localhost> In-Reply-To: <25998.1640367466@localhost> --RMFn2tlkIZPKcViyuqTCn4YpnTAUwIirU Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Michael, Thanks, it looks good! Best, /Marco On 2021-12-24 18:37, Michael Richardson wrote: > Marco Tiloca wrote: > > On the second point, it may just fit as a short paragraph in Sec= tion 6 > > "Privacy Considerations". For instance: > > > "The use of URL shorting services discussed in Section 3.2.4 may= result in > > trading convenience and efficiency with privacy, since the servi= ce provider > > might leverage per-device or per-customer short URLs to track an= d correlate > > requests." > > I've added this to https://github.com/mcr/mud-qrcode/pull/4 > > > Thanks, I guess these points are also covered in the cited > > mud-acceptable-urls . I think it would be good have them briefly= included in > > this document too, along the same lines in your reply above. > > Added above too. > > >> > * I think it would be good to add considerations on the secur= ity of the > >> > (access to the) physical premises, and on the trust required = on the network > >> > operators performing device deployment and QRcode scanning on= those > >> > premises. > >> > >> Are you thinking about a situation where the devices are deploy= ed on a > >> campus, and employees or students could attach new stickers to = the device? > > > =3D=3D>MT > > Yes, and to possible active actions from QRcode examiners as hin= ted in the > > review at [1]. > > > [1] > > https://datatracker.ietf.org/doc/review-richardson-mud-qrcode-02= -iotdir-early-jimenez-2021-11-25/ > > okay, so I think that I've added text about this already. > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T cons= ulting ) > Sandelman Software Works Inc, Ottawa and Worldwide --=20 Marco Tiloca Ph.D., Senior Researcher Division: Digital System Department: Computer Science Unit: Cybersecurity RISE Research Institutes of Sweden https://www.ri.se Phone: +46 (0)70 60 46 501 Isafjordsgatan 22 / Kistag=C3=A5ngen 16 SE-164 40 Kista (Sweden) --RMFn2tlkIZPKcViyuqTCn4YpnTAUwIirU-- --9OeHKhgNkMZzj6OkVzZPpabrKIFTTddTS Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEOEo4cV326Z7GypVg7iZktA5Y2kMFAmHGFfwFAwAAAAAACgkQ7iZktA5Y2kNx vQf+KNG4RhKzIXoR2Ct0qH8brN+giBT6jUzYAtcOuxctVQXeKShtEoEH4IdaiuGo5Lr5XOnRNpLU OXCK2Mw1iIjCoa+5qd/OUNKj703ImuNuFrznfyON9glXIVo671NPce97GD54GiFxNYYkTp9e//9D i+yRJV8+6v6UHX0L/GlbyBXNmhm4V6iNSSaiftn3n/s1WzzI6CVCN3DUql4ElhxBM5+JqQQkhkYk M43iCrW6cRqImrcZ6xM+K/lJ1cvYnRUl7hSX1fpi8Uwakif+8+ID+BpLv2t8cVHSWdP2CI7kTYTg OjZ8KORAbi+MM1KtJm9krEMhhSBoiopu7cylKTEiIQ== =UViE -----END PGP SIGNATURE----- --9OeHKhgNkMZzj6OkVzZPpabrKIFTTddTS-- From nobody Fri Dec 24 10:52:45 2021 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 1416E3A0EE8; Fri, 24 Dec 2021 10:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca 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 6ri6AoKCLdAl; Fri, 24 Dec 2021 10:52:31 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0FB3A0EE7; Fri, 24 Dec 2021 10:52:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 21E7D38B76; Fri, 24 Dec 2021 13:57:13 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MRRUMx0RdSLn; Fri, 24 Dec 2021 13:57:12 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D29CB38B75; Fri, 24 Dec 2021 13:57:11 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sandelman.ca; s=mail; t=1640372231; bh=svrc07piU3bgq7XXNAU3Y7VdmHkiljY4lXKjc5bOhvk=; h=From:To:Subject:In-Reply-To:References:Date:From; b=SuHAPohtCF1fZI9YwxllLu52nMkjSTvekXw4Eu72gmcwK/SK8jsD4HerLxThjHiMM WBgKa4ioWkhNqCuV+4C+O91pTz903n99K8wVo57Z9PMKGpbaOro5TaMfWXlW0bmhfY g2O9ryEngh00Qxjf3ZQqYxfOiwX1SXfAeulc5XqTEulHG83OGzdy46dy3QHvB/U1Vt yUbxEzr3Fgn6c2z3RqGRBUvr76RpBvE3Mq/qPt7YJ/kb4kgVGfSj0xKXFdSWr6ffL0 McKocW8z/8ayRIb0N8W6JySv941p9ot3vcIhlAAJUSpUVy8WOh70dkU0HTdOY5Li3K X0tyKXpDUVldA== Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A080F48F; Fri, 24 Dec 2021 13:52:26 -0500 (EST) From: Michael Richardson To: David Lamparter , int-dir@ietf.org, mud@ietf.org, draft-ietf-opsawg-mud-iot-dns-considerations.all@ietf.org, opsawg@ietf.org In-Reply-To: <163994413394.12070.6171048717943515773@ietfa.amsl.com> References: <163994413394.12070.6171048717943515773@ietfa.amsl.com> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Mud] Intdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-02 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: Fri, 24 Dec 2021 18:52:36 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Normally, I like to reply with specific changes, but I haven't figured out what changes to make, and I also see that there are some XXX in my document that also reflect places I wanted to also make changes. So, please expect another reply with some specific text, once I've faulted enough pages back into the brain. David Lamparter via Datatracker wrote: > re. 3. Strategies to map names > - plain reverse lookups. > Some vendor working with cheapest available developers will sadly und= erstand > your list as "oh I just need to do my reverse maps /right/ and then i= t should > work." I'd say "explain in detail how this can fail." is not enough,= it might > need to be "explain in detail how this can fail even if the vendor tr= ies its > best". I think that I'd like to take another round trip with DNSOP then to make su= re that I've covered all the ways, and perhaps there is simply a document that= I can reference. > - the controller doing lookups, (potentially using the same caching r= esolver) > The MUD controller and the device using the same resolver is a neccss= ary > requirement, but not a sufficent one. Worse even, this is essentiall= y a > Time-Of-Check-Time-Of-Use security vulnerability. An attacker may be= able to > distinguish device-originated DNS lookups from controller-originated = lookups > and give the controller a much longer list of replies while still all= owing the > device to function normally to cover their tracks. It's fringe (if y= ou can > break DNS like that there's probably better things you can exploit), = but still. Yes, I agree that there is vulnerability here. Having the MUD controller do DNSSEC validation helps a lot, if the manufacturer can be bothered to sign with DNSSEC. Or using DoH, DoT... as either way the attacker now has to compromise the authoritative servers. I feel that there is a lot more to say here. > I haven't really put extensive thought into this, but the only > pedantically-correct solution to me seems to be to actually track the= exact > DNS responses that were given to the device. Yes, that certainly can be done, and in the home router (which is also the DNS server for the device), then it occurs quite naturally. Note that the goal of MUD is not perfect mapping, but rather a reduction in risk. As such I want to be very cautious about throwing away incremental improvements because they aren't perfect. > re 4.1. Use of IP address literals in-protocol > Nothing says the MUD file and device spec need to specify the target = in the > same way. It might actually be a good idea to give the device a DNS = name to > resolve, but just list all the IP addresses in the MUD file. The ven= dor should > absolutely be able to do that in some cases at least (i.e. no highly = dynamic > changes to the addresses.) Considering all else, this might even be = one of the > better approaches? This is already possible. I think that it will lead to too many operational problems. Do you think that the document should deal with this in a pro/con section? > On a sidenote, this also means it's wrong for the firewall to try to = validate > SNI names when the MUD file only lists IP addresses. Yes, that's true. As we go towards ESNI, I hope that firewalls won't try to do this, as I thi= nk that *validating* SNI is a mistake. Observing and auditing and logging if there are changes is a different situation though. I think it is reasonable for a MUD file to tell the MUD controller if the S= NI should be visible or not (see draft-ietf-opsawg-mud-tls...) > Technically the MUD file could also list a *different* DNS name that = is > guaranteed to return a superset of addresses that might be used by th= e device. > Whether this is a good idea I don't know. (Also note this conflicts = with > monitoring a device's DNS lookups to track the actual responses it re= ceived.) This definitely could be done. www-all.example.com, when www.example.com will return a geo-fenced address. > Ultimately though what I'd like to note here is that there's 2 differ= ent > objectives here. The device itself wants a useful subset of addresse= s to > contact. But the firewall needs the superset of anything the device = might > need to talk to. Agreed. I think that this paragraph is worth integrating into the document= somewhere. > re 5. DNS privacy and outsourcing versus MUD controllers > I honestly don't understand how any device vendor can reasonably enco= de some > specific DNS service into their device and expect it to work. If my = network, > whether it be home or corporate, has a policy for some specific DNS c= ache to > be used (e.g. on some firewall appliance), a MUD file isn't going to = punch a > hole into my policy for that. And this really zaps all the DoT & DoH= bits at > the same time. Yes, it sure happens. Go read the threads in ADD, particularly from Paul Vixie, about how Google devices will keep trying to talk to 8.8.8.8, even when given a local, fully functional, DNS server via DHCP, and even when 8.8.8.8 is blocked. > And with me being from Germany I can tell you we have ISPs that give = their > users a checkbox to block Cloudflare DoH on their service - not even = for > technical merits, just because it was a publicity sh*tstorm. (Neverm= ind the > fact that the ISPs may have their own ulterior motives.) Yes, go read Geoff Houston comments/presentation from the side meetings aft= er IETF112, at RIPE-83, and on the RIPE DNS-WG ML. The short of it is that DNS resolution doesn't make any money for the ISP, having it break costs th= em money and reputation, and so if they can outsource it to Google, from the ISP's point of view and for many users, it's a win-win. From=20a MUD controller point of view, it's just fine if the home router ta= lks to some outsourced DNS server rather, as long as the queries from the device get cached in the router. This is exactly how openwrt running dnsmasq work= today. > 6.5. seems a no-brainer, maybe even too weak of a conclusion. Device= s /really/ > should use the DNS they get told by the network. Yeah. Are you asking for strong language here? > 6.1. is the MUD file a protocol too? It's not clear from the text. > (I do also disagree on the conclusion, in my naive world the vendor s= hould > really be able to list all possible IP addresses for the services, an= d doing > so is likely the most robust way. But I'm a "there is no cloud, just= other > people's computers" person, so maybe I expect too much of vendors.) 6.1 is not about MUD exactly, but rather other protocols. Section 4.1 talks about this problem. In my experience trying to fashion MUD files for things like printers, it's endemnic in the update protocol. > re 7. Privacy and 8. Security: >> Posession of intimate devices may cause embarassment. Posession of = personal >> healthcare devices may open people up to attacks on their life. Ima= gine some >> dissident in Atlantis being assassinated on Princess Arielle's order= s by way >> of targeting something on the dissident's dialysis machine, pacemake= r, or >> whatever else. May I use your Atlantis/Little Mermaid example? :-) I am of the wrong age to really have experienced that film (too old for me, and it's too ancient to interest my kid... now teenager). I don't remember there being dialysis machines in Atlantica. > But vendors will still read this as "eh, people won't care if someone= has my > devices". And then 5 years later they get bought up and the new owne= r makes > sex toys off the same codebase :) > And lastly: "requirements for the devices to get access to network re= sources > that may be critical to their continued safe operation." ... I guess = this is > more of a comment, but I certainly hope no hospital, metalworks, sewa= ge works, > or power plant ever depends on MUD functioning correctly to ensure *s= afe* > operation. Frankly, I hope that they do use MUD. That's the whole point here. If it's not good enough for them, then why are we even bothering? They are currently frantically trying to put ACLs in place to restrict acce= ss by devices to the network. The amount of call-home-or-it-does-not-work is quite amazing. Yes, most of here in the IETF think that IoT should be devices talking to other devices, not device->cloud->device, but firewalls and NAT44 have gotten in the way. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmHGFuoACgkQgItw+93Q 3WU+Cwf/ZHC27Ktr0wtzy1Fkuixizc6FE6cjcYQsmqPD2Gi0bZ2YNDWYgtvdxfaT h6D4/4jcV0+ri+log9O/CdXgbKbEJf1bIjdFnDuCYwyaM0NLgSQ0D1oKUkluhfze cdu/wvJLUulWo0aHHp9twjUjpXzMzzJK5GlSk7bZY+6ca7N4nJl0oB/RnE1NoUBJ LYkvHcB8apzGOKlg6TJK5Qvra729MzAQP9ipiNY0MRbIsq/sXhw2fFqqupi6aW2g lvpa6chla3Vp5BNBX5DkVKgee1mAmxjGsewY7IabLB0nTVQpjQd/WU00ayoZI2Q7 TEl2CZ3xd6IfqYBcjfhpgkcpI17XIw== =isIr -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Dec 25 03:09:36 2021 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 A35F73A0D43; Sat, 25 Dec 2021 03:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 L8oYC6EKqtu2; Sat, 25 Dec 2021 03:09:18 -0800 (PST) Received: from eidolon.nox.tf (eidolon.nox.tf [IPv6:2a07:2ec0:2185::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E1203A0D42; Sat, 25 Dec 2021 03:09:15 -0800 (PST) Received: from equinox by eidolon.nox.tf with local (Exim 4.94.2) (envelope-from ) id 1n14vF-0092VB-6h; Sat, 25 Dec 2021 12:09:09 +0100 Date: Sat, 25 Dec 2021 12:09:09 +0100 From: David Lamparter To: Michael Richardson Cc: int-dir@ietf.org, mud@ietf.org, draft-ietf-opsawg-mud-iot-dns-considerations.all@ietf.org, opsawg@ietf.org Message-ID: References: <163994413394.12070.6171048717943515773@ietfa.amsl.com> <14215.1640371946@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <14215.1640371946@localhost> Archived-At: Subject: Re: [Mud] Intdir early review of draft-ietf-opsawg-mud-iot-dns-considerations-02 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: Sat, 25 Dec 2021 11:09:24 -0000 On Fri, Dec 24, 2021 at 01:52:26PM -0500, Michael Richardson wrote: > Normally, I like to reply with specific changes, but I haven't figured out > what changes to make, and I also see that there are some XXX in my document > that also reflect places I wanted to also make changes. > So, please expect another reply with some specific text, once I've faulted > enough pages back into the brain. I'm noticing I communicated some of my thoughts quite poorly, probably in part because I was somewhat unsure on distinguishing "comments" from "review". Apologies for that, I'll note to put a bit more time into clearer communication on future reviews. I also have really taken a wrong turn in basing some of my feedback on thinking the names looked up by the device would match ACL entries in the MUD file, particularly this first item: > > - the controller doing lookups, (potentially using the same caching resolver) > > > The MUD controller and the device using the same resolver is a neccssary > > requirement, but not a sufficent one. Worse even, this is essentially a > > Time-Of-Check-Time-Of-Use security vulnerability. An attacker may be able to > > distinguish device-originated DNS lookups from controller-originated lookups > > and give the controller a much longer list of replies while still allowing the > > device to function normally to cover their tracks. It's fringe (if you can > > break DNS like that there's probably better things you can exploit), but still. > > Yes, I agree that there is vulnerability here. > > Having the MUD controller do DNSSEC validation helps a lot, if the > manufacturer can be bothered to sign with DNSSEC. > Or using DoH, DoT... as either way the attacker now has to compromise the > authoritative servers. In retrospect, I really regret bringing this perspective to the table. It only makes sense from a "100% match/constraint" perspective. But with a make-before-break approach, the ACL being wider than the actual usage by the MUD device is intentional. Turning my paragraph on its head, it might rather be prudent to repeat (for the benefit of network operators) that a MUD file can be arbitrarily lax on its constraints. Attacks on DNS can't widen it further than plain manufacturer indifference to putting work into a good set of ACLs. But after spending a bit more thought on this, I actually think I have a good piece of proper "review" suggestion: I think it would be immensely useful to add/describe the perspective of what happens when addresses associated with a service are 1. added, 2. removed, or 3. fully replaced. All the DNS caching and "perspective" effects come down to the same differences, but they're corner cases to ops. Moving services around is core ops. [-- continued below at anchor "A"] > I feel that there is a lot more to say here. And it really applies generally to using DNS names in ACLs. I'm unaware of any other document that went this direction, is there any? RFC 8520 might've skipped over a seemingly innocuous but on closer look quite nontrivial chunk of considerations here. > > I haven't really put extensive thought into this, but the only > > pedantically-correct solution to me seems to be to actually track the exact > > DNS responses that were given to the device. > > Yes, that certainly can be done, and in the home router (which is also the > DNS server for the device), then it occurs quite naturally. [-- anchor "A", continuing on add/remove/replace] Looking at these 3 temporal changes, the takeaway I've evolved to at this point is that there are 2 overall patterns to get to "full correctness": - either the MUD controller shares the exact DNS->IP view that the MUD device has, ideally down to individual DNS lookup results. BUT: this implies the names listed in the MUD file must exactly match what the device looks up - and that's neither provided nor intended by 8520. Which really just renders this moot for further consideration. (It also requires controller and device to use the same DNS infrastructure.) - or the entire thing instead moves to a make-before-break approach. The names in the MUD file receive address additions before the device sees them, and deletions after they expire out of device visibility. BUT: this implies the names listed cannot match what the device looks up/uses, and needs significant extra care by the device manufacturer. The second item here I had kindof headed towards in my original review when I mentioned using separate names, but I'll freely admit I hadn't thought this to the end of being good ol' make-before-break. Both approaches would solve the 3 "temporal operations", though in almost antithetical ways: construct a kind of atomicity to the changes vs. split the operation into 2 or 3 stages. [-- anchor "B", the following 3 paragraphs are redunant, left them here just for clarity/explicitness] Ultimately, again, this is really an issue of diametrically opposed function of the name lookups. Not sure which terms to use - "necessary vs. sufficient", "additive vs. subtractive", "permissive vs. restrictive" - but it boils down to: The MUD device starts with an empty set of endpoints and uses DNS to put a few addresses into the set so it can pick something to talk to. If the set of addresses is *smaller* than the set of addresses that provide the necessary service/function for the device to operate, that's perfectly fine. The MUD controller starts with allowing the unrestricted set of the entire internet (equivalent to no MUD file too) and is using DNS to narrow down this set. If the set of addresses is *larger* than the set id above, that's perfectly fine. [-- end redundant] > Note that the goal of MUD is not perfect mapping, but rather a reduction in > risk. As such I want to be very cautious about throwing away incremental > improvements because they aren't perfect. Fully agree. Lacking sufficient context and knowledge, I unfortunately have no clue what would lead to the best actual realized improvements. > > re 4.1. Use of IP address literals in-protocol > > > Nothing says the MUD file and device spec need to specify the target in the > > same way. It might actually be a good idea to give the device a DNS name to > > resolve, but just list all the IP addresses in the MUD file. The vendor should > > absolutely be able to do that in some cases at least (i.e. no highly dynamic > > changes to the addresses.) Considering all else, this might even be one of the > > better approaches? > > This is already possible. > I think that it will lead to too many operational problems. > Do you think that the document should deal with this in a pro/con section? This paragraph of mine really came about from me thinking about the make-before-break consideration above, though I hadn't arrived at that myself just yet. I suggested listing all the IP addresses only because I was stuck with this "additive" use of DNS and took listing addresses as "subtractive" converse. The real point is to distinguish that converse approach, not the distinction between use of DNS and addresses. > > On a sidenote, this also means it's wrong for the firewall to try to validate > > SNI names when the MUD file only lists IP addresses. > > Yes, that's true. > As we go towards ESNI, I hope that firewalls won't try to do this, as I think > that *validating* SNI is a mistake. Observing and auditing and logging if > there are changes is a different situation though. > I think it is reasonable for a MUD file to tell the MUD controller if the SNI > should be visible or not (see draft-ietf-opsawg-mud-tls...) Let me reword the review item: for section 1, SNI considerations, I think you should make clear the MUD file is making no commitment at all that the names listed in the ACLs would match what the device ends up negotiating a TLS connection to. The DNS names in a MUD file are just indirections to listing IP addresses. So looking at SNI names is wrong even when it's possible. > > Technically the MUD file could also list a *different* DNS name that is > > guaranteed to return a superset of addresses that might be used by the device. > > Whether this is a good idea I don't know. (Also note this conflicts with > > monitoring a device's DNS lookups to track the actual responses it received.) > > This definitely could be done. > www-all.example.com, when www.example.com will return a geo-fenced address. Exactly this. > > Ultimately though what I'd like to note here is that there's 2 different > > objectives here. The device itself wants a useful subset of addresses to > > contact. But the firewall needs the superset of anything the device might > > need to talk to. > > Agreed. I think that this paragraph is worth integrating into the document somewhere. [this is what the earlier 3 paragraphs at anchor "B" are redundant with.] [...some paragraphs cut...] > > 6.5. seems a no-brainer, maybe even too weak of a conclusion. Devices /really/ > > should use the DNS they get told by the network. > > Yeah. Are you asking for strong language here? Yes, though to clarify, I should've inserted a "first" there. Nothing wrong with a fallback, if it's implemented correctly. (And if a particular network requires DNS lookups from devices to pass through its DNS service to enforce some security purpose, it needs to be blocking other DNS anyway.) > > 6.1. is the MUD file a protocol too? It's not clear from the text. > > > (I do also disagree on the conclusion, in my naive world the vendor should > > really be able to list all possible IP addresses for the services, and doing > > so is likely the most robust way. But I'm a "there is no cloud, just other > > people's computers" person, so maybe I expect too much of vendors.) > > 6.1 is not about MUD exactly, but rather other protocols. > Section 4.1 talks about this problem. In my experience trying to fashion > MUD files for things like printers, it's endemnic in the update protocol. Ok - this absolutely needs wording clarification, because your current wording can be read as recommendations to either "always use DNS names on the device and MUD file", but also "always use DNS names, but this is no statement about the MUD file". > > re 7. Privacy and 8. Security: > > >> Posession of intimate devices may cause embarassment. Posession of personal > >> healthcare devices may open people up to attacks on their life. Imagine some > >> dissident in Atlantis being assassinated on Princess Arielle's orders by way > >> of targeting something on the dissident's dialysis machine, pacemaker, or > >> whatever else. > > May I use your Atlantis/Little Mermaid example? :-) Sure :D > I am of the wrong age to really have experienced that film (too old for me, > and it's too ancient to interest my kid... now teenager). I don't remember > there being dialysis machines in Atlantica. Honestly I just didn't want to name any particular oppressive regime for obvious political reasons. I thought about fictional continents and only associated to the movie from there... > > And lastly: "requirements for the devices to get access to network resources > > that may be critical to their continued safe operation." ... I guess this is > > more of a comment, but I certainly hope no hospital, metalworks, sewage works, > > or power plant ever depends on MUD functioning correctly to ensure *safe* > > operation. > > Frankly, I hope that they do use MUD. Oh they absolutely should. I was trying to say they can't rely on it for functional safety. In most fields, safety regulations and certifications will already require safe operation to be a property inherent to the device as much as possible. A MUD file is an extra defensive layer, but if it fails open, that's no excuse for a device to die in a "bad" way (e.g. because background internet traffic like SSH portscans tripped/deadlocked something in its embedded firmware, and the deadlock causes e.g. raw sewage to get into the drinking water supply.) Cheers and Happy Holidays, -David