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

From: Simon Josefsson <[email-masked]>
Date: Tue, 05 Feb 2008 23:19:32 +0100

<[email-masked]> writes:

> For single-DES, it's easy to explain why using it isn't a good 
> idea; for IDEA, I'd like to see some better text than mine...
> Does anyone know about e.g. cryptographic results for IDEA
> (like attacks more efficient than exhaustive key search)?

I believe weak keys is a sign of historical cipher designs, and both DES
and IDEA have weak keys.  A reference for IDEA is:

http://citeseer.ist.psu.edu/daemen93weak.html

I think there are even better results than that paper, but that was one
of the earliest.

One can debate how problematic weak keys are, but I haven't seen anyone
arguing that existence of weak keys improve the security or confidence
in a cipher.

/Simon
_______________________________________________
TLS mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/tls

---

From: <[email-masked]>
Date: Wed, 6 Feb 2008 12:38:44 +0200

Len Sassaman wrote:
> 
> On Tue, 5 Feb 2008 [email-masked] wrote:
> 
> >    IDEA has a 128-bit key, and thus is not vulnerable to exhaustive
> >    key search. However, IDEA has not seen widespread use, 
> >    and has not
> 
> IDEA has been widely used, particularly in disk and email 
> encryption programs.

I stand corrected -- maybe that could be rephrased to "IDEA cipher
suites for TLS have not seen widespread use"?

> >    received as extensive cryptographic analysis as AES and 
> other more
> 
> IDEA has received a much better "test of time" than AES, and many
> attempts at attacking IDEA have taken place over the last few
> decades.
> 
> IDEA's problem is its patent, nothing more.

In earlier discussions, some folks brought up the issue of rarely used
code. Even if IDEA as algorithm is fine, it's not necessarily a good
idea to include code in TLS libraries that is basically never used
(and thus might contain undetected bugs, impacting potentially both
security and interoperability).

> (If you're going to claim otherwise, I think you need to provide
> citations for both of those, or else you'll find a lot of
> disagreement.)

Yes, I agree that we need citations and/or better arguments.

Best regards,
Pasi

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 6 Feb 2008 18:10:22 -0800

>> IDEA has been widely used, particularly in disk and email 

Indeed.

> suites for TLS have not seen widespread use"?

Yes, makes sense.

[...]
>> IDEA's problem is its patent, nothing more.

IDEA's problem also is the 64-bit block length.

With networks getting faster, it is increasingly easier to get
uncomfortably close to the number of blocks where you can no longer
expect full security (around 2^32 blocks, i.e. 32 GB, for CBC
encryption; with a non-neglible probability to have a security failure
well below this limit).

---

From: Mike <[email-masked]>
Date: Wed, 06 Feb 2008 21:53:51 -0800

> encryption; with a non-neglible probability to have a security failure

Can you explain how security weakens after sending 32GB of data?
Is this just for IDEA or for AES and others as well?  In TLS,
can you just renegotiate the security parameters well before
reaching this threshold?

Thanks,

Mike

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 7 Feb 2008 06:02:17 +0000

On Wed, 06 Feb 2008 21:53:51 -0800
Mike <[email-masked]> wrote:

> > encryption; with a non-neglible probability to have a security
> > failure well below this limit).
> 
The problem is the probability of a collision in the ciphertext
blocks.  The blocksize is 64 bits, for DES and IDEA; therefore, it's
collision resistance is O(sqrt(2^64)) or 2^32.  That's why AES has a
128-bit blocksize, to raise that parameter to 2^64 blocks.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
TLS mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/tls

---

From: <[email-masked]>
Date: Fri, 8 Feb 2008 14:16:14 +0200

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

N.  Security Considerations

N.1.  DES Cipher Suites

   DES has an effective key strength of 56 bits, which has been been
   known to be vulnerable to practical brute force attacks for over 20
   years [DH].  A relatively recent 2006 paper by Kumar et al.  [COPA]
   describes a system which performs exhaustive key search in less than
   nine days on average, and costs less than 10,000 USD to build.

   Given these, the single-DES cipher suites SHOULD NOT be implemented
   by TLS libraries.  If a TLS library implements these cipher suites,
   it SHOULD NOT enable them by default.  Experience has also shown that
   rarely used code is a source of security and interoperability
   problems, so existing implementations SHOULD consider removing these
   cipher suites.

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?

Best regards,
Pasi

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Fri, 8 Feb 2008 08:44:37 -0500

> N.1.  DES Cipher Suites

OK regarding DES.

> N.2.  IDEA Cipher Suites

OK regarding IDEA. As for the last paragraph, you definitely want to bring its short block size up. One may mention in one short sentence that in addition to the above, user of IDEA must make sure he acquired the license to use it.
--
Regards,
Uri

---

From: "Bodo Moeller" <[email-masked]>
Date: Fri, 8 Feb 2008 11:27:37 -0800

> (and in worst case, FUD).

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

---

From: Mike <[email-masked]>
Date: Sat, 09 Feb 2008 07:35:32 -0800

> 3DES still is frequently used, for historical

What don't people like about AES?  Is their dislike of it
technically justified, or is it based on personal preference?

Thanks,

Mike

---

From: [email-masked] (Peter Gutmann)
Date: Sun, 10 Feb 2008 15:45:52 +1300

Mike <[email-masked]> writes:

>What don't people like about AES?  Is their dislike of it technically
>justified, or is it based on personal preference?

There's a number of reasons that I've run into:

- Lots of 3DES legacy hardware/software out there.
- Lots of existing 3DES standards/security specs out there.
- It's a long-time banking standard, and banks are very conservative.
- Some false alarms about AES' security a few years ago.
- ...

All of it adds up.  I'm still using 3DES as the default cipher for protecting
private keys from a combination of "no-one ever got fired for specifying 3DES"
(some users will question use of AES over 3DES, but I don't think anyone's
ever questioned 3DES), and because the data amounts being protected are so
small that there's no speed advantage to be had from AES.  OTOH I make it
user-configurable, so it's up to the users.

Peter.

---

From: <[email-masked]>
Date: Mon, 11 Feb 2008 09:23:34 +0200

Uri Blumenthal wrote:

> One may mention in one short sentence that in addition to the above, 
> user of IDEA must make sure he acquired the license to use it.

This is one thing we *cannot* put in the document, as it would be 
an opinion on the validity of the IPR claim (and RFC 3979
Section 11 explicitly prohibits this).

Best regards,
Pasi

---

From: "Bodo Moeller" <[email-masked]>
Date: Mon, 11 Feb 2008 11:21:42 -0800

>  technically justified, or is it based on personal preference?

This is a question I'd like to answer 20 years from now, then putting
hindsight to use ;-)

I guess you could say that some people have a personal preference to
think that their dislike of AES is technically justified.  Take a look
here, for example: http://www.cryptosystem.net/aes/  A rather
confusing page (not even just about AES even though it pretends so at
first sight), but then the author *is* a cryptanalysis expert, so his
concerns probably shouldn't be ignored lightly.

Others have complained about AES because its internal structure is
rather prone to side-channel attacks.

I'm not sure who really would recommend 3DES over AES for reasons like
these, but 3DES certainly appears to be fine as long as you don't have
to handle too large an amount of data (the small block length isn't an
issue then), and it has been around for longer -- so arguably we can
expect fewer cryptanalytic surprises regarding 3DES than regarding
AES.

Bodo