[Cryptography] Verisimilitrust

[ianG]

On 8/01/2016 09:09 am, Peter Gutmann wrote:
>  From the Mozilla policy list, in a discussion about what to do about
> Kazakhstan requesting that their MITM certificate be added to the browser
> trust lists:
>
>    It would appear from this information, that this CA (and probably others
>    like it) is deliberately serving a dual role:
>
>    1. It is the legitimate trust anchor for some domains that browser
>       users will need to access (in this case: Kazakh government sites
>       under gov.kz).
>
>    2. It is the trust anchor for fake MITM certificates used to harm
>       browser users, and which should thus be regarded as invalid.
>
> causing an immediate panicked response to try and find a reason to deny the
> request, because the CA/Browser Forum policies don't actually say you can't
> have an acknowledged MITM cert as a trusted root:


The problem with this is that it has been acknowledged in the past by at 
least Mozilla that if there is due process - court order or user 
permission - then it is OK to MITM.  As this is simply awful but legal 
behaviour, this is OK, and it applies to all CAs in all countries.  And 
we typically don't write policies that say "we'll ignore court orders" 
because those courts then strike them down nor do we typically enter 
into criminal conspiracies to tell our partners to ignore court orders...

In contrast there was a bit a push to try and ban MITM boxes on the 
grounds that even employee permission isn't sufficient for spying on 
/inter alia/ online banking.

Part of the problem is probably that Mozilla just buried the debate. 
Back when I was in that group, they'd been caught twice running the 
secret conversations internally, so they know things and act on things 
that we have no idea over nor can govern over.  Now they're caught in 
the open and have to explain all that wasn't explained in the past.

If this theory is true, then they've likely been permitting MITM boxes 
for friendly governments for a while...  So this just amounts to normal 
WASPish or WEIRD discrimination against one of the Darkistans.


>    Kazakhstan has submitted the request for root inclusion:
>    https://bugzilla.mozilla.org/show_bug.cgi?id=1232689
>
>    So, we really do need to have this discussion now.
>
> I think we need to formally give up on the use of the word "trust" in its
> conventional sense in relation to PKI.  Browser PKI has done to the term
> "trust" what the popular press has done to the word "hacker".


If you go back to the early versions of PKI documents, they talked about 
how the acceptance of the roots was based on an entry into clear 
agreements and obligations to do various checks which would then be a 
foundation for your risk analysis, leading to a decision to proceed - 
aka trust - conducted by the relying parties.

Since then, the "popular" PKI for secure browsing found itself reversing 
much of that.  Agreements were made opaque, liability was buried, and 
users were stripped of the analytical tools to make any sort of risk 
analysis.  E.g., for most of Verisign's life you weren't allowed to rely 
unless you had agreed to their contracts, which basically said you had 
no chance in suing them.  Hobson's choice.

One could argue (and it is argued) that this was the only way to make 
secure browsing work - strip the users of the tools to do the analysis - 
because they had proven beyond a doubt incapable of doing it.

But sadly or otherwise, this means that trust is no longer part of the 
system, or at least that trust that the PKI originally envisaged, pre 1994.

Trust is a human decision of taking a risk that things will turn out 
right in the future based on past information.  In contrast, that which 
is called "trust" in PKI is precisely the reverse:  the browser hides it 
all and you carry on regardless.  If trust turns up at all it is that 
some browsers once told you that "you trust this site" ... which of 
course is bogus.

In practice, users make a trust decision precisely once - when they 
download their browser or purchase their new computer.  They trust their 
vendor to get it right - one decision leading to trust over years of 
usage on Apple, Mozilla, Google and Microsoft platforms.  Although that 
trust is pretty poorly informed and mixed up with other things, it's 
actually the trust that goes with branding, so it's not zero, it's quite 
rational and well studied in marketing.

Which gives us another clue to the word trust - users literally cannot 
trust what they do not know, and they statistically do not know the 
names of the CAs, or if they do, they don't know what they do.

Which all goes on to say, pretty much anyone who's using the word 
"trust" in the CA / PKI world is in a state of sin.  That's ok, it's 
whatever you have to do to collect a pay cheque.  Everyone has to make 
compromises in professional life.


>    Thus it would be prudent to extend the trust list format (and the NSS code
>    using it) to be able to specify additional restrictions beyond those
>    specified in the CA root itself.


Yes - so the muddled thinking that goes on in the browsers is because 
they have to live with the cognitive dissonance that the browser policy 
departments are the certification authorities over the certification 
authorities, but they can't call themselves CAs because that'll upset 
their chums over at the club.


>    [...]
>
> In other words certificates are going to be turned inside-out, instead of the
> cert encoding policy-related information as per X.509, we've got a third party
> (browser vendors) imposing its policy on the certificate from the outside.


Yup.  Inevitable.  Notice how they got into the revocation game?  How 
soon will it be before someone throws a switch inside and starts 
delivering signed root lists?  Oops, there is one that already does ;)


> We've already got the same third party overriding CAs on revocation via
> hardcoded cert blacklists,


Snap!

> and as has been shown over and over again, CAs do
> only the bare minimum of checking for anything but EV certs.  So if this
> change is made we can summarise the purpose of a CA as follows:
>
>    Verify identity in certs - Not really (except to justify premium-priced EVs).
>    Provide policy for certs - No, the browser vendor will.
>    Provide revocation info for certs - No, the browser vendor will.
>    Charge money to turn off the browser warnings - Yes.
>
> So that's pretty much pared browser PKI down to its essence, a license to
> print money for a select group of companies.


Well, the scaling problem is harder.  Getting certs out at 
Internet-personal-scale is a hard problem, so maybe some money has to be 
made somewhere to make it work.  But yes, one day someone in the 
browsers will figure out that certs that are too easy to spoof are no 
different from certs that people create themselves.

White certs should be the same - ones that are indistinguishable from 
HTTP.  But the problem here is that they got it into their heads that a 
cert means a signal of non-MITM-ness, not of equivalence to HTTP.  Oh 
dear...



iang