On Fri, 22 Jun 2007, Alex Alten wrote:
> Actually I think we need a shadow Internet that is used only for > security purposes (and is fully encrypted). It is sort of like the > old SS7 signaling infrastructure of the phone network. It doesn't > need the same bandwidth, maybe 1/1000 or 1/10,000 as much. It would > use strictly cryptographic protocols for identity & authentication > and key management, etc.. I don't think I agree that a fully encrypted net is for a "security" network only. Most of the attacks we see on protocols require one of the following properties: * packets can be inserted into the network that do not come from the machines they claim to have come from (spammers exploit SMTP) * packets are readable somewhere besides their intended destination. (criminals eavesdropping on "secure" transactions and logins) * packets can be easily modified in-flight (unethical ISPs or others exploit HTTP by inserting ads into documents that aren't supposed to have them). * authorization information is available in plaintext packets (killed telnet) These are (or were) protocols that EVERYBODY uses; not just security applications. If someone develops SIP (Secure Internet Protocol, in which all payload packets are encrypted end-to-end and completion of a secure key agreement protocol is required to initiate every payload packet stream) then running our network on TCP/SIP solves all of these issues. Further, merely encrypting a network doesn't make it suitable for a "security" network. Although that would solve a lot of problems with common protocol attacks, it doesn't really address authorization issues. It makes them easier to address, but by itself it doesn't do it. We think of security problems as being associated with machines, but security problems are really associated with users. What keys &c are stored on the machine, in a "security" network, is not really appropriate information to rely on if a different user is sitting in front of it. A "security" network (or VPN done right) needs two more things: someone issuing fully revocable is-a-person credentials (indicating, roughly, that the bearer *IS* authorized to use this particular secure-net), and strict standards for how secured applications must work. Every packet needs to be traceable to the is-a-person credential (not just the machine) that was used to enter it on the network. I would be happiest if this credential were hardware: a passcard that you stick into a slot in the side of the machine in order to enable the secure-net, for example. But you still need support from secure applications. The applications must guarantee that the is-a-person credential is NEVER stored on the hard drive; your participant should have to enter it each time they enable the secure-net. And all the "user profile" information, browser settings, etc, should key off the is-a-person credential. If someone who is not using that credential changes a setting, it should have absolutely no effect on someone who is using that credential. And of course, 100% standard checking is required. Rejecting any non-standard-conforming packet or payload is flatly necessary. Once you have a secure-net, you kill another common problem: * problematic users can't be effectively and selectively banned - they just come back under a new pseudonym/account. (killing NNTP, SMTP, creating severe problems for SSL) The secure-net, without further modification, is then effectively an "island" within which NNTP, SMTP, FTP, SSL, HTTP, etc, can only see other systems on the same secure-net. I'm going to let other people think hard about the problems of establishing and controlling gateways between secure-nets. > SSL seems to be hanging by a thread, mainly the name to public key > mapping depends on how thorough the checking is done in to SSL vs > application layers inside of the web browser. If this is hosed then > unrestricted MITM is in the cards sometime in the near future. SSL is dying because the trust model implemented by its key certification process is horrifically clumsy from the user POV and the choices it presents are not meaningful to most people nor based on distinctions they can practically make. No information about the signing or trust policies in use by different signing authorities is generally available, and sadly, this is largely because there _is_ no information to convey about it. The sole thing that an SSL key establishes is that someone paid the signing authority money. Further, the signing authority is often some random unknown person whose name doesn't even appear on the cert, but who bought the key on a secondary market. Further still, the SSL keys themselves are bought and sold -- an SSL key is frequently in use by a person other than the person whose name appears on the cert, and the signing authorities do not track these further transfers nor revoke transferred keys. There is no root key whose further key-signing is controlled by any process related to security, nor is keysigning halted or signed keys revoked in the case of users who have perpetrated or permitted known security abuses. It should therefore be no surprise that SSL is nearly useless. Bear --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]