First point: not necessarily.
Not necessarily means there is an existance proof. The point was
that there are more ways to snoop traffic than having access to a
router.
It only requires being on a non-IGMP'd switch or a hub; at that point,
you can snoop the traffic and see any packet going to any multicast group.
It's much harder to snoop UDP; for non-broadcast, you'd have to be
in-line (on the wire, effectively) or on a hub. While hubs are becoming
less common, they're often being replaced with cheaper non-IGMP-capable
switches. Which means that they're still hubs, as far as multicast
traffic is concerned.
Without a dobut you are right, though I think the degree of difference is
awful small. Through hosts with root on switches or through wireless into
the mix and you are back to being roughly equivalent.
However, for any reasonable content provider the difference shouldn't
matter. If you have sensitive/valuable content, whether it is unicast
or multicast, it should be protected. To say that multicast isn't being
used because there isn't security is a non-sequitor.
Alternately, if you're on a non-IGMP'd switch or a hub, and someone else
on the LAN is a member of the group, then you don't have a 28-bit key.
You can snoop and see the list of addresses in use, a much smaller set.
Finally, there are rules that hint at how to use subsets of addresses
for different uses (notably different scopes), e.g., RFC2365, a BCP.
That makes finding the 'needle in the haystack' much easier, e.g., if
you're hunting for teleconferencing, unless overrides are used, the
space is 15 bits, not 28.
Better yet, try RFC3171. Bottom-line: there are weak links in the chain.
But, if those weak links weren't there, other links would be weak links,
and THOSE weak links would still be weak enough to require using encryption.
It just so happens that the weak multicast links are only a bit weaker than
the unicast links. Understand that convoluted logic? :-)
-Kevin