Key Pair Conversion Openssh => SSH2

[Dan Kaminsky]

> i do realize that openssh was around long before the secsh draft, and as i
> said in the last thread i don't really know which key format is better, it
> seems to me they both have their benefits. i raised this issue again only
> because it seems that not a week goes by without someone posting a
question
> about key formats... people are obviously confused about this. and just to
> agree with your next point, yes, people are confused about a lot of
things,
> but when the confusion is caused by not following a standard then that's
> something that can be fixed with out the user needing a lobotomy.
>
> i'm really not trying to bash anyone here, i do appreciate the work done
by
> the openbsd team, but since it is the open source community that is
> continually harassing and belittling corporations for not following open
> standards i really think that the open source community should make
> following standards the number two priority, before functionality, before
> performance and before portability... i'll give you that security should
> come first.

The short version:

Our standard came first, their standard is one broken thing from a series of
broken things,

===

I'll be the first to admit that there are interesting conclusions that can
be drawn from the typology of "conspicuous outrage" directed towards actions
of the "weak" vs. actions of the "powerful", but I do not believe anyone
will be guilted into supporting a questionable format from a questionable
design process anytime soon.  To be honest, standards always fall back to
the status quo, and OpenSSH implemented the SSH Key Management Status Quo,
prior to the unfortunate (but undeniable) fiasco of the SSH2 Non-Deployment.

It just ain't a Standard if nobody will deploy it.  A little history:

Ssh.com's attempt to migrate the market to SSH2 could sadly be studied as a
step by step guide to bungling a migration.
--New clients couldn't connect to old servers
--Old clients couldn't connect to new servers
--A massive crackdown on open licensing was instituted
--The protocol was new, complex, unfamiliar, and untrusted
--Configuration was quite different
--Complete misrepresentations were made about how SSH2 differed (the "it
offers on a completely different level of the packet", perhaps a reference
to the as-of-yet-still-unimplemented optional MAC header, but utterly false
beyond that)
--No new features to justify the pain, except perhaps at the cryptographic
layer.  (OK, channels could command forward now, and the crypto *really was*
fixed.  But that's about it.)

All this, all at once, now throw in broken key management, and that's What
Went Wrong.  Ahh, but why broken?

The belief was that appropriating the file system would make update
processes far more elegant; you'd simply use standard file tools to
manipulate your keyspace.  In theory, moderately elegant.  In practice,
though...well, a one megabyte hosts file is quite manageable; one thousand
individual host files are not.  Updating a mesh of the former requires one
thousand transfer operations; updating a mesh of the latter requires one
*million*.  Which do you prefer?

Now, we could arguably adopt the SSH2 key format and then retain
one-file-many-keys storage semantics, but then there'd be *three* standards
for key management.  What's the user to expect?  The user really shouldn't
have to care.

In my opinion, it's pretty clear that SSH requires a protocol standard for
exchanging keys to be used for future authentications.  It's quite
ridiculous to have to know the exact file semantics necessary to cause the
remote server to allow future logins using a given key, for the same reason
it'd be absolutely ridiculous to have to manually copy
/etc/ssh/ssh_host_rsa_key.pub into the local known_hosts representation.  We
can simplify the process somewhat -- an escape sequence that emits the
pubkey that *should* have authenticated that session into whatever text
editor is listening on the remote side would eliminate some of the need for
tar/scp hacks -- but in all honesty, until there's something better on the
wire, I don't see the very real problem you complain about (pubkey
management is needlessly annoying) going away.

Key formats need to be handled by the clients maintaining the key.  If the
remote side wants to throw their keys in a MySQL database, my client
shouldn't have to understand remote SQL invocation.  If the remote side
wants all keys encoded in complete bit expanded form, one bit per line, my
client shouldn't have to care.  File formats for individual keys are
actually quite important -- and indeed, a single format that can be run
through a command like "ssh-key-import" will be of some use.  But the fact
that individual key transfer and integration of that key into an
authentication database are quite conflated means that simply syncing to
SSH2 is leaving the core problem unsolved -- we're still forcing the client
to care about how the server will store a key.

Yours Truly,

    Dan Kaminsky
    DoxPara Research
    http://www.doxpara.com