Re: des-cbc cipher

[Thor Simon <tls%cs.stevens-tech.edu@localhost>]

On Fri, Nov 30, 2001 at 11:01:20AM -0500, RJ Atkinson wrote:
> At 06:45 30/11/01, Thor Simon wrote:
> >It's the plain fault of the folks who chose to name their DES-CBC
> >implementation "des-cbc" instead of "des-cbc%ssh.com@localhost" that this situation
> >exists.  Why should we break the standard just for them?  Should we do so
> >in the future any time an implementation that's widely used violates any
> >detail of any standard?
> 
> Thor,
> 
>         Those implementations PRE-DATE the first draft spec.  So 
> they can't be blamed now for following a draft that DIDN'T EXIST
> at the time it was coded up.  The history is relevant here -- ugly
> to be sure, but highly relevant.

As has been repeatedly pointed out, the implementations that existed
when the draft first appeared (and did *not* include the des-cbc cipher)
were of a different, if ancestral protocol; they would quite simply not
interoperate with an implementation of the protocol described by this
year's (or last year's!) drafts.

The people who maintain those implementations are parties to this process;
they had their chance to fix their implementation long ago; they didn't
(accidentally, it seems).  Nonetheless, why bend the protocol to suit
their implementation?  Would you suggest that we document or even require
every *other* rejected protocol feature that those implementations support
(or once supported) just to avoid causing them inconvenience?  That seems
wrong, particularly (and maybe this is just my personal bias showing, but I
have a *big* smoking hole in my pocket here...) given the lengths some
of those implementors went to to cause trouble for other implementors of
the protocol, for which so far as I know none of us have received so 
much as a simple apology.  Heck, so far as I know, they *still* might
slap me with a specious lawsuit next week!  Why should the other participants
in this group, pretty much all of whom are in the same situation, and some
of whom maintain an implementation that's freely available and *wildly* more
popular than the noncompliant ones in question, pretend there's consensus
to include des-cbc in the protocol when there's clearly not?  There is no
compelling technical reason; and unfortunately for your position, I suspect 
that even if they are not undiplomatic enough to say so, many others in 
this group feel as I do: the people who would most benefit from this are not 
people to whom we are prone to do any favors.

Thor