----- 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
signature.asc
Description: Digital signature
