Hiya, On 29/09/2020 20:56, Michael Richardson wrote: > > Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > > On 29/09/2020 19:41, Michael Richardson wrote: > >> It will be good if we can get a document from the MAC randomization > >> proponents (if there is such a group), to explain the thread profile. > >> I don't think it includes active compromised hosts. > > > That is a problem yes. I no longer think "compromised host" is the > > correct term there though. In the case of android, we found google play > > services regularly calls home linking all these identifiers and more > > (phone#, sim serial, imei...) [1] for Google's own uses. I'd be very > > I feel that you have confounded two things, and I don't think it's helpful. > I won't dispute your observatrions about surveillance capitalism, but I feel > that you've sensationalized what I thought was a pretty specific technical > point. Namely: > You can't see into the L3 layer of WIFI, even when there are > ARP broadcasts, unless your are also part of that L2 network.
I disagree about sensationalising, obviously;-) The point is that we tended to think of a compromised host as one that had been subject to a successful attack often run by an unknown party. For mobile phones, the privacy adversary seems more often to be an entity that the phone user has accepted one way or another, whether that be the OS or handset vendor or whoever wrote that cute spirit- level app. > > I'm sure that Google Play calls home and tells Google all the your > L2/L3/IMEI/etc. I don't doubt it. > > I don't see how this relates to a local passive eavesdropping observing the > L2 frames with the encrypted L3. One not involved with the operation > of the wifi, nor connected to that link. The MAC address and other identifiers are payload with the source IP address and thus correlated at the destination without having to locally eavesdrop. But they can be used to later correlate with the local eavesdropper's data, probably after that's also been centralised (perhaps via another app using the same SDK). > > Unless you are saying that Google Play operates as active eavesdropper on all > the networks on which it is connected? I.e. it sends the L2/L3 mappings for > all devices on that network? I don't believe google do that for that attack, but they can correlate the MAC and IP addresses, yes, for all the devices on a n/w running their OS. > > > More on-topic, But yeah the above is a bit off-topic, except that it shows there's a *lot* more to do in the mobile context to get benefit from address randomisation. S. PS: to be clear - the above's not really anti-google - we've seen similar looking traffic from handset vendors' pre-installed s/w too. > I do think MAC address randomisation has a role to play > > for WiFi as it does for BLE, but yes there is a lack of guidance as to > > how to implement and deploy such techniques well. It's a bit tricky > > though as it's fairly OS dependent so maybe not really in scope for the > > IETF? > > The IEEE has a spec on how to do MAC address ramdomization. > It says nothing about how to automatically update the accept-list rules > created by RFC8520, or RFC8908/RFC8910 (CAPPORT). Or EAP-FOO. > > > (For the last 3 years I've set a possible student project in > > this space, but each time a student has considered it, it turned out > > "too hard";-) > > :-( > > -- > ] Never tell me the odds! | ipv6 mesh networks [ > ] Michael Richardson, Sandelman Software Works | IoT architect [ > ] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet >
0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
