Re: [TLS] Proposed text for IDEA/DES document

["Bodo Moeller" <bmoeller at acm.org>]

On Feb 8, 2008 4:16 AM,  <Pasi.Eronen at nokia.com> wrote:

> Here's an update to the text proposal, incorporating many of
> the comments received so far:

> N.2.  IDEA Cipher Suites
>
>    IDEA has a 128-bit key, and thus is not vulnerable to exhaustive key
>    search.  However, IDEA cipher suites for TLS have not seen widespread
>    use: most implementations either do not support them, do not enable
>    them by default, or do not negotiate them when other algorithms (such
>    as AES, 3DES, or RC4) are available.
>
>    Experience has shown that rarely used code is a source of security
>    and interoperability problems; given this, the IDEA cipher suites
>    SHOULD NOT be implemented by TLS libraries, and SHOULD be removed
>    from existing implementations.  If a TLS library implements these
>    cipher suites, it SHOULD NOT enable them by default.
>
>    (To be determined: should we include text speculating why IDEA has
>    been rarely used, including e.g. reasons mentioned on the list so
>    far?  This would include at least IPR, performance in software, short
>    block size, and lack of government approval in many countries.)
>
> The last paragraph of IDEA text obviously needs work (if we choose
> to include some of those reasons), and we need to be careful to
> distinguish facts (where everyone agrees) and personal opinions
> (and in worst case, FUD).
>
> Comments?

Mentioning the IPR issues can't hurt, but I don't think that any of
that justifies the "should not enable by default" verdict.  I am not
aware of any IDEA-related interoperability or security problems in TLS
in practice: exchanging the block cipher to be used in CBC mode is
simple enough, and even if the specific TLS ciphersuite may not have
been tested a lot, we are talking about IDEA implementations some of
which have been used to implement IDEA encryption with PGP data
formats, successfully demonstrating interoperability at least in this
context.  (And of course with the TLS ciphersuite negotation
mechanism, there are no grounds to deprecate anything just because it
is not used much.  A simple note amounting to "you might not want to
bother implementing these" would do.)

If we were worried about untested code, it's probably the DSA
ciphersuites that we should disallow -- these are much easier to get
dangerously wrong if you have managed to get right your implementation
of, say, TLS_RSA_WITH_3DES_EDE_CBC_SHA!  (Not that I am actually
recommending getting rid of DSA, mind you!)

The reasons to deprecate IDEA ciphersuites in TLS are

1. it's block size is small, with unpleasant security implications, and

2. it won't be missed a lot.

This is what should be covered by the rationale for deprecating the
ciphersuites.

Note that reason #1 similarly applies to all the 3DES ciphersuites as
well.  I think we should note this in the document!  The only reason
that we are keeping 3DES ciphersuites (for now) is that reason #2 does
not apply to them -- 3DES still is frequently used, for historical
reasons on the one hand, and probably because not everyone likes AES
all that much on the other hand.

Bodo
_______________________________________________
TLS mailing list
TLS at ietf.org
http://www.ietf.org/mailman/listinfo/tls