Mailing List Archive

On Sat, 1 Jan 2000, Dug Song wrote:

> On Sat, 1 Jan 2000, Brian Fundakowski Feldman wrote:
>
> > http://www.FreeBSD.org/~green/openssh.SHA-1.patch
> > MD5 (public_html/openssh.SHA-1.patch) = e21a896f59474a31ab3b9103acf44c35
> >
> > P.S.: I realize other people may have proposed something very similar.
> > Indeed, markus's proposal may be something like this. However,
> > since it's impossible to work with anyone who is Theo, or
> > "under" Theo, it's unrealistic to work with that. Hence the
> > reason we need to make a code fork of OpenSSH as soon as
> > convenient.
>
> i'm sorry you feel this way. so far, the OpenBSD OpenSSH developers and
> the Linux/Solaris/etc. OpenSSH developers led by Damien Miller have been
> getting along just fine. we hereby cordially invite you to join the party!
>
> http://violet.ibs.com.au/openssh/list.html
>
> best wishes for the new year.

Have you, personally, ever tried to talk to Theo? I know I'm not the
only one who has tried, and only gotten flames in response. I don't
think someone like that should be the head of any project, and it's
truly impossible to work with such a... person.
Now, if you come to tell me there's a way to actually discuss things
with ration human beings, not having to deal with flaming egomaniacs,
I am all ears! I would love to have more people to work with, where
the people could actually remain civil.

> -d.
>
> ---
> http://www.monkey.org/~dugsong/

--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
green@FreeBSD.org `------------------------------'

On Sat, Jan 01, 2000 at 04:37:07PM -0500, Brian Fundakowski Feldman wrote:
> On Sat, 1 Jan 2000, Dug Song wrote:

> > On Sat, 1 Jan 2000, Brian Fundakowski Feldman wrote:

> > > http://www.FreeBSD.org/~green/openssh.SHA-1.patch
> > > MD5 (public_html/openssh.SHA-1.patch) = e21a896f59474a31ab3b9103acf44c35

> > > P.S.: I realize other people may have proposed something very similar.
> > > Indeed, markus's proposal may be something like this. However,
> > > since it's impossible to work with anyone who is Theo, or
> > > "under" Theo, it's unrealistic to work with that. Hence the
> > > reason we need to make a code fork of OpenSSH as soon as
> > > convenient.

> > i'm sorry you feel this way. so far, the OpenBSD OpenSSH developers and
> > the Linux/Solaris/etc. OpenSSH developers led by Damien Miller have been
> > getting along just fine. we hereby cordially invite you to join the party!

> > http://violet.ibs.com.au/openssh/list.html

> > best wishes for the new year.

> Have you, personally, ever tried to talk to Theo? I know I'm not the
> only one who has tried, and only gotten flames in response. I don't

As a matter of fact I have. Theo and I shared more than a few
beers down in San Antonio at the Usenix Security Symposium a while back.
I found that he was just as opinionated and arrogant as I was. I quickly
figured out that one did NOT come to debate one's position with Theo
unless one was fully prepared to defend one's position. I like that man!
I don't agree with him on all points and we may send some people scrambling
for 911 when we debate, but I like him. He knows his position and he IS
prepared to debate it and defend it. Anyone who attempts to argue with
him who is not prepared it engaging in a self inflicted injury. I don't
know and don't really care if he remembers our debates (hell, it was 2 in
the morning). He has my respect, whether I agree with him or not.

> think someone like that should be the head of any project, and it's
> truly impossible to work with such a... person.

Excuse "my french" at this point.

No... He is easy to work with... I know plently of assholes who
don't know jack shit about what they are managing, but the are "the manager".
THEY are impossible to work with. I have watched at least one totally
incompetant moron, whose sole goal in life is to be a role model for a
dilbert comic strip, totally destroy a corporate position with regard
to platforms and support. This man micromanaged by "buzzword". Buzzword
bingo is no fun when everyone goes balistic five minutes into one of his
monologs.

I would work under Theo in a heart beat, even if they had to
call the goon squad to keep us from throtalling each other. Theo knows
his shit and is prepared to defend his position. Anyone who argues with
him and is NOT prepared to do this same gets what they deserve.

> Now, if you come to tell me there's a way to actually discuss things
> with ration human beings, not having to deal with flaming egomaniacs,
> I am all ears! I would love to have more people to work with, where
> the people could actually remain civil.

I had this with Theo. If you are prepared to defend your ideas
and are prepared to LISTEN to his, you CAN have a productive debate with
him. You will not win all the arguements. You may even win a few points
with him. You may even part as friends (I hope I can claim that). He may
concede some points and learn some things and so may you. You DON'T
engage him in debate to convince him of something. You engage him in debate
expecting that you BOTH MIGHT learn something. And you will...

> > -d.

> > ---
> > http://www.monkey.org/~dugsong/

> --
> Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
> green@FreeBSD.org `------------------------------'

Mike
--
Michael H. Warfield | (770) 985-6132 | mhw@WittsEnd.com
(The Mad Wizard) | (770) 331-2437 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!

I'm sorry for bringing this up under all these public eyes. Let me suffice
it to say that all the communcation so far I have had with Theo regarding
OpenSSH has come down to (on my receiving side):
a. name-calling
b. NIHism
c. ignoring of all technical arguments
d. "religious" issues
e. "disappearing" from a discussion when proven wrong

Therefore, I do not find it unreasonable to state that it is nearly
impossible to try to communicate with him. I had no bias at all,
but what I've experienced from attempting rational discussion with
him has obviously given me an opinion.
I'd be elated if it were possible to have a rational discussion
with him. I suppose if I wasn't affiliated with the FreeBSD project,
I might be able to. All the evidence of possibility of rational
discussion, so far, has pointed to there being none.

--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
green@FreeBSD.org `------------------------------'

On Sun, Jan 02, 2000 at 01:00:17AM -0500, Brian Fundakowski Feldman wrote:
> I'm sorry for bringing this up under all these public eyes. Let me suffice
> it to say that all the communcation so far I have had with Theo regarding
> OpenSSH has come down to (on my receiving side):

*rest deleted*

Since I've never dealt with Theo, I won't comment on the ability (or
lack thereof) of Theo to hold a public discussion with others.
What I AM concerned about is the discussion of a possible 1.6 protocol.
Since the openssh-dev-list was never involved in that discussion, could
someone please let us know the details.

Speaking completely without facts, I am personally skeptical about
enhancing the 1.x protocol when all of the standards processes are
focused on getting 2.0 out the door. That said, I am willing to be
convinced on the matter.

Thanks,
David

--
David W. Rankin, Jr. Husband, Father, and UNIX Sysadmin.
Email: drankin@bohemians.lexington.ky.us Address/Phone Number: Ask me.
"It is no great thing to be humble when you are brought low; but to be humble
when you are praised is a great and rare accomplishment." St. Bernard

On Sun, Jan 02, 2000 at 06:15:48AM -0500, David Rankin wrote:
> Speaking completely without facts, I am personally skeptical about
> enhancing the 1.x protocol when all of the standards processes are
> focused on getting 2.0 out the door. That said, I am willing to be
> convinced on the matter.

i have put the latest revisions of my SSH 1.6 patches to
http://wwwcip.informatik.uni-erlangen.de/~msfriedl/openssh/

basically they consist of:
(1) CRC is replaced with hmac-sha1 + sequence-numbers. the bytes
needed for the hmac-key are taken from the shared session-key
(2) authentication for parameters passed in the clear: the session-id
is extended from
session_id := MD5 (host_key_n |session_key_n|cookie);
to
session_id := MD5 (host_key_n |session_key_n|
supported_ciphers|supported_authentications|
client_flags|server_flags|
client_version_string|server_version_string|
cookie);

and yes, having openssh speak SSH-2.0 would be nice.
mail me if you are interested in helping implement 2.0.

-markus

On Sun, 2 Jan 2000, Markus Friedl wrote:

> On Sun, Jan 02, 2000 at 06:15:48AM -0500, David Rankin wrote:
> > Speaking completely without facts, I am personally skeptical about
> > enhancing the 1.x protocol when all of the standards processes are
> > focused on getting 2.0 out the door. That said, I am willing to be
> > convinced on the matter.
>
> i have put the latest revisions of my SSH 1.6 patches to
> http://wwwcip.informatik.uni-erlangen.de/~msfriedl/openssh/

My concern here is, how much does it convolute the code? I believe
that it's probably not as useful to make the old SSH 1.X protocol
as infinitely more secure as it is useful to make OpenSSH support
the 2.X protocol.

>
> basically they consist of:
> (1) CRC is replaced with hmac-sha1 + sequence-numbers. the bytes
> needed for the hmac-key are taken from the shared session-key

I really don't see why we should need sequence numbers if we do
a continuous SHA-1 hash of the entire stream. Are you proposing
just one use per SHA_CTX, each packet having its own independent
hash and sequence number?

> (2) authentication for parameters passed in the clear: the session-id
> is extended from
> session_id := MD5 (host_key_n |session_key_n|cookie);
> to
> session_id := MD5 (host_key_n |session_key_n|
> supported_ciphers|supported_authentications|
> client_flags|server_flags|
> client_version_string|server_version_string|
> cookie);

That does sound better, although I wouldn't know ow much better than
before.

>
> and yes, having openssh speak SSH-2.0 would be nice.
> mail me if you are interested in helping implement 2.0.

Of course!

>
> -markus
>

--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
green@FreeBSD.org `------------------------------'

On Sun, Jan 02, 2000 at 02:46:49PM -0500, Brian Fundakowski Feldman wrote:
> My concern here is, how much does it convolute the code? I believe
> that it's probably not as useful to make the old SSH 1.X protocol
> as infinitely more secure as it is useful to make OpenSSH support
> the 2.X protocol.

i don't think the patch 'convolutes' the code, it just replaces
the CRC with a real authenticating MAC, hmac-sha1 in this case.

> I really don't see why we should need sequence numbers if we do
> a continuous SHA-1 hash of the entire stream. Are you proposing
> just one use per SHA_CTX, each packet having its own independent
> hash and sequence number?

yes, each packet has an independent MAC that depends on the current
packet and current packet number. this number is not transmitted.
i don't know a protocol that uses a continuous hash for authentication.
both ipsec and ssh2 use hmacs. usage of hmac is common practice for
authentication (hmac-sha1 is required for SSH2).

> > session_id := MD5 (host_key_n |session_key_n|
> > supported_ciphers|supported_authentications|
> > client_flags|server_flags|
> > client_version_string|server_version_string|
> > cookie);
>
> That does sound better, although I wouldn't know ow much better than
> before.

it _authenticates_ the cleartext parameters that are transmitted
before the session key can be used for authentication/encrytion.

-markus

On Sun, 2 Jan 2000, David Rankin wrote:

> Speaking completely without facts, I am personally skeptical about
> enhancing the 1.x protocol when all of the standards processes are
> focused on getting 2.0 out the door. That said, I am willing to be
> convinced on the matter.

I agree entirely. I'd love to see a free, BSD-licensed, SSH 2.x
implementation out there. The continuing emphasis on improving the
non-standard, albeit widely deployed, SSH 1.x protocol seems to be a less
useful allocation of resources. While a free version of 1.x is extremely
useful, it's not the end-all. :-) If you can get people to upgrade to
modified 1.x with backwards compatibility, wouldn't you be better served
getting them to upgrade to 2.x with backwards compatibility? :-)

Robert N M Watson

robert@fledge.watson.org http://www.watson.org/~robert/
PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1
TIS Labs at Network Associates, Safeport Network Services

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 3 Jan 2000, Robert Watson wrote:

> I agree entirely. I'd love to see a free, BSD-licensed, SSH 2.x
> implementation out there. The continuing emphasis on improving the
> non-standard, albeit widely deployed, SSH 1.x protocol seems to be
> a less useful allocation of resources. While a free version of 1.x
> is extremely useful, it's not the end-all. :-) If you can get people
> to upgrade to modified 1.x with backwards compatibility, wouldn't
> you be better served getting them to upgrade to 2.x with backwards
> compatibility? :-)

While I agree that a free version of SSH 2.x is a worthwhile goal,
it will take _months_ of effort (of course I would be happy to be
proved wrong on this).

We already have a strong SSH 1.x implementation, why not clean up its
few remaining nits (which may take only weeks)?

Apart from standards-compliance, what does SSH2 buy you over a cleaned
up SSH1?

Regards,
Damien Miller

- --
| "Bombay is 250ms from New York in the new world order" - Alan Cox
| Damien Miller - http://www.mindrot.org/
| Email: djm@mindrot.org (home) -or- djm@ibs.com.au (work)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4cF5GormJ9RG1dI8RAooeAKCz3U4Riz1CL1ikvlWVfkTdZAU0MQCfcli1
mMn9rFYT50BnvFFIKEFZDiY=
=bL3g
-----END PGP SIGNATURE-----

In message <Pine.BSF.3.96.1000103022509.7881A-100000@fledge.watson.org>, Robert
Watson writes:
>I agree entirely. I'd love to see a free, BSD-licensed, SSH 2.x
>implementation out there. The continuing emphasis on improving the
>non-standard, albeit widely deployed, SSH 1.x protocol seems to be a less
>useful allocation of resources. While a free version of 1.x is extremely
>useful, it's not the end-all. :-) If you can get people to upgrade to
Actually, Markus' modifications for the 1.6 protocol contain elements that
may be reused in a SSH 2.x implementation. I would not call it a waste
of time at all. The diff is rather small, more a necessary cleanup.

Greetings,
Niels.

Markus Friedl <markus.friedl@informatik.uni-erlangen.de> writes:

> On Sun, Jan 02, 2000 at 06:15:48AM -0500, David Rankin wrote:
> > Speaking completely without facts, I am personally skeptical about
> > enhancing the 1.x protocol when all of the standards processes are
> > focused on getting 2.0 out the door. That said, I am willing to be
> > convinced on the matter.
>
> i have put the latest revisions of my SSH 1.6 patches to
> http://wwwcip.informatik.uni-erlangen.de/~msfriedl/openssh/

Quick question. Does this fall foul of this clause in the license:

Any derived versions of this software must be clearly marked as
such, and if the derived work is incompatible with the protocol
description in the RFC file, it must be called by a name other than
"ssh" or "Secure Shell".

If so, are these new features worth losing the right to call the
executable ssh?

Cheers, Phil.
--
Boycott Amazon! --- http://linuxtoday.com/stories/13652.html

On Mon, Jan 03, 2000 at 07:30:58PM +1100, Damien Miller wrote:
> Apart from standards-compliance, what does SSH2 buy you over a cleaned
> up SSH1?

Functional support for challenge/response authentication, at least.
When I looked, I could not find any good way to add this to the 1.x
protocol.

I think it still doesn't fix my biggest beef with ssh, though: Agent
forwarding. The implementation of this in SSH essensially gives
out access for all your accounts to all machines you log into with
* no logs
* no way of restricting who gets authenticated (beyond turning a-f off)
* no way for the machine having the original authentication to verify who
is asking for authentication and for what purpose (where to log into)
* a default of sending out agent forwarding
* no way to change the default and still selectively forward

The patches for the latter two problems are trivial; I'm including
them below for completeness. Fixing the other problems is not as easy
(it require a bit of thought and several orders of magnitude more
coding); if anybody wants to do this, contact me and I'll send you an
outline for how get a reasonable implementation, including backwards
compatibility (allows the enhancements to be used securely even when
forwarding through servers that have not got support for the
enhancements.)

Eivind.

Central patch, to make it possible to selectively enable agent forwarding:

--- ssh.c.orig Wed May 12 13:19:28 1999
+++ ssh.c Sat Nov 6 20:50:55 1999
@@ -280,6 +280,7 @@
fprintf(stderr, " -l user Log in using this user name.\n");
fprintf(stderr, " -n Redirect input from /dev/null.\n");
fprintf(stderr, " -a Disable authentication agent forwarding.\n");
+ fprintf(stderr, " -A Enable authentication agent forwarding.\n");
#if defined(KERBEROS_TGT_PASSING) && defined(KRB5)
fprintf(stderr, " -k Disable Kerberos ticket passing.\n");
#endif /* defined(KERBEROS_TGT_PASSING) && defined(KRB5) */
@@ -537,6 +538,10 @@

case 'a':
options.forward_agent = 0;
+ break;
+
+ case 'A':
+ options.forward_agent = 1;
break;

case 'k':

Change the default to the correct (security rule #1: Disable
everything, enable what you need.)

--- readconf.c.orig Wed May 12 13:19:27 1999
+++ readconf.c Sat Nov 6 20:47:49 1999
@@ -716,7 +716,7 @@
void fill_default_options(Options *options)
{
if (options->forward_agent == -1)
- options->forward_agent = 1;
+ options->forward_agent = 0;
if (options->forward_x11 == -1)
options->forward_x11 = 1;
if (options->rhosts_authentication == -1)

On Mon, Jan 03, 2000 at 01:00:11PM +0000, Philip Hands wrote:
> Markus Friedl <markus.friedl@informatik.uni-erlangen.de> writes:
>
> > On Sun, Jan 02, 2000 at 06:15:48AM -0500, David Rankin wrote:
> > > Speaking completely without facts, I am personally skeptical about
> > > enhancing the 1.x protocol when all of the standards processes are
> > > focused on getting 2.0 out the door. That said, I am willing to be
> > > convinced on the matter.
> >
> > i have put the latest revisions of my SSH 1.6 patches to
> > http://wwwcip.informatik.uni-erlangen.de/~msfriedl/openssh/
>
> Quick question. Does this fall foul of this clause in the license:
>
> Any derived versions of this software must be clearly marked as
> such, and if the derived work is incompatible with the protocol
> description in the RFC file, it must be called by a name other than
> "ssh" or "Secure Shell".

IANAL - but in my interpretation, no. It stays compatible; it just
can negotiate higher security.

Eivind.

On Mon, Jan 03, 2000 at 07:30:58PM +1100, Damien Miller wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1

> While I agree that a free version of SSH 2.x is a worthwhile goal,
> it will take _months_ of effort (of course I would be happy to be
> proved wrong on this).

It's probably a 2-4 month job to take OpenSSH 1.2.1 and implement SSH 2.0
start to finish, but it could be significantly less. The main difference
between 1.5 and 2.0 is the change in the transport protocol (and those
aren't that major). All of the encryption changes (DSS/DSA, blowfish, etc.)
are already in OpenSSL, with the exception of twofish.

> We already have a strong SSH 1.x implementation, why not clean up its
> few remaining nits (which may take only weeks)?

Please don't get me wrong. I believe that OpenSSH 1.2.1 needs to be
working now. I just happen to think that extending the SSH 1.5 protocol
should yield to implementing the 2.0 protocol, especially where the 1.6
features are a subset of the 2.0 protocol. Of course IMHO.

> Apart from standards-compliance, what does SSH2 buy you over a cleaned
> up SSH1?

I know it's been mentioned already, but the #1 is you can do PAM
challenge/response authentication correctly. You can also handle
"You must change your password" correctly.

David

--
David W. Rankin, Jr. Husband, Father, and UNIX Sysadmin.
Email: drankin@bohemians.lexington.ky.us Address/Phone Number: Ask me.
"It is no great thing to be humble when you are brought low; but to be humble
when you are praised is a great and rare accomplishment." St. Bernard

On Sun, Jan 02, 2000 at 02:46:49PM -0500, Brian Fundakowski Feldman wrote:
> On Sun, 2 Jan 2000, Markus Friedl wrote:

> > and yes, having openssh speak SSH-2.0 would be nice.
> > mail me if you are interested in helping implement 2.0.

> Of course!

Since it looks like there's a significant interest in this, I propose
that we look at an "OpenSSH 2" project. At this point, we need a mailing
list. I'd love to host the list, but the US laws make that too painful for
me should someone post encryption code.

Once we get someone to make a list, I think we can start working on
the details. No use flooding security@FreeBSD.org or openssh-dev-list
with a lot of off-topic discussion (and can stop the monster CC:... :)

David

--
David W. Rankin, Jr. Husband, Father, and UNIX Sysadmin.
Email: drankin@bohemians.lexington.ky.us Address/Phone Number: Ask me.
"It is no great thing to be humble when you are brought low; but to be humble
when you are praised is a great and rare accomplishment." St. Bernard

I can host one. Please contact me privatedly for details.

Regards!


En un mensaje anterior, David Rankin escribió:
> On Sun, Jan 02, 2000 at 02:46:49PM -0500, Brian Fundakowski Feldman wrote:
> > On Sun, 2 Jan 2000, Markus Friedl wrote:
>
> > > and yes, having openssh speak SSH-2.0 would be nice.
> > > mail me if you are interested in helping implement 2.0.
>
> > Of course!
>
> Since it looks like there's a significant interest in this, I propose
> that we look at an "OpenSSH 2" project. At this point, we need a mailing
> list. I'd love to host the list, but the US laws make that too painful for
> me should someone post encryption code.




Fernando P. Schapachnik
Administración de la red
VIA NET.WORKS ARGENTINA S.A.
fernando@via-net-works.net.ar
(54-11) 4323-3333

Eivind Eklund <eivind@FreeBSD.ORG> writes:

...
> * a default of sending out agent forwarding
> * no way to change the default and still selectively forward
>
> The patches for the latter two problems are trivial; I'm including
> them below for completeness.

I've included this in the Debian packages of ssh and OpenSSH for some
time. I also disable X forwarding by default, since that allows
classic X attacks to be launched by untrustworthy remote systems.

These patches should be accepted upstream IMO.

As ever, my openssh stuff can be found here:

http://www.hands.com/~phil/debian/openssh/openssh_1.2.1pre24-1.diff.gz

I think all changes except the debian/ directory itself should be
either useful or at worst harmless upstream.

Cheers, Phil.
--
Boycott Amazon! --- http://linuxtoday.com/stories/13652.html

David Rankin <drankin@bohemians.lexington.ky.us> writes:

> On Sun, Jan 02, 2000 at 02:46:49PM -0500, Brian Fundakowski Feldman wrote:
> > On Sun, 2 Jan 2000, Markus Friedl wrote:
>
> > > and yes, having openssh speak SSH-2.0 would be nice.
> > > mail me if you are interested in helping implement 2.0.
>
> > Of course!
>
> Since it looks like there's a significant interest in this, I propose
> that we look at an "OpenSSH 2" project. At this point, we need a mailing
> list. I'd love to host the list, but the US laws make that too painful for
> me should someone post encryption code.
>
> Once we get someone to make a list, I think we can start working on
> the details. No use flooding security@FreeBSD.org or openssh-dev-list
> with a lot of off-topic discussion (and can stop the monster CC:... :)

Would it not be better to attempt to get lsh finished off, since that
doesn't have any possible licensing problem related to the
protocol/name thing.

Regardless, there is not a vast amount of point in duplicating
efforts, so this idea should probably be mentioned to the lsh
developers to ensure that the most efficient approach can be taken to
develop one or other of these.

Cheers, Phil.

Is there a reason why we ought not to use openssh-unix-dev? It's
already here, and i suspect most folks on the list would be interested
in an SSH-Protocol-2.0 implementation. I don't particularly think it's
off-topic, either (except for the bit about whether certain folks can
be communicated with effectively).

--
jim knoble
jmknoble@pobox.com

På 2000-Jan-03 klokka 09:27:33 -0500 skrivet David Rankin:

: Since it looks like there's a significant interest in this, I propose
: that we look at an "OpenSSH 2" project. At this point, we need a mailing
: list. I'd love to host the list, but the US laws make that too painful for
: me should someone post encryption code.
:
: Once we get someone to make a list, I think we can start working on
: the details. No use flooding security@FreeBSD.org or openssh-dev-list
: with a lot of off-topic discussion (and can stop the monster CC:... :)

On Mon, Jan 03, 2000 at 03:21:12PM -0500, Jim Knoble wrote:
> Is there a reason why we ought not to use openssh-unix-dev? It's
> already here, and i suspect most folks on the list would be interested
> in an SSH-Protocol-2.0 implementation. I don't particularly think it's
> off-topic, either (except for the bit about whether certain folks can
> be communicated with effectively).

It's Damien's list, so his will be the deciding opinion, but IMHO
openssh-unix-dev isn't the best place for the discussion since it's
for development of the OpenSSH 1.2.1 port. OpenSSH 2.0 is going to be
(at first) a design and organization effort that will interfere with the
"daily business" of OpenSSH 1.2 on a shared list.

Thanks,
David

--
David W. Rankin, Jr. Husband, Father, and UNIX Sysadmin.
Email: drankin@bohemians.lexington.ky.us Address/Phone Number: Ask me.
"It is no great thing to be humble when you are brought low; but to be humble
when you are praised is a great and rare accomplishment." St. Bernard

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 3 Jan 2000, David Rankin wrote:

> It's Damien's list, so his will be the deciding opinion, but IMHO
> openssh-unix-dev isn't the best place for the discussion since it's
> for development of the OpenSSH 1.2.1 port. OpenSSH 2.0 is going to be
> (at first) a design and organization effort that will interfere with the
> "daily business" of OpenSSH 1.2 on a shared list.

I don't mind discussions pertaining to the extension of OpenSSH
to support SSH2. If they become too intrusive then we can move
them to another list.

Regards,
Damien


- --
| "Bombay is 250ms from New York in the new world order" - Alan Cox
| Damien Miller - http://www.mindrot.org/
| Email: djm@mindrot.org (home) -or- djm@ibs.com.au (work)


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE4cSLWormJ9RG1dI8RAgLRAKCB70v1PcF65o5nz5KZYIehwiVe0wCeJGQA
4EftSGVRBa6IBcmVZvPIRdg=
=zxHc
-----END PGP SIGNATURE-----

I hope this is my last mail on this subject. All this discussion
about SSH2 misses the fact that we are talking about a security
product, so 'features' should not be overrated.

Especially for ssh it should be remembered that "complexity is the
enemy". You almost get my SSH1.6 for free. The patches consist
of minor modifications that are supposed to makes SSH1 much more
secure. Compare the code size of OpenSSH (~ 20.000 lines) with the
code size of ssh-2.0.1x (~ 100.000 lines), an incarnation of SSH2.
Do secure protocols leed to secure implementations?

Security is also about trust. SSH1 is old, stable, venerable,
widely used, reviewed and testetd. Thus it consists of trusted
code. Minor modifications, e.g. SSH1.6, should not reduce trust.
But what happens with major modifications, i.e. SSH2? Can you still
trust the code? Or can you trust an entirely new implementation
of a complex protocol?

Wrt 'features': SSH1 has some support for challenge/response
authentication, OpenSSH does s/key within the SSH1 framework.

Wrt OpenSSH 2: I don't think we need a special mailing-list. If
you know of the internals of OpenSSH and/or the SecSH-drafts and
want to help implement SSH2, send private mail to me and I'll share
my code fragements. But it's too soon for publication.

If you want an implementation that does not use the old code: LSH
speaks SSH2.

cheers, -markus

What did you mean about not supporting the "change password" feature?
Were you referring to the passwd fields which expire passwords/accounts?
If so, you should take a look at my FreeBSD OpenSSH port... I've
implemented quite a bit of new stuff, like that, login.conf support,
and a framework (with good, working defaults) for prevention of
connection-based DoS.

--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
green@FreeBSD.org `------------------------------'

I'll condense two different responses into one letter. Also, I have
posted what I'd call a "draft action plan" for an OpenSSH 2.0 project
to http://www.bohemians.lexington.ky.us/~drankin/openssh2.proposal
for anyone interested to examine.

I suggest that we limit further discussion of this thread to
openssh-dev-list.

Thanks,
David

On Mon, Jan 03, 2000 at 07:47:15PM +0000, Philip Hands wrote:
> David Rankin <drankin@bohemians.lexington.ky.us> writes:

> > Once we get someone to make a list, I think we can start working on
> > the details. No use flooding security@FreeBSD.org or openssh-dev-list
> > with a lot of off-topic discussion (and can stop the monster CC:... :)

> Would it not be better to attempt to get lsh finished off, since that
> doesn't have any possible licensing problem related to the
> protocol/name thing.

So long as we maintain compatability with SSH 1.5, I don't think that
there are licensing issues. This should be true even when/if SSH 2.0
support is included.

As for lsh, I like what is already there, but there's a couple of
fundamental design choices that I don't agree with in lsh. They are:
1> Lack of compatability with the SSH 1.5 protocol. This is of course
the biggest issue for me. There are a ton of SSH 1.x implementations
out there.
2> Non-forking server. A select() system is inherantly more complex than
a fork/exec design. I can see a lightweight thread replacement for
fork/exec, but not a monolithic non-forking server.

> Cheers, Phil.

On Mon, Jan 03, 2000 at 11:49:30PM +0100, Markus Friedl wrote:
} I hope this is my last mail on this subject. All this discussion
} about SSH2 misses the fact that we are talking about a security
} product, so 'features' should not be overrated.

} Especially for ssh it should be remembered that "complexity is the
} enemy". You almost get my SSH1.6 for free. The patches consist
} of minor modifications that are supposed to makes SSH1 much more
} secure. Compare the code size of OpenSSH (~ 20.000 lines) with the
} code size of ssh-2.0.1x (~ 100.000 lines), an incarnation of SSH2.
} Do secure protocols leed to secure implementations?

I wasn't aware of how close to completion your SSH 1.6 patches are.
In this case, I think that it'd be a Good Thing(tm) to include them
right after OpenSSH 1.2.1 is ready.

Also, I'm not sure if comparing code lines is fair. OpenSSH + OpenSSL
are more than ~20000 lines, although still not in the 100k range.

That said, your point is valid: SSH 2.0 is more complex, and any SSH 2.0
implementation is also more complex. That means that it's going to be
a while before OpenSSH 1.2 is obsolete. I agree with your SSH 1.6 proposal
as an interim solution, possibly its completion driving OpenSSH 1.3.

Thanks,
David

--
David W. Rankin, Jr. Husband, Father, and UNIX Sysadmin.
Email: drankin@bohemians.lexington.ky.us Address/Phone Number: Ask me.
"It is no great thing to be humble when you are brought low; but to be humble
when you are praised is a great and rare accomplishment." St. Bernard