On 18/09/11 4:34 PM, M.R. wrote:
On 17/09/11 17:56, lodewijk andré de la porte wrote:
> ...therefore assumes others assume SSL to be broken by design...
SSL is not "broken by design"!
See counter-proof at bottom.
SSL was designed to protect relatively low-value retail commerce,
and it still does that job reasonably well.
It does it badly, if protecting relatively low-value commerce includes
stopping phishing. Proof:
Note that SSL includes a large dose of authentication. Indeed, the
raison d'etre for SSL v2 was authentication. PKI.
In phishing, it fails to authenticate.
Now, to cut the conversation short, you'll say "oh, SSL doesn't protect
that!" And I'll say, "then, SSL doesn't protect what needs protecting...."
E.g., low-value retail commerce.
And we'll go round and round in circles for years while users get
robbed. Which has been going on for around 8 years now. Make a
difference, step off the merry-go-round...
What failed were our mechanisms to ensure that system usage regime does
not exceed it's design parameters. If I can be flippant, SSL was a
pedestrian bridge which ended up used to drive 18-wheelers across it.
Well, I'm one who uses analogies and has them reversed against me :) So
I'll have a go.
Actually SSL was designed to drive 18-wheelers over it, when pedestrians
and bicycles were all that was needed. Note the PKIX's obsession with
256 bit algorithsm and exotica like renegotiation.
In contrast, note the absence of any attention as to how to use the
authentication in a suitable fashion... They put the bridge in the
wrong place, there ain't a river for miles.
"Bridge in nowhere" :)
What failed was the total absence of an equivalent of a notice in
big red letters somewhere on the access ramp: "this structure is not
capable of carrying heavy vehicles. If you use it to do so, it will
collapse and you will get hurt or killed".
I kind of agree with that. What failed was a complete absence of
responsibility on the part of the engineers to say "don't do that!"
Instead they repeated the mantra that SSL was very strong, and should
always be used. And and and...
When it came to actual failures ... they are silent. Still. But they
love their merry-go-round :)
There once was a rich, well organized industry fighting such move,
(think CA's :), but we finally got those "Smoking Kills" notices on
cigarette boxes. And the reasons we are not, at least as a stop-gap
measure, putting up such notices on browsers (i.e., the package)
right now (as the evidence of the danger of the product misuse is
emerging not only among the experts but among the general public
as well) is twofold: the industry lobby, helped immensely by that
most misguided computer security doctrine: "the user is an uneducated
moron and must be treated accordingly".
Well. Actually I agree with that last statement, but not as a
disrespect. The customer is king.
The most important thing that drives any security design is K6:
"Finally, it is necessary, given the circumstances that
command its application, that the system be easy to use,
requiring neither mental strain nor the knowledge of a
long series of rules to observe."
If you look at threat modelling, the first point is: know the business
model. Same point.
Get K6 right and you have a chance. Get it wrong and it's all over
before you begin. You have zero chance.
PKI got it wrong; by design: In PKI, the CPS is a document that
describes whether and how to rely. This is patently and absurdly in
contradiction to K6.
Hence, SSL v2 got it wrong, by design. QED.
What the vendors (browsers) did was to unwind the K6 mistake in PKI by
homogonising the CA's influence (and thus removing the CPS from the eyes
of the user). Now, this isn't entirely grand, they were right in doing
that, but wrong in enough other things that we got an unworkable mess.
They didn't unwind enough (but there again, given the architectural
direction they got from the SSL community, they can be forgiven for
getting it wrong in 1994).
iang
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
