9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Jim Choate <ravage@ssz.com>
To: Markus Friedl <markus.friedl@informatik.uni-erlangen.de>
Cc: cypherpunks@einstein.ssz.com, 9fans@cse.psu.edu,
	hangar18@einstein.ssz.com
Subject: [9fans] Re: The problem with SSH2
Date: Sun, 31 Dec 2000 11:55:20 -0600	[thread overview]
Message-ID: <Pine.LNX.3.96.1001231113151.31533H-100000@einstein.ssz.com> (raw)
In-Reply-To: <20001231162642.A9783@folly>


On Sun, 31 Dec 2000, Markus Friedl wrote:

> On Fri, Dec 29, 2000 at 06:30:01PM +0000, Peter Fairbrother wrote:
> > Why not use a communication method that makes MITM attacks impossible to
> > successfully complete? Doesn't that "not expose them to risk at all"?
> 
> as Damien wrote: SSH2 + pk auth 'makes MITM attacks impossible to
> successfully complete'.

'pk auth' is handwaving.

How do you defeat the MITM attack against the key server this approach
requires? You don't, at some point there is a question of nothing but
'trust'. And it isn't testable. This is the fundamental weakness any any
security scheme that requires anything approaching public pk distribution.

The original point that what is needed is a distributed system with no
interest in message content is still valid. Then the parties using the
system can impliment the appropriate security for their purposes. Any
central server based system should be avoided. Any system that
pre-dictates the low-level format (ie non-delivery related) should be
avoided like the plague. Any system that requires single source (prefer
Open Source or PD) tools should be avoided like the black plague.

What we really need is a distributed network/process model (ala Plan 9)
that impliments content encryption at all levels, though 'next level' 
addressing should still be in the clear. Key management at the network
layer should be node-to-node (peer-to-peer) and left to the discression of
the individual parties. We accept that we need trust in our model and
distirbute it to the lowest level as well. This limits any breach of
security without massive amounts of resources, which limits the targets of
such attacks to reasonably readily identifiable, and as a result
protected, lists. Then using a distributed file system we can break the
actual contents up and store them 'holographically' (this probably means
multi-site storage for each little blob of a target file) so small amounts
of sites dropping off are irrelevant to the integrity of the file system.
At that point with some sort of 'anonymous thunking layer' (eg standard
anonymous remailer, posts through Usenet, or anonymous IP proxies) we can
impliment a 'data haven' sort of mechanism. This effectively means I can
access my 'home workspace' from anywhere on the Internet anonymously and
transparently (with respect to resource usage).

As an aside, this sort of architecture would also solve a lot of the
wireless issues as well.

    ____________________________________________________________________

           Before a larger group can see the virtue of an idea, a
           smaller group must first understand it.

                                           "Stranger Suns"
                                           George Zebrowski

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------



       reply	other threads:[~2000-12-31 17:55 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20001231162642.A9783@folly>
2000-12-31 17:55 ` Jim Choate [this message]
2001-01-01  7:38   ` Boyd Roberts
2001-01-26 14:33     ` Ozan Yigit
2001-01-01 14:37 rob pike
2001-01-01 15:18 ` Markus Friedl
2001-01-01 15:37 rob pike
2001-01-01 15:43 ` Boyd Roberts
2001-01-02  8:27   ` Lyndon Nerenberg
2001-01-02 17:49   ` cLIeNUX user
2001-01-26 19:56 rsc
2001-01-26 20:46 ` Dan Cross
2001-01-29 13:40   ` David Rubin
2001-01-27  0:43 ` Boyd Roberts
2001-01-27  1:01 ` Boyd Roberts
2001-01-27 14:34 ` Markus Friedl
2001-01-27  1:04 presotto
2001-01-27  2:13 dmr
2001-01-27  2:30 ` Boyd Roberts
2001-01-27  2:34 rob pike
2001-01-27  2:37 ` Boyd Roberts

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.3.96.1001231113151.31533H-100000@einstein.ssz.com \
    --to=ravage@ssz.com \
    --cc=9fans@cse.psu.edu \
    --cc=cypherpunks@einstein.ssz.com \
    --cc=hangar18@einstein.ssz.com \
    --cc=markus.friedl@informatik.uni-erlangen.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).