[Cryptography] Toxic Combination

[Ben Laurie]

On 7 December 2014 at 18:16, ianG <iang at iang.org> wrote:
> 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.

Come on, seriously? As I said below, I'm prepared to retract that
requirement, but I still ask: what is the point of using a ZKP if it
isn't to conceal the password from the site operator?

In any case, your position appears to be "you should implement this
even though I cannot point to a single example of how". Not tenable.

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

Pinning does not scale: you risk your site becoming unavailable for an
extended period if you screw up. Remediation is necessarily manual.

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

I think it is absurd to claim nothing happens. Certificate
Transparency and Safe Browsing are two obvious examples that improve
user security and have none of the above going on.