Subject: Re: des-cbc cipher

From: Darren Moffat <[email-masked]>
Date: Wed, 28 Nov 2001 18:14:41 -0800 (PST)

>DES isn't the issue per se, despite the attempts of you and some 
>to cloud the interoperability issue.  Broad interoperability of

I'm certainly not trying to cloud the issue and I don't think others
are either.  Myself and others are only pointing out that the protocol
already allows for additional algorithms and implementing des-cbc
is certainly possible using that mechanism.  Nothing addtional has
to be added to the drafts to add the functionality.

>any IETF standards-track protocol is crucially important to me.
>That alone justifies documenting how DES-CBC works, even if it is 
>marked as deprecated, optional-to-implement, or what have you.
>(And I don't care if those sorts of recommendations are made,
>provided it is clearly documented in the RFC).

Given the reaction to this on the list I doubt you are going to get
consensus - but I maybe wrong.  I suggest you log a personal submission
that references the relevant sections from the core drafts, you could
then ask if the secsh-wg is willing to take it on as a working group draft.

Since we are trying to get last call on the core drafts it is unfortunate
timing regardless of the issues of appropriateness, but not too late
if you get agreement from the group.

I suggest this be brought up at the SLC IETF meeting as an agenda item.

--
Darren J Moffat

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 29 Nov 2001 02:28:22 +0000

> then ask if the secsh-wg is willing to take it on as a working group draft.

I'd be rather inclined to object to having des-cbc (or des-anything) in
the core specs,  if for no other reason than to reduce the size of the
documents.

I'd certainly have no objection to it being documented in an seperate
informational RFC.

DF

---

From: RJ Atkinson <[email-masked]>
Date: Wed, 28 Nov 2001 21:36:09 -0500

At 21:14 28/11/01, Darren Moffat wrote:
>I'm certainly not trying to cloud the issue 
>and I don't think others are either.  

Darren,

        Kindly put the shoe on the other foot for a moment.
What problem is solved by omitting the DES-CBC information 
from the drafts ?  Are we saving bytes on a disk or what ?

Ran
[email-masked]

---

From: Damien Miller <[email-masked]>
Date: Thu, 29 Nov 2001 13:50:14 +1100 (EST)

> from the drafts ?  Are we saving bytes on a disk or what ?

What benefit is obtained from enshrining a known insecure transform
in the protocol?

-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 22:26:11 -0500

>> from the drafts ?  Are we saving bytes on a disk or what ?

Damian,

        Kindly answer the question posed.  Are we saving bytes ?
Or is your goal to make it impossible for folks to use DES-CBC
because you think you know more than they do about their situation 
and threat environment ?   

        And by the way, all algorithms are insecure.  And the low-cost 
attacks on SSHv2 aren't brute force and don't vary with the algorithm 
in use (try reading Ross Anderson's paper on "Why Cryptosystems Fail" 
if any of this seems confusing).

Ran

---

From: Damien Miller <[email-masked]>
Date: Thu, 29 Nov 2001 14:53:26 +1100 (EST)

>         Kindly answer the question posed.  Are we saving bytes ?

Your question was not posed to me, but since you asked: I would
prefer that we do not make further unnecessary changes to the drafts
at this late stage, especially when such changes are obviously 
controversial.

> because you think you know more than they do about their situation 

The protocol includes an extension mechanism which allows you to 
implement des-cbc for those few cases where it may be appropriate.
There is nothing stopping you, or another interested party from 
agreeing on an implementation and advancing that separately.

>         And by the way, all algorithms are insecure.

Some are even more insecure than others.

> if any of this seems confusing).

If there are feasible attacks against the protocol which require a
similar or lesser order of work than breaking DES, then I'd certainly
like to know about them - please share.

-d

---

From: Markus Friedl <[email-masked]>
Date: Thu, 29 Nov 2001 09:43:41 +0100

> from the drafts ?  Are we saving bytes on a disk or what ?

Adding "des-cbc" to the draft encourages use of DES-CBC.

However, if you need to have DES-CBC, write a document,
use "[email-masked]" and everything will be fine.

-m

---

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

>use "[email-masked]" and everything will be fine.

        Regrettably, that doesn't help at all -- because it doesn't document
how to implement such that one can interoperate with the installed base 
of DES-CBC implementations of SSHv2.  There are multiple such 
implementations and an installed base of users.

        I'd REALLY prefer to resolve this in the WG.  I've tried to
propose several forms of packaging that would both let the technical
detail get documented and also let folks who have passion against
DES-CBC document their issues/concerns/recommendations and also make
it crystal clear that DES-CBC isn't something an implementation is
expected to support.  If we can't resolve this issue here, then an appeal 
is likely -- which will necessarily delay the documents substantially 
(delay being explicitly NOT my objective).  Sigh.

Yours,

Ran
[email-masked]

---

From: Markus Friedl <[email-masked]>
Date: Thu, 29 Nov 2001 16:29:38 +0100

> implementations and an installed base of users.

but these implementations violate the drafts if they
use "des-cbc". they must use "des-cbc@domain".

if i add some cipher to openssh without a "@", will
the working group add the cipher to the drafts?

i don't think so.

> (delay being explicitly NOT my objective).  Sigh.

i don't think it's the job of the WG to add a specification
just because some broken implemenations violate the draft.

the drafts should not try to describe all existing implemenations
and their bugs. or am i missing something?

-m

---

From: Derek Fawcus <[email-masked]>
Date: Thu, 29 Nov 2001 15:29:05 +0000

On Thu, Nov 29, 2001 at 10:14:03AM -0500, RJ Atkinson wrote:
> of DES-CBC implementations of SSHv2.

Is it the name of the protocol that's the issue 'des-cbc' vs
'des-cbc@somthing',  or that you want this in the base docs?

I'd have thougth an Informational RFC (wg owned or not - I'm not bothered)
would have been sufficient.

> There are multiple such implementations and an installed base of users.

Hmm - Is one of them by any chance Cisco routers when using a 'export'
version of crypto code?  i.e. DES instead of 3DES.

DF

---

From: Jeffrey Altman <[email-masked]>
Date: Thu, 29 Nov 2001 10:29:05 -0500

The way this should be handled in the IETF is to publish the
deprecated functionality as a separate Historical RFC.  This
documents the required functionality to provide backward
compatibility and indicates in no uncertain terms that the
functionality should no longer be used.

Isn't this what we agreed should be done for the SSHv1 protocol?

- Jeff

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 29 Nov 2001 10:35:45 -0500

>'des-cbc@somthing',  or that you want this in the base docs?

I think there are multiple issues.  One is that folks appear
to want to outlaw the currently deployed protocol token for
DES-CBC.  A second is that folks want to prohibit documentation
of how DES-CBC is currently used (in a widely deployed context)
with SSHv2.  There might be other issues that I personally
have not yet puzzled out...

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 29 Nov 2001 10:40:05 -0500

At 10:29 29/11/01, Jeffrey Altman wrote:
>deprecated functionality as a separate Historical RFC.  

        The IETF has not traditionally required that.  It would
be one approach.  It would not appear to solve all issues (more
below) in any event.

        Instead, a common IETF approach is to document the deprecated 
capability in an Appendix of the regular documents, clearly marked as 
deprecated or informational (I don't object to the labelling either way), 
so that an implementer trying can easily locate it and then make an 
informed decision about what to do in her/his implementation.

        In any event, it appears (I hope I'm confused and this can
be clarified) that some folks want to make sure the protocol element 
changes -- so that the existing deployed implementations won't be 
interoperable or compliant with the SSHv2 standard (regardless of
how DES-CBC were documented or even not documented).

        Sigh.

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 29 Nov 2001 10:41:59 -0500

>use "des-cbc". they must use "des-cbc@domain".

The IETF traditionally does not change a spec after it is deployed
such that existing implementations are gratuitously made non-compliant.
Am I confused ?  Is this WG trying to make existing deployed SSHv2
implementations non-compliant with its current drafts ?  

Ran
[email-masked]

---

From: "Chris M. Lonvick" <[email-masked]>
Date: Thu, 29 Nov 2001 10:12:07 -0600

>version of crypto code?  i.e. DES instead of 3DES.

No.  Cisco's IOS does not support SSHv2
which is what is being discussed. 
<Apologies to the group for addressing
a vendor specific issue.>

Beyond that, from what I've seen, the 
IETF doesn't respect any political
boundaries with regards to crypto
strengths permitted or denied by any
governing body, nor by any vendor.  
Let's not revisit that argument here.

Regards,
Chris

---

From: Markus Friedl <[email-masked]>
Date: Thu, 29 Nov 2001 17:25:47 +0100

> implementations non-compliant with its current drafts ?  

do you have an old WG draft that has specified "des-cbc" before?
i cannot find one in my archives.

so implementations using "des-cbc" -- i only know of ssh.com's software
and their author says it was accidentially assigned the name "des-cbc"
-- will not interoperate, since there was never any specification.

adding "des-cbc" to the spec does not unbreak these implementations,
it does not make them "compliant".

not adding "des-cbc" does not change them to "non-compliant", since
they have not been "compliant" before.  if some old implementations use
"des-cbc", well, good luck, they might interoperate. adding "des-cbc"
will not change their implemenation.

i really don't understand what all this is about.  if we modify the
drafts every now and then we will never have a _single_ compliant
implemenation since there never will be a SSHv2 standard.

thanks.

---

From: Bill Sommerfeld <[email-masked]>
Date: Thu, 29 Nov 2001 13:08:10 -0500

Ran,

> Is this WG trying to make existing deployed SSHv2 implementations
> non-compliant with its current drafts ?

No.

To the best of my knowledge:

 1) before this discussion started, there was smooth working group
    consensus to avoid weak algorithms in the spec, single-DES included.

 2) i've seen zero interest in actually including des-cbc before this
    point was raised.

 3) The spec has never mentioned des-cbc.  This thread started when
    someone noticed that one implementation chose to use the (never
    officially allocated and thus out-of-spec) des-cbc algorithm name for
    single-DES.

We're behind schedule; building consensus to add des-cbc to the spec
(since I see substantial opposition) will make the documents even
later.

						- Bill

---

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

>-- will not interoperate, since there was never any specification.

There are several actually.  They interoperate using the token "des-cbc"
just fine today.

>they have not been "compliant" before.  

Not so.  The spec didn't strictly prohibit the use of "des-cbc" 
(as different from "des-cbc@domain" all along.  That's the part 
that makes the deployed implementations non-compliant.

>i really don't understand what all this is about.  

Interoperability of deployed SSHv2 clients is the topic;
or at least its my topic...

Ran
[email-masked]

---

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

> There are several actually.  They interoperate using the token "des-cbc"

what implementations?

> that makes the deployed implementations non-compliant.

it's obvious from draft-ietf-secsh-transport-00.txt that the
"alg@domain" notation must be used for "additional algorithms" that are
not "defined in the base protocol":
  
  [...] There are two formats for algorithm
  identifiers:
  
  o  Algorithms defined in the base protocol are simple strings, such as
     "3des-cbc", "sha-1", "hmac-sha", or "zip" (the quotes are not part of
     the name).  Defined algorithms may be mandatory or optional.  All
     interoperable implementations should implement mandatory algorithms
     and offer them as a possibility in key exchanges.  Optional
     algorithms are not crucial for interoperability, but may provide
     better performance or other advantages.  It is up to an
     implementation to decide which of these are supported and which are
     offered in key exchanges by default.
  
  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 may contain any non-
     control characters except at signs and commas.  The part following
     the at sign should be a valid internet domain name for the
     organization defining the name.  It is up to the each organization
     how they manage its locally defined names.
  
  [...]
  
  The following ciphers are currently defined:
  
            none             optional          no encryption
            3des-cbc         mandatory         three-key 3DES in CBC mode
            idea-cbc         optional          IDEA in CBC mode
            arcfour          optional          ARCFOUR stream cipher
            blowfish-cbc     optional          Blowfish in CBC mode
  
  [...]

---

From: [email-masked] (Sami J. Lehtinen)
Date: 29 Nov 2001 22:11:03 +0200

> will not change their implemenation.

How would the implementations be non-compliant, if des-cbc was added?

The text would probably be something like:

The "des-cbc" cipher is DES (Data Encryption Standard) in CBC mode,
with 56 bit keys. The key is represented as 64 bits, with the least
significant bit of every byte used as parity [SCHNEIER]. This is a
block cipher with 8 byte blocks. Note: this algorithm is considered
INSECURE because of small key size.

I really don't have a strong opinion about this; if it were only up to
me, the cipher would be removed from our implementation. But if it
gets added to the spec, our implementation would be conformant in this
respect without me adding compatibility code :)

-- 
[[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: 29 Nov 2001 21:12:06 +0100

> that makes the deployed implementations non-compliant.

People seem to disagree on this point. As far back as I can remember,
all wg drafts have clearly given a list of Official Algorithm Names
(not including des-cbc), and clearly stated that for any algorithm not
on that list, one MUST use a name of the form <algorithm>@<domain>.

Could you please quote the spec that said differently?

Finally, I agree with Bill that the timing of your proposal is highly
sub-optimal.

Regards,
/Niels

---

From: Thor Simon <[email-masked]>
Date: Fri, 30 Nov 2001 06:45:53 -0500

> implementations and an installed base of users.

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