Jeff Schiller writes:
> Actually for the TLS crowd, going to DES is a step up.
It is a step up -- right now, of sorts. But in 10 years time it will
look like a step up from ROT-13 to ROT-n (where you have to guess n).
Lucky is right on the money, as usual:
> DES or RC4-40 have no business being in any IETF standard. If that
> means there won't be an IETF standard, fine. And if that means that
> deployment of a known insecure technology will be slowed due to lack
> of standatization, better still. Considering the alternative, a
> "security" architecture designed to be be weak that will remain
> around for backwards capability for decades, no TLS today wold be
> much better for the future of the Internet than TLS with DES.
As Lucky says, DES and RC4-40 aren't secure. I agree too with Lucky
that it would be far better to not include DES in IETF standards even
if this reduced the value of the standards to microsoft et al -- if
for example netscape and microsoft were made to add political
ciphersuites such as DES to TLS under the extension mechanism that
would be a better outcome.
> I presume that the TLS WG is planning to use DES to replace the RC4
> 40 bit cipher that was used for export compliance.
I saw no indication that this was the case, though this sounds better
than just adding DES and leaving all the 40 bit ciphersuites intact
which looks like what the current plan is by my reading.
> Normally we would not profile a weak cipher for use in export
> applications. We made an exception for TLS/SSL because it was
> already widely deployed and it didn't make sense to have this battle
> (the export control vs. strong security) hold up the standardization
> process for it.
> An interesting issue here is should we remove RC4 40 from TLS as a "price"
I suggest removing RC4-40 which is a joke as a cipher immediately
(it is getting closer to ROT-13 equivalence by the day).
A better general approach in my view is to have nothing but strong
ciphersuites in TLS. Folks who want weak ciphersuites can do so using
SSL3, and by adding marginally less weak ciphersuites to SSL3 (eg DES
ciphersuites)
As another point of order, the TLS list crowd seems to want to
propogate proprietary standards in the form of RSA also, as two of the
5 propose ciphersuites use RSA. I see no reason to use RSA as
non-patented alternatives exist (DHE, EDH), and there are no backwards
compatibility issues. (Previous complaints of this also fell on deaf
ears in TLS list. Tactic for dealing with complaints is silence --
netscape and micrsoft are not interested in WG input that does not
match their ideas.)
The ciphersuites proposed on the TLS list, by Microsoft, seconded by
netscape's Tom Weinstein:
Tom Weinstein wrote recently on ietf-tls list:
: John Banes <[EMAIL PROTECTED]> wrote:
: > CipherSuite TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA = { 0x00,0x62 };
: > CipherSuite TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA = { 0x00,0x63 };
: > CipherSuite TLS_RSA_EXPORT1024_WITH_RC4_56_SHA = { 0x00,0x64 };
: >
: > I'm not so sure about supporting the DHE/RC4 cipher suites, but if there's
: > some demand, I don't have a problem adding these to the specification.
: >
: > CipherSuite TLS_DHE_DSS_EXPORT1024_WITH_RC4_56_SHA = { 0x00,0x65 };
: > CipherSuite TLS_DHE_DSS_WITH_RC4_128_SHA = { 0x00,0x66 };
: >
: > How's this sound?
Adam
