commit 411e44064ff3aff4a1b2dd0935e9c5029ad939aa
parent a5392ef9bc7981887dc8a6dc9d1fc22affb83af3
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Fri, 18 Jul 2025 16:47:25 +0200
motivation
Diffstat:
1 file changed, 33 insertions(+), 1 deletion(-)
diff --git a/draft-schanzen-pils.xml b/draft-schanzen-pils.xml
@@ -91,7 +91,38 @@
<section anchor="introduction" numbered="true" toc="default">
<name>Introduction</name>
<t>
- TODO explain motivation
+ Consider the following scenario: You use your GNUnet peer day-to-day from home.
+ One day, you decide to take a trip. With your device, and GNUnet peer.
+ Let's assume you take that trip by plane to Oceania.
+ It may be dangerous for you, depending on your activities and occupation at home,
+ if your GNUnet peer would reconnect to the network when you arrive on Oceania and
+ advertise your Peer ID because it would be linkable to the your peer's activities
+ back home.
+ </t>
+ <t>
+ More generally, we would like some degree of Peer unlinkability, depending on the
+ context in which we run our peer.
+ Ideally, the Peer ID changes when the context changes.
+ </t>
+ <t>
+ Changing PeerID requires further considerations than simply unlinkability.
+ For example it may seem prudent to use dedicated, randomly generated public key per address.
+ The reason why this is a bad idea is hidden in requirements from higher layers:
+ Having the peer handle multiple peer identities for each endpoint address will cause the connectivity on the DHT overlay to deteriorate.
+ The same physical node in the network may be reachable on N different endpoints.
+ If each of those endpoints is associated with a random peer identity (and advertised as such) other peers
+ may populate their routing tables with more than one of those addresses, in the worst case all N of them.
+ However, any connection establishment to the same node in the network does not improve connectivity and
+ resiliance of the overlay network.
+ Likely, connectivity will degrade and if the peer is no longer reachable (churn / peer offline) more than one
+ entry in the routing table will have to be replaced with new connections that in turn will again possibly
+ only be connections to the same local node in the network.
+ </t>
+ <t>
+ This document details a method to deterministically derive a peer identity from the current set of
+ endpoint addresses the peer is available at currently.
+ This provides a reasonable tradeoff between unlinkability for certain use cases, and stability for higher
+ layers in the GNUnet protocol stack.
</t>
<t>
This specification was developed outside the IETF and does not have
@@ -121,6 +152,7 @@
<t>
The address hash is calculated over the concatenation of all
address strings (URIs) (excluding 0-terminator) using SHA-512.
+ The addresses <bcp14>MUST</bcp14> be sorted alphanumerically.
</t>
</section>
<section anchor="pid_derivation" numbered="true" toc="default">
