Re: [Int-area] [homenet] [Captive-portals] [EXTERNAL] Re: Evaluate impact of MAC address randomization to IP applications

[Michael Richardson <[e-mail]>]

Stephen Farrell <[e-mail]> wrote:
    >> Stephen Farrell <[e-mail]> 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.

My take home from your work is that MAC address randomization is a useless
waste of time.  It causes significant costs to the network operator(s) without
actually providing any benefit to the mobile phone owner, because the
adversary is inside the device, invited in by the owner.
In such a situation, MAC randomization feels like security theatre to me.

[I'm reminded of various systems of magic in fiction, where you are safe as long
as you don't unwittingly invite the bad guys in]

You have defined the security perimeter as being from "top" of the phone.
(Between the screen and the human)

I have defined the security perimeter as being the "bottom" of the phone
(between the phone and the Internet).

I think that we can do more here, and I think that the cost to the operator
(moving from unencrypted, MAC-address excepted networks, to encrypted 802.1X
authenticated networks with provisioned identities) with some correspondant
benefits to the operator as well as the end user.

    > 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.

Agreed.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [


--
Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide