The way it works is simple. The admin for a site signs a message that "pins" a given public key to the domainname. This message is delivered by an SSL extension or appended to the SSL cert chain (a hack, but requires no protocol changes).
The pin message states that the public key won't change for a given period. If it changes, a rogue CA has issued a different cert and you are under attack. The browser will reject the session.
The admin can "break" the pin early by signing another message, distributed the same way. Then they can re-pin a new cert. This allows certificate mobility, fully under the control of each site admin.
This accomplishes the same goal as whole-cert pinning (as practiced in Chrome), but with many advantages. First, when you pin the cert (not public key), you don't allow for CA mobility. So if you keep the same server key but get a new cert, this appears to be an attack. Second, you have to notify Google and wait for them to issue a browser update when you do get a new cert. This is complicated and too costly.
Whole-cert pinning is used extremely rarely (not even all top 500 sites) and will never gain widespread adoption.
TACK is an extremely simple protocol, and the messages are tiny. It is very well-designed, and the site has working code on Github in addition to the Internet draft.
Trevor and Moxie are doing great things, so please do all you can to support them in this. It really is one of the few initiatives in recent times to have a huge impact on your family's actual security, as well as dissidents in countries like Iran.
EDIT: It's difficult to find a confirmation online, but I recall that Public Key Pinning is already live in Chrome, starting with version 18.
The criticism of Chrome's pinning is still valid though. The pinned key is allowed to show up anywhere in the cert chain, not just at the leaf certificate. Also, they have to pin several CAs, as well as multiple keys per CA to deal with sub-CAs.
> When a client sees a new hostname and TACK key combination, an inactive pin is created. Every subsequent time the client sees the same pin, the pin is "activated" for a period equal to the timespan between the first time the pin was seen and the most recent time, up to a maximum period of 30 days.
But this means failing to protect in many cases where protection is possible.
If a pin is seen once, then any future certificate without that pin should generate a warning, immediately and forever. If there is reason to suspect that a tack is invalid (say, because it's very old), then soften the warning message. (This would probably mean that a domain has changed owners. In that case, I want to at least clear cookies for that domain, and would appreciate a warning and an easy user interface for doing so.)
And if I visit a site exactly twice, I see a tack the first time, and I don't see it the second time, then regardless of whether it was an attack the first time and is okay now, or was okay the first time and is an attack now, I absolutely must know because that is not something that will happen legitimately.
Also, I would add the following language: "If TACK validation fails, the client SHOULD provide an easily accessible mechanism for submitting the certificate and associated information to a third party for analysis." Because that's what it'll take for rogue CAs to be discovered.
The general goal of this part of the spec, I think, is to deal with the case where an attacker forges a pin (using his own key) for a third-party site.
Think firesheep, where the attacker could make a fake pin for yahoo.com and send it to all coffee shop patrons. If the victim had not visited yahoo.com before, their browser would cache the fake pin, and it would report errors when the real one was seen.
To prevent the user from having to manage a known-hosts file by hand, like ssh, they went the route of making it take a second visit before a TACK pin is activated and the interval it is valid for is related to the delta between first and last visits.
SSH takes the route of forcing the user to verify the host key the very first time it's seen, and then it has an infinite lifetime. The user has to manually delete it to restart the cycle.
That wouldn't fly if it's a browser and your grandfather, so they came up with something more clever but slightly less secure in one specific way.
On the other end, it concerns me that the upper limit is set to 30 days. I understand it is all about damage control, but it also means that the pinning is not going to protect me when visiting web sites only once in a while. For example, I am an infrequent PayPal user. I will log into their web site once every couple of months. TACK wouldn't work for for my use case.
Yes, I think their main concern was about admins testing out pinning and accidentally locking their customers to the wrong key due to a configuration error. Perhaps the default UI action if a previously-activated pin has expired and a new pin key is being presented should be to warn the user.
For anyone who doesn't understand why SSL for browsers as deployed is broken, a quick exercise is to look at how many CA certificates come trusted with your favourite browser. For example, Firefox trusts the "Hongkong Post Root CA". This means that anyone who has access to the signing key can claim to be any SSL site. So they could issue a certificate for www.gmail.com which would allow someone to transparently intercept all your traffic.
Certificate Pinning is a very good start to somewhat mitigate this.
Think of it like ssh known-hosts, but with the added feature that the server side (sshd) can securely tell you to stop using an old entry in known-hosts and use a new one instead when its server key changes.
Also, TACK is not certificate pinning. It's public-key pinning (the thing inside the cert). You can change certs all you want without changing the public key, and the same TACK pin will be valid for all of them. This is better than cert pinning since you can change CAs without having to redo all your cert pins.