[cryptography] preventing protocol failings

Ian G iang at iang.org
Tue Jul 5 18:52:57 EDT 2011

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 

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*.


[0] An alternate view on why & how client certs work:

[6]    http://iang.org/ssl/h6_its_your_job_do_it.html#6.6
Hmm, perhaps that should be numbered H6.6.6 ?

More information about the cryptography mailing list