Is IP multicast in scope?

[LPardue]

It seems the API would allow IP mulicast, and if so it would help to describe some use cases for it. I'm not so closely involved any more but I did write a white paper, describing BBC R&D's work experimenting with multicast in the browser. This was based on a multicast profile of the QUIC transport protocol, available as an Internet-Draft: https://tools.ietf.org/html/draft-pardue-quic-http-mcast-06

@GrumpyOldTroll is pursuing browser multicast from a different angle -the MulticastReceiverAPI - https://github.com/GrumpyOldTroll/wicg-multicast-receiver-api/blob/master/explainer.md. So I'm pinging him here.

[ewilligers]

The initial focus of this effort is communication with a single device or server. This helps focus the security discussions.

[LPardue]

That seems reasonable and I would guess applies to IPv4 broadcast too. Probably useful to highlight that in the explainer.

[LPardue]

Thanks ewilligers.

[elansys-kc]

I'm not sure blocking MDNS makes sense. There is far more danger in the proposal than allowing multicast on multicast ports to help the user allow a connection without internet access?

It would make far more security sense in my mind to only allow MDNS and a specific TCP port to be used by the browser and so developers would need to consciously decide to allow browsers to communicate with their devices.

There is far more danger in allowing connections to existing printers than MDNS over MDNS ports! Especially when printing support is already good in browsers and networks.

Perhaps any port could be allowed to the internet but only specific ports locally?

[ewilligers]

Using MDNS to resolve .local hostnames will likely be fine.

The mitigation for hostnames resolving to non-public addresses will need to allow .local

[GrumpyOldTroll]

I'm reading the discussion under this issue as allowing raw socket access to UDP port 5353?
This seems like an idea that adds a very large attack surface to in-home devices, and one that goes far beyond adding, say, a specific MDNS API (one that cannot for instance send mal-formed DNS packets trying to exploit badly implemented IoT devices). The overall API seems to introduce a very substantial new class of attack traffic capability to web apps, but allowing any outbound multicast (even rate-limited) seems like it makes it somewhat worse.
Receiving inbound multicast may have trouble as well, but I don't think it helps with the MDNS use case--it might allow a web app to provide a locally discoverable service, for instance, but this doesn't seem to fit the desired use case of interoperability with legacy network apps (and that capability might also have some dangerous spoofing problems for posing as a service that other devices local to the browser might be trying to find, though it at least wouldn't provide as easy a path to exploiting IoT devices).

[elansys-kc]

(one that cannot for instance send mal-formed DNS packets trying to exploit badly implemented IoT devices)

Certainly, that would be better. I assume this would allow Golang mdns wasm packages or packages like the following flutter one to extend to flutter for the web, one way or another?

"https://pub.dev/packages/multicast_dns"

Some networks do block multicast however and so broadcast DNS is another potential requirement? My personal interest is in allowing a unified development app like a flutter app to be able to resolve a local servers IP whilst minimising user interaction or need for understanding. A browser startup flag may be one way. Reducing the understanding to having installed a trusted app? To support all platforms that chrome is already packaged for, rather than just the mainstream systems supported by flutter.

On the IoT security point, IoT microchip devices should not be and are unlikely to be listening to this traffic. It is more likely that they will be listening to and exploitable via http already, which in my opinion is also a poor design choice on the IoT designers end but none the less a more pertinent threat enabled today, with I believe very few js controls that could be in place?

If by IoT, we mean a Linux system of some type then it shouldn't be more of an issue than any other MDNS listening desktop device. I certainly agree that an important point is that I believe malformed packet creation would normally require root on a Linux desktop.

Designs like the following largely mitigate that risk but don't necessarily excuse it, of course.

http://www.haesbaert.org/openmdns/

[beriberikix]

IoT microchip devices should not be and are unlikely to be listening to this traffic

That's not exactly accurate, unless I'm misunderstanding your point. Many IoT products use DNS-SD, fka Bonjour for device setup and configuration. That's the whole reason Apple designed it in the first place.

UPnP is a hot mess and relies on HTTP - is that what you were thinking of?

[elansys-kc]

IoT microchip devices should not be and are unlikely to be listening to this traffic

That's not exactly accurate, unless I'm misunderstanding your point. Many IoT products use DNS-SD, fka Bonjour for device setup and configuration. That's the whole reason Apple designed it in the first place.

Well IoT itself is a debated term. By IoT microchip devices I meant deep embedded or those without MMU, like cortex-m3 that are far smaller than raspberry PI or mobile devices. If they have an MMU and can run Linux/Apple IOS code without issue then I don't see any security risks that differentiate from desktops, except through poor design perhaps.

Of course apple support doesn't last very long in terms of IoT, leaving all IOS browsers vulnerable to webkit exploits that they monopolise upon users, so an IoT mobile device would quite possibly be ill advised, in any case?

[beriberikix]

deep embedded or those without MMU, like cortex-m3

I agree with the general sentiment but respectfully disagree wrt to IP Multicast. I've worked on products that are Cortex M devices with 256KB of RAM and use mDNS for device discovery and setup. There are 1M+ of those devices deployed. It, like many IoT devices I'm familiar with, use a lightweight IP stack (ex LwIP) and can easily run mDNS without an MMU (mDNS example.)

apple support doesn't last very long in terms of IoT

Apologies, the mention of Apple may have a caused a red herring. I only mention Apple because they're the ones who originally created mDNS, originally called Bonjour, to simplify printer discovery and setup. Multicast DNS + DNS-SD are now IETF standards RFC 6762 & RFC 6763. So no need to be concerned about Apple's commitment or implementations as they relate to IoT.

Anyway, I think the discussion has gone beyond the original intent of the issue. While I do hope that IP Multicast becomes in scope for future iterations of the proposal, focusing on single client/server pairs (aka unicast) as @ewilligers stated makes sense.

[GrumpyOldTroll]

+1 to "outbound Multicast out of scope for native sockets and should be blocked". I'm not sure whether this API can be made viable at all (c.f. issue #1 ), but I'm pretty sure allowing outbound multicast with arbitrary payloads adds to the difficulties in a relatively dangerous way, even for such a dangerous API.

I also doubt inbound multicast is necessary for the main use case here (allowing communication with legacy devices). I like the "having installed a trusted app" approach that @elansys-kc mentioned, which occurred to me also as a better design for the overall use case. It seems to me that combining httpslocal with app-launcher solves more than 95% of that problem with vastly fewer security headaches thrust upon the users.

So I think I'm also +1 to an overall "multicast is out of scope" for this API, and probably also +1 to "this API is not viable because security, and the use case should be accomplished in a different and safer way". But I'm less firm on those last 2 than on "block sending of multicast UDP".