Moxie Marlinspike Proposes New TACK Extension To TLS For Key Pinning
Trailrunner7 writes "Two independent researchers are proposing an extension for TLS to provide greater trust in certificate authorities, which have become a weak link in the entire public key infrastructure after some big breaches involving fraudulent SSL certificates. TACK, short for Trust Assertions for Certificate Keys, is a dynamically activated public key framework that enables a TLS server to assert the authenticity of its public key. According to an IETF draft submitted by researchers Moxie Marlinspike and Trevor Perrin, a TACK key is used to sign the public key from the TLS server's certificate. Clients can 'pin' a hostname to the TACK key, based on a user's visitation habits, without requiring sites modify their existing certificate chains or limiting a site's ability to deploy or change certificate chains at any time. If the user later encounters a fraudulent certificate on a "pinned" site, the browser will reject the session and send a warning to the user. 'Since TACK pins are based on TACK keys (instead of CA keys), trust in CAs is not required. Additionally, the TACK key may be used to revoke previous TACK signatures (or even itself) in order to handle the compromise of TLS or TACK private keys,' according to the draft."
It seems to me that you could do a p2p certificate authority where a certificates trust is based on the number of people who trust the cert as well as a past history of your trusts.
So, if historically you trust certs that are frauds then the trust in you is reduced and all certs you trusted are reduced.
If the opposite is true than the trust in you is higher as is the trust in the certs you have trusted.
You're still bringing in an absolute arbiter, just hiding it a little. Or to clarify, without an absolute arbiter, there are no certificates marked as frauds, just those marked as unpopular.
Without an arbiter (or arbiting class), all you have are records of who trusted certifications that other people trusted and who trusted certifications that few others trusted. This offers nothing as it will simply lead to distributed manipulation fo trust attacks, although in a best-case scenario you can build a model that forces the botnets to be civil a significant majority of the time and only support hostile certificates irregularly.
Its not. Its a verification scheme orthogonal to certificate chains which can be used either alongside traditional certificate chain verification or without traditional certificate chain verification. It is compatible with self-signed certs, but equally compatible with CA-signed certs. Ideally, you'd use it with CA-signed certs, since CA-signed certs -- though they have known problems -- are better than nothing (unlike self-signed certs) on a first connection with no prior information, but after that TACK pins are useful to detect later CA-assisted shenanigans.
No, what you need is an effective mechanism to detect and revoke trust in nefarious CAs. If CAs aren't trusted, they are of no value to potential clients, and thus the stream of income from signing certificates dries up. The problem isn't that CAs derive income from signing certificates, the problem is that there is no effective accountability mechanism that imposes sufficient consequences to make it so that improperly signing certificates reduces the marketability of that CA's signing services.
It seems to me that you could do a p2p certificate authority where a certificates trust is based on the number of people who trust the cert as well as a past history of your trusts.
As someone else pointed out, that's Moxie's other project, Convergence. The trouble with "web of trust" schemes like that is fake "people", i.e. dummy accounts. Dummy account generators have trashed Craigslist, turned Hotmail into a reply service for spammers, garbaged Gmail, filled Google+ with fake accounts, and created vast numbers of bogus Yelp reviews. See my paper "Social is bad for search, and search is bad for social." for the details of who does that dirty work.
The trouble with crowdsourcing is that crowds can be outsourced.