Re: des-cbc cipher

[RJ Atkinson <rja%inet.org@localhost>]

At 20:52 28/11/01, Darren Moffat wrote:
>>At 20:07 28/11/01, Damien Miller wrote:
>>>They will interop just fine if they follow Bill's second point and 
>>>ignore des-cbc.
>>
>>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.
>
>Since 3DES-CBC is the MANDATORY algorithm all implementations that
>comply with the spec will have it, therefore it is an admin choice to
>disable 3DES-CBC in favour of DES-CBC thus the admin should only do this
>if they know that all connecting clients will provide the weak DES-CBC
>method.

You are trying to decide someone else's policy for them.  Policy
requirements on operators are outside the scope of the IETF.  Not
appropriate for this list or another IETF list.  Recommendations
to operators are fine and normal (e.g. "don't use DES because
...") but levying policy requirements on network operators aren't fine 
or normal in the IETF since we just define protocols here.  

>To my knowlege only SSH Inc code supplies DES-CBC, and I don't believe
>all of their engineers agree with doing so.
>
>Why is DES-CBC so important to you ?

DES isn't the issue per se, despite the attempts of you and some 
to cloud the interoperability issue.  Broad interoperability of
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).

Ran
rja%inet.org@localhost