06 Dec 2010
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.