[Cryptography] [messaging] Gossip doesn't save Certificate Transparency

[Jerry Leichter]

On Sep 28, 2014, at 1:47 AM, Peter Gutmann <pgut001 at cs.auckland.ac.nz> wrote:
> ...Looking at what CT gives you, there seem to be three scenarios to cover:
> 
> 1. Cert issued for Google or Paypal.
> 2. Cert issued for First Bank of Podunk.
> 3. Cert issued for www.verify-chase-credit-card.com.
> 
> Case #1 is already handled by pinning, and cases #2 and #3 won't be helped
> through CT.  So CT will end up solving the browser PKI problem in the same way
> that SPF solved the spam problem....
Think about the broader implications of this assertion:  Certificate pinning is, in effect, doing away with PKI.  The entire structure of layers of trust in CA's becomes meaningless:  You're trusting whoever gives you the "pins" to tell you how to reach Google or Paypal.  Oh, sure, they gave you a cert signed by some CA - but to verify that cert, you go look up the CA - and it had better be pinned as well, or what have you gained?  The whole point of pinning was to have *trustable* ways to reach important sites....

The logical outcome of pinning is to get rid of the certs entirely.  Your browser vendor provides you with a bucket of public keys for well-known sites, and you just use them.  The only thing the intermediate layer of CA certs provides in this scenario is the ability for the site to issue new keys - but it does so at the cost of requiring you to trust an extra party.  Proper rekeying mechanisms shouldn't need that.

Pinning is a hack to buttress a PKI system that we know is failing.  I appreciate the importance of having something that improves existing systems as transparently as possible - it's so difficult to deploy anything entirely new.  As a transition - that's fine.  But it shouldn't block us from thinking about a better replacement.

PKI was introduced to the Web as a solution to a problem:  There were too many sites you might want to go to - many of which you'd never been to before - for it to be practical for you to have all the necessary keys up front.  Besides, the links themselves were too slow (dialup!) and storage was too expensive, to make distribution of a list of keys possible.  None of those apply today.

Consider the sites that correspond to 1. on the list.  Those are supposedly the top sites on the Internet - the ones "everyone goes to".  How many are there?  What percentage of connections does it cover?  The Alexa "top sites" lists seem to provide a good starting point, but I had trouble getting that kind of data - it's probably what Alexa provides for a fee.  The closest I could find was http://www.rypmarketing.com/blog/928-the-top-0-0016-of-websites-get-nearly-75-of-the-traffic-from-google.whtml, which claims that the top 10000 sites got 75% of "Google organic search traffic" 2013.  One can debate the details - even if Alexa is measuring *exactly* what it claims to be measuring, that's not quite what we are looking for - but it certainly looks as if a list of 100,000 pre-distributed keys would easily cover what anyone would reasonably call the members of that class.  (For any given person, it would be gross overkill - hardly anyone regularly contacts the top sites in English, Chinese *and* Arabic, say.)  How much data is that?  Let's assume 2048-bit RSA keys - 256 bytes.  The name of the site has to be in there - not typically very long, but let's simplify the math a round the total up to 300 bytes.  So we're talking 30MB of data.  Today, that's no big deal.  Why not just distribute it to everyone?

For sites in this list - which would probably cover the vast majority of connections made by the vast majority of people - you don't need certs, CA's, or any of that junk.  The browser makers - who you have to trust *anyway*; crypto is useless if the code is spiked - can distribute and update this list on a regular basis.  If the list is signed, there's no hazard in getting copies from random places on the net - the browser will reject a fake or modified version.
Revocation can work as well - or as badly - as today, using similar mechanisms.

Of course, that leaves the item 2 sites - the First Bank of Podunk, et al.  These are probably of low enough value, and visited infrequently enough, that serious attacks against them are unlikely.  Key continuity (the site uses the same key it used last time, or it's used a proper key rollover procedure to tell me what its new key is) covers everything but the initial contact problem. Again, in today's world, storage of keys of sites I've spoken to in the past is no big deal - and distribution of my stored keys to all my devices is a problem that can be solved.  And the initial contact for any but the best-known sites was always problematic anyway:  Just what *is* the proper web address for the First Bank of Podunk?  Just because firstbankofpodunk.com has a cert for that address saying First Bank of Podunk doesn't mean it's really the site for that bank down the street - *they* are using 1stbankofpodunk.com, and don't have the time or money to go after all the fake addresses similar to their name.  If I want to be sure of the site, I need to walk up the street and find out where their site is.  They can just as easily give me their key - e.g., with a QR code - at the same time.

The PKI structure we're trying to patch up attempted to solve problems that are barely relevant to the world we actually live in today.  It's time to move on.

                                                        -- Jerry

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20140928/83121bc3/attachment.html>