[Cryptography] Toxic Combination

ianG iang at iang.org
Sun Dec 7 13:16:30 EST 2014


On 4/12/2014 11:28 am, Ben Laurie wrote:
>
>
> On Thu Dec 04 2014 at 7:22:16 AM Peter Gutmann
> <pgut001 at cs.auckland.ac.nz <mailto:pgut001 at cs.auckland.ac.nz>> wrote:
>
>     Ben Laurie <benl at google.com <mailto:benl at google.com>> writes:
>
>      >I think that's a completely unfair accusation - the difficulty has
>     always
>      >been the lack of a _usable_ way to _securely_ implement such
>     protocols.
>
>     You forgot the rest of the list that gets trotted out:
>
>     It won't scale, there's no user demand, there's insufficient
>     industry support,
>     I ran out of gas, I had a flat tire, I didn't have enough money for
>     cab fare,
>     my tux didn't come back from the cleaners, an old friend came in
>     from out of
>     town, someone stole my car, there was an earthquake, a terrible flood,
>     locusts!
>
>     There have been endless studies done and papers published on how to do
>     perfectly usable shared secret-based authentication.
>
>
> Oh really? Please provide references. Actually, I don't have time to be
> drowned in a million crap papers, so please, for now at least, provide a
> reference for the best solution you are aware of (or two or three if
> choosing is hard).

As you yourself show below, asking for references is a setup for a 
knockdown.

>        Heck, I devote
>     significant chunks of my book (draft) to them, I'd be surprised if
>     there were
>     less than a hundred references to published work on how to do it.
>
>
> There are many papers on how to do it badly. I have yet to see one
> (backed by actual testing, I am not interested in usability by
> assertion) that's actually deployable.


As I'm sure you know, things like certificate pinning were trialled and 
tested seriously in the mid 2000s as phishing turned up.  Browsers 
successfully ignored those efforts.  I don't recall whether that excuse 
was used, but I'd not be surprised, they were on a mission to block all 
outside influence.

This is all pre-chrome times so perhaps google can look to avoid the 
mistakes of Mozilla and Microsoft.  But as I'm also sure you found out, 
it wasn't that easy, the power of standards and compliance is immense.


>      >And it has to be secure - which includes "not allow credential
>     theft _even by
>      >the site operator_".
>
>     Oh, that's a new one: Set a requirement that can't possibly be met
>     (except
>     perhaps through the use of magic) and then claim you can't meet that
>     requirement, therefore it's not worth doing.
>
>
> I did muse about that one for a while, and surely its the point of using
> zero knowledge protocols? If it is not, then what is?
>
> But if you really think its impossible, I'm certainly prepared to drop
> it as a requirement.
>
>     Looking past all the excuses, there is one, and only one, reason why no
>     browser supports proper shared secret-based mutual auth: The browser
>     vendors
>     don't want to do it.
>
>
> And you claim that don't want to because


No, no, let me put words into Peter's mouth ;)

The reason the vendors won't act for user security is twofold.  Firstly, 
the vendors are doing what they are told by the standards bodies and the 
upstream vendors.  The browsers don't really have security / 
architectural capability because they just follow the standards [0]. 
The vendors have outsourced the security equation, so they are totally 
going to ignore any input from any alternate source, peter paper or 
proven, up to and including evidence that they are part of a perpetual 
and profitable criminal enterprise.

You might (should) ask why.  There is at least one reason why Mozilla 
and Microsoft refused to enter into the strategic architectural security 
game:  liability.  If they recognised that there was a security 
weakness, and they sought to do something about it, they could become 
theoretically liable for phishing losses from their users.  Given the 
state of American legal behaviour, they did the obvious thing, and 
denied their liability for all security losses [1] and therefore sat on 
their "we follow standards" principles aka "best practices" lie aka get 
out of jail card.

(The exception to the above dynamic might be google which has been 
caught on both sides of the fence - as browser vendor and as online 
merchant.  It has therefore been incentivised by being liable for more 
parts of the equation to somewhat rock the status quo.  By thinking of 
alternates, and trying to push them through [2].)

Then, secondly, when there is a new standard, the vendors wait until 
others have done it.  As nobody wants to leap off without a guarantee of 
the others doing it too, the natural state is that nothing happens.  As 
per Peter's suggestion.  This is by way of a natural cartel, and yes, 
there is such a thing, and it can be deliberately constructed, and it 
can be manipulated.


> they're all is a secret cartel
> to keep CAs in  business? Really?


Yes, but you confuse the causality and/or intent.  It is a fact that the 
vendors entered into a cartel called CABForum that prepared its 
do-nothing set of standards in secret.  But, entry into a cartel only 
worked because the vendors had a total absence of security capability at 
the architectural level, as above, which is the underlying causality. 
The vendors did not themselves think they were trying "to keep the CAs 
in business" but of course the CAs didn't care what was thought, only 
what was achieved.


>        Meanwhile they're busy implementing more mission-
>     critical stuff like live in-browser video chat via WebRTC, because
>     that's
>     functionality that everyone has been crying out for for a web browser.


The mission of browsers is pretty much that.  They don't do new security 
designs.  The do what standards and cartels tell them to do, and try to 
preserve the web in the process.

Sucks to be a user.



iang


[0] in Mozilla's case, this is written into their manifesto and their 
bloodstream.  Observance of standards is an inviolable part of their 
genetic makeup, and I doubt they even understand where it comes from 
(the browser wars, as it happens).
[1] for fascinating circumstantial evidence of this, look to BR 18.2 
from memory.
[2]   FWIW, YMMV, that's just my theory.  Google like all vendors 
famously never says anything of any substantial fact basis so they are 
unable to correct that theory if it were to be erroneous.


More information about the cryptography mailing list