This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/[email protected]/
[iot-wg] "The Internet of Threats: Fighting FUD with MUD"
- Previous message (by thread): [iot-wg] "The Internet of Threats: Fighting FUD with MUD"
- Next message (by thread): [iot-wg] "The Internet of Threats: Fighting FUD with MUD"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Michael Richardson
mcr at sandelman.ca
Mon Oct 22 23:38:47 CEST 2018
Peter Steinhäuser <ps at embedd.com> wrote: > I did like the MUD proxy idea from Michael’s presentation that provides > „correct“ MUD files. Some of the security criticisms of the mud spec is that: a) a MUD controller does not have to check the signature b) the entity that signed the MUD file has no clear relationship to the manufacturer. It's basically TOFU. c) it is underspecified as to what to do if the URL inside the MUD file that points to the signature file is a relative URL. So our idea is that we would like to have a cloud service that provides currated MUD files, signed with a signature that is properly anchored. It is my understanding that for industrial uses, that this is where some vendors think the money is: in the subscription to this service. The SHG crew are looking towards some kind of crowd-sourced service where people collaborate to improve MUD files. It would be as simple as a github repo on which people can send pull requests, but the curration activitiy would require too much human resources in such a simple situation. In particular, we'd want a MUD-diff program that presented the changes in a much easier to understand format. With voting up/down... so think stackexchange.com/serverfault/uservoice/etc. instead. > Another concern is how far CPE/home gateway manufacturers would adopt > related technical proposals. So far most firmwares are based upon > chipset maker’s SDKs that serve the purpose of selling chipsets instead > of providing reliable and secure solutions. The lastest FCC and ETSI > rulings (=> RED discussion) did also not make it easier to provide > alternative firmware solutions (i.e. OpenWRT), let’s see how the RED > ruling goes. I'd say a lot depends upon whether or not ISPs will put out an RFP that asks for an IoT firewall based upon MUD in future products. Maybe some one here would like to test the waters with an RFI. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: </ripe/mail/archives/iot-wg/attachments/20181022/b4a299a3/attachment.sig>
- Previous message (by thread): [iot-wg] "The Internet of Threats: Fighting FUD with MUD"
- Next message (by thread): [iot-wg] "The Internet of Threats: Fighting FUD with MUD"
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ iot-wg Archives ]