On 5/07/11 3:59 PM, Jon Callas wrote:
There are plenty of people who agree with you that options are bad. I'm not one
of them. Yeah, yeah, sure, it's always easy to make too many options. But just
because you can have too many options that doesn't mean that zero is the right
answer. That's just puritanism, the belief that if you just make a few absolute
rules, everything will be alright forever. I'm smiling as I say this --
puritanism: just say no.
I find it ironic to be on the side of the puritans, but I think it's not
inappropriate.
The 90s were the times of an excess of another religious crowd -- the
hedonists. In those times, more modes was more better. The noble drive
to secure the Internet intersected with the jihadic expression of code
as freedom, the net as the new world, crypto as numbers, government as
the enemy, and as much as possible of all of them. Right now! Today!
Hell, I was even part of it. I thought it was so cool I coded up extra
algorithms for Cryptix, just for fun, and lobbied to get extra
identifiers stuffed into OpenPGP.
But what was the benefit? Let's just take one example, the
oft-forgotten client certificate.
Does anyone make much use of client certificate mode in SSL? No,
probably not. They work [0], but nobody uses them, much. And, it turns
out that there is a good reason why nobody uses this fairly workable
product: because you don't have to. Because it is optional. As client
certificates are optional, sites can't rely on the client certs being
available. So they fall back to that which they can insist on, which is
passwords. Which humans can be told to invent, and they will, without
any audible grumbling.
So, options means unavailability. Which means it can't be used.
Yet, there's no *security* reason for them being optional. Client certs
could be mandatory, just like server certs. There is no *business
benefit* for users in client certs being optional (and by this I mean
client-side and server-side).
That's just one mode. It turns out there is another mode -- HTTP. This
mode is turned on far more than it should be, resulting in a failure of
user discrimination. Hence, phishing.
Now, we may poo-poo the whole phishing thing, but consider that phishing
is a bypass on SSL's authentication properties for online banking, etc.
At whatever layer we found it. Phishing is the breach that exploits
HTTP mode in browsing.
And consider that phishing, alongside server-breaching, financed the
current wave of crime, step by step, to our current government
cybercrime social disaster.
It's a lot to lay at the feet of a little mode like optional HTTP in
secure browsing, but the bone points squarely at it.
If you've followed the history of real use and real breach, modes can be
shown to cause failure. OTOH, if we look at famous systems with few
modes, we see less failure. Skype has only one mode. And it is secure.
SSH has very few modes. And what modes it has -- password login for
example -- caused a wave of SSH password snaffling until sysadms learned
to turn off password mode!
In contrast: SSL again. Some packet bugs fixed in SSL v3. MD5
deprecation, much anticipated by a squillion cipher suites but target
missed completely! Re-negotiation - a mode to re-negotiate modes! And
finally the TLS/SNI bug. Ug.
I claim that we've got causality and we've got correlation. Which gives
us the general hypothesis:
there is only one mode, and it is secure.
I think that crypto people are scared of options because options are hard to
get right, but one doesn't get away from options by not having them. The only
thing that happens is that when one's system fails, someone builds a completely
new one and writes papers about how stupid we were at thinking our system would
not need an upgrade. Options are hard, but you only get paid to solve hard
problems.
What's left is arguing about the exceptions. In H6.6 [6], I argued that:
"Knowing the Hypotheses is a given, that's the job of a
protocol engineer. That which separates out engineering
from art is knowing when to breach a hypothesis."
Another way of putting it is, do you think you know as much as Jon or
Peter or the designers at Skype or Tatu Ylönen? Probably not, but I for
one am not going to criticise you if you've got the balls for trying,
and you *know the risks*.
iang
[0] An alternate view on why & how client certs work:
http://wiki.cacert.org/Technology/KnowledgeBase/ClientCerts/theOldNewThing
[6] http://iang.org/ssl/h6_its_your_job_do_it.html#6.6
Hmm, perhaps that should be numbered H6.6.6 ?
_______________________________________________
cryptography mailing list
[email protected]
http://lists.randombit.net/mailman/listinfo/cryptography
