Hi Ben, Much of this relitigates RFC 8520, but IMHO it is worth reviewing assumptions from time to time. Remember, the purpose of MUD is to identify an authorization profile for a device to a network so that either access can be granted based on that profile or an anomaly can be detected. The primary, but not exclusive, focus is on IOT.
Please see below. > > This design treats the MUD file as a "widely shared secret", which is a > fragile arrangement. It does not appear to match the main conceptual model > of MUD, which describes MUD files as being "published", i.e. generally public. We should separate the MUD URL from the MUD file. The MUD file is absolutely 100% public, and consists of information that is observable – or should be observable – from the device. So if you are a Meddler In The Middle (;-) (MITM) you get this information anyway. The MUD URL gives up device type information. This is different in character, but often but not always easily gotten. I would say that if a manufacturer is taking steps to prevent fingerprinting, then they should take steps to protect the MUD URL. That’s an active area of interest for some. > I also think this proposal is likely to seriously impede the ability of IoT > vendors to adopt new versions of TLS, or new protocols such as QUIC. Such > updates would be delayed by (1) the need to add entries to this YANG model, > and then (2) the time for MUD gateways to develop and deploy the new entries. > Delaying protocol upgrades reduces security, contrary to the goals of this > draft. One can deploy a MUD file update in advance of a code update. The latter takes a whole lot longer than the former. No IoT manufacturer is going to put out something in less than the default time of 48 hours, lest they brick millions of devices. Is this more work for an IoT manufacturer? Sure. One thing the draft might do is discuss how to incorporate something into unit testing to write out the change. Eliot
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
