Re: des-cbc cipher

[nisse%lysator.liu.se@localhost (Niels Möller)]

RJ Atkinson <rja%inet.org@localhost> writes:

> SSHv2 was deployed before the time of the first IETF WG I-D,
> so that isn't really sufficient here.  The WG is supposedly
> standardising the deployed protocol, though perhaps not in fact.
> 
> The need remains and is technically founded in interoperability
> and in not making otherwise conforming implementations non-conforming.

I'm not getting this. I've been involved with an secsh
implementations, and in this wg, since a week or two after
draft-ietf-secsh-transport-04.txt was published 6 August 1998, more
than three years ago. The use of "des-cbc" by SSH Inc. was pointed out
to me in December 1998 (in private mail, or on the psst mailing list,
I don't quite remember how or by whome). I regarded it as yet another
deviation from the protocol, and I didn't think much about it. All
other similar "implementing-before-the-spec" bugs in SSH Inc's
implementation that I can remember have been fixed sooner or later, I
don't think this one is any special. [1]

And in all that time, "des-cbc" has never ever been allowed by any
draft spec, and noone have ever proposed it on this mailing list. I
don't understand why its suddenly so important *today*. After more
than three years?!

>From a pragmatic point of view, I don't see a problem either.
Implementations that currently uses "des-cbc" will continue to do so
for a few years, for backwards compatibility. The proper name
"des-cbc%ssh.com@localhost" will be added in the next release of each of the
involved implementations. Breaking the spec in this regard won't cause
any practical problems.

That said, I think des-cbc should be abandoned (cpu-constrained
devices are better off with arcfour or blowfish (which have both been
in the spec for a long time) or aes or something. I would consider
its introduction in the spec as a wart.

But it would be a benign wart that I could ignore with no trouble. I
don't want to fight against it to the extent that the standardization
process is delayed even more.

/Niels

[1] Actually, at one time the specified format used for dss signatures
    *was* changed to match SSH Inc's implementation. That's the only time
    the spec has adapted to that particular implementation, and I didn't
    quite like that either.