Subject: des-cbc cipher

From: Simon Tatham <[email-masked]>
Date: Wed, 21 Nov 2001 20:55:25 +0000

Looking at ssh.com's SSH-3.0.1, it appears that it supports
single-DES encryption under the identifier "des-cbc".

I don't see this listed as an approved name in the latest transport
draft. Is it an approved name, or has ssh.com unilaterally added it
and failed to put a domain on the end?

Cheers,
Simon
-- 
Simon Tatham         "My heart bleeds.
<[email-masked]>    (That's how it works.)"   -- Gareth Taylor

---

From: [email-masked] (Sami J. Lehtinen)
Date: 22 Nov 2001 01:16:43 +0200

> and failed to put a domain on the end?

Shall we say, a misfeature. It is not in the transport draft (nor
should it).

DES is supported for marketroid reasons (some people actually really
want to use it, even with advice for the contrary), and it not having a
"@ssh.com" ending is a bug. Which will also be present in 3.1.0,
unfortunately.

This shouldn't have any adverse affect on interoperability, as other
implementations will just ignore it as not supported (or do you
specifically look for algorithms that are not in the spec, and
disconnect in disgust?).

-- 
[[email-masked]          --  Sami J. Lehtinen  --           [email-masked]]
[work:+358 20 5007425][gsm:+358 40 864 3001][http://www.iki.fi/~sjl]
[SSH Communications Security Corp               http://www.ssh.com/]

---

From: [email-masked] (Niels Möller)
Date: 22 Nov 2001 09:55:53 +0100

> specifically look for algorithms that are not in the spec, and

At least I simply ignore it. I only check that the _length_ of the
name is allowed. Next I look it up in my list of known names. Unknown
names are ignored, with no further syntax checks of any kind.

I think this is the right way to behave. New algorithms could be added
to the spec (like aes was not long ago), even if I hope noone will
ever propose adding plain single-des.

/Niels

---

From: Simon Tatham <[email-masked]>
Date: Thu, 22 Nov 2001 09:34:52 +0000

> specifically look for algorithms that are not in the spec, and

*grin* no, I'm not _that_ pedantic. In fact I've just added support
for it to PuTTY, because a user claimed to have some weird kind of
router with an SSH server that supported no other ciphers at all. By
default PuTTY will give a warning about the low security level.

I agree it's not a major namespace problem - I can't easily imagine
anyone inventing another cipher called DES which needs the same
name! And I can't imagine single-DES being standardised, if it's
ever standardised at all, in a way that's different from the way
you've done it.

Just checking, really. If I'm in violation of a spec I like to at
least know about it.

Cheers,
Simon
-- 
Simon Tatham         These are my opinions. There are many
<[email-masked]>   like them but these ones are mine.

---

From: [email-masked] (Sami J. Lehtinen)
Date: 22 Nov 2001 15:53:22 +0200

> Just checking, really. If I'm in violation of a spec I like to at

And I thank you for that.

Cheers,

---

From: Bill Sommerfeld <[email-masked]>
Date: Wed, 28 Nov 2001 17:50:48 -0500

On this issue, it looks like we have consensus that:

  - there should be no mention of a des-cbc algorithm in the spec.

  - implementations should treat algorithms they don't know about the
same as they treat algorithms they've been told not to use.

						- Bill

[I'm somewhat bemused by this because I distinctly remember seeing a
certain ssh implementor standing up in front of an IETF WG meeting a
few years ago saying that ssh-the-program would never support weak
crypto]

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 28 Nov 2001 19:46:23 -0500

>same as they treat algorithms they've been told not to use.

Pardon ?

I haven't seen this thread in some while.  I really disagree with the
first conclusion.  DES-CBC is widely deployed with SSHv2 right now,
so it ought to be mentioned.  That way a new implementer has a good 
chance of interoperating with the installed base.  Paranoid folks should 
kindly note well that I'm not saying ANYTHING about what should be the 
recommended or default algorithm used with SSHv2.

Yours,

Ran
[email-masked]

---

From: Damien Miller <[email-masked]>
Date: Thu, 29 Nov 2001 12:07:23 +1100 (EST)

On Wed, 28 Nov 2001, RJ Atkinson wrote:

> chance of interoperating with the installed base. 

They will interop just fine if they follow Bill's second point and 
ignore des-cbc.

-d

-- 
| By convention there is color,       \\ Damien Miller <[email-masked]>
| By convention sweetness, By convention bitterness, \\ www.mindrot.org
| But in reality there are atoms and space - Democritus (c. 400 BCE)

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 28 Nov 2001 20:39:35 -0500

>They will interop just fine if they follow Bill's second point and 

Not accurate.  They won't be able to talk with remote end systems that
want to talk des-cbc, which is the definition of interoperability that
matters here.

Ran

---

From: [email-masked] (Niels Möller)
Date: 29 Nov 2001 18:00:02 +0100

RJ Atkinson <[email-masked]> writes:

> so it ought to be mentioned.

As far as I understand, the fact that SSH Inc's implementation use the
name "des-cbc", rather than "[email-masked]", is an accidental bug
that'll be fixed in the their next release.

Even if I don't think it's totally outrageous to document "des-cbc" to
the spec, as long as its use is discouraged, there are a lot of other
bugs in various versions of ssh implementations, including SSH Inc's,
that does a lot more damage to interoperation than this one. I don't
see why it is necessary or desirable to change the spec to match this
particular bug.

If you (or anybody else) really needs des-cbc, write up a document
that defines "[email-masked]" or "[email-masked]", and if you like,
add a paragraph on bug compatibility that mentions that some existing
implementations use the name "des-cbc" for the same thing.

Would that solve the problem? To me, des-cbc seems like a specialized
algorithm, useful only under very specialized circumstances (like if
you're trying to export boxes from certain countries, or have
customers that for some peculiar reason *insists* on using plain des),
and therefore it makes sense to specify it independently from the core
drafts.

[ Furthermore, I'd expect that in any real SSH communication where
  des-cbc is used, at least one of the end-points doesn't support
  3des-cbc, and is thus not complying with the spec. That makes the
  issue look even more like a question of bug-compatibility. ]

/Niels

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 29 Nov 2001 14:39:42 -0500

>implementations use the name "des-cbc" for the same thing.

What's needed is to document that using "des-cbc" (not "des-cbc@domain")
is permitted, but not required of anyone, and that using that token
(not the "des-cbc@domain" token) for that purpose does not make an
existing implementation non-compliant with the standards.

>  issue look even more like a question of bug-compatibility. ]

No.  One might choose not to use 3DES even if it were available,
for example because the time to break DES-CBC is longer than the
information being protected is valuable (e.g. real-time stock quotes)
or because one's client/server is a tiny device with small CPU
where the computational expense is not justified for the value 
of the data being protected.

Ran
[email-masked]

---

From: Markus Friedl <[email-masked]>
Date: Thu, 29 Nov 2001 21:02:24 +0100

> existing implementation non-compliant with the standards.

no, "des-cbc" was never permitted, i checked:
	draft-ietf-secsh-transport-00.txt
	draft-ietf-secsh-transport-01.txt
	draft-ietf-secsh-transport-02.txt
	draft-ietf-secsh-transport-03.txt
	draft-ietf-secsh-transport-04.txt
	draft-ietf-secsh-transport-05.txt
	draft-ietf-secsh-transport-06.txt
	draft-ietf-secsh-transport-07.txt
	draft-ietf-secsh-transport-08.txt
	draft-ietf-secsh-transport-09.txt
	draft-ietf-secsh-transport-10.txt
	draft-ietf-secsh-transport-11.txt

-m

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 29 Nov 2001 15:09:56 -0500

>no, "des-cbc" was never permitted, i checked:

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.

Ran

---

From: Markus Friedl <[email-masked]>
Date: Thu, 29 Nov 2001 21:40:13 +0100

On Thu, Nov 29, 2001 at 03:09:56PM -0500, RJ Atkinson wrote:
> so that isn't really sufficient here.

hm, draft-ietf-secsh-transport-00.txt is from March 22, 1997
and does not even define the current key-exchange.

the protocol described in the draft-ietf-secsh-transport-00.txt
is very very different from the current SSHv2 spec.

so i doubt that a 1997 implemenation, that only speaks
"double-encrypting-sha" should be considered in this WG.

  "Currently, the following key exchange methods have been defined:

            double-encrypting-sha        mandatory

   The implementation of these methods is described later in this section."

> The WG is supposedly

the WG cannot, see below.

> and in not making otherwise conforming implementations non-conforming.

have you ever realized that many deployed implementations of SSHv2 are
violating the current specs?  this because the specs have changed.

* there are several implementations that use a different encoding
  of the session id during authentication.

  these implementations are non-conforming to the current drafts.

* there are several implementations that use a different encoding
  of the data that will be signed during authentication.

  these implementations are non-conforming to the current drafts.

* the encoding for SSH_MSG_CHANNEL_OPEN_FAILURE has changed.

  so there are yet more implentations that are not conforming to the
  current drafts.

delaying the last call will only leed to more non-conforming
implementations.

should the WG add all these 'bugs' to the specs, just to make existing
implementations conforming?

-m

---

From: [email-masked] (Niels Möller)
Date: 29 Nov 2001 22:24:08 +0100

> 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
"[email-masked]" 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.