|
||
|
5 October 2011. Add ianG comment. Another view ("locked in ones own OODA loop"): http://yorkporc.wordpress.com/2011/10/04/a-rant-on-cryptome/ 4 October 2011. Add Ben Laurie comment. Add Bodo Moeller and Marsh Ray exchange. 3 October 2011. Add Marsh Ray and Jon Callas exchange. Add Steve Bellovin and James Donald comments. 3 October 2011 SSL Was Broken by Design
Date: Sat, 01 Oct 2011 08:11:15 -0400 On 9/20/11 12:51 PM, ianG wrote: > On 20/09/11 01:53 AM, Andy Steingruebl wrote:>> SSH doesn't solve phishing either. Is it a total failure also? I don't think so. SSL is used for a lot more than HTTPS. Any proposal to "fix" it *must* take that into account. - Andy Actually, SSH faced a lot of the same political pressures as SSL. SSH didn't cave! Instead, they carefully did all the work by non-US persons outside the US -- even though that meant some foreign developers of OpenSSH had to drive across the US border into Canada. Meanwhile, back when Netscape was located near the Stanford campus (an easy walk from the computing center), Paul Mockapetris got me to visit. I sat down with Taher Elgamal and others, explaining what we were doing with Photuris. To the best of my memory, we thought it would be better to: 1) Authenticate the list of supported methods/transforms. We did that in Photuris to avoid MITM attackers choosing the lowest common denominator. And not only the parameters, but the length fields of the parameters, too. [Phil] Karn had insisted on cheap Photuris renegotiation from the start, and that requires protection against substitution. 2) Hide the certificates/users. We called that "party privacy protection". We used the initial D-H exchange to create a temporary stream key, and "masked" the data with the stream (simply an MD5 hash). 3) Require Perfect Forward Secrecy. We'd not managed to get IPsec to do that. It was a big argument at the time. Even today, not all TLS suites provide PFS. 4) Authenticate outside of encryption, so we could quickly and cheaply check before doing a more computationally intensive decryption. We managed to force that into IPsec, and hoped to get Netscape to do the same for SSL (now TLS). IIRC, that's since been proven to be more secure, but we didn't know it at the time. We were mostly interested in practicality. So how was it that Netscape SSL had exactly the same faults as IPsec, ISAKMP, Oakley, IKE? Political pressure! Somebody really REALLY wanted to be able track users and intercept/substitute.... Do I have proof? No, it's merely circumstantial. Also, my multi-year FBI personal investigation over PPP CHAP was coincidental, too. Netscape caved, for their commercial interests. There was also the CA business model. User's own interests took last place. So, arguing about ease of use is a waste of time, as long as the easy to use protocol was designed to be broken. It really is time to start over. _______________________________________________
cryptography mailing list
Date: Sun, 2 Oct 2011 09:48:01 +0800 William Allen Simpson <william.allen.simpson[at]gmail.com> wrote: > 3) Require Perfect Forward Secrecy. We'd not managed to get IPsec to do that. It was a big argument at the time. Even today, not all TLS suites provide PFS. What on Earth were the arguments against it? I'd have thought PFS was a complete no-brainer. So how was it that Netscape SSL had exactly the same faults as IPsec, ISAKMP, Oakley, IKE? Political pressure! Somebody really REALLY wanted to be able track users and intercept/substitute.... That is certainly a distinctly plausible motive. However, it would have had to be disguised as technical or ease-of-use arguments. I find it impossible to imagine any.
From: Peter Gutmann <pgut001[at]cs.auckland.ac.nz> Sandy Harris <sandyinchina[at]gmail.com> writes: What on Earth were the arguments against it? I'd have thought PFS was a complete no-brainer. Two things, it's computationally very expensive, and most people have no idea what PFS is.
Date: Mon, 03 Oct 2011 19:23:39 +1100 On 1/10/11 22:11 PM, William Allen Simpson wrote: I started reading this thread, and then left it alone, and am catching up. It's hard to know where to start, so changing the subject a little. :) > On 9/20/11 12:51 PM, ianG wrote:>> On 20/09/11 01:53 AM, Andy Steingruebl wrote:SSH doesn't solve phishing either. Is it a total failure also? I don't think so. SSL is used for a lot more than HTTPS. Any proposal to "fix" it *must* take that into account. - Andy [William Simpson message above snipped.] Proof is hard. But we might see it in the future. Not now, but in a few years. Whoever that somebody is, they did too good a job. And now they get to pay the cost. It isn't as if they can cherry-pick the consequences, because the net was cast too wide: the whole infrastructure is institutionally weak, and if we triangulate the spots that should have been strong but are weak, they all seem to point one location. So now we have the cyber-war scenario. One side spikes a nuclear plant, the other side punches a hole in "trust" infra. Tit for tat, bring it on! I suspect if it does take off -- tit for tat in cyber warfare -- there will be some smarter people who will realise they stupidly fired the first shot. And now they can't stop the 100 shots... Not a few people in there will be examining the causes, and realise that they set themselves up for a fall. Ho to reverse this? I suspect the only way is for somebody to come clean and tell people what they did. Otherwise, all the believers out there will ... carry on, keeping our infrastructure insecure. > Netscape caved, for their commercial interests. There was also the CA business model. User's own interests took last place. https://financialcryptography.com/mt/archives/000609.html I think it was inevitable. > So, arguing about ease of use is a waste of time, as long as the easy to use protocol was designed to be broken. It really is time to start over. Well, yes and no, WYTM? The thing is, "somebody" doesn't really matter to us. Arguably, ComodoHacker doesn't really matter as much as all the press makes out. And he's fixable. What matters is phishing and breaches. And the former is impacted by SSL. If we could get more SSL it would improve things. The reason we can't is because the UI is so horrible that people prefer to avoid it.
Date: Mon, 03 Oct 2011 17:44:41 -0500 [Ray] At the risk of feeding the conspiracy angle, I note that there is only one stream cipher for SSL/TLS (RC4). All the others in common use are CBC modes, with that same predictable IV weakness as IPsec (i.e. BEAST). There are no DHE cipher suites defined for RC4. So if you want PFS, you have to accept predictable IVs. If you want resistance to BEAST, you have to give up PFS. Hmmm, I wasn't trying to say that exactly. Mainly I thought it was a little ironic. Let me try to clarify. I think there were, and still are, "biases" among vendors like everyone else. This is Situation Normal, to suggest otherwise is to say that every party acts perfectly rational and with complete information. Understanding how we make decisions when faced with imperfect logic or information is critical to making our own best decisions and interpreting those of others. The technique of "putting one's self in another's shoes" is particularly helpful. [Callas] After all, if we look through the library of publicly-available, well-trusted stream ciphers there is, ummmm, well, there's always, urrrrr, well. http://www.mozilla.org/projects/security/pki/nss/ssl/draft302.txt It has a date of November 18, 1996 on it, this was probably the date on which the draft was uploaded to the IETF. This draft was allowed to expire. RC4 http://en.wikipedia.org/wiki/RC4 is the only stream cipher defined. As you point out, there weren't exactly a lot to choose from. RC4 had been a poorly kept trade secret of RSA until September 1994 when someone posted some source code for an equivalent implementation on the net. For some reason, RSA seems to have refused to acknowledge its child in the algorithm itself, yet they claim ownership of the name RC4. The authors of the draft302 document undoubtedly found the situation difficult. Evidence of their struggle surfaces in the body, where citations are made "DES[DES], RC4[RC4], etc.", yet there is no actual entry for [RC4] in the References section. The Glossary puts it thusly: RC2, RC4 Proprietary bulk ciphers from RSA Data Security, Inc. (There is no good reference to these as they are unpublished works; however, see [RSADSI]). RC2 is block cipher and RC4 is a stream cipher. Later specs would not fare much better. http://tools.ietf.org/html/rfc2246 TLS 1.0 January 1999RC4 The IETF really likes to have the RFCs describe things well enough that they can actually be implemented and interoperable. They also really like to have intellectual property disclosures along with the things they standardize too. Putting myself in those spec authors' shoes, I think they were probably wishing the RC4 problem would just go away somehow. But it couldn't for two good reasons: * RC4 was (and still is) preferred by many sites for performance reasons. DES was specifically designed for a hardware implementation. From 1999 onward, defining a new cipher suite for using Diffie-Hellman key exchange would have been straightforward matter of writing it up and allocating the code point. But it would have been a largely pointless exercise unless Microsoft or Mozilla implemented it. Or worse, possibly the author would have been accused of contributing to the "unnecessary proliferation of ciphersuites" [RFC 3268]
What would have been the demand for it? Security-minded endpoints wanting
PFS would prefer triple-DES or, later, AES. Performance-minded sites wouldn't
have touched EDH with a ten foot pole. Or so the thinking Take a look at the RFC 3268, the one which allocates the code points for AES based ciphersites. http://tools.ietf.org/html/rfc3268 June 2002 Overview Reason numero uno. The other reasons given are interesting too. None of them really seem too concerned with the prospect of RC4 being less secure than AES. So yeah, in summary, I'd say there was some "vendor bias" in the process going on. Not against stream ciphers in general, but against RC4 and its uncooperative vendor in particular. On 10/03/2011 01:37 PM, Jon Callas wrote: [Callas] Oh, I know! Counter mode! Yeah, that's it. Yeah that would have come in handy about now. http://www.dial911anddie.com/dtls/tlsctr.html As I understand it, people weren't comfortable with using DES or 3DES in a way that looked so much like a related-plaintext attack. Or maybe they simply didn't see much of a need to improve upon CBC: http://www.ietf.org/mail-archive/web/tls/current/msg00337.html [Callas] On the agility front, most people seem to be against it. Weren't we in a huge o-choices-are-the-only-security mood a few weeks ago? In SSL/TLS the thing you really can't have agility on is the HMAC that authenticates the handshake messages negotiating all the other specifics. If there's a choice of algorithm there, the attacker gets to choose the weakest one to attack. In TLS 1.2 this was changed from a combination of MD5 and SHA-1 to SHA-256. But there have been multiple generations of ciphers to have come in and fallen out of favor over the lifespan of SSL/TLS. Cipher suite agility is one reason the protocol survives today. [Callas] Stream ciphers are hard. They're hard to build correctly, hard to use correctly, and have been the red-headed-stepchild of cipher design for really good reasons. They're not as amenable to cryptanalysis with the standard linear/differential framework developed for DES.
Time and power are objectively measurable (in $) whereas security beyond
the minimum needed to resist standard attacks is largely subjective. So in
practice the designer is going to have a harder time arguing for any [Callas] Remember WEP? The most damning problem in it to my mind was the order-2^24 attack caused by using a stream cipher (and a 24-bit pseudo-IV). Well the problem was the specific stream cipher RC4 and the way it was used, not stream ciphers in general. The problem with WEP was so bad it allowed for key recovery, not just a many-megabyte distinguisher. Unlike, say, the way that block ciphers in general require additional complexity (and things to go wrong) in the form of CBC mode :-)
TLS does a really good job of deriving pseudorandom keys for every new
connection. Even resumed sessions get new cipher and MAC keys in each direction.
My understanding is that this makes it not vulnerable to the [Callas] Any stream cipher that gets created has to answer this really good question: Why are you better than AES-CTR? I know some secure websites that would love to be able to choose AES-CTR right now. Why can't they? Probably some of the same reasons there's only one stream cipher to choose from. [Callas] The next question would be why it's better than Serpent-CTR, or Twofish-CTR, or heck why not Just some example answers for RC4, I'm not sure how well they generalize to stream ciphers: RC4 may be faster for you. RC4 maintains an internal state size of around 1600 bits using 272 bytes of storage. That's a lot for a symmetric cipher! Those who are concerned with the collision properties of small block ciphers may consider that an advantage. The general algorithm is even well-defined as large as you'd like to make it. If you were to make it larger than a memory chip, you could define a work factor in terms of external memory transactions like scrypt. RC4 probably comes closest to a maximizing this (random memory lookup cost)/(other stuff that can be accelerated by ASIC) ratio. [Callas] Of course right now, the best thing to do stream-cipher-wise is to use GCM mode, with is in TLS 1.2, but hardly deployed at all, no doubt because of bias against wanting to use something that's authenticated, right? I've never heard of such a bias. Maybe it exists and I've never heard of it, or maybe you're just pulling my leg. [Callas] After all, wouldn't the surveillance state want us all to be vulnerable to CBC attacks like BEAST, and people who are preventing that must be in cahoots with the NSA, right? No, SSL/TLS is a protocol and implementations. Sometimes the important parts are actually in hardware and sometimes they're in software in so many machines nobody can break interoperability with 0.01% of them. I don't believe we understand the problems. If we did, we wouldn't have guys in Argentina decrypting PayPal cookies transmitted over properly-encrypted TLS as a stage trick. It's hard for me to imagine a first-rate engineer with an unbiased mind knowing all the issues today sitting down with a clean sheet of paper and coming up with CBC as a new design. Yet it continues to be regarded as some kind of gold standard. Why? Because we love Mother AES and Grandmother DES so much and CBC is such an improvement over ECB that surely it's "good enough"? Because people who propose alternatives are alternately ignored or accused of "inventing their own crypto", "vanity crypto", or "wasting our precious cipher suite code points"? [Callas] The wrong questions have been asked for so long in this long discussion that I think the only reasonable people are the ones ignoring the whole thing.
Yeah. I wish those reasonable people would participate more. :-)
_______________________________________________
Date: Tue, 04 Oct 2011 10:18:15 +1000 [Jon Callas] Come on. This discussion has descended past whacko, which is where it went once the "broken by design" discussion started. On 2011-10-04 9:18 AM, Steven Bellovin wrote: Quite. I had to point someone at some of these threads today; when it came to this part, I alluded to black helicopters. SSH faced political and administrative difficulties that protocols easier for the authorities to intercept did not face. That is suggestive.
Date: Tue, 4 Oct 2011 11:22:13 +0100 On Tue, Oct 4, 2011 at 1:18 AM, James A. Donald <jamesd[at]echeque.com> wrote:
> SSH faced political and administrative difficulties that protocols
easier Really? When I added SSL to Apache it turned out it used to exist in NCSA (Apache's original codebase) and was removed at the request of the NSA.
Date: Tue, 04 Oct 2011 13:58:05 -0500 On 10/04/2011 09:25 AM, Bodo Moeller wrote: There's TLS_ECDHE_RSA_WITH_RC4_128_SHA. Thanks! That is informative and helpful. Seriously. http://tools.ietf.org/html/rfc4492 Unfortunately, it looks like because it was only standardized 5.5 years ago *sigh* it's not available in my server environments yet. But it looks like it's coming in the next round of upgrades. - Marsh
Date: Wed, 05 Oct 2011 23:57:34 +1100 On 4/10/11 10:18 AM, Steven Bellovin wrote: [Callas] Come on. This discussion has descended past whacko, which is where it went once the "broken by design" discussion started. This thread originated in a state-led attack on google and 4 CAs (minimum) with one bankruptcy, one state's government certificates being replaced, measured cert uses (MITMs?) in the thousands. USG is the likely end game due to a recent shot across the bows at a nuclear processing plant. The business has been declared a legal munition since forever, and the NSA's cute trick has been turned on its own flock. Whaddya guys need? A declaration of war? The name of this syndrome is called "being locked in ones own OODA loop." C.f., John Boyd.
|