On Sun, 20 Sep 2020 at 14:05, Eliot Lear <[email protected]> wrote: > > > > On 11 Sep 2020, at 12:40, Nick Lamb <[email protected]> wrote: > > > > On Fri, 11 Sep 2020 12:32:03 +0530 > > tirumal reddy <[email protected]> wrote: > > > >> The MUD URL is encrypted and shared only with the authorized > >> components in the network. An attacker cannot read the MUD URL and > >> identify the IoT device. Otherwise, it provides the attacker with > >> guidance on what vulnerabilities may be present on the IoT device. > > > > RFC 8520 envisions that the MUD URL is broadcast as a DHCP option and > > over LLDP without - so far as I was able to see - any mechanism by which > > it should be meaningfully "encrypted" as to prevent an attacker on your > > network from reading it. > > That’s a bit of an overstatement. RFC 8520 specifies a component > architecture. It names three ways of emitting a URL (DHCP, LLDP, 802.1X w/ > certificate). Two other mechanisms have already been developed (QR code, > Device Provisioning Protocol), and a 3rd new method is on the way for > cellular devices. > > I would not universally claim that a MUD URL is secret but neither would I > claim it is not. The management tooling will know which is which, as will > the manufacturer, and can make decisions accordingly. > > This having been said, it seems to me we are off on the wrong foot here. > The serious argument that needs to be addressed is Ben’s and EKR's. We > have to be careful about ossification. >
In order to address the comments on ossification, we added a new section 6 to explain the rules to processing the MUD (D)TLS rules to handle unknown TLS parameters and updated Section 10 to enable faster update to the YANG module. Please see https://github.com/tireddy2/MUD-TLS-profile/blob/master/draft-reddy-opsawg-mud-tls-06.txt -Tiru
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
