[cryptography] PKI "fixes" that don't fix PKI (part III)

Lucky Green shamrock at cypherpunks.to
Thu Sep 8 19:11:43 EDT 2011

My 'PKI "fixes" that don't fix PKI' series has resulted in my receiving
quite a few private emails and phone calls. I am happy to hear that
readers find this series interesting. While I do not plan to make this a
daily post, the queue of proposed fixes is pretty long.

Before analyzing more proposed fixes, let me answer some questions that
I received on and off list that might be of interest to a broader audience.

o What do I mean by the "SSL system"?
You could call it PKI. The reason why I chose the term "SSL system" is
to help the reader internalize that there is far more to SSL and https
security than the SSL/TLS protocol. The SSL system includes (not an
exhaustive list):

- the SSL/TLS protocol
- the certificate-consuming applications
- certificates
- zero, one, or more certificate issuers (CAs)
- a minimum of two clocks (ideally synchronized)
- a reliable transport protocol (ideally - but in practice not always -
one that is actually reliable), typically TCP
- a user interface, often one that involves the user in security
decisions, which is often, but not always, a bad idea
- at least one, more typically four or more actors, that seek to derive
benefits from the system

o What makes me say that the SSL system was not designed to withstand
governmental security services adversaries?
I have a firm no rock fetching policy, but I don't believe that this
question was meant as rock fetching. The answer is two-fold:

- we know for fact that weak crypto (RC4-40) was a hard requirement on
the design of the SSL system for the explicit purpose of facilitating
governmental security/law enforcement services interception.

- while it is possible to build communication systems that use some of
the components of the SSL system that withstand governmental security
services interception (I have designed and deployed such systems
myself), no such systems trust a broad range of CAs in far-away places
to issue credentials to such a system.

Now on to more PKI "fixes" that don't fix PKI.

o Increase the granularity of trust of CAs in the root store
We have this already in the form of regular vs. EV certificates. It
didn't help with Diginotar. Adding two or five or 15 more levels of CA
trustworthiness grades can help add to user confusion, which rarely
leads to higher security, may help increase CAs' ARPU, but there is no
reason to believe that assigning fine-grained trust grades to
certificate providers will increase overall security.

Moreover, assigning grades of trust breaks a design assumption of the
SSL system that a CA is either trusted or not. This likely will lead to
unintended consequences. In a crypto design, incorrect (or made no
longer true) assumptions almost always result in lower, not higher security.

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 to some CA that traditionally has
only served a niche market in a particular geographical area, etc. The
SSL Observatory is a gold mine of information that could be leveraged by
such risk analysis logic, though I anticipate that many browser vendors
will choose to maintain the server cert database in house.

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. 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. Yet this is not fixing
PKI. This is throwing PKI overboard and designing an entirely different
system from the ground up.

Until the next episode of 'PKI "fixes" that don't fix PKI',
--Lucky Green

More information about the cryptography mailing list