Re: [9fans] Re: The problem with SSH2

Re: [9fans] Re: The problem with SSH2

[rob pike]

My disagreement with SSH is more specific.  It is a securitymonger's
plaything, so has been stuffed with every authentication and encryption
technology known, yet those that are configured when it is installed is
a random variable.  Therefore both sides must negotiate like crazy to figure
how to talk, and one often finds that there is no shared language. This is
idiocy.  The complexity is silly, but much worse is that there isn't at least
one guaranteed protocol for authentication and encryption that both
ends always have and can use as a fallback.  I would argue that that
would always be sufficient, but I know I'm in the minority there.  I do
argue that it's demonstrably necessary.

Algorithms everywhere, and not a byte to send.

-rob

Re: [9fans] Re: The problem with SSH2

[Markus Friedl]

On Mon, Jan 01, 2001 at 09:37:12AM -0500, rob pike wrote:
> The complexity is silly, but much worse is that there isn't at least
> one guaranteed protocol for authentication and encryption that both
> ends always have and can use as a fallback.  I would argue that that
> would always be sufficient, but I know I'm in the minority there.  I do
> argue that it's demonstrably necessary.

While I aggree that the SSH protocol is very complex, I think this
problem is more a policy issue than a protocol issue. E.g. the SSH2
protocol drafts require certain basic algorithms for authentication
and encryption.  This could be used as a fallback -- but only if
the server admin policy agrees to enable the methods.
But of course, if the protocol allows too many options it's probably
too hard for the server admin to decide which option is a good
or a bad thing.

Re: [9fans] Re: The problem with SSH2

[rob pike]

> Come on now Boyd, can't you just say
>  нет, а не то да?

User is not a typewriter.

-rob

Re: [9fans] Re: The problem with SSH2

[Boyd Roberts]

From: rob pike <rob@plan9.bell-labs.com>
> >  нет, а не то да?
>
> User is not a typewriter.
>

what ENOTTY?

Re: [9fans] Re: The problem with SSH2

[dmr]

>> If I were Russian, I might say "niet".

> nyet, although it is written:

>    HET

Come on now Boyd, can't you just say
 нет, а не то да?

	 -- Деннис

Re: [9fans] Re: The problem with SSH2

[Boyd Roberts]

> Come on now Boyd, can't you just say
>  нет, а не то да?
>
> -- Деннис
>

yer, a terror.  thanks to russ i got it installed.

it's complicated here.

Re: [9fans] Re: The problem with SSH2

[presotto]

[-- Attachment #1: Type: text/plain, Size: 59 bytes --]

I guess someone has to do it...

OK, you're a bonehead.

[-- Attachment #2: Type: message/rfc822, Size: 1803 bytes --]

From: "Boyd Roberts" <boyd@planete.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] Re: The problem with SSH2
Date: Sat, 27 Jan 2001 02:01:34 +0100
Message-ID: <005901c087fc$b1de0600$0ab9c6d4@cybercable.fr>

call me a bonehead, but security has to be simple,
so that you know exactly what it does.

Re: [9fans] Re: The problem with SSH2

[rsc]

	it may just be the instances you have seen. i've spend a bit of time
	with the draft documents; there is nothing intrinsic to its protocol
	that necessiates those larded implementations. 

no, but there's also nothing intrinsic to the
task at hand that requires such a larded
ad-hoc protocol.  cpu(1) does everything
and more with just 9P and ssl.  while you
might complain about ssl, the complexity
of the ssh protocol is not in the layer-level
encryption code.  it's everything else.
you also might complain that 9P would be
too slow, but i tried it and found that the
small-packet latency was actually _less_
using 9P than using native ssh on the same
unix boxes for various networks.

we're stuck with ssh, but let's not delude
ourselves into thinking it's a good protocol.

(i'm talking about ssh1; ssh2 looks worse.)

russ

Re: [9fans] Re: The problem with SSH2

[Dan Cross]

In article <200101261956.OAA30860@smtp4.fas.harvard.edu> you write:
>we're stuck with ssh, but let's not delude
>ourselves into thinking it's a good protocol.

Indeed.

It's that whole ``role model'' thing.  It's hard for someone to design
a good protocol if they don't have good examples to work from.  Same
thing with implementing software.

Most efforts these days are predisposed to poor implementations because
that's the only world that the people doing the implementations know
about; people *have* deluded themselves into thinking that these things
are ``good.''  But look at where this stuff is coming from: Solaris,
Linux, and Windows.

Coincidence?  I think not.

Well designed systems help those that know about them, but aren't even
close to ubiquitous.  Couple that with rabid dogmatism about the
systems they *do* know about, and the situation is grim.

	- Dan C.

Re: [9fans] Re: The problem with SSH2

[David Rubin]

Dan Cross wrote:

> Well designed systems help those that know about them, but aren't even
> close to ubiquitous.

Ahh yes...Unix helps those who help themselves :-)

	david

-- 
FORTRAN was the language of choice for the same reason
that three-legged races are popular.
	-- Ken Thompson, "Reflections on Trusting Trust"

Re: [9fans] Re: The problem with SSH2

[Boyd Roberts]

From: <rsc@plan9.bell-labs.com>
> it's everything else.
> you also might complain that 9P would be
> too slow, but i tried it and found that the
> small-packet latency was actually _less_
> using 9P than using native ssh on the same
> unix boxes for various networks.

surprise, surprise,  but you already knew that.

Re: [9fans] Re: The problem with SSH2

[Boyd Roberts]

call me a bonehead, but security has to be simple,
so that you know exactly what it does.

Re: [9fans] Re: The problem with SSH2

[Markus Friedl]

On Fri, Jan 26, 2001 at 02:56:40PM -0500, rsc@plan9.bell-labs.com wrote:
> no, but there's also nothing intrinsic to the
> task at hand that requires such a larded
> ad-hoc protocol.  cpu(1) does everything
> and more with just 9P and ssl.  while you
> might complain about ssl, the complexity
> of the ssh protocol is not in the layer-level
> encryption code.  it's everything else.
> you also might complain that 9P would be
> too slow, but i tried it and found that the
> small-packet latency was actually _less_
> using 9P than using native ssh on the same
> unix boxes for various networks.
> 
> we're stuck with ssh, but let's not delude
> ourselves into thinking it's a good protocol.
> 
> (i'm talking about ssh1; ssh2 looks worse.)

compared to SSH-1 the SSH-2 protocol is much simpler,
cleaner and layered -- and i don't think that the transport
layer of SSH-2 is more complex than SSL. only SSH-1 is a
larded ad-hoc protocol.

-m

[9fans] Re: The problem with SSH2

[rob pike]

Yes, precisely. By making the thing too complicated, they defeat
the very purpose of security.  Difficult administration results in
incorrect or inadequate installation.  There are cases when I can't
use ssh, a direct consequence.

-rob

Re: [9fans] Re: The problem with SSH2

[Boyd Roberts]

From: rob pike <rob@plan9.bell-labs.com>

> Yes, precisely. By making the thing too complicated, they defeat
> the very purpose of security.  Difficult administration results in
> incorrect or inadequate installation.  There are cases when I can't
> use ssh, a direct consequence.

hey, rob and i agree.  bloody miracle :-)

Re: [9fans] Re: The problem with SSH2

[Lyndon Nerenberg]

> hey, rob and i agree.  bloody miracle :-)

A *sure* sign that we're firmly into the new millennium! ;-)

Happy New Year!

--lyndon

Re: [9fans] Re: The problem with SSH2

[cLIeNUX user]

boyd@planete.net... 
>From: rob pike <rob@plan9.bell-labs.com>
>
>> Yes, precisely. By making the thing too complicated, they defeat
>> the very purpose of security.  Difficult administration results in
>> incorrect or inadequate installation.  There are cases when I can't
>> use ssh, a direct consequence.
>
>hey, rob and i agree.  bloody miracle :-)

Worse.

THe ssh2 package organization isn't very inspiring either.

Rick Hohensee
Forth, unix, cLIeNUX, and worse.

[9fans] Re: The problem with SSH2

[Jim Choate]

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 --'-
    --------------------------------------------------------------------

Re: [9fans] Re: The problem with SSH2

[Boyd Roberts]

real problem with SSH is that its too big and too complicated.

you can't verify it or test it easily.

Re: [9fans] Re: The problem with SSH2

[Ozan Yigit]

boyd@planete.net (Boyd Roberts) writes:

> real problem with SSH is that its too big and too complicated.

it may just be the instances you have seen. i've spend a bit of time
with the draft documents; there is nothing intrinsic to its protocol
that necessiates those larded implementations. [want a trip into the
twilight zone? take a look at lsh. keep a bucket nearby, as the trip
may be too hard on your stomach. :-/]

oz
-- 
www.cs.yorku.ca/~oz	 | if you couldn't find any weirdness, maybe
york u. computer science | we'll just have to make some!   -- hobbes