Subject: Re: des-cbc cipher

From: Thor Simon <[email-masked]>
Date: Sun, 2 Dec 2001 01:54:54 -0500

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

---

From: Bill Sommerfeld <[email-masked]>
Date: Mon, 03 Dec 2001 14:30:45 -0500

> were of a different, if ancestral protocol...

So, this being "ancestral", seems like it would be appropriate to list
them (in the IANA registry once it exists) as Historic.

Ran pointed out to me that a strict reading of the spec as it stands
now would be that interoperable implementations otherwise compliant to
the spec become non-compliant simply because they offer to use
"des-cbc" as a crypto algorithm in addition to (for example) 3des.

This strikes me as unnecessarily harsh, in particular because the
language in the architecture draft stating that un-@-qualified ssh
protocol names are assigned soley by IETF consensus is significantly
more recent than the current generation of the protocol (to my
knowledge, it was first discussed in detail around the time of the San
Diego ietf about a year ago).

Before that text was added to the draft, the use of non-@-qualified
names was designated as "assigned by IANA"; this turns out to have
very little meaning -- as IANA requires guidance from the IETF in how
to do these assignments, and no such registry exists (and it won't
exist until our documents get to the IESG).  So it strikes me as
unnecessarily restrictive to attempt to exert retroactive control
here.

Anyhow, RFC2026 says about the "historic" designation:

   A specification that has been superseded by a more recent
   specification or is for any other reason considered to be obsolete
   is assigned to the "Historic" level.

This seems to fit the situation closely; also, according to Jeff
Schiller, it is possible for RFC's to be "born historic".

What does this mean for the specs:

 - No change is necessary to the core protocol drafts.

 - The working group needs to allocate "des-cbc" as historic
   (deprecated) and/or Not Recommended

 - an additional working group document (which I believe Ran has
volunteered to write) would designate des-cbc as historic and
deprecated, and would be intended for publication as a Historic RFC.

					- Bill

---

From: [email-masked] (Niels Möller)
Date: 03 Dec 2001 22:03:47 +0100

> unnecessarily restrictive to attempt to exert retroactive control

I don't want to object to your proposed resolution for this issue, but
I want to point out that even if the IANA considerations section of
older drafts was quite vague, I think the algorithm naming section
makes it pretty clear. My reading of that is all valid names are
defined either

* directly in in the spec (these names will turn up in the initial
  IANA approved list whenever the IANA registration process is
  opened), or

* by IANA registration (and this set of names have so far always been
  empty as no registration process have ever been started), or

* by using the @-form.

From draft-ietf-secsh-architecture-02.txt, section 5 (the oldest
architecture draft I have around):

: There are two formats for algorithm names:
: 
: o  Names that do not contain an at-sign (@) are reserved to be assigned
:    by IANA (Internet Assigned Numbers Authority).  Examples include
:    `3des-cbc', `sha-1', `hmac-sha1', and `zlib' (the quotes are not part
:    of the name).  Additional names of this format may be registered with
:    IANA; see Section ``IANA Considerations''.  Names of this format MUST
:    NOT be used without first registering with IANA.  Registered names
:    MUST NOT contain an at-sign (@) or a comma (,).
: 
: o  Anyone can define additional algorithms by using names in the format
:    name@domainname, e.g. "[email-masked]". The format of the part
:    preceding the at sign is not specified; it MUST consist of US-ASCII
:    characters except at-sign and comma. The part following the at-sign
:    MUST be a valid fully qualified internet domain name [RFC-1034]
:    controlled by the person or organization defining the name. It is up
:    to each domain how it manages its local namespace.

If anyone can explain how to read that as allowing the unregistered
name `des-cbc', please mail me privately, I hope we need not discuss
that anymore on this list.

Regards,
/Niels