Can we protect P2P names from spoofing?

There is an obvious security issue with P2P names: spoofing.
In the absence of a reference server for the P2P top domain, pretty much anyone
can claim to own the name “Microsoft.P2P.” There are many ways around that. One
is to only ask for name resolution to peers that you trust, so if you ask them
“what is the address of Microsoft.P2P” they give you an answer that you can
trust. Another way is to rely on a certificate authority to validate the name.
Yet another way is to only use self-validating names, such as
“ZA32-5FT-RT0.P2P,” so any answer can be signed with the public key tied to the
name.

Of course, these anti-spoofing protections have their own
problems. Relying on trusted friends does not scale unless one allows for
“chains of friends,” but it takes only one crook or one fool in the chain to
break the trust. Certificate authorities can provide a reasonable security
level, but this defeats the pure P2P nature of the system by relying
effectively on a central authority. Self-validating names are hard to remember,
which can enable a different level of spoofing attacks, e.g. convincing a
hapless party that Christian’s peer address is “SA33-5FD-VT0.P2P” instead of
the actual “ZA32-5FT-RT0.P2P.” Self-validating names also have a limited
life-time, which cannot be longer than the lifetime of the public key from
which they are derived.

My colleagues at Microsoft and I studied that a great deal
when developing PNRP. In PNRP, we defined two categories of names, “secure” and
“insecure.” The insecure names are just picked by the user, something like
“myName.0” in the PNRP syntax. The secure names are derived from a public key
that is generated locally, something like “8188bbb7107c5ee6dd3387375ff55d009862f937.participant”.
The long string of hexadecimal digits is the secure hash of the public key of
the name publisher. Secure names works well in some applications, but are too
unwieldy for a DNS replacement. People could not remember them, and most likely
would not be able to copy them without typos.

The name form that I used in the previous example,
“SA33-5FD-VT0.P2P,” is derived from work that I pursued at Microsoft after PNRP.
With Kim Cameron and Josh Benaloh, we conceived a way to securely compress the
hash code, which we dubbed “Call Signs.” To compress the hash, we search for a
string that, when hashed with the key, results in a hash code ending with “lots
of zeroes.” This compression requires a lot of computing power when the code is
first generated, but results in “call signs” that are no longer than most
domain names. The technology is not used in PNRP, but could certainly be used
in a P2P naming scheme. Whether that’s friendly enough is indeed a matter of
debate.

Advertisements

About Christian Huitema

I have been developing Internet protocols and applications for about 30 years. I love to see how the Internet has grown and the applications it enabled. Let's keep it open!
This entry was posted in Uncategorized. Bookmark the permalink.

5 Responses to Can we protect P2P names from spoofing?

  1. Jérôme Nicolle says:

    What about a statistical approach ? In a sparse trust graph, the preferred target node is which has the most routes found.

    Considering a few nodes in a loose trust scheme could leak spoofed IDs, their announces couldn’t spread unless fully trusted by their direct peers. Herein, weights could be assigned based on both reputation and direct trust, to build a “best route set” to the most trustworthy target.

    Determination of the absolute best route set is dependent of the time allowed for the request to get answered by a sufficient (yet to be determined) number of nodes.

    Some nodes could declare themselves as “supernode”, waiting for trust, provided they have legitimacy on a zone, and provide complementary checks via a DNSSEC-like mechanism, thus allowing any peer to flag a node untrusted.

    Those “supernodes” could be refered to as… registries ? Well, at least a certificate repository.

    Sorry if it’s unclear, I’m kind of a newb around here :p Just fascinated by the graph theory and its numerous applications.

  2. huitema says:

    Pick the answer that is believed by most of my peers, or some similar voting mechanism? Certainly a possibility, but you have to consider the “sybil attack:” http://en.wikipedia.org/wiki/Sybil_attack.

    • Jérôme Nicolle says:

      Of course, that’s the main issue.

      Considering “Sybil attack depends on how cheaply identities can be generated…” and trusted, we could assume that a node in this mechanism cannot approve of a new peer automatically, it could be done either with specific rules (and over time), or manually by its administrator.

      I’m thinking of a decentralized naming system as a core exchange protocol, rather than an enduser tool. That’s what we currently do with BGP, for instance. Every AS is responsible for his announcements, and transit sessions are announcing prefixes on behalf of upstream’s peers.

      Let’s suppose P2PDNS is actually designed as a core exchange protocol, to replace the unidirectional trust relationship a DNS server has with the root servers. Client users could still request a P2PDNS gateway using the old school “God Almighty” kind of relationship with its ISP’s gateway. Establishing trust relationships would be the job of skilled name services administrators, who could decide to “peer” on the naming network as they would on the routing network. (network in a trust graph sense)

      This would not be a complete solution nor a fully decentralized system, but it could untie any subordination link between naming authorities, and therefore make them easily dispensable.

      Now, once the first “ring” of trust relationships is bound, we’d have “tier 1” naming operators. Any sys^Wnameadmin could then establish a manual trust relationship with such tier 1 (could be a paid service, like IP transit is), and peer with other “tier 2” naming systems, and so on.

      That’s for the manual approach to establish initial trust relationships.

      Chances are, those manual trusted peerings will not be sufficient to get an exhaustive view of the entire namespace. Also, if a node is willing to announce new zones (eg. a TLD), it could take a while for it to be trusted by the “tier 1” ring (proven stability in announcement, assignment and governance). Therefore its trust relationships will be sparse and therefore heavily wighted with “doubtful resolution” markers.

      For such nodes, a trusted-route-exploration has to be implemented. To avoid Sybil attacks, some of the trusted routes would have to be manually established by a trustworthy node. If no prior trusted peering exists, it would be up to the nameadmin to preconfigure it’s node to accept or decline answers from this upcoming node. Rules could be based on zone unicity (not announced from any other peer or transit), cryptographic strength with shared certification authority, or any plausible technical criteria.

      An added statistical approach would be to give a predefined timeout for any P2P resolution request, and build resolution routes until a “fake” pointer appears. Fake pointers could be generated by any node seeing one of its route announced by a untrusted node. Once trust relationships are checked by the initiating node, it could decide wether or not shall he drop this announce (NXDOMAIN)….

      Well, I’m thinking it as I write, so basically, my point is to combine manual trusts (peering agreements or paied transit corresponding to a humanized verification service) to a graphed trust relationships where both announcements and markers could be exchanged within, and forwarder through, mutual peers. Different weights on trusts could be sufficient to differentiate righteous from bogons, loose peerings will undermine a centralization attempt, competition between “tier1” naming providers could have a positive impact on their neutrality, and if one of them ever get caught dropping announcements on purpose, they could disappear from every trusted relations within minutes.

  3. huitema says:

    Having a network of name servers make sense. Tying that to ISP, on the other hand, is dubious. In many countries, ISP are closely controlled by governments. Not sure we would gain that much independence.

    • Jérôme Nicolle says:

      Tying it to ISPs is the natural way for eyeballs. Any user could pontentially run his own node, as anyone could set up BIND to hit on any root-servers (ICANN run or not).

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s