----- Forwarded message from Matthew Kaufman <[EMAIL PROTECTED]> -----

From: Matthew Kaufman <[EMAIL PROTECTED]>
Date: Thu, 27 Oct 2005 19:28:53 -0700
To: "'Peer-to-peer development.'" <[EMAIL PROTECTED]>
Subject: RE: [p2p-hackers] P2P Authentication
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
Reply-To: "Peer-to-peer development." <[EMAIL PROTECTED]>

 
Alen Peacock:
>   Personally, I'm put off by the centralization.  I'm not 
> really concerned about the library size or complexity of 
> PKI,.  In fact, my experience indicates that implementing 
> centralized CAs is a good deal less complex than trying to 
> distribute identity verification throughout the system with 
> no centralization.

Agreed... Hierarchical PKI with a single root is distinctly easier than
multiple roots, random chains of trust, or reputation models, which is why
we've started with the simplest design for the default PKI that ships with
the amicima MFP and MFPNet libraries.
 
>   Completely decentralized p2p applications have the 
> advantage of being especially resilient to DoS and other 
> attacks on centrality. 
> Introducing centralized components negates this advantage.  

It negates some advantages, not all.

> In the case of using CAs in a p2p app, the entire network can 
> be disabled by attacking the CAs.

As has already been pointed out, the network still runs, but new clients
can't be authenticated. However, it is possible to make that unlikely... For
instance, if enough trusted entities already have the ability to sign keys,
you can reduce the odds that an attacker can successfully disable ALL of the
CAs. Adding additional roots to the PKI, especially if they are public roots
that are unlikely to be disabled, also helps... It doesn't seem likely that
the world will shut down the existing secure web PKI in order to take your
P2P app off the air.
 
>   p2p networks pose an interesting challenge because you have 
> to design for the fact that malicious or misbehaving clients 
> *will* be present. 

This is actually true of the entire Internet and isn't unique to p2p
networks at all. All protocol implementations and higher level applications
that run on them must be designed to deal with malicious or misbehaving
clients will be present... See buffer overflows of mail servers and http
servers, for instance.

> Since there is no single entity or known 
> group of entities controlling the nodes (as in typical 
> distributed applications), there is no way to enforce 
> adherence to protocols other than with the protocols 
> themselves.  

This isn't about p2p networks at all, but about open-source distribution, it
seems. Lots of totally proprietary p2p and client-server applications have
been shipped where "a single entity" controls the implementation... Skype
comes to mind as an example in the P2P space. These have the temporary
advantage of unpublished protocols and implementations, but this won't stop
a dedicated attacker for long, which brings us back to the original point,
that everything attached to the Internet needs to assume that malicious and
misbehaving things will try to mess things up.

Whether or not that really matters is another point... There's numerous ways
one could build a highly incorrect Gnutella peer, for instance, and yet it
doesn't seem to have become commonplace.

> This may sound idealistic and naive, perhaps 
> justly so, but the further away from protocols that require 
> centralized architectures we get, the better (IMHO, of course).

Well, that's why we're all here on the "P2P" hackers list, I suppose,
because we believe that decentralization is good, but it doesn't really
change the most basic of the design parameters at all.

Matthew Kaufman
[EMAIL PROTECTED]
www.amicima.com

_______________________________________________
p2p-hackers mailing list
[EMAIL PROTECTED]
http://zgp.org/mailman/listinfo/p2p-hackers
_______________________________________________
Here is a web page listing P2P Conferences:
http://www.neurogrid.net/twiki/bin/view/Main/PeerToPeerConferences

----- End forwarded message -----
-- 
Eugen* Leitl <a href="http://leitl.org";>leitl</a>
______________________________________________________________
ICBM: 48.07100, 11.36820            http://www.leitl.org
8B29F6BE: 099D 78BA 2FD3 B014 B08A  7779 75B0 2443 8B29 F6BE

Attachment: signature.asc
Description: Digital signature

Reply via email to