Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
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
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
Adam Back wrote: My arguments that adding broken ciphersuites to an IETF standard was in direct and obvious violation of RFC 1984 fell on deaf ears, as Netscape, microsoft and even openSSL (in the form of Ben Laurie) busily rushed and implemented the proposed broken ciphersuites. OpenSSL has them disabled by default. But I am torn on this question: these new ciphersuites give greater strength than existing ones when interopping with export stuff. Is it sensible to refuse to add stronger ciphersuites? If it isn't, because they are crap, should we (the OpenSSL team) disable _all_ export ciphersuites? I mainly implemented them because they required extensions to the ephemeral RSA key generation (to specify the number of bits), and I wanted to add that long before it was actually needed. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
IMNSHO, 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. The inclusion of weak ciphers in TLS is really just a symptom of a much more severe problem: the IETF is no longer under the control of the geeks. Sound engineering is being replaced by "feel good" politics. 128 times XOR, 128 bit IDEA, who cares how good the tech is. As long as we can tell the customer we are standards compliant. [I know Jeff does not fall into this category. He has done an admirable job. Perhaps nobody can forever hold back the tide of politcial control over engineering]. --Lucky On Fri, 25 Jun 1999, Jeffrey I. Schiller wrote: Actually for the TLS crowd, going to DES is a step up. I presume that the TLS WG is planning to use DES to replace the RC4 40 bit cipher that was used for export compliance. 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" for adding DES or should we require that both be removed before the next TLS document is published as a Proposed or Draft Standard. I would be interested in hearing people's opinions on this (though given the recipient list on this message, I have a pretty good idea what I am likely to hear!). -- Lucky Green [EMAIL PROTECTED] PGP v5 encrypted email preferred.
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
Ben Laurie wrote: OpenSSL has them disabled by default. But I am torn on this question: these new ciphersuites give greater strength than existing ones when interopping with export stuff. Is it sensible to refuse to add stronger ciphersuites? If it isn't, because they are crap, should we (the OpenSSL team) disable _all_ export ciphersuites? Speaking as a user of OpenSSL... Today I can accept RC4-40 connection on my servers from export browsers. For many of my applications, this is a sufficient level of security (I refuse RC4-40 in applications where it is important). As the export browsers migrate to DES, I want to be able to accept them. After all, this would be an improvement. If OpenSSL were to remove support for RC4-40 and DES, I would have to find another solution. Refusing the connections is just not an option from a business perspective. There it is. Now blessing DES and RC4-40 from a standards perspective is another matter. I will have discussions with the TLS Working Group about whether or not it is appropriate to continue to include them in the standard. I know people on this list would probably love to hear me state that I would refuse to approve new versions if they included them. However for me to make such a prejudicial statement is probably not appropriate until I have a chance to have a discussion with the working group itself. You can guess my sympathies! -Jeff
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
Adam Back wrote: 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. There's no indication either way, since the new ciphersuites are a standalone I-D, not a modification to TLS. Cheers, Ben. -- http://www.apache-ssl.org/ben.html "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
RE: NPR story on crypto...
At 06:34 PM 6/24/99 -0400, David Lesher wrote: NPR's ATC has a story at the end of their first segment; i.e. 4:25 Eastern. I missed most of it but it was about some aspect of Osama bin Laden's group being arrested. Mention was made of encrypted files, and the inference that they were cracked. And Vin McLellan replied: Whether the Yeminis and the Western LEAs had already obtained access to the contents of the encrypted files was left unclear, although it was implied. If so, it seems likely that we (or at least selected judges and legislators) will hear a lot about the incident in future debates over Wassenaar and crypto export controls. Yet it appears folks who make this argument won't be able to say the info. remained encrypted despite their best efforts. All of which begs a question: why has the crypto debate been so quiet this year? Perhaps the govt. is nearing its end game. One highly placed LEA source told me he expects crypto liberalization to pass _this year_ -- in all likelihood something like McCain's PROTECT Act which would do away with essentially all controls once the Advanced Encryption Standard is done. That, BTW, is supposed to happen no later than 1/1/2002, the bill says flatly. Of course, Clinton still won't sign it. For years I thought it would be 2005 or later before we saw the end of controls. What's happening now seemed almost impossible just a year ago... My story: http://www.usatoday.com/life/cyber/tech/ctf452.htm Will Rodger USAToday.com
RE: NPR story on crypto...
Nice article in USAToday, Will! You might find it useful to note -- and I'm open for correction on this from anyone -- that the US Government's Bernstein brief is, I believe, the first time the Govt has openly acknowledged that the export control issue is all about sigint -- listening to the legal communications of citizens and officials of other national, allied and friendly. Repeatedly, in the past, the US Govt. has reduced the public policy debate to absurdity by claiming that only by severely limiting the strength of the crypto available to legitimate commercial buyers of American (and Wassenaar) computer and communications technology could the we safeguard children, womenfolk, and the home hearth from blood-thirsty terrorists and ravening pornographers. _Vin At 05:06 PM 6/25/99 -0400, Rodger, William wrote: All of which begs a question: why has the crypto debate been so quiet this year? Perhaps the govt. is nearing its end game. One highly placed LEA source told me he expects crypto liberalization to pass _this year_ -- in all likelihood something like McCain's PROTECT Act which would do away with essentially all controls once the Advanced Encryption Standard is done. That, BTW, is supposed to happen no later than 1/1/2002, the bill says flatly. Of course, Clinton still won't sign it. For years I thought it would be 2005 or later before we saw the end of controls. What's happening now seemed almost impossible just a year ago... My story: http://www.usatoday.com/life/cyber/tech/ctf452.htm Will Rodger USAToday.com "Cryptography is like literacy in the Dark Ages. Infinitely potent, for good and ill... yet basically an intellectual construct, an idea, which by its nature will resist efforts to restrict it to bureaucrats and others who deem only themselves worthy of such Privilege." _A Thinking Man's Creed for Crypto _vbm * Vin McLellan + The Privacy Guild + [EMAIL PROTECTED]* 53 Nichols St., Chelsea, MA 02150 USA 617 884-5548
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
-- At 01:34 PM 6/25/99 -0700, Tom Weinstein wrote: I think your view only makes sense if you are only interested in protecting yourself against entities who have $100,000 (or $50,000, or whatever) to build a DES cracking machine. You assume that most businessmen are confident that all their activities are legal. Most businessmen are not confident of this, and any businessman who is confident of this, is living in a fool's paradise. While 40 bits is doubtless adequate to protect credit card numbers, it is not satisfactory for internal business discussions. Despite your contempt for Netscape and Microsoft, they do, in fact, sell strong crypto products where they are able to. If the CEOs of these companies went to their boards of directors and told them that they were going blow off the entire international market because they didn't want to put export grade crypto into their products, they'd be out of their jobs faster than you could say "stockholder lawsuit." PGP neither crippled its product, nor did it blow off the export market. Instead it vigorously worked around the existing laws. Microsoft has made some effort to get around these laws, but seemed to lose interest. Perhaps Bill Gates was the recipient of a little talk. Netscape does not seem to have made any effort to get around these laws. --digsig James A. Donald 6YeGpsZR+nOTh/cGwvITnSR3TdzclVpR0+pr3YYQdkG te44YTbMzpsZ9qSQVGv80eTNWCC2ZXXEw/VOFIS5 4eeqchga4hvY5eKPXLvLFxKrMWZhwuC88zSQQIZPP
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
"William H. Geiger III" [EMAIL PROTECTED] writes: In [EMAIL PROTECTED], on 06/25/99 at 10:29 AM, "Jeffrey I. Schiller" [EMAIL PROTECTED] said: Single DES, RC4-40, or any other weak crypto has no place in the IETF standards. I though these kind of issues were put to rest during the S/MIME debate. Now I see them rearing their ugly head again. If Netscape Microsoft are allowed to control the standard process, it will not be long before there are no standards but their own. To the extent that these issues were "put to rest during the S/MIME debate" it was in favor of the approach used by TLS. CMS specifies how to do RC2-40, but mandates support for 3DES, exactly as TLS does. -Ekr -- [Eric Rescorla [EMAIL PROTECTED]]
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
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
Re: so why is IETF stilling adding DES to protocols? (Re: It's official... DES is History)
OpenSSL is a library. It should support whatever the standard supports and whatever users and/or authors of the lib desire to be in the lib. That may include broken or null-ciphers. But the user should have to take positive action to get at the broken ciphers. I believe by default, OpenSSL should ship with the weak ciphers disabled. And there should be a clear warning: "Not secure, don't fool yourself, do not use, etc]". Offering ROT-13 in a library you one maintains is one thing. Making broken crypto an Internet security standard is another matter entirely. Doing so is bad engineering, bad for the Internet as a whole, and ultimately worse for security purposes than no crypto at all. (Reader: see other posts on this topic if the last statement doesn't make sense to you). --Lucky On Fri, 25 Jun 1999, Jeffrey I. Schiller wrote: Ben Laurie wrote: OpenSSL has them disabled by default. But I am torn on this question: these new ciphersuites give greater strength than existing ones when interopping with export stuff. Is it sensible to refuse to add stronger ciphersuites? If it isn't, because they are crap, should we (the OpenSSL team) disable _all_ export ciphersuites? Speaking as a user of OpenSSL... Today I can accept RC4-40 connection on my servers from export browsers. -- Lucky Green [EMAIL PROTECTED] PGP v5 encrypted email preferred.
