Re: des-cbc cipher

[Markus Friedl <markus%openbsd.org@localhost>]

On Thu, Nov 29, 2001 at 03:09:56PM -0500, RJ Atkinson wrote:
> >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.

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
> standardising the deployed protocol, though perhaps not in fact.

the WG cannot, see below.

> The need remains and is technically founded in interoperability
> 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