On Tue, 7 Dec 2004 09:32:52 +0100 Jan-Peter Koopmann <Jan-Peter.Koopmann@???> wrote:
> >>> very good reputation, so I'd choose AES128, 3DES,
> >>> ARCFOUR128 and ARCFOUR40, in this order.
> >
> >> I second this!
> >
> > i won't second it because it's not strong enough.
> >
> > RC4 is not even obsolescent, it's obsolete. the barn door has
> > been open on that one for a long long time.
> Agreed. So if the two clients cannot negotiate on AES128 or 3DES
> you would rather have them communicate without any encryption
> just because RC4 has been cracked? If you choose to allow
> AES128/3DES only that is your decision to make. We are talking
> about the default ciphers here and to teach the components to favour
> AES128/3DES over ARCFOUR. I see no harm in that.
the harm (to the extent that there is harm, and i would concur with the
idea that it is a small harm) comes not from informed individuals making
well considered decisions, but from less-well-informed individuals who
are under the mistaken impression that RC4 is any good at all. these
are the same ones who barely understand the important differences
between what GPG/PGP and S/MIME do, and what SMTP-over-TLS
does.
i've just spent too much time in places with lots of PHBs and third
rate sysadmins ("cryptography, that's supposed to be good stuff,
right? we should get us some of that.") to believe that a lot of decision
making is well informed, particularly with more complex network
engineering issues.
having said that, RC4 is still enabled on my server, with lower
priority. it's been a while since i did any crude stats on what
ciphers were being selected, but the last time i did it, i was
pretty dismayed that RC4 was selected for close to 1/2 of the
SMTP/TLS sessions.
richard
--
Richard Welty rwelty@???
Averill Park Networking 518-573-7592
Java, PHP, PostgreSQL, Unix, Linux, IP Network Engineering, Security
