[Cryptography] Toxic Combination
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
> >been the lack of a _usable_ way to _securely_ implement such
> 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,
> 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
> 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
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
> 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
> 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 .
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  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 .)
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
> 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.
 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).
 for fascinating circumstantial evidence of this, look to BR 18.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