[cryptography] PKI "fixes" that don't fix PKI (part III)
iang at iang.org
Fri Sep 9 18:46:24 EDT 2011
On 09/09/2011, at 9:11, Lucky Green <shamrock at cypherpunks.to> wrote:
> o What do I mean by the "SSL system"?
I've taken to using TLS for the protocol, SSL in the wider context including PKI/certs, and "secure browsing" for the headline or flagship application.
(imho, we can safely ignore any criticism on semantics, the critic is more interested in derailing opposition than thinking about fixing the system.)
> o Increase the granularity of trust of CAs in the root store
> We have this already in the form of regular vs. EV certificates. ...
Trust grades can be compared to AAA+ bond ratings. They are useful until they are not, and then the house of straw is blown away. Typically, "compliance" investors follow them, and in good times they may be better than nothing.
Smarter investors look to brand. E.g., who here cannot order this list:
Bundesbank, Buffet, IMF, Soros, UST.
> Moreover, assigning grades of trust breaks a design assumption of the
> SSL system that a CA is either trusted or not.
Does anyone believe this still design assumption still stands? If so, what does trust mean, and how does it effect the user? What does the user get if it isn't? DigiNotar's trust means what?
Users don't trust CAs, they don't have a choice. Relying parties are instructed in RPAs not to. Meta-CAs do not, they verify instead.
It's probably safe to say that certificates are a compliance thing not a choice (trust) thing.
> This likely will lead to
> unintended consequences.
It has :)
> This is not to say that browsers should not consider risk analysis logic
> improvements, such as if a cert for a site has been seen before, if the
> site suddenly switched CA providers ...
My guess is that what is now called CA Pinning is likely to be direction forward.
> o Do away with trusted CAs and switch to self-signed certs
> This proposal largely fails to meet the most basic SSL design
> requirement to allow Joe Browser user to connect to a site with which
> Joe has no prior relationship and feel reasonably confident that he is
> talking to that site without MITM.
It's curious to ponder where that design requirement came from. Historically, we were not bombarded with confirmatory evidence. Quite the contrary, in that the threats seem to be: server hacking, app-level MITMs, and MITBs.
Indeed, is there a need to keep the old assumptions so concrete, when the threat model is elsewhere? Are there better results available?
> There is a reason why many SSL
> servers pay for a certificate.
> That said, one could envision an entirely different system in which each
> SSL certificate seen by a browser is sent up to the browser vendor
> checking for consistency.
> The first few visitors to a website would be
> exposed to a higher risk, but the many subsequent visitors would be
> quite safe. Overall, such a system would likely be safe enough to meet
> the design goal for Internet users to be able to send their credit card
> information over the network with fraud rates due to interception being
> on par or lower than card present transactions.
Sorry, that doesn't work. Afaik, there is practically zero evidence of Internet interception of credit cards. Compared to other forms, it would be so low, they dont even have the answers.
> Yet this is not fixing
> PKI. This is throwing PKI overboard and designing an entirely different
> system from the ground up.
I'd not be so sure, but maybe it's another semantics skirmish? We still have certs in place, we just check them out in different ways.
More information about the cryptography