Tom Weinstein writes:
> Adam Back wrote:
> > Jeff Schiller writes:
> >
> > > 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.
>
> I would prefer that the 40 bit ciphersuites remain in the spec but
> be deprecated. However, if the consensus is to remove them, I
> wouldn't object.
But I read what you write to say you want to deprecate them to replace
them with DES, a rather small incremental improvement in the scheme of
things. DES is bust now, people have been arguing it's keys were too
small since it was installed as a FIPS. It'll only get worse. And
for the reasons you yourself give:
> The reality is that they will most likely continue to be supported
> by Netscape and Microsoft for the forseeable future.
once it's installed in an IETF standard and implemented in browsers
and servers it'll be effectively impossible to kill becaues of
backwards compatibility issues.
As Gilmore's cracker shows, DES really ain't that strong even now.
Give it 10 years. The DES ciphersuite will be doomed to haunt us for
many years to come causing untold damage to security, and keeping NSA
in open source SIGINT for years to come.
> > 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)
>
> It would not be outside the bounds of reason to move the weak ciphers to an
> informational RFC. Expunging them altogether would simply introduce the
> possibility for a ciphersuite id collision in the future.
Note I suggested adding broken things to SSL3 as proprietary
extensions, not to TLS. I'd sooner see TLS kept clean of broken
crypto, and have SSL3 gradually phased out.
> > 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.)
>
> Far from being some nefarious plot, it has a lot more to do with
> what they already have implemented.
TLS has a must key exchange algorithm which is *NOT* RSA. You can't
implement TLS without implementing DHE.
RSA is still currently a proprietary technology.
Therefore why go add more ciphersuites based on RSA? What's the
point?
> In light of the forthcoming expiration of the RSA patent, what's the
> big deal?
The problem is that it adds no useful functionality, adds complexity,
violates IETF doctrine about not using proprietary ciphers when
non-proprietary ones are available, and there is no backwards
compatibility argument which could be used to justify it.
> In any case, DHE is already the only required key exchange method.
Right.
> Oh, and in case you didn't notice, I'm no longer with Netscape.
The message of yours I quoted from IETF-TLS was from the time when you
were at netscape, or at least using a netscape address.
Adam
