OpenSSH protocol 1.6 proposal

Markus Friedl markus.friedl at informatik.uni-erlangen.de
Tue Jan 4 09:49:30 EST 2000


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





More information about the openssh-unix-dev mailing list