From nobody Fri Jan 10 11:15:01 2020 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 F40391200B5 for ; Fri, 10 Jan 2020 11:14:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 UTfKy4pHe0pD for ; Fri, 10 Jan 2020 11:14:56 -0800 (PST) Received: from mail-il1-x12c.google.com (mail-il1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110FA120019 for ; Fri, 10 Jan 2020 11:14:56 -0800 (PST) Received: by mail-il1-x12c.google.com with SMTP id t8so2641344iln.4 for ; Fri, 10 Jan 2020 11:14:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+NITPUdTrI1SVn2g2JwT9bl0vGeBnxvhRhXmOpxqTU0=; b=egAatAU4Xxd+BGiQMH6JUjUS5N8cL15ub2exu57lhv5MrKGn0fa8iGIwgEE/b0Aas0 vWqKIj3ZJKHVOG3XEBeSQHMQiTBA0P5KG3JDTGyGtafyhNA4qQh0LtpiVhfXMwoI+vyQ 3o/KtwT8fDW1jd/tFA8ej4BVagzsi3sje1us5GE+dU5Ky+C6mo0gAidi+w2XUJ5Lv3Sx gymvoEEBxA+ktBbdl9KiCoDWO7CYK9asDJ0QnBiE2htG53zv6I6OhwMsNnMpjG13S5U4 DpxMIMpVEZm6gqwSbLTo/MYdsTmp9cVQ9G8+A2D2BCjPHR2Uv7yK7IgY+8RD+ITsjjHL eIGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+NITPUdTrI1SVn2g2JwT9bl0vGeBnxvhRhXmOpxqTU0=; b=iQkoJ+fZOHjxRzBV5R94oatwK5T/cy9awmTHH9nC/ArWHlIrTesIHG9vbkabfDxnaS ywYDyTUOAmgVeUxhSMh0HXBwsxFX9BogTArNrqbxEeVFTpE2fmhB6QkQqG4z5kTwacV9 63Z1KbjwUGC/kSRwINA6OHg7+wxbEZVTGM/Rf4y1Q2yAfaSKTdRmlavBW7HGtxJL+cQw LSThsL4dAcFejEFz4/1/8x5tFHYrYzpzunSgg1z/udm50nbAMnMlHWbdzSQqFxYtwOP5 ugt+yGKxcLPXbkIbGTBX9aHBz69C85nTgslTPV7/ERWrR9CfY3kNdQLA5z/jnL3VZreY rq2g== X-Gm-Message-State: APjAAAUnjIVxHR4tE00MxXFg2dmAe6QU5rUQQt5dUsSCzGgOCGDXIYcU hn71iZiRSCp4zaeMxMarUQvMLvbQrDVKE9DPT/E2euwMg7YwKQ== X-Google-Smtp-Source: APXvYqzGtYhNmjUlTUAW0DHANZ6lkw+Um/5m0K8WZ6JHuVtndAYSFQLv1xYLW4axwUpMF4amV7Zas1A0VSwpOMGAMmM= X-Received: by 2002:a92:dcca:: with SMTP id b10mr4147907ilr.294.1578683694891; Fri, 10 Jan 2020 11:14:54 -0800 (PST) MIME-Version: 1.0 From: "M. Ranganathan" Date: Fri, 10 Jan 2020 14:14:18 -0500 Message-ID: To: mud@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Mud] DPP + MUD onboarding 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, 10 Jan 2020 19:14:59 -0000 I am tinkering with ideas on onboarding devices using DPP and device certificates. In DPP a trusted configurator onboards a device. I added (prototyped) piggy backing device certificates to DPP config requests so the device transmits its full device certificate (not just raw public key) as part of the DPP config request. This certificate is verified by the configurator which is a trusted application assumed to have the CA certifcate and can be assumed to reside on the same network as the MUD-enabled device.( This certificate transmission is not part of the DPP spec but I am hoping somebody picks up on it.) The question is how to transmit the MUD URLin a non-spoofable way given that the configurator is trusted, has possession of the public key of the device and has already onboarded the device. I want to avoid defining new API for the MUD controller. Does the following make sense? - Configurator broadcasts the public key and MAC address of the device being onboarded (which is part of the DPP onboarding URL) on the local network using a reserved port. - MUD server picks up this information. - MUD-enabled device sends *signed* MUD URL as part of the DHCP request (using options 161). - MUD server verifies signature and installs rules / blocks device if signature fails. Thank you for reading. Thoughts? Best regards and best wishes for 2020. Ranga -- M. Ranganathan From nobody Fri Jan 10 11:59:44 2020 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 3A30F120052 for ; Fri, 10 Jan 2020 11:59:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 zECKjFN90csz for ; Fri, 10 Jan 2020 11:59:39 -0800 (PST) Received: from mail-io1-xd35.google.com (mail-io1-xd35.google.com [IPv6:2607:f8b0:4864:20::d35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF2C812001A for ; Fri, 10 Jan 2020 11:59:39 -0800 (PST) Received: by mail-io1-xd35.google.com with SMTP id i11so3343157ioi.12 for ; Fri, 10 Jan 2020 11:59:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=E2pIA/4DYf1Oa5nGnJHp+B+exjrR5exqGVD0L6hnnto=; b=pDcI+ee9UJprmrrnYhqYWISEM6z/dyUPCVilKcoAmk3z1gWi/Rdy0HVEkA3Kk9izs7 OmuPa8KA/bBXae1dde/n9/IHMXDkExKOcyAEvTW/Pb1AxKoHsuQALVwSc7jFLkiIYEAO Z8+D9m7qu8alGzl1j+JfSx94WrZdia9wo+IMuyvovZPUqew7g+cBGuVWJohYA3LsyVsn P5kIV6plGiOGWihKN2/ewMq5644MXxO4met4jl5eq0PCLSlCNMIUvihcWtnVdTZSoIOU sqLjn9kT7vEK1NmKaESyXSq3kpYh8y2ZrojsgG9wL/5Eo/OYr9Ns2H8jQ1E9XrxAXCaI oGog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=E2pIA/4DYf1Oa5nGnJHp+B+exjrR5exqGVD0L6hnnto=; b=abf1f5sNljM7o9iUWmayfjYZ7nquUxO/iTmRnh6qvGMoh9DQuXwMYHv0d73qNL2eGv /eKiK863jdw8mNPXdkYsuHphgrzqZboBwKB7YJKlL9appEOjdHepsUOdfyJ8DsdaMHCk 0w9A3SI1laAxP5nrqAZt5M0erxi9DG1W0qu4qC4XItc9EDRouoMXstYCfyGjTASlcdyp UBVVzyGKI/XPpzkmcMxx5wScRM9vPMVnXRRFb8Y9ajVHG5f++LI/Lq7wCfTyJ55fbgT7 V9ZUsxbwBopAwXa6AuDCNdQvUXbG75mJoQtLNfKRxPZgE/938vMTYnPBr21R2QaUDooH 8XHQ== X-Gm-Message-State: APjAAAVdU5hHCsGY2jYEiDD0b6x0pHYKuAqiJJ1nDAVuwHD11QLB7/MP odP7j9al5kUZLJ4l6eUbH6V8F9FoRSwiy0xFeexYkl9kBEQvqw== X-Google-Smtp-Source: APXvYqyKSAfThsie3KrO8uRh4c2KN0D6QUmskB2+n+5CkNp80vhQexBqg7QTn0UZvJ8lbyL5OWglV8ECCEfIhfbRSbs= X-Received: by 2002:a6b:6813:: with SMTP id d19mr4025733ioc.52.1578686378354; Fri, 10 Jan 2020 11:59:38 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: "M. Ranganathan" Date: Fri, 10 Jan 2020 14:59:02 -0500 Message-ID: To: mud@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Mud] DPP + MUD onboarding 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, 10 Jan 2020 19:59:42 -0000 A few holes .. excuse the spam I need to think this through again. On Fri, Jan 10, 2020 at 2:14 PM M. Ranganathan wrote: > > I am tinkering with ideas on onboarding devices using DPP and device > certificates. > > In DPP a trusted configurator onboards a device. I added (prototyped) > piggy backing device certificates to DPP config requests so the device > transmits its full device certificate (not just raw public key) as > part of the DPP config request. This certificate is verified by the > configurator which is a trusted application assumed to have the CA > certifcate and can be assumed to reside on the same network as the > MUD-enabled device.( This certificate transmission is not part of the > DPP spec but I am hoping somebody picks up on it.) > > The question is how to transmit the MUD URLin a non-spoofable way > given that the configurator is trusted, has possession of the public > key of the device and has already onboarded the device. I want to > avoid defining new API for the MUD controller. > > Does the following make sense? > > - Configurator broadcasts the public key and MAC address of the device > being onboarded (which is part of the DPP onboarding URL) on the local > network using a reserved port. > - MUD server picks up this information. > - MUD-enabled device sends *signed* MUD URL as part of the DHCP > request (using options 161). > - MUD server verifies signature and installs rules / blocks device if > signature fails. > > Thank you for reading. > > Thoughts? > > Best regards and best wishes for 2020. > > Ranga > -- > M. Ranganathan -- M. Ranganathan From nobody Sat Jan 11 16:33:35 2020 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 335BA12004D for ; Sat, 11 Jan 2020 16:33:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 B51URGkDh0LV for ; Sat, 11 Jan 2020 16:33:32 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C46812001A for ; Sat, 11 Jan 2020 16:33:32 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C5A603897F; Sat, 11 Jan 2020 19:33:07 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 6FE7C431; Sat, 11 Jan 2020 19:33:31 -0500 (EST) From: Michael Richardson To: "M. Ranganathan" cc: mud@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] DPP + MUD onboarding 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: Sun, 12 Jan 2020 00:33:34 -0000 --=-=-= Content-Type: text/plain M. Ranganathan wrote: > The question is how to transmit the MUD URLin a non-spoofable way given > that the configurator is trusted, has possession of the public key of > the device and has already onboarded the device. I want to avoid > defining new API for the MUD controller. I am not that concerned about spoofing of the MUD URL in this process. I think that a place where we need an Operational Security Considerations document is in how MUD URLs are updated. The DHCP mechanism in particular, is easily spoofable, and quite reasonable for MALWARE in the device to change it's URL. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4aaVsACgkQgItw+93Q 3WUGZAf5AQQ9vsCP97qvDCHwDk60XTj/5M59zsz5RguCf+FYw4ALvxGoU56KvGaf TgNw2r5yVA21WrPleQ2qYFDcFfXL7bSml4dOs3pvH4Q8kcJiWt2JHzR5/LiqPeOc EEnqQe0bQkcdgbE80HJ44yHsb685ffVBPj27mPmNfLOWaZtdQc4wkFCRJg7pGBDf NQqOdZNJlxdjh70W4X3/2xUwdB6tvyF7eOZFSEKg/GPcw7oxn/Gwdt3vS11DRFzW xXevYeVwG0b1TcKiRi0I1xI+06UbbhvH5VN62LZz3sxrwFItR2eVotj5ykV3USEL OBa1g6qhgdYKWtqYVK0DKb7JAJJWXw== =nLDM -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 14 12:04:37 2020 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 14FCE120A03 for ; Tue, 14 Jan 2020 12:04:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 b0DTpUL_Bg0n for ; Tue, 14 Jan 2020 12:04:29 -0800 (PST) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D1D312093D for ; Tue, 14 Jan 2020 12:04:29 -0800 (PST) Received: by mail-io1-xd32.google.com with SMTP id n11so15243842iom.9 for ; Tue, 14 Jan 2020 12:04:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=FDPoHhnBFb3snEaDbBjuHKZHDQF2vsDg7ovKh8toDis=; b=HMq7OcWNxjBwo6FQeuE3NDU9nrUupZBjTMCFomXP6BL//L3phAkPQjuQFQ7jAxkyq9 mGbRZjSGcljCCU7zkOcxJ9eCJlizvVgUXuo/bLVcLD3FhF65ClWlOv4ZeTQNy5KW7Bku XSAxMBQIGm4kUdSFdnxi1QxCAsjIKWeXUI6Kc5+GMnF420k2tpG6OtkizA1TTykCk6ne 9WVyhvx3AU48162B1Ar9sNKsHs8H24l0aZAnMsjvDr1O6irdgFi/xyDHDd1P1ZqqrOXW 91O4lYB7lV4fmP66OLs6Fo4cmJkPqRFp0jcBhyVj73m9dacOn0fck9tIoshIKu/XLChY QrIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FDPoHhnBFb3snEaDbBjuHKZHDQF2vsDg7ovKh8toDis=; b=VdKBrIx7Ss3xXEQlVZTRucaHIM6+aeabztdMn52DPw2YSc81JuMfKtBQpKQgjAFgbl uWKUdGHnQPCxIWik/3Gj7e3GrCb43A/2ju4JWDQ/CqaLn4+5JYu/e4c0QwfDkJwlDvVT bmuToLuOS1hURUpnlWCojEGnVLUWOKIjyqgsbOHYVO2oiuGtHJv8m1r7wBT8YMGm9Kf6 CBV3pGQh85FqquZNcTQUKd+bEB8IZgK1ahmzv+AFn6kE7qEV7OfRuSviVxmyo4IH82bX 1bDP1YnAYqxC1PoNQIwFNRUhxaz0cC7nw0T9flm575/0GbM67PnSyZf1fUjysvHRu/u1 264Q== X-Gm-Message-State: APjAAAXttITpM97KkwdBya2NaimNBoW0EWQ//jbqYAzWTmVIqdZk1e3x Bo/+RU7yo5QjeMaGeWboLd3T3jKvoxtZoLE1i1gR6ZT19kQ= X-Google-Smtp-Source: APXvYqyZtYmuO0Eutno50f4hLuyAGEs88SVcckjvk54lKrQz3cXbal6jdkxYrLRZeG2JORXiPpylO+jdFhNC+eri1P8= X-Received: by 2002:a5d:8cce:: with SMTP id k14mr19351918iot.294.1579032268077; Tue, 14 Jan 2020 12:04:28 -0800 (PST) MIME-Version: 1.0 From: "M. Ranganathan" Date: Tue, 14 Jan 2020 15:03:52 -0500 Message-ID: To: mud@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [Mud] MUD server discovery? 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: Tue, 14 Jan 2020 20:04:36 -0000 There are a couple of situations I can think of where a trusted agent may need to communicate with a MUD server: 1. Controller Application: A Controller application may need to "tell" the MUD server when it joins the network and that it is a controller for a device. Perhaps it presents a signed certificate to assert its identity to the MUD server. 2. Onboarding using a third party app (e.g. DPP). The onboarding application may need to communicate the identity (Device certificate) to the MUD server. Is there a use case for the MUD server address to be published so it can be discovered by such applications? If yes, then should there be a REST API for such use cases? Are there better ways of doing this? Thanks Ranga -- M. Ranganathan From nobody Tue Jan 14 13:53:28 2020 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 0DB6F120113 for ; Tue, 14 Jan 2020 13:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 hHEGQOUPT31L for ; Tue, 14 Jan 2020 13:53:25 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7DC5F120059 for ; Tue, 14 Jan 2020 13:53:25 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 8335B3897B; Tue, 14 Jan 2020 16:52:19 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 91EC2108F; Tue, 14 Jan 2020 16:52:45 -0500 (EST) From: Michael Richardson To: "M. Ranganathan" cc: mud@ietf.org In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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] MUD server discovery? 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: Tue, 14 Jan 2020 21:53:27 -0000 --=-=-= Content-Type: text/plain M. Ranganathan wrote: > There are a couple of situations I can think of where a trusted agent > may need to communicate with a MUD server: > 1. Controller Application: A Controller application may need to "tell" > the MUD server when it joins the network and that it is a controller > for a device. Perhaps it presents a signed certificate to assert its > identity to the MUD server. > 2. Onboarding using a third party app (e.g. DPP). The onboarding > application may need to communicate the identity (Device certificate) > to the MUD server. My opinion is that the this should be an extension in the CAPPORT API. MUD controllers need the CAPPORT API to indicate if they have quarantined a device. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4eOC0ACgkQgItw+93Q 3WUnuggAweZKMLqH5vKydqLXztblB/utng9l5SkP26CA1dawvYTaO4k6qmIL4FFl g/49RRcA0PJkVY4hmfdKkZF6eitB1kTNft49+B1/qnDTEP5ZLXjKsuz4ZrGEM4S/ XyivBlmAAxE1JrnmNi47BwEvSQGLGZM1Oysklk9qbLzLIRd8CtePsaxKIsVKqDz0 a2Y84fmqz5UwdlNH07hsXqFbIz5GYQcepeUijTDWfSaaGwiHl3vwEuTnWOH5Rijc Z7WwKx+W6d0Ep6aXp4sFl20WhIr5Z5R3t1OrynhSx3G21UkY0Y5XvS6jDGSzMWyE zYmT4OceLr9zfIqMiZR49wbhpQwfzg== =//44 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 15 08:33:04 2020 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 E852112004A for ; Wed, 15 Jan 2020 08:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 kkP4pZYk-XPD for ; Wed, 15 Jan 2020 08:32:12 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70F8A12085B for ; Wed, 15 Jan 2020 08:32:12 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id b10so18397531iof.11 for ; Wed, 15 Jan 2020 08:32:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=3m0CgN6YfaEaLay1LVdXpRh1PrwjenO1UnSGEJeG/pM=; b=AFxiVjVWyTy6ZhAWohNOiIxVlQivu9FCPby1FiQXhKr0axNQXIL8KcXyleq/w9YYpd 4ivl0eeld3fOw6/7Wxn0yRlglYuXjNdc/949FRrab53OBzZcg9pq6JL025fai8/1NSlf wbhMSAGrEIlbGAUNVBXY8mymLMRYhlcM7UTNZUBJKcyDdEvmNMR52u8qZijlegaYHern cKWWbRuGahMUTL2/ftslwXsUXUoDzHTBzzdAuOffphJom6TZdS2l/klPg+1YdIvG4hTJ Qal8fi5zVEn/W4uysdZEcOlG+Fe8RNuyCefL3AmnLd7FlcoiRw9HShxKnMsw3qabnIiq WG9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=3m0CgN6YfaEaLay1LVdXpRh1PrwjenO1UnSGEJeG/pM=; b=ZxAzGdLUB2zoxoI+uECftVnhBYTfK1lHOom4hgLCv8vHYI3+EFW1J5TBX7xBsT82Wc FHO2jlqcOkHNus4ShWsLB/EWy9FIBMq8hel1kW25Kp8ud+UqBwjhsqiCgZaxg3661dUL QlJ+vaQ+W9KStoe/3IyxOdSbj7RN0qeTOEl/SO65xNI86jdTqeQdxbxHjYdwajUBGMwF 5NZUv4esKzjp7l/m4LhfdYZqFPobYeVmYqQw7kC79eIbF9nKO/OXD0DPn1CfWgyILkJI H8NIpFEsioOkrxMu0FeZjK0Il56lpQo73HstELQ+yGLTf+VVC1HZgQl2kYPlbX/02xnp Hfpw== X-Gm-Message-State: APjAAAX/ABjt3vLBPBlTawoZIpwTCHqROS+U71Ii1bVP4uP7q8Ee3zOP KG2Igq7l7b+LxlLKDuqA80PeMZxzHXKXT7abnuwwcUTRwKI= X-Google-Smtp-Source: APXvYqxD6WSl2ojZ8jIRPrBRSx3b793I6qIS4LOyUMFQdeY2DhyBt/Fg0VC9kcjW+170dhpak7uvRel5sGm4LQsjOQA= X-Received: by 2002:a5e:924c:: with SMTP id z12mr22678087iop.296.1579105931481; Wed, 15 Jan 2020 08:32:11 -0800 (PST) MIME-Version: 1.0 References: <24846.1579038765@localhost> In-Reply-To: <24846.1579038765@localhost> From: "M. Ranganathan" Date: Wed, 15 Jan 2020 11:31:35 -0500 Message-ID: To: Michael Richardson Cc: mud@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Mud] MUD server discovery? 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: Wed, 15 Jan 2020 16:32:18 -0000 On Tue, Jan 14, 2020 at 4:52 PM Michael Richardson wrote: > > > M. Ranganathan wrote: > > There are a couple of situations I can think of where a trusted agent > > may need to communicate with a MUD server: > > > 1. Controller Application: A Controller application may need to "tell" > > the MUD server when it joins the network and that it is a controller > > for a device. Perhaps it presents a signed certificate to assert its > > identity to the MUD server. Not sure how this fits into the Captive portal model. What we need is some way to assert the app identity to the MUD server so it can be trusted to be a device controller. If the APP is trusted and bundled with a private key and certificate then it should be relatively simple using TLS handshake. > > > 2. Onboarding using a third party app (e.g. DPP). The onboarding > > application may need to communicate the identity (Device certificate) > > to the MUD server. > > My opinion is that the this should be an extension in the CAPPORT API. > MUD controllers need the CAPPORT API to indicate if they have quarantined a > device. > The trusted onboarding application is assumed to have a connection to the MUD server via the CAPPORT API (how?). The onboarding app sends the device certificate to the MUD server via the CAPPORT API extension. The device sends a signed MUD URL in the DHCP request (until which time it is effectively quarantined from the local network). The MUD server receives the signed MUD URL (sent via DHCP) and verifies the signature using the device certificate that was previously sent to it by the onboarding application. How will unconstrained devices (e.g. a laptop) on the network fit into this model? > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > -- M. Ranganathan From nobody Wed Jan 15 09:08:36 2020 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 086881208A0 for ; Wed, 15 Jan 2020 09:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 BgN-VQrzjNpB for ; Wed, 15 Jan 2020 09:07:50 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A602120886 for ; Wed, 15 Jan 2020 09:07:50 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id n21so18546148ioo.10 for ; Wed, 15 Jan 2020 09:07:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vXtnHe6O5KZ75Ii3BSaZx660zUR2Rseg7bkj5sE8YMc=; b=YBZ1aEYDPzNViTs6KPLD1+Ne/bGfGRzTDszP8m+5rPBQ7kp4XKSBYZ30TuPVoXiTam csYIYfNH/kyxEAIjt/uz+iqX02ihnt6v71GY+qe2p9+DNysQ4jUVoIzzmNcULikSkxh3 idArEnbCOyfT1Xe9BOqOpF+V/YIKjtbyE47z8Mulq/z62q13mXLq2K0E1atNBuXy22rk S2LIPlIcOJhGdygDtnVUdjYh56TALunSLROkmBifRsTDoyyk/8+A2f7Fc/UKFk3ddh9O jYzvnSjWct8ibhC0h6RCEPGd0sHY4uMEuBZt5xXlAoXGbe5LhyNaNCuh+4u5dBl6QBuT /iDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vXtnHe6O5KZ75Ii3BSaZx660zUR2Rseg7bkj5sE8YMc=; b=BolWe1J9hR20SVZqEybbRUUxF76z8feBoROOuUSsbYDLerTUG+8IX3UjdFjC3O/u0z Tmnx8TBB+hChCBOkufI3NM7rHhU/RhslUyTqr9emgnUxD4CH/Gj7JadM8a6D653q9gXF vc+aPRoaVULxJuGip2VLBNrqpBeBYEGj2hInGXzQLIwZNKo44Va+Zw2FUX8zo+zaKAOc XuFWL3QxUsSPLA/PZp8p/Bk1HXNKX/adK0CFV7GMQ5htJfJaquM10488Qc7ncTg+MzOX A1KswiF2D8UQh3LGrAHOJKDy7w+P/lOaSpIYJmmTRoN2a95gniUncHSL4AnUT+SnIdPL bEiQ== X-Gm-Message-State: APjAAAXzC7UA9FQ6hFv3cgRygPf7vdCMNxK7kSmEvaMf6PGtuU3iDr5N 9srmNB6EfEdF6LwvW3zcDYydloNQvIP95PJ0zYBcK6KUaoM= X-Google-Smtp-Source: APXvYqxp5KmNsouAVTxf+updEVS7lImxPAL+g5KUosjzKDiv5faWxhqnk2p7TlmdGbkJ8m/LhHPPk8SSCTKmX8o8ExA= X-Received: by 2002:a05:6638:301:: with SMTP id w1mr25470758jap.63.1579108069288; Wed, 15 Jan 2020 09:07:49 -0800 (PST) MIME-Version: 1.0 References: <24846.1579038765@localhost> In-Reply-To: From: "M. Ranganathan" Date: Wed, 15 Jan 2020 12:07:13 -0500 Message-ID: To: Michael Richardson Cc: mud@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Mud] MUD server discovery? 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: Wed, 15 Jan 2020 17:07:56 -0000 On Wed, Jan 15, 2020 at 11:31 AM M. Ranganathan wrote: > > On Tue, Jan 14, 2020 at 4:52 PM Michael Richardson wrote: > > > > > > M. Ranganathan wrote: > > > There are a couple of situations I can think of where a trusted agent > > > may need to communicate with a MUD server: > > > > > 1. Controller Application: A Controller application may need to "tell" > > > the MUD server when it joins the network and that it is a controller > > > for a device. Perhaps it presents a signed certificate to assert its > > > identity to the MUD server. > > Not sure how this fits into the Captive portal model. What we need is > some way to assert the app identity to the MUD server so it can be > trusted to be a device controller. If the APP is trusted and bundled > with a private key and certificate then it should be relatively simple > using TLS handshake. > > > > > > 2. Onboarding using a third party app (e.g. DPP). The onboarding > > > application may need to communicate the identity (Device certificate) > > > to the MUD server. > > > > My opinion is that the this should be an extension in the CAPPORT API. > > MUD controllers need the CAPPORT API to indicate if they have quarantined a > > device. > > > > > The trusted onboarding application is assumed to have a connection to > the MUD server via the CAPPORT API (how?). The onboarding app sends > the device certificate to the MUD server via the CAPPORT API > extension. The device sends a signed MUD URL in the DHCP request > (until which time it is effectively quarantined from the local > network). The MUD server receives the signed MUD URL (sent via DHCP) > and verifies the signature using the device certificate that was > previously sent to it by the onboarding application. > > How will unconstrained devices (e.g. a laptop) on the network fit into > this model? On second thoughts, indeed the onboarding application could send the MUD URL of the device to the MUD server. It would be part of the device certificate. DHCP based mechanism would be redundant. One could use RFC 7710 to transmit the captive portal URL. So yes this scheme makes sense. > > > > -- > > ] Never tell me the odds! | ipv6 mesh networks [ > > ] Michael Richardson, Sandelman Software Works | IoT architect [ > > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ > > > > > > > -- > M. Ranganathan -- M. Ranganathan From nobody Thu Jan 16 05:43:44 2020 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 1E0EB12022A for ; Thu, 16 Jan 2020 05:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 FrbX1rHl6zsp for ; Thu, 16 Jan 2020 05:43:34 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4037F12081E for ; Thu, 16 Jan 2020 05:43:34 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id n21so21752300ioo.10 for ; Thu, 16 Jan 2020 05:43:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=BN8/RYYxX/pSyXyEy9Lb+LEQb9pZwhYO4UaoR9iCRgc=; b=KBqCNrezjjr4WOVhVBFj7HJi2X/jB/4hTIzJTVdebIuuaZ6eZfT7jG9EB7dDS6yPwX jsAwoPJEm04WawgryDunfZlBtwmPlb1gqeqFy6Z8u/fYVAlHmsF/ZbNRSXJ46Pk39c8j LYYUBNFXBcrs/TiRII93DsPgAiE/zMEITfB5LKdLNUgZp5FEaq5wI4pVIdvW7D5hNE2B 9IxcHxAtxBDJGA4FZoABaXA6vDGxegr6uAjNZ7wCjNGA52jA2ehPHO7M1HJTUay6I3dV rch/scPof+oCTCZlUd+6IqyAgDoQKrrMgFlK61kOltJD2iRQ19QTZJbI+oVHCUNLo5T6 Qh3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=BN8/RYYxX/pSyXyEy9Lb+LEQb9pZwhYO4UaoR9iCRgc=; b=eqQJb22UfEBVVuXZb0k09btzhTFV00M3Sa36cjFtsf6OCB5zpyYfcuALHaTJDgLs94 q1ZQT1mZPmTh0F8kv88icYNydctdFDqQBl8QRX/kuwrlB2xpD5XlHx9r90Ol8xjDSNcF c4LvjeqQwXzEPaPkDcQCqVIi22tWE+2pk91ShRk+fwfUeMw/OQ13E8AJG5/GIYSUgDdt hVwhqVca7rLpkxr4HBt08HW6MT0SFLycQ0CKjMR2e3Nnga+LF2glDVzjVTpqgubaCbgs 9awwbTF6uL0oj0LJO8tHvtA9W/cMO3fqYPRwEEue1Eo9dJQF1KPcnZQ0mlQDZHeHARTW dyBg== X-Gm-Message-State: APjAAAVNwPh+doMHxFbDqwVgXvClNOLM7OMqoo5zbGRKr2UOnOM/EUUU A4lDuyviShiRpmPrmqYKlNR8LWdv8ttVZBONMnG30dte X-Google-Smtp-Source: APXvYqx0UCZtUdXh3qY6XEeUYVdHgyPMcVWh2UyJRhI8N6esMbAzZa6ehxJk9BHnkwq4NtNkQKd+GWo5zIKeM0lExi0= X-Received: by 2002:a02:3948:: with SMTP id w8mr27623620jae.124.1579182213332; Thu, 16 Jan 2020 05:43:33 -0800 (PST) MIME-Version: 1.0 References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> In-Reply-To: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> From: tirumal reddy Date: Thu, 16 Jan 2020 19:13:20 +0530 Message-ID: To: mud@ietf.org Content-Type: multipart/alternative; boundary="000000000000dc857a059c42024a" Archived-At: Subject: [Mud] Fwd: New Version Notification for draft-reddy-opsawg-mud-tls-02.txt 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, 16 Jan 2020 13:43:42 -0000 --000000000000dc857a059c42024a Content-Type: text/plain; charset="UTF-8" Hi all, This revision https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-02 updates the draft to discuss privacy enhancing technologies and evasion techniques used by malware, visibility into TLS 1.3 parameters and how certain types of malware can be blocked without acting as a (D)TLS 1.3 proxy. As a reminder, this draft extends Manufacturer Usage Description (MUD) to incorporate (D)TLS profile parameters. This allows a network element to identify unexpected (D)TLS usage, which can indicate the presence of unauthorized software or malware on an IoT device. Comments and suggestions are more than welcome. Cheers, -Tiru On Thu, 16 Jan 2020 at 18:58, tirumal reddy wrote: > ---------- Forwarded message --------- From: Date: Thu, 16 Jan 2020 at 18:44 Subject: New Version Notification for draft-reddy-opsawg-mud-tls-02.txt To: Tirumaleswar Reddy.K , Dan Wing , Blake Anderson A new version of I-D, draft-reddy-opsawg-mud-tls-02.txt has been successfully submitted by Tirumaleswar Reddy and posted to the IETF repository. Name: draft-reddy-opsawg-mud-tls Revision: 02 Title: MUD (D)TLS profiles for IoT devices Document date: 2020-01-16 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/internet-drafts/draft-reddy-opsawg-mud-tls-02.txt Status: https://datatracker.ietf.org/doc/draft-reddy-opsawg-mud-tls/ Htmlized: https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-02 Htmlized: https://datatracker.ietf.org/doc/html/draft-reddy-opsawg-mud-tls Diff: https://www.ietf.org/rfcdiff?url2=draft-reddy-opsawg-mud-tls-02 Abstract: This memo extends Manufacturer Usage Description (MUD) to incorporate (D)TLS profile parameters. This allows a network element to identify unexpected (D)TLS usage, which can indicate the presence of unauthorized software or malware on an endpoint. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --000000000000dc857a059c42024a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,


This revision https://tools.ietf.org/html/draft-reddy-opsawg-mud-tls-02 = updates the draft to discuss privacy enhancing technologies and evasion techniques used by malwa= re, visibility into TLS 1.3 parameters and how certain types of malware can be blocked without acting as a (D)TLS 1.3 proxy.

=C2=A0

As a reminder, this draft extends Manufacturer = Usage Description (MUD) to incorporate (D)TLS profile parameters.=C2=A0 This allo= ws a network element to identify unexpected (D)TLS usage, which can indicate the presence of unauthorized software or malware on an IoT device.

=C2=A0

Comments and suggestions are more than welcome.=

=C2=A0

Cheers,

-Tiru


<= div dir=3D"ltr" class=3D"gmail_attr">On Thu, 16 Jan 2020 at 18:58, tirumal = reddy <kondtir@gm= ail.com> wrote:

---------- Forwarded messa= ge ---------
From: <internet-drafts@ietf.org>
Date: Thu, 16 Jan = 2020 at 18:44
Subject: New Version Notification for draft-reddy-opsawg-m= ud-tls-02.txt
To: Tirumaleswar Reddy.K <kondtir@gmail.com>, Dan Wing <danwing@gmail.com>, Blake Anderson <blake.anderson@cisco.com>


=
A new version of I-D, draft-reddy-opsawg-mud-tls-02.txt
has been successfully submitted by Tirumaleswar Reddy and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-reddy-opsawg-mud-tls Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A002
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MUD (D)TLS profiles for IoT device= s
Document date:=C2=A0 2020-01-16
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 19
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-reddy-opsawg-mud= -tls-02.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-reddy-opsawg-mud-tls/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /tools.ietf.org/html/draft-reddy-opsawg-mud-tls-02
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0= https://datatracker.ietf.org/doc/html/draft-reddy-opsawg-mud-tls
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-reddy-opsawg-mud-tls-= 02

Abstract:
=C2=A0 =C2=A0This memo extends Manufacturer Usage Description (MUD) to inco= rporate
=C2=A0 =C2=A0(D)TLS profile parameters.=C2=A0 This allows a network element= to identify
=C2=A0 =C2=A0unexpected (D)TLS usage, which can indicate the presence of =C2=A0 =C2=A0unauthorized software or malware on an endpoint.




Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

--000000000000dc857a059c42024a-- From nobody Tue Jan 21 17:03:11 2020 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 B51121200C4; Tue, 21 Jan 2020 17:03:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 hVbN9GjL6Mii; Tue, 21 Jan 2020 17:03:07 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD9301200C3; Tue, 21 Jan 2020 17:03:07 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id C70E13897E; Tue, 21 Jan 2020 20:02:33 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A1FF9E99; Tue, 21 Jan 2020 20:03:05 -0500 (EST) From: Michael Richardson to: opsawg@ietf.org, mud@ietf.org In-Reply-To: <20570.1579314460@localhost> References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> <20570.1579314460@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.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: [Mud] how to increase trust in MUD URL 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: Wed, 22 Jan 2020 01:03:10 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable draft-reddy-opsawg-mud-tls-02 proposes to describe TLS profile options in a MUD file in order to help middle boxes (Intrusion Detection Systems) to identify malware. I wrote an email about issues related to the idea, but this email is about the way in which MUD files become trusted, and how they should be updated. Michael Richardson wrote: > I see two advantages of this work, which mitigates my concern slightl= y. > (but, only slightly) > 1) if it's gonna get done by IDS vendors, then IoT device manufacture= rs > might as well provide a way to help them *get it right* A tussle that I thought I put into a document, but it seems that I did not yet do that, is whether to update the MUD URL to a firmware specific value, or whether to update the MUD file place. I thought I was going to cover that in draft-richardson-opsawg-securehomega= teway-mud-02 and I said so in the introduction, and I thought I decided that was a poor place to put that discussion, and I wrote some text in some document, but it seems that was a delusion :-) I guess I wrote this in email to mud@ actually. The issue is that if you update the MUD file in place without changing the URL then it will apply to older firmware revisions as well as new ones. If a vendor is going to put very specific information relating to TLS libraries into a MUD file, then it is going to be critical that any updates to the firmware (such as BUG FIXES) result in updates to the MUD TLS profil= e. Updating the URL that the firmware emits via DHCP or LLDP is relatively eas= y, but not very secure. An IDS system should *not* trust updates to that URL as malware could trivially update the URL as well. But, updating the URL in IDevID is difficult to do. Quite reasonably it mig= ht be impossible without a device recall. The IDevID version is much easier to invest trust into. And it clearly links back to the manufacturer. If relatively ephemeral things like a TLS profile are going to go into a MUD file, then I think that we need to think again about the update issue. [this draft sits in outbox for a week] I've now written: https://datatracker.ietf.org/doc/draft-richardson-opsawg-mud-acceptable-u= rls/ =2D-=20 ] 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 = [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4nn0kACgkQgItw+93Q 3WXpPAf+PVgj/w6jKAZ1DnBL2g7FyPneS6VwqY5mgJ7BX/z3n94r8XdEceIW+JHU C3qGYK2C7mV152d+xFqyVPv+CgmPgfoZMOr2hlWb19lz5EdUtlmZnPIiLMu2eJ/E L7LavmxXhgc2lEc+1zQPqWMqlhncT9qrBg20RU2ATSfywiECqyedEKAdqj0ZLWbW oKyNlcR6U1KmoZsSlxIvfi7yPW+0CDQXrivpCqA4Vtc3CE1eYqjHpm9VyffwAYG7 akLy2/sCzh4RctgQwiI1CWhpQgPHjB8Jne4R2ly5BLln6J/s8bmuXWv7PrU6kQ1N hoMYZNSsAzOUemIfKPdA2plmv4WxfA== =vuBV -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 21 17:44:40 2020 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 CCFF71200C3 for ; Tue, 21 Jan 2020 17:44:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 BetXG-Sd773w for ; Tue, 21 Jan 2020 17:44:37 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8FF3120013 for ; Tue, 21 Jan 2020 17:44:36 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B09923897E for ; Tue, 21 Jan 2020 20:44:03 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A1C07E99 for ; Tue, 21 Jan 2020 20:44:35 -0500 (EST) From: Michael Richardson To: mud@ietf.org X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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: [Mud] [Dumpsterfire] telnet (fwd) lefty via Dumpsterfire: [Dumpsterfire] telnet 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: Wed, 22 Jan 2020 01:44:39 -0000 Return-Path: Received: from tuna.sandelman.ca [2607:f0b0:f:3::184] by localhost with IMAP (fetchmail-6.3.26) for (single-drop); Tue, 21 Jan 2020 15:24:44 -0500 (EST) Received: from tuna.sandelman.ca ([unix socket]) by tuna (Cyrus git2.4.17+0-Debian-2.4.17+nocaldav-0+deb8u2) with LMTPA; Tue, 21 Jan 2020 11:41:43 -0500 X-Sieve: CMU Sieve 2.4 Received: from delivery.mtaroutes.com (delivery.mtaroutes.com [185.201.17.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tuna.sandelman.ca (Postfix) with ESMTPS id 7781A3897C for ; Tue, 21 Jan 2020 11:41:43 -0500 (EST) X-DKIM-Failure: signature_incorrect Received: from ukiah.firemountain.net ([207.114.3.55]) by mx47.antispamcloud.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1itwbP-0005Ni-4Y for mcr@sandelman.ca; Tue, 21 Jan 2020 17:42:12 +0100 Received: from ukiah.firemountain.net (localhost [127.0.0.1]) by ukiah.firemountain.net (8.14.9/8.14.9) with ESMTP id 00LGek7O016764; Tue, 21 Jan 2020 11:40:46 -0500 (EST) Received: from taos.firemountain.net (taos.firemountain.net [207.114.3.54]) by ukiah.firemountain.net (8.14.9/8.14.9) with ESMTP id 00LGef4i029571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 21 Jan 2020 11:40:42 -0500 (EST) Received: from mail-qt1-f176.google.com (mail-qt1-f176.google.com [209.85.160.176]) by taos.firemountain.net (8.15.1/8.14.9) with ESMTPS id 00LGeZFM005736 (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128 verify=FAIL) for ; Tue, 21 Jan 2020 11:40:46 -0500 (EST) Received: by mail-qt1-f176.google.com with SMTP id d5so3150332qto.0 for ; Tue, 21 Jan 2020 08:40:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=AzO91lu9zUMTyqlTy9UGAksgc0jA7lTmbaMCNWXECKE=; b=eMWJMAfDXC4R1hH9iXX5OIK7w698xyTjfcLwoAOW01WpOp827X0p4AIBXUK+94JIyo OZGm0zukodJ+QQc0GCNWWmh4prg8mjy5aMIJ3TrUAzJWp/mkeyT5ThPqNwSsheaBrY6L A+h0I2IhmbU17n/amGZhw7ZohvaR4fe7Ntd+eg/Y08N9ULKcRzqC6PEdeMmkQQpFE4T4 +Gi4WkLamvHbpq7CpfR1KK5XrDyTDZk9KUA+X9knps+xKYFuaPk5Ajmk2Nn09qorggmh ikx6BjbZQmcQ04qdsYyqIZOugxHF5VCj7ibD/+lOuWpkJGfWufro/N+2VPGQf7zZBV0E 35zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=AzO91lu9zUMTyqlTy9UGAksgc0jA7lTmbaMCNWXECKE=; b=myOfZ/LOQtkZRUQ8wOe/q7AtGtzLiuvzwlRq0Bby1Yroubk+oMFg+g3VvPzimShzME aOUZkgR/B4r9f3diQCvMcnTg9nKTj14Uj1XXno4sykmoET/3/qIYzPJwRLSJRJ2SC/FV UXyM9sXgfkuyeA78vyzrEbino2TOEkBIA97e3ofAqRtkZK+//C7IvP9IHWohR3TYeIN+ ku7DYXwFHr7JKyXrMCjoOSIaTG1QysSrRotX3n3kWGg2Iivw65uWmnJJHQPSzk5m8fZh vLeiEPBG8cYlrQL3waOZ24vCgjvHHurYcVGfTesI1bLfAmNEN/LXUQDvEXUqFccuVLpg WT9A== X-Gm-Message-State: APjAAAWId7TJmldNqK/z5OemD7l0kZoq+ogV20MUhb9/SNKqOvgRK4aB Fj3VD+dg/hD5jgUCE3pLRUtFTQpI X-Google-Smtp-Source: APXvYqxU4rGPRdJv8xCPwH7zrJ6Cd1zgIGzb+QbZ22uSiKr0ib+moQLNxQrasAuYaUJcZ7J9OE/EsQ== X-Received: by 2002:ac8:4257:: with SMTP id r23mr5353978qtm.126.1579624824539; Tue, 21 Jan 2020 08:40:24 -0800 (PST) Received: from [192.168.1.236] (c-68-81-208-60.hsd1.pa.comcast.net. [68.81.208.60]) by smtp.googlemail.com with ESMTPSA id g21sm17439124qkl.116.2020.01.21.08.40.23 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 21 Jan 2020 08:40:23 -0800 (PST) To: dumpsterfire@firemountain.net Message-ID: <135796ee-6595-b1be-243f-4228c685bf20@gmail.com> Date: Tue, 21 Jan 2020 11:40:22 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 Content-Language: en-US Subject: [Dumpsterfire] telnet X-BeenThere: dumpsterfire@firemountain.net X-Mailman-Version: 2.1.29 Precedence: list List-Id: Dumpsterfire - the mailing list for IoT security and privacy failures List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: lefty via Dumpsterfire Reply-To: lefty Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: dumpsterfire-bounces@firemountain.net Sender: "Dumpsterfire" Received-SPF: pass (mx47.antispamcloud.com: domain of firemountain.net designates 207.114.3.55 as permitted sender) client-ip=207.114.3.55; envelope-from=dumpsterfire-bounces@firemountain.net; helo=ukiah.firemountain.net; X-SPF-Result: mx47.antispamcloud.com: domain of firemountain.net designates 207.114.3.55 as permitted sender Authentication-Results: mx47.antispamcloud.com; dmarc=pass header.from=firemountain.net Authentication-Results: antispamcloud.com; spf=pass smtp.mailfrom=dumpsterfire-bounces@firemountain.net; dkim=fail (signature_incorrect) header.i=gmail.com X-Filter-Label: newsletter X-MailAssure-Class: ham X-MailAssure-Evidence: Combined (0.00) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Xm17NJf4el5vffImWwWrhCpSDasLI4SayDByyq9LIhVgMu2a8D7qgB7 B9U4GDgqtkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDR6k3ZaTOixxpyXIRqqgntMfT L5Vk7ZSjJErBan4vOMzWQRIXBgIQouPK6MKDFmLq49GmogNFq1JMiIbb9waeVyYcRR/5VyJsip7X LWF9fUaef9wGDM5LDH/uffkxxEwXZnvBUmYAD0T/UDk7jlMguK6smANquCQb08BMF1ayWZd8HYiQ werCikpdDoQ79eRe4xtx8X6g2fqY88vRFjo/T4JgKqW8gub69l+DnsJgVmid90ArxoqrpRyIYE+9 NXr5NOrb0lF/P2SeAS7yGgBJLlI1FgIZkSGL9esOjm3jsmQ/+ndkjgQT3Tr5P9eHCeWFhMJ8sp46 CdzmGgq7NTUlHxnyh5UIg/OAyRsA+PeSM3HUG218mAsMhCybw2uuG0D8fPtnX77FkO9dFKmg3yDY 9YxJ4/tP7LpAV9e4/IZ+noh0nriuedFx+PXd4OnYu4BlehIqUczFWeS6sE8e1b5/UoWX1tvr272h z+zoHarCTxZFXYii8rs+f8KpwKAO5iwimz3NJmJzTE1T6wyg1SHXC5HmpsOjOFz4k3wMNTYMXlag Gl1aPxAtivmw3hSDPS17rSkMUjv4CFNmP7zQQNgy6I0AOHAuMgaMkRL4ioiXWfsrBGniPBhM7TNy 99XV1rf5lpMV7NNMSm7dWOrJ5dyfVS8QeiPLIqS2h+VkQHnMR6ln6D4AZKj5lVar/Z5mz/LyEon7 xu0hgMXuAWz1FiKtOQkyCUctcfKsRSG94Q+C0Q4CQyjD30PEK5ROhdLDyBZLfqb5R4VemuUI6bcE ARsm0NxqEOPQOJoeUrlPzxd3rKtafqUtWly0E+LhAqXOW3tHXuPifZp7rqHq2NDb9vrEPvAFMvX7 q8M4x6bP/gjzw0OrPM2L4EAGpWL0lg0ttbr6 X-Report-Abuse-To: spam@quarantine10.antispamcloud.com More than 500k telnet credentials for IoT devices leaked https://threatpost.com/hacker-leaks-more-than-500k-telnet-credentials-for-iot-devices/152015/ Meh - a small gesture ********************************************************************** The Dumpsterfire mailing list is hosted by firemountain.net. To unsubscribe or change delivery options: http://www.firemountain.net/mailman/listinfo/dumpsterfire From nobody Tue Jan 21 23:32:11 2020 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 A89B0120052 for ; Tue, 21 Jan 2020 23:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 KNFDMW7kzkCY for ; Tue, 21 Jan 2020 23:32:08 -0800 (PST) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 D2201120013 for ; Tue, 21 Jan 2020 23:32:06 -0800 (PST) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 00M7W4Vj003406 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT) for ; Wed, 22 Jan 2020 08:32:05 +0100 Received: from [192.168.16.50] (79.234.120.240) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 22 Jan 2020 08:31:59 +0100 To: References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> <20570.1579314460@localhost> <30267.1579654985@localhost> From: Henk Birkholz Message-ID: <9b50e4ca-d516-3f3b-5992-1695f8147d18@sit.fraunhofer.de> Date: Wed, 22 Jan 2020 08:31:58 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <30267.1579654985@localhost> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.234.120.240] Archived-At: Subject: Re: [Mud] how to increase trust in MUD URL 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: Wed, 22 Jan 2020 07:32:10 -0000 Hi mud'ler, On 22.01.20 02:03, Michael Richardson wrote: > But, updating the URL in IDevID is difficult to do. Quite reasonably it might > be impossible without a device recall. The IDevID version is much easier to > invest trust into. And it clearly links back to the manufacturer. This is one of the biggest issues that came to my mind ad-hoc. Is changing the URI really an option? I would assume this type of encapsulation is trustworthy, I think. On 22.01.20 02:03, Michael Richardson wrote: > If a vendor is going to put very specific information relating to TLS > libraries into a MUD file, then it is going to be critical that any updates > to the firmware (such as BUG FIXES) result in updates to the MUD TLS profile. Hm. I always assumed that either a MUD file or the parameters to a MUD URI would take care of "versions" or "composition" of the requester (so the requester appends information about that in the URI). Is that not how other people think about it? The idea of a canonical composition of the segments in the URI did not fly IIRC (due to rfc7320 I assume). Viele Grüße, Henk From nobody Wed Jan 22 09:21:36 2020 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 2028E12021C for ; Wed, 22 Jan 2020 09:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 22qGNdnE-cki for ; Wed, 22 Jan 2020 09:21:30 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17368120108 for ; Wed, 22 Jan 2020 09:21:29 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2D6403897E; Wed, 22 Jan 2020 12:20:56 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 96210C69; Wed, 22 Jan 2020 12:21:27 -0500 (EST) From: Michael Richardson To: Henk Birkholz cc: mud@ietf.org In-Reply-To: <9b50e4ca-d516-3f3b-5992-1695f8147d18@sit.fraunhofer.de> References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> <20570.1579314460@localhost> <30267.1579654985@localhost> <9b50e4ca-d516-3f3b-5992-1695f8147d18@sit.fraunhofer.de> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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] how to increase trust in MUD URL 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: Wed, 22 Jan 2020 17:21:33 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Henk Birkholz wrote: > On 22.01.20 02:03, Michael Richardson wrote: >> But, updating the URL in IDevID is difficult to do. Quite reasonably= it might >> be impossible without a device recall. The IDevID version is much e= asier to >> invest trust into. And it clearly links back to the manufacturer. > This is one of the biggest issues that came to my mind ad-hoc. Is cha= nging > the URI really an option? I would assume this type of encapsulation is > trustworthy, I think. Changing the URI in an IDevID is not, in my opinion, feasible. While I can imagine ways for an IDevID to be renewed online, I would prefer that it be buried so deep into the TPM that it can't be changed in the fiel= d. > On 22.01.20 02:03, Michael Richardson wrote: >> If a vendor is going to put very specific information relating to TLS >> libraries into a MUD file, then it is going to be critical that any = updates >> to the firmware (such as BUG FIXES) result in updates to the MUD TLS= profile. > Hm. I always assumed that either a MUD file or the parameters to a MU= D URI > would take care of "versions" or "composition" of the requester (so t= he > requester appends information about that in the URI). Is that not how= other > people think about it? The idea of a canonical composition of the seg= ments in > the URI did not fly IIRC (due to rfc7320 I assume). Yes, so I assume that the MUD URL will depend upon the firmware version. In draft-richardson-opsawg-mud-acceptable-urls-00 I am proposing something like: IDevID MUD URL https://www.example.com/mud/frobits/modelT/base.json DHCP MUD URL https://www.example.com/mud/frobits/modelT/build1176.json The base.json -> build1176.json transition is either *implicit*, only the last part can change. Or we introduce a mud-base-url attribute to the base.json file. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4ohJcACgkQgItw+93Q 3WXEkAgAoNxbdxJ+Triyh8nb+adE9Lm+IpksiZxwK58ioUcFpMfOsRR6WTAKbuuT Xgsy1PZovWB5NCz3LqDiVu6OWqxbahXBrd1Qlz19PAMCosyGVKQXE5wjLvP0pT8Y AIxRNjKFX+wj5/kZURRrIt5iRx3olP3dkLNqvoEQ7mLzSREkDyDETqNu9OEbp8bJ QIuPnZJ+7ZmRoZy45PCk+ZRM8EtD/b72D3WLAdSizipDP4XtqzqlKTRdXjqXTgVT TKUM2B34z3yhM7MSN4gOvAqGghQu9l8oRihE72FFp/k2i9H8FtUeSsYttJ6c0HGL xJBIDIwrdQhNjkFjDtuJRtU2VuR8Ew== =fahs -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 22 10:26:56 2020 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 C60DB120802 for ; Wed, 22 Jan 2020 10:26:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 mNQKrxpBXyf9 for ; Wed, 22 Jan 2020 10:26:52 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 591E71207FB for ; Wed, 22 Jan 2020 10:26:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6548; q=dns/txt; s=iport; t=1579717612; x=1580927212; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=L2ePiZ+yG01Dfs810R63pkymGh1xoFVPfXtUkBzeRq4=; b=XsikUJrXT2ozxPu+a0iQyjAn3Df042ZxngRIqmf+4K4GCiLM9JU1VnwL CAn33mI1o3TojyLE3QvKD/efXmfP0I7/DL6edbzdoQyZ50r6pTvMuGMTd sHMjmB91m69rMI0ZGJe2e4cfUIZ/alWWUCF6YGLRPlX4bFNY384rYzndr Y=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A6AwDQkihe/xbLJq1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuCKWx1EiqNFYgIJYlgiUyICwIHAQEBCQMBARgBDAoBAYN7RQK?= =?us-ascii?q?CPjgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQECAQEBTCALBQsLDgMDAQIBLiE?= =?us-ascii?q?GChUJCAYICx0EgwUBgkoDDiAPrlyCJ4Q1AQsBBQUPL0CCQg2CEBCBOIFThCy?= =?us-ascii?q?GMYIAgTgMFIJMPoICGT4LAQGCA4MigiwElzKXXESCQ4JLgRyDWIpLhCkbgz+?= =?us-ascii?q?OLIkMl0CCIoxXgy0CBAYFAhWBaSKBWDMaCBsVOyoBgkEJNRIYDYg5gzuEWTu?= =?us-ascii?q?FQEADMI1sAQE?= X-IronPort-AV: E=Sophos;i="5.70,350,1574121600"; d="asc'?scan'208,217";a="22437798" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jan 2020 18:26:50 +0000 Received: from dhcp-10-61-103-205.cisco.com (dhcp-10-61-103-205.cisco.com [10.61.103.205]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 00MIQmxh027764 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Jan 2020 18:26:49 GMT From: Eliot Lear Message-Id: <911BB7CD-4006-4DEE-AA93-724F9C280CD0@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_50650C22-6ACC-4C60-B635-87E283E698B2"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Wed, 22 Jan 2020 19:26:48 +0100 In-Reply-To: <9157.1579657475@localhost> Cc: mud@ietf.org To: Michael Richardson References: <9157.1579657475@localhost> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.103.205, dhcp-10-61-103-205.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Mud] [Dumpsterfire] telnet (fwd) lefty via Dumpsterfire: [Dumpsterfire] telnet 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: Wed, 22 Jan 2020 18:26:55 -0000 --Apple-Mail=_50650C22-6ACC-4C60-B635-87E283E698B2 Content-Type: multipart/alternative; boundary="Apple-Mail=_F2EB8F7E-9C14-4CEA-947D-FC8C8372A7F9" --Apple-Mail=_F2EB8F7E-9C14-4CEA-947D-FC8C8372A7F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The question is this: Was this an example of a service that was left running or is telnet = actually required for the device to be configured? Eliot > On 22 Jan 2020, at 02:44, Michael Richardson wrote: >=20 >=20 > From: lefty via Dumpsterfire > Subject: [Dumpsterfire] telnet > Date: 21 January 2020 at 17:40:22 CET > To: dumpsterfire@firemountain.net > Reply-To: lefty >=20 >=20 > More than 500k telnet credentials for IoT devices leaked > = https://threatpost.com/hacker-leaks-more-than-500k-telnet-credentials-for-= iot-devices/152015/ >=20 > Meh - a small gesture >=20 >=20 > ********************************************************************** > The Dumpsterfire mailing list is hosted by firemountain.net. >=20 > To unsubscribe or change delivery options: > http://www.firemountain.net/mailman/listinfo/dumpsterfire >=20 >=20 >=20 > -- > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud --Apple-Mail=_F2EB8F7E-9C14-4CEA-947D-FC8C8372A7F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
The question is this:

Was this an example of a service that was left = running or is telnet actually required for the device to be = configured?

Eliot

On 22 = Jan 2020, at 02:44, Michael Richardson <mcr@sandelman.ca> = wrote:


From: lefty via Dumpsterfire <dumpsterfire@firemountain.net>
Subject: [Dumpsterfire] telnet
Date: = 21 January 2020 at 17:40:22 = CET
To: = dumpsterfire@firemountain.net
Reply-To: lefty <leftystrat1@gmail.com>


More than 500k telnet credentials for IoT = devices leaked
https://threatpost.com/hacker-leaks-more-than-500k-telnet-crede= ntials-for-iot-devices/152015/

Meh - a = small gesture


***************************************************************= *******
The Dumpsterfire mailing list is hosted by = firemountain.net.

To unsubscribe or change = delivery options:
http://www.firemountain.net/mailman/listinfo/dumpsterfire



--
Mud mailing list
Mud@ietf.org
https://www.ietf.org/mailman/listinfo/mud

= --Apple-Mail=_F2EB8F7E-9C14-4CEA-947D-FC8C8372A7F9-- --Apple-Mail=_50650C22-6ACC-4C60-B635-87E283E698B2 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl4ok+gACgkQh7ZrRtnS ejMKRwgAuzbjhyUwJdj1u9ZLLcZPP+Dk47W2J0gWs8fYCbKd7BIuFjLeLSYSRhWd YaCfpe1o4gdM4a0cSWo7/VXQmYO9zi40Jg+AaPBWwaYWz90FLO1dDnCbpXl72CCe Pcp4V6jbU9JyOflZFQkJHgndRYHAcdkR3CaCEXZrnPIBke1nvFEH2Qqu8tVEPmuY GAHHltKlof7o6tRZn93KwPXkEOMEUK/y8IhyqrFrDtSZ7a/qm6g4oSHPMv2ashMF 5SUTuuBezI61dlmcP3uHnvA/f9ky4jDKCJytZVz9kVfWGU1w0fVPt0vWmdgxHw3q xhoyxcscdKAgIBU2dbgfGRfAAbhQuA== =1dxw -----END PGP SIGNATURE----- --Apple-Mail=_50650C22-6ACC-4C60-B635-87E283E698B2-- From nobody Wed Jan 22 10:32:21 2020 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 9497A120804 for ; Wed, 22 Jan 2020 10:32:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 XHZMmqZU7Pzf for ; Wed, 22 Jan 2020 10:32:16 -0800 (PST) Received: from mail-io1-xd41.google.com (mail-io1-xd41.google.com [IPv6:2607:f8b0:4864:20::d41]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A857120802 for ; Wed, 22 Jan 2020 10:32:16 -0800 (PST) Received: by mail-io1-xd41.google.com with SMTP id z193so303085iof.1 for ; Wed, 22 Jan 2020 10:32:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jUC7Y2gPsAPBf8ynJD7jkRZN+eaF2xdcofkaGlFh1D8=; b=S+ZUXUZ3YGjrQC+rSwExYHfmdmJNTr6wxIZLXEo3pDVM9LtFs22Es7nCB7VoGH/Zh2 g90hfLtfXsjj6OG239TLv+SKw5wHvG4SUHF9lzWHcvyE9OSR0dANCiWQ1wv7bw6jESwi K3BSK4M6WMVexwZ1QsEq69wA9Z+bG06Q3Q1RAu2E+NGhfhcJlKPZ6Mkasjjg7ywPnlJh cRYALhKvIaqpKFp8tvDp5VEIjFOJ+l6fE5hBu5bdLQeTzFM2L3dF9Ldpop0GLt6bR5iH TByzLWplacAKn9yldEAyi2DDWAYNYjVy2bsioRgfrfKDtInMO/wkZAU9ZLcKAVbL4z1t iQUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jUC7Y2gPsAPBf8ynJD7jkRZN+eaF2xdcofkaGlFh1D8=; b=NfR2aAviy6WyLrKNQoIC+EI8W8Y9udPVf/obJMoa6B7lXjkbHx1xK7nXTFFYhYQdtd F3J2WhyuFStCUGMJleXtnXcvlCM7PyFXaTijHrMpBHNsEXz3JyFhlSljUIr9U5QQLVkS DANnI8G/++krugpXQdOPv0ckIfNY6lGTkSYNFy/Oj6Hwq1oOd5Zr+9rXhNpT5eFG5GRL YCY+akVoSP3uzluuB0m7bAqD1bJpIJBKbKt4iswpswYwhORUx1sDmxiDzyexipMbm/z9 zCwTZEAD8//GAve/+H5DcQojlOL9NaaTi0wragJW96xY6NxV0PDXhDAABRYLgzuyQJtJ unsQ== X-Gm-Message-State: APjAAAWeFDHdlwiEOWJFsdLlOQkgpljiGbMfsWEmNTPOIbsGeFbKmSTc UffGCWB2pdeMEcLD9YhuBunyvqY0G+plav1M7/k= X-Google-Smtp-Source: APXvYqxUs88kIYOUgCAL8QF0lyC0tb1TTArlUJ1vIy1esDozRKtKLhmBagCHa2S87ku8LdbWonGSXlyXCD4Jz5CYu3s= X-Received: by 2002:a5d:8cce:: with SMTP id k14mr8391436iot.294.1579717935585; Wed, 22 Jan 2020 10:32:15 -0800 (PST) MIME-Version: 1.0 References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> <20570.1579314460@localhost> <30267.1579654985@localhost> <9b50e4ca-d516-3f3b-5992-1695f8147d18@sit.fraunhofer.de> <30626.1579713687@localhost> In-Reply-To: <30626.1579713687@localhost> From: "M. Ranganathan" Date: Wed, 22 Jan 2020 13:31:39 -0500 Message-ID: To: Michael Richardson Cc: Henk Birkholz , mud@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Mud] how to increase trust in MUD URL 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: Wed, 22 Jan 2020 18:32:20 -0000 On Wed, Jan 22, 2020 at 12:21 PM Michael Richardson wrote: > > > Henk Birkholz wrote: > > On 22.01.20 02:03, Michael Richardson wrote: > >> But, updating the URL in IDevID is difficult to do. Quite reasonably it might > >> be impossible without a device recall. The IDevID version is much easier to > >> invest trust into. And it clearly links back to the manufacturer. > > > This is one of the biggest issues that came to my mind ad-hoc. Is changing > > the URI really an option? I would assume this type of encapsulation is > > trustworthy, I think. > > Changing the URI in an IDevID is not, in my opinion, feasible. > While I can imagine ways for an IDevID to be renewed online, I would prefer > that it be buried so deep into the TPM that it can't be changed in the field. I see some words to the contrary in https://tools.ietf.org/html/draft-richardson-opsawg-mud-acceptable-urls-00 i.e. I see the following: "The DHCP and LLDP mechanisms are not signed, but are asserted by the device. " Why can't the MUD URL emitted by the device using DHCP be signed with the device private key? If the IDevID for the device can be sent to the MUD Controller using a trusted agent then the Device can just send a signed MUD URL in the DHCP request (or LLDP),. With this mechanism, it may not be necessary to imbed the MUD URL in the device certificate and the device can freely change the MUD URL with firmware updates. Onboarding mechanisms (e.g. DPP) can be used to authenticate the device against the certificate. With this setup, it is not necessary to include the MUD URL as part of the device certificate. Am I missing something obvious. > > -- > Mud mailing list > Mud@ietf.org > https://www.ietf.org/mailman/listinfo/mud -- M. Ranganathan From nobody Wed Jan 22 11:07:44 2020 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 33CAD120802 for ; Wed, 22 Jan 2020 11:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 hcslPgOTL9Cc for ; Wed, 22 Jan 2020 11:07:39 -0800 (PST) Received: from mailext.sit.fraunhofer.de (mailext.sit.fraunhofer.de [141.12.72.89]) (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 E571312080F for ; Wed, 22 Jan 2020 11:07:37 -0800 (PST) Received: from mail.sit.fraunhofer.de (mail.sit.fraunhofer.de [141.12.84.171]) by mailext.sit.fraunhofer.de (8.15.2/8.15.2/Debian-10) with ESMTPS id 00MJ7XET007105 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA256 bits=128 verify=NOT); Wed, 22 Jan 2020 20:07:34 +0100 Received: from [192.168.16.50] (79.234.120.240) by mail.sit.fraunhofer.de (141.12.84.171) with Microsoft SMTP Server (TLS) id 14.3.468.0; Wed, 22 Jan 2020 20:07:28 +0100 To: "M. Ranganathan" , Michael Richardson CC: References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> <20570.1579314460@localhost> <30267.1579654985@localhost> <9b50e4ca-d516-3f3b-5992-1695f8147d18@sit.fraunhofer.de> <30626.1579713687@localhost> From: Henk Birkholz Message-ID: Date: Wed, 22 Jan 2020 20:07:27 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [79.234.120.240] Archived-At: Subject: Re: [Mud] how to increase trust in MUD URL 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: Wed, 22 Jan 2020 19:07:42 -0000 On 22.01.20 19:31, M. Ranganathan wrote: > Am I missing something obvious. No, not at all. I am not aware of potential procedural caveats and in principle this sounds fine. Alas, now the "trust in the MUD URL" relies on the protection of the private key. If that key is not shielded/isolated properly and the integrity of the devices is compromised, the trustworthiness of the MUD URL is gone without any indications, consecutively. Please mind, maybe I am the one missing something now. The burden of providing evidence about the "trust in the MUD URL" lies with the device in this scenario. If you embed it in the device's DevID, this burden is with the trust anchor, I think. Although a complementary entity is required to remediate loss of device integrity, still (as in most cases). A compromised device alone can and will use any MUD URL it wants. Maybe I am over-simplifying my point, but I think that is one main difference. Analogously, I am still not convinced that changing the MUD URL is not dangerous in principle. If you do not allow for a MUD URL to change, you avoid a lot of complexity. The simplicity of MUD is one of its main selling points. Viele Grüße, Henk On 22.01.20 19:31, M. Ranganathan wrote: > On Wed, Jan 22, 2020 at 12:21 PM Michael Richardson > wrote: >> >> >> Henk Birkholz wrote: >> > On 22.01.20 02:03, Michael Richardson wrote: >> >> But, updating the URL in IDevID is difficult to do. Quite reasonably it might >> >> be impossible without a device recall. The IDevID version is much easier to >> >> invest trust into. And it clearly links back to the manufacturer. >> >> > This is one of the biggest issues that came to my mind ad-hoc. Is changing >> > the URI really an option? I would assume this type of encapsulation is >> > trustworthy, I think. >> >> Changing the URI in an IDevID is not, in my opinion, feasible. >> While I can imagine ways for an IDevID to be renewed online, I would prefer >> that it be buried so deep into the TPM that it can't be changed in the field. > > I see some words to the contrary in > https://tools.ietf.org/html/draft-richardson-opsawg-mud-acceptable-urls-00 > > i.e. I see the following: > > "The DHCP and LLDP mechanisms are not signed, but are asserted by the device." > > Why can't the MUD URL emitted by the device using DHCP be signed with > the device private key? > > If the IDevID for the device can be sent to the MUD Controller using a > trusted agent then the > Device can just send a signed MUD URL in the DHCP request (or LLDP),. > > With this mechanism, it may not be necessary to imbed the MUD URL in > the device certificate > and the device can freely change the MUD URL with firmware updates. > > Onboarding mechanisms (e.g. DPP) can be used to authenticate the > device against the certificate. > > With this setup, it is not necessary to include the MUD URL as part of > the device certificate. > > Am I missing something obvious. > > >> >> -- >> Mud mailing list >> Mud@ietf.org >> https://www.ietf.org/mailman/listinfo/mud > > > From nobody Wed Jan 22 12:12:35 2020 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 6073012087A for ; Wed, 22 Jan 2020 12:12:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 AuToMdQhb4zZ for ; Wed, 22 Jan 2020 12:12:32 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7D1A120142 for ; Wed, 22 Jan 2020 12:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1759; q=dns/txt; s=iport; t=1579723952; x=1580933552; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=3AdOaAIV/Bw2Hqeuk9S15FqzqNQoDDHkV61CCJ9yAWE=; b=ZRam0dzh7q2GQUHMQCSURzAVdUkR/J2GtPSHduLjynnpvydn7z8/ILn1 zAHEJuQ2z8lGgXTGBlHRvOPtOYdztAa85JJqT3AD/Pthv9r7J9QwtAmLd e3AHuKBeWeIpWONTud6kJPakea+wmGZrGE/iIGnKBFFEfayzwzUrBOQxN U=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVBACvqyhe/xbLJq1lHQEBAQkBEQU?= =?us-ascii?q?FAYF7gimBYRIqjRWICCWbNwIHAQEBCQMBAS8BAYRAAoI+OBMCAw0BAQQBAQE?= =?us-ascii?q?CAQUEbYVDhV4BAQEBAgF5BQsLGC5XBhODJgGCWyCucoInhUqEZBCBOIFTil2?= =?us-ascii?q?CAIE4DBSCFwcuPogLgiwEjXKJQJgggkOCS4EckkwbmnemOYMtAgQGBQIVgWk?= =?us-ascii?q?igVgzGggbFWUBgkE+EhgNlkhAAzACjWoBAQ?= X-IronPort-AV: E=Sophos;i="5.70,350,1574121600"; d="asc'?scan'208";a="22440519" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jan 2020 20:12:29 +0000 Received: from dhcp-10-61-103-205.cisco.com (dhcp-10-61-103-205.cisco.com [10.61.103.205]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 00MKCTB7022864 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Jan 2020 20:12:29 GMT From: Eliot Lear Message-Id: <104874F4-BB08-4284-9ED2-0400BC067942@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_2952D7A3-4DB8-4740-B00C-35982BC46C4D"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Wed, 22 Jan 2020 21:12:28 +0100 In-Reply-To: <9b50e4ca-d516-3f3b-5992-1695f8147d18@sit.fraunhofer.de> Cc: mud@ietf.org To: Henk Birkholz References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> <20570.1579314460@localhost> <30267.1579654985@localhost> <9b50e4ca-d516-3f3b-5992-1695f8147d18@sit.fraunhofer.de> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.103.205, dhcp-10-61-103-205.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Mud] how to increase trust in MUD URL 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: Wed, 22 Jan 2020 20:12:33 -0000 --Apple-Mail=_2952D7A3-4DB8-4740-B00C-35982BC46C4D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 22 Jan 2020, at 08:31, Henk Birkholz = wrote: >=20 > Hi mud'ler, >=20 > On 22.01.20 02:03, Michael Richardson wrote: >> But, updating the URL in IDevID is difficult to do. Quite reasonably = it might >> be impossible without a device recall. The IDevID version is much = easier to >> invest trust into. And it clearly links back to the manufacturer. >=20 > This is one of the biggest issues that came to my mind ad-hoc. Is = changing the URI really an option? I would assume this type of = encapsulation is trustworthy, I think. To me this is something that TEEs can really assist with, but we may = need to think about how the URL is communicated. Should it be in an = idevid long term or in some other signed object? Eliot --Apple-Mail=_2952D7A3-4DB8-4740-B00C-35982BC46C4D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl4orKwACgkQh7ZrRtnS ejMPDgf8CU5X/Gw2GiRJ1qRCoJfo3B7zMcfBhvRFCAvnaQeCDG4DgsA/u4UblLRv ppKWRkpKqMfaDS2+BxmHwejHBNmQHXxk3OmA3loYgw1a91VtkA2rW00AVzEUsJGW eqEEBk2YGqV73RD8mCwy7C0S3MFg4HOmRiUsnyLE7i/Uk0ZYRFlvfAEZm+0i7Un+ +N6hJRLI+qNnjropE8v2cf5f+p7rlINcBi0o02sYomNlFfGAEAstfZRDAnBrCl7M i1XUEAeIYbrN9Di5QP9aQDX/1xAoKq18fZCuqNuADyT5+KSQDjnIqOdfw9RNAlyY xbakFrDj+PN5LQVg0V/j+YIiT+0XIA== =Jcw5 -----END PGP SIGNATURE----- --Apple-Mail=_2952D7A3-4DB8-4740-B00C-35982BC46C4D-- From nobody Wed Jan 22 13:01:04 2020 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 D3A66120872 for ; Wed, 22 Jan 2020 13:01:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 7d1B1OXgy48Y for ; Wed, 22 Jan 2020 13:00:59 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B19F12086B for ; Wed, 22 Jan 2020 13:00:59 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 02C9B3897E for ; Wed, 22 Jan 2020 16:00:24 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 8652BDB1 for ; Wed, 22 Jan 2020 16:00:57 -0500 (EST) From: Michael Richardson To: mud@ietf.org In-Reply-To: <911BB7CD-4006-4DEE-AA93-724F9C280CD0@cisco.com> References: <9157.1579657475@localhost> <911BB7CD-4006-4DEE-AA93-724F9C280CD0@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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] [Dumpsterfire] telnet (fwd) lefty via Dumpsterfire: [Dumpsterfire] telnet 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: Wed, 22 Jan 2020 21:01:03 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: > The question is this: > Was this an example of a service that was left running or is telnet > actually required for the device to be configured? I think there are three questions. 1) Was telnet intended to be enabled in production? I'll bet that 95% of it is no. MUD would have helped significantly, provided, i guess, that the device was behind something that could provide ACLs. I'll bet half the devices are broken home routers. =20=20=20 2) Was a credential needed to access? Old revisions of openwrt just left a a root shell on a telnet port, because there wasn't code space for anything else, and what's the point of a default credential that everyone knows. 3) Assuming that the service was needed in production, and either had a default credential or no credential, was there even a way to change the credential, or turn off the service? The article says that this is a problem in telnet, and as the one comment says, it's nothing to do with telnet. It is a serious limitation of passwords. (I remember trying to figure out if I could write an S/Key calculator for an stack calculator... not an HP, which was too limited) >> On 22 Jan 2020, at 02:44, Michael Richardson wrot= e: >>=20 >>=20 >> From: lefty via Dumpsterfire >> Subject: [Dumpsterfire] telnet >> Date: 21 January 2020 at 17:40:22 CET >> To: dumpsterfire@firemountain.net >> Reply-To: lefty >>=20 >>=20 >> More than 500k telnet credentials for IoT devices leaked >> https://threatpost.com/hacker-leaks-more-than-500k-telnet-credential= s-for-iot-devices/152015/ >>=20 >> Meh - a small gesture >>=20 >>=20 >> ********************************************************************= ** >> The Dumpsterfire mailing list is hosted by firemountain.net. >>=20 >> To unsubscribe or change delivery options: >> http://www.firemountain.net/mailman/listinfo/dumpsterfire >>=20 >>=20 >>=20 >> -- >> Mud mailing list >> Mud@ietf.org >> https://www.ietf.org/mailman/listinfo/mud > ---------------------------------------------------- > Alternatives: > ---------------------------------------------------- =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4ouAkACgkQgItw+93Q 3WUB4gf/Z/NYqpDsLVkdDuXhIBtXQiqc7+MgTTOm7mL5tGV6mYT904VYa4U35NQy 778anvM38LcW/+uhDkSfp4NyFxpW7pwvbyNIuozes7QVOlNp3rAwbWPk3qEA9OAh +nUpzm0nR5SbzLsRNeSC7XLWCyzrfMNGCl6yacM3F7/Qwge8R8qWLziyn62iS+0f 4UDoXBYkRiuq5RYI0H53/yRg+/tmq+ogOk7UJPpYut79zuN6w803Qa2UGoFtpox/ ZYcfgXF0tH6MR9MxVdwRfB08xBLUAFfYjGo6MaeOX2F9ydO1ugTx/4t6BTBIw5yE pJ7to9O9r6dupGr2k/HvBijMQKQK0Q== =UyHw -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 22 13:35:15 2020 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 3EB45120045 for ; Wed, 22 Jan 2020 13:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 UzOYMMQw43pD for ; Wed, 22 Jan 2020 13:35:10 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9398612001B for ; Wed, 22 Jan 2020 13:35:10 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5E9D23897E; Wed, 22 Jan 2020 16:34:36 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E40A0C69; Wed, 22 Jan 2020 16:35:08 -0500 (EST) From: Michael Richardson To: mud@ietf.org cc: "M. Ranganathan" , Henk Birkholz In-Reply-To: References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> <20570.1579314460@localhost> <30267.1579654985@localhost> <9b50e4ca-d516-3f3b-5992-1695f8147d18@sit.fraunhofer.de> <30626.1579713687@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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] how to increase trust in MUD URL 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: Wed, 22 Jan 2020 21:35:13 -0000 --==-=-= Content-Type: multipart/mixed; boundary="=-=-=" --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable M. Ranganathan wrote: > On Wed, Jan 22, 2020 at 12:21 PM Michael Richardson > wrote: >>=20 >>=20 >> Henk Birkholz wrote: > On 22.01.20 >> 02:03, Michael Richardson wrote: >> But, updating the URL in IDevID = is >> difficult to do. Quite reasonably it might >> be impossible without a >> device recall. The IDevID version is much easier to >> invest trust >> into. And it clearly links back to the manufacturer. >>=20 >> > This is one of the biggest issues that came to my mind ad-hoc. Is >> changing > the URI really an option? I would assume this type of >> encapsulation is > trustworthy, I think. >>=20 >> Changing the URI in an IDevID is not, in my opinion, feasible. While >> I can imagine ways for an IDevID to be renewed online, I would prefer >> that it be buried so deep into the TPM that it can't be changed in t= he >> field. > I see some words to the contrary in > https://tools.ietf.org/html/draft-richardson-opsawg-mud-acceptable-ur= ls-00 > i.e. I see the following: > "The DHCP and LLDP mechanisms are not signed, but are asserted by the > device. " > Why can't the MUD URL emitted by the device using DHCP be signed with > the device private key? It could be. Bud: a) we haven't defined the MUD DHCP extension that way. We could probably sign the entire DHCP request with RFC3110. I've done this in the distant= past. b) it doesn't gain us anything. It's not a signature from an IDevID (or LDevID) that is interesting. The malware, having taken over the device could do that. That could be as easy, on a *nix machine, as dropping a file into /etc/dhclient.d/ with the new MUD URL, and the DHCP mechanism would sign it for you. What we want is a signature from the manufacturer, or possibly, as Eliot suggests, from a TEE/TPM. But, how does it know what the MUD URL for this firmware is? And, if you've got all that, then you have remote attestation anyway, so why not just have the RATS Verifier provide the MUD URL as part of the Attestation Results? Since remote attestation is not going to be common case for home appliances in the near future (not because the devices are incapable, but because the homes are ill-equipped [%]), what we can do do today to easily keep the MUD URL from changing too much, without locking it down completely? [%] - the lack of equipment to do remote attestation also means that probably also has no secure controller to do onboarding, or evaluate the IDevID. So, MUD will be TOFU. Henk Birkholz wrote: Henk> If you do not allow for a MUD URL to change, you avoid a lot of Henk> complexity. The simplicity of MUD is one of its main selling Henk> points. Eliot had previously convinced me that updating the MUD file in place was probably workable, and this was not that big a deal.=20=20 The TLS profile convinces me otherwise. The need to pin the manufacturer signature probably deals with a lot of the changes that we might need. Eliot Lear wrote: >> This is one of the biggest issues that came to my mind ad-hoc. Is >> changing the URI really an option? I would assume this type of >> encapsulation is trustworthy, I think. Eliot> To me this is something that TEEs can really assist with, but we Eliot> may need to think about how the URL is communicated. Should it = be Eliot> in an idevid long term or in some other signed object? I think that you really mean a TPM-enabled secureboot environment, which a TEE can implement. If the firmware (update) comes with a signed blob that the boot environment can interpret, then that could also contain a manufacturer signed URL.=20=20 The SUIT manifest pretty much satisfies this requirement, but we still need= a signed thing to put into a DHCP (or LLDP) package. That would likely need = to be a simple CoseSign0 object. --=-=-= Content-Type: text/plain Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Description: Signature =2D-=20 ] 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 = [ --=-=-=-- --==-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4owAwACgkQgItw+93Q 3WUijQf7BzlGELxf1J1h+EIBz7DZ87DtgYyo3FBO78GAW7sEEyVlkdVg792XvUBE /eBCLOALk0Qd6LNdiaoyVKeJ3SwuLktONhr0SsLvF7M0Ieq9IsNQeuWj8JBa5jYc bWODC53zoylwRVDBrLJkHEtktCqQv5uvDzwPkUgs1ebG88QNGipXqDK0BSjTonMi YPH6N3Gf0DaUcn7TjHYi7hU/oZIt5/0W4WFpoy063/JE80XLBjNHlNJgjZLyqmec Cf4Qf10bOuroEPEoWi9sgVvnr+po7t5txzHjVZONSYxJe+TpHoMYRyJob6d3wRVE /M7Bn/8HDG38LnLfZgUUKvO0JkiBGw== =5uE5 -----END PGP SIGNATURE----- --==-=-=-- From nobody Wed Jan 22 18:33:25 2020 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 478C5120089 for ; Wed, 22 Jan 2020 18:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 jLrYcezT19Jd for ; Wed, 22 Jan 2020 18:33:22 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88E18120018 for ; Wed, 22 Jan 2020 18:33:21 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2BAF53897E for ; Wed, 22 Jan 2020 21:32:48 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id E31919B0 for ; Wed, 22 Jan 2020 21:33:20 -0500 (EST) From: Michael Richardson to: mud@ietf.org In-Reply-To: <428.1579728908@localhost> References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> <20570.1579314460@localhost> <30267.1579654985@localhost> <9b50e4ca-d516-3f3b-5992-1695f8147d18@sit.fraunhofer.de> <30626.1579713687@localhost> <428.1579728908@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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] how to increase trust in MUD URL 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, 23 Jan 2020 02:33:24 -0000 --=-=-= Content-Type: text/plain If a device provides a MUD URL which points to a 404, what does that mean? Section 1.6 says that it should tolerate failures for awhile. I am thinking about a case where malware discovers that a particular version of firmware has a MUD file that contains an error that allows for exploit traffic. Can a manufacturer just remove a MUD file from their web site if the firmware revision is obsolete? That seems wrong. It seems that it ought to just post an "empty" (no ACLs) mud file in that case. But, then we wind up with a bunch of tombstones. Maybe the file could have something assertive, like: "bad bad, do not run, quarantine now" as flag? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4pBfAACgkQgItw+93Q 3WUCRwgAmWlbgagVuauvnFAzKrcZ8RMXGK6hhOu66azKzplUDpLglTOPzTayfOUX uKRQN3U43Yjc6pRmFZQvMZ/Sfj0G6X1CjjsPMMochQVc42ut4zHbvzPfHzQlv/FA ssN1/kNhnSQPV3JRo2ZuXL/3LeXgVCzFZzOS+cwI/cRF5Kor5cTTn2ITyWBX4O8j 6AacYN1BFvtVBJxvgemZLK5CBmdVGlIl9lEVn1l0Faa/4WqJLOKJXfwgU6k+2BxV El9dG3KG3dDUAWjPqTvaFNNjDmCfZwSnUsAYcSiVa1Z+DI1+IhhtqpjcCmCG5w0y 2ZvFMjQjO9qhRlpoLuDzy/asM0KWCg== =Zb5Q -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 22 18:48:53 2020 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 872AB120018 for ; Wed, 22 Jan 2020 18:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=fugue-com.20150623.gappssmtp.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 0Yjuj7Vrs-Rn for ; Wed, 22 Jan 2020 18:48:51 -0800 (PST) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1449112006F for ; Wed, 22 Jan 2020 18:48:51 -0800 (PST) Received: by mail-qk1-x72b.google.com with SMTP id 21so2020727qky.4 for ; Wed, 22 Jan 2020 18:48:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=7H9tG9e4MURMutMEFDP49/AZvO+2UG1Dj2FgqzNBSYM=; b=homFFu4u+NkizWGDPldlBnHJkX5eQpD/R8MkJ+xWMnlOYZ8jb354xBfLqVL9EfzEd1 BEfXPhyB+JOc9YzXF1nD56w+K1d+sbdTENQ13XG7QgCnwAD4FWm4gCUs3ZR9IjIDG5yH Am4X4mFUUB4uIRJ+Jz3fF6rqD49kMkSZPAJ3XcFVJ7KJkQzDeCLQ2oFc1juNWXjIR7S/ +PbSJenVqG3DLqWpXIXqczPL7Wkn6PQZYiQLcrXVuzy137yFJOnSuT0cuxisHwj+5Eyx JqX2XrLeg4M85+0pr8L6r1BOWMa8Yewf0YJN0h0+3GnBuNNi6EkdmpJWheldhAsWv6TO o4bA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=7H9tG9e4MURMutMEFDP49/AZvO+2UG1Dj2FgqzNBSYM=; b=dvkB8IjNJo4wVEQ+rZFqcH5YNSG3k2QymEB96OJ0H3CzYEFCX923hhoRPPrAUs2L46 5VAdUDm32UW32/NtHpMKzn01pUCC5jpE8ATlQMUyLfdgH4webPM2qcrxw9UPAzt3v9e7 Fiuc9+3b7GC6TNm7zkPQn8oIm4IaLHLRDJIIqLIZD8SDeqonQsjFoSoxrpiSFSAT24Z1 /ZIrl0RvTtkl5oE4QJxJP6KRsJ5AlMdfGcA2U3NcBZalCgHXY2qiYhBulNCG0Ep0GFMt DGutvFIbYmPqwNPVq7gkuNDSg2YjRjYZIHPMbbUF6hNEtSp1j4aD3FSOIByW6AVutVmT CCQw== X-Gm-Message-State: APjAAAWhuywFG2BXHK8Mmvo6FB02nZCu6iyEafCWjI/JkNK3HhztEUt5 qwfQ6rbHZ3ACogcYCKOlCjhro13nTufvSQ== X-Google-Smtp-Source: APXvYqwzgafb9OmhcGa5Y5aGrg+tHC6KyRIz4LefCxj+8+JfzatJKUqLrN5JWaY46X5MkU1H/bKoDw== X-Received: by 2002:a05:620a:248:: with SMTP id q8mr6372448qkn.354.1579747730161; Wed, 22 Jan 2020 18:48:50 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:f530:d7fe:78b4:aa4d? ([2601:18b:300:36ee:f530:d7fe:78b4:aa4d]) by smtp.gmail.com with ESMTPSA id i16sm266482qkh.120.2020.01.22.18.48.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Jan 2020 18:48:49 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3A32FF4D-1FC8-4BF7-8A61-0A1AA0DF789D" Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.4\)) Date: Wed, 22 Jan 2020 21:48:48 -0500 In-Reply-To: <23472.1579746800@localhost> Cc: mud@ietf.org To: Michael Richardson References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> <20570.1579314460@localhost> <30267.1579654985@localhost> <9b50e4ca-d516-3f3b-5992-1695f8147d18@sit.fraunhofer.de> <30626.1579713687@localhost> <428.1579728908@localhost> <23472.1579746800@localhost> X-Mailer: Apple Mail (2.3608.80.4) Archived-At: Subject: Re: [Mud] how to increase trust in MUD URL 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, 23 Jan 2020 02:48:52 -0000 --Apple-Mail=_3A32FF4D-1FC8-4BF7-8A61-0A1AA0DF789D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jan 22, 2020, at 9:33 PM, Michael Richardson = wrote: > It seems that it ought to just post an "empty" (no ACLs) mud file in = that > case. But, then we wind up with a bunch of tombstones. Why is that bad? --Apple-Mail=_3A32FF4D-1FC8-4BF7-8A61-0A1AA0DF789D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Jan 22, 2020, at 9:33 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
It seems that it ought to just post an "empty" (no ACLs) mud = file in that
case. =  But, then we wind up with a bunch of tombstones.

Why is that bad?

= --Apple-Mail=_3A32FF4D-1FC8-4BF7-8A61-0A1AA0DF789D-- From nobody Wed Jan 22 21:38:49 2020 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 4772B120108 for ; Wed, 22 Jan 2020 21:38:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 BJklYxCnz1d1 for ; Wed, 22 Jan 2020 21:38:46 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F38D12010E for ; Wed, 22 Jan 2020 21:38:45 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 786523897E; Thu, 23 Jan 2020 00:38:11 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 5640868B; Thu, 23 Jan 2020 00:38:44 -0500 (EST) From: Michael Richardson To: Ted Lemon cc: mud@ietf.org In-Reply-To: References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> <20570.1579314460@localhost> <30267.1579654985@localhost> <9b50e4ca-d516-3f3b-5992-1695f8147d18@sit.fraunhofer.de> <30626.1579713687@localhost> <428.1579728908@localhost> <23472.1579746800@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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] how to increase trust in MUD URL 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, 23 Jan 2020 05:38:48 -0000 --=-=-= Content-Type: text/plain Ted Lemon wrote: > On Jan 22, 2020, at 9:33 PM, Michael Richardson wrote: >> It seems that it ought to just post an "empty" (no ACLs) mud file in that >> case. But, then we wind up with a bunch of tombstones. > Why is that bad? It's not bad in of itself, except that sometimes clutter gets cleaned up. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4pMWQACgkQgItw+93Q 3WVt0gf/Y/oxJwlLf4b4NHVMgMnNPPnoFF5nR4ZmCkE53zNyVbNzowyFV93/+wnX uPtnpYN7w6tglUnMu6Nf1rmkye8jt5C9TvN3GBqEyig+dutP1JtAhrh0eG2s5Tky +KTCOeKeIpZT+m6Eapp0P0wJPdBSijQAPK5nWXgEZUHK7hREej8eR3DWSc/jdQU+ NQWrqPOoq+CrwB7a5XLiLkiBhWyB8Pz/izlUuddkbskq5Q1llCl/ouEbUa/D6Jo0 irN+Tubl99m2QMi49T93JvhRw4Ip+4T9yxtQcAivD+gzPjzK19vapKhlIfGi2anA mBeJeBexZ1DYSg1FEC7Gk0pcDV5N4Q== =bi3i -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jan 22 23:49:05 2020 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 0EB9712012E for ; Wed, 22 Jan 2020 23:49:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham 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 xwjmNIMxC1ga for ; Wed, 22 Jan 2020 23:49:02 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11C4C120111 for ; Wed, 22 Jan 2020 23:49:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5398; q=dns/txt; s=iport; t=1579765742; x=1580975342; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=SrSplEEZVv67TP1ipdmH26qaXPz6ro7fJQj/F4KalkM=; b=JgH90rWxOsjUwo3rIpMwGZbJxTWR+HFTd7aIYmdHbihcDLGVmwLmh0SB Ij6XyptAc0Axw8g3/zbIFWS+JEGCWlYYDrwgAoXc+GiPu55y+KH/XMHvJ tAt9EayTzZIi+SeslHWEWahx7FjTf1jf5/6UX5EUf7h4yS0/aCzDMpgN2 0=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A8BAAGTyle/xbLJq1lHQEBAQkBEQU?= =?us-ascii?q?FAYF7gimBQSASKoQSiQOILZMtiAsCBwEBAQkDAQEvAQGEQAKCPjgTAgMNAQE?= =?us-ascii?q?EAQEBAgEFBG2FQ4VeAQEBAQIBI1YFCwsEFCoCAlcGE4MmAYJbIK0cdYEyhUq?= =?us-ascii?q?EVxCBOIFTh3uCY4IAgTgggh4uPoQzgyYygiwEiXyNOJgggkOCS4EcjUiFBRu?= =?us-ascii?q?ad6Y5gy0CBAYFAhWBaSKBWDMaCBsVZQGCQT4SGA2ICAUXjiRAAzCNH2ABAQ?= X-IronPort-AV: E=Sophos;i="5.70,353,1574121600"; d="asc'?scan'208,217";a="22461511" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jan 2020 07:49:00 +0000 Received: from dhcp-10-61-103-205.cisco.com (dhcp-10-61-103-205.cisco.com [10.61.103.205]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 00N7mxMc028599 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 23 Jan 2020 07:48:59 GMT From: Eliot Lear Message-Id: <901B77A8-C631-496B-B322-EAE26ED26DC0@cisco.com> Content-Type: multipart/signed; boundary="Apple-Mail=_1883C821-73BE-4D72-B6C8-C59E11C774E3"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Date: Thu, 23 Jan 2020 08:48:58 +0100 In-Reply-To: <23472.1579746800@localhost> Cc: mud@ietf.org To: Michael Richardson References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> <20570.1579314460@localhost> <30267.1579654985@localhost> <9b50e4ca-d516-3f3b-5992-1695f8147d18@sit.fraunhofer.de> <30626.1579713687@localhost> <428.1579728908@localhost> <23472.1579746800@localhost> X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Outbound-SMTP-Client: 10.61.103.205, dhcp-10-61-103-205.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Mud] how to increase trust in MUD URL 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, 23 Jan 2020 07:49:04 -0000 --Apple-Mail=_1883C821-73BE-4D72-B6C8-C59E11C774E3 Content-Type: multipart/alternative; boundary="Apple-Mail=_B2C07ADB-D56A-4205-BED9-8969603CAAA8" --Apple-Mail=_B2C07ADB-D56A-4205-BED9-8969603CAAA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Michael, > On 23 Jan 2020, at 03:33, Michael Richardson = wrote: >=20 >=20 > Maybe the file could have something assertive, like: "bad bad, do not = run, > quarantine now" as flag? >=20 If the MUD file itself contains an error that overexposes a vulnerable = device, it seems to me that the proper course of action is simply to = post a correction that will get picked up sometime after the = cache-validity period expires. As to your other question: what if the MUD file can=E2=80=99t be = reached? The general answer is simple: keep doing what you were doing. = Don=E2=80=99t change policies because you can=E2=80=99t get to the mud = file server. That=E2=80=99s just asking for a boot to the head. If the = device never had a MUD file, you would have some default handling. If = it already had a mud file, then you have some policy to go with. So suppose the device has a bad mud file, and the attacker tries to = block the file server. At that point, the device is vulnerable, but the = fact that the file is not accessible, particularly if it is not = accessible for some period of time, is probably something that is worthy = of attention. Did it become unavailable because of an attack, or did it = become unavailable because the maker went out of business? Is it the administrator or the mud file manager that should attend to = this? Could be either, but over the long run you would rather it be the = latter, with some back end support. Eliot --Apple-Mail=_B2C07ADB-D56A-4205-BED9-8969603CAAA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Michael,

On 23 Jan 2020, at 03:33, Michael Richardson = <mcr+ietf@sandelman.ca> wrote:


Maybe the file could = have something assertive, like: "bad bad, do not run,
quarantine now" as flag?



If the MUD file itself = contains an error that overexposes a vulnerable device, it seems to me = that the proper course of action is simply to post a correction that = will get picked up sometime after the cache-validity period = expires.

As to = your other question: what if the MUD file can=E2=80=99t be reached? =  The general answer is simple: keep doing what you were doing. =  Don=E2=80=99t change policies because you can=E2=80=99t get to the = mud file server.  That=E2=80=99s just asking for a boot to the = head.  If the device never had a MUD file, = you would have some default handling.  If it already had a mud = file, then you have some policy to go with.

So suppose the device has a bad mud = file, and the attacker tries to block the file server.  At that = point, the device is vulnerable, but the fact that the file is not = accessible, particularly if it is not accessible for some period of = time, is probably something that is worthy of attention.  Did it = become unavailable because of an attack, or did it become unavailable = because the maker went out of business?

Is it the administrator or the mud file = manager that should attend to this?  Could be either, but over the = long run you would rather it be the latter, with some back end = support.

Eliot
= --Apple-Mail=_B2C07ADB-D56A-4205-BED9-8969603CAAA8-- --Apple-Mail=_1883C821-73BE-4D72-B6C8-C59E11C774E3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAl4pT+oACgkQh7ZrRtnS ejN8Rgf+O6Dd58wUAQt0wwJ7tiOr+YhWg9zek/Np0oQF4CKf9DVoMcff8XLbPN7e efB2GqT8CViEije+c5RBc6OhBAVlEfcqs4lXoQ2ctdOEz6+BV1NL5FAiKMMCilGe yBWAcfEfvSQbo40mPPfGQB5erplotydmK7nQSjang6wwJgkZf7Vh3ruEiHF7+3+X QdGMSloyOmotJJoetDol4Gpvc8IRyN+gBowMXG0e5z5bieFqAwo4+7+eRbu1bCpS OitrEL3jqK7tKggKsn+UfjUVdB0kZ1yqrj90jDMF8keVyJFbeIblAgICVXc4UjwB yDYRE3YGYiVyuaw2am+cRp18Bg6oiA== =GkOA -----END PGP SIGNATURE----- --Apple-Mail=_1883C821-73BE-4D72-B6C8-C59E11C774E3-- From nobody Thu Jan 23 08:47:22 2020 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 57500120121 for ; Thu, 23 Jan 2020 08:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 OFVJMNNgjE8e for ; Thu, 23 Jan 2020 08:47:18 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90F66120918 for ; Thu, 23 Jan 2020 08:47:18 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8A17C38980; Thu, 23 Jan 2020 11:46:43 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id C9A9E9B0; Thu, 23 Jan 2020 11:47:16 -0500 (EST) From: Michael Richardson To: Eliot Lear cc: mud@ietf.org In-Reply-To: <901B77A8-C631-496B-B322-EAE26ED26DC0@cisco.com> References: <157918044299.26236.8163535356477976451.idtracker@ietfa.amsl.com> <20570.1579314460@localhost> <30267.1579654985@localhost> <9b50e4ca-d516-3f3b-5992-1695f8147d18@sit.fraunhofer.de> <30626.1579713687@localhost> <428.1579728908@localhost> <23472.1579746800@localhost> <901B77A8-C631-496B-B322-EAE26ED26DC0@cisco.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 25.1.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] how to increase trust in MUD URL 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, 23 Jan 2020 16:47:20 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eliot Lear wrote: >> On 23 Jan 2020, at 03:33, Michael Richardson = wrote: >> >> >> Maybe the file could have something assertive, like: "bad bad, do no= t run, >> quarantine now" as flag? >> > If the MUD file itself contains an error that overexposes a vulnerable > device, it seems to me that the proper course of action is simply to > post a correction that will get picked up sometime after the > cache-validity period expires. Assume that it's not the file itself that is broken, but the firmware that references it. That is, version N of the firmware is bad, and it references mud file example.com/revN.json. How does the manufacturer indicate to the MUD controller that, if you have revN, that you want it offline. > As to your other question: what if the MUD file can=E2=80=99t be reac= hed? The > general answer is simple: keep doing what you were doing. Don=E2=80= =99t change > policies because you can=E2=80=99t get to the mud file server. That= =E2=80=99s just > asking for a boot to the head. If the device never had a MUD file, y= ou > would have some default handling. If it already had a mud file, then > you have some policy to go with. Agreed, we should not change behaviour if the file is gone. The question is, is there a path which leads to the MUD controller abandonning the file? =2D- Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4pzhQACgkQgItw+93Q 3WUMIQgAutqpc7Rqxf6LwBuF+u3115hATRPH5nMOhGOXoNeifOnQ9W41FR5KHti7 OhA7bnHse1EViQbsw+uVC9+xuAKRhpvx7UxGtigpkEg4O94VfaGOMfirucB25TGe r/tZDVUl2B80EUqEYemcciYWDAggRXCzeSXxuBiMakAIXa9zUsvA5fmb2s35VSGj 2Vmr8d80tw8etwQPZD+Sy7lHxoTPNAe0NXJDPT95Cp4Lqlb813lEaVrYuenV1HEZ XLXQQYjfgkO4pzz9ByqOkhd1YaGn988FdPaAXILKwODLMzJkxD07nGxaLArqNlU4 mbzK4BeKo8bcn75tflcYmgbBJEAM5A== =tnXY -----END PGP SIGNATURE----- --=-=-=--