Discussion about PeerIDs on per address level

[Jacki]

Hi,

on our meeting today we discussed multiple cases and potential issues
of PeerID changes regarding attackers potentially tracking
users/devices via HELLO strings.

Because of that the PILS service is planned to allow PeerID changes so
that different addresses from communicators (their network interfaces)
cause a new PeerID making it much more difficult to track a device
around its addresses.

However one possible case would be that a mobile device might have an
interface for mobile traffic or even a Wifi connection that reaches far
enough, so that its address might be part of multiple HELLO strings
with different PeerIDs. Allowing tracking of a device via intersections
of addresses in the HELLO strings.

One possible way to solve this issue might be to use some sort of sub-
PeerIDs bound to communicator addresses which do not change. However
they for an attacker they would look like a fully separate PeerID with
its own HELLO string, not intersecting with the original one.

A device could configure address interfaces to use such a sub-PeerID or
not (with it being disabled by default). Another options would also be
to disable specific address interfaces completely for TRANSPORT (or
communicators) to avoid the issue.

I'm not sure whether it would be required to make a connection between
the original PeerID and such a sub-PeerID (like a signature from one to
another, authenticating to be a sub-PeerID from a specific PeerID for
example) or not. Because higher level APIs could effectively treat both
as fully separate devices as well.

If there's such a connection between them, it might help for finding a
back-channel. But it shouldn't be directly discoverable via HELLO
strings to avoid same kind of tracking as before. Additionally the sub-
PeerIDs could be rotated after a configured time interval. So even if
an attacker would discover such a connection, it wouldn't be possible
to easily track it over a longer period of time.

Essentially the idea is to have an artificial PeerID per address in
case of a long term address which doesn't change regardless of moving a
device significantly to avoid tracking. It would be implemented most
likely in TRANSPORT and operate additionally to the changing PeerIDs
via PILS.

What do you think?

Best regards
Jacki