A secure Internet requires a secure network protocol

[bear]

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 majordomo at metzdowd.com