3 ms·

It's a shame more people haven't really spent time on Tack. I spent a weekend playing with it and it was really great. Trevor stopped paying for the TACK test

It's a shame more people haven't really spent time on Tack. I spent a weekend playing with it and it was really great. Trevor stopped paying for the TACK test server so Im guessing the push has died. Trust agility and certificate transparency really need to come about...yesterday.

moxie 12y ago
At this point Google pretty much controls the future of web-oriented internet protocols, since they control the client in the form of Chrome, as well as the server in the form of Google properties. What they do is basically what goes. People inside of Google were putting together HPKP at the same time that we were putting together TACK, so that was pretty much the end of TACK. HPKP is really simple for Google (just pin their own CA), but isn't as clean for most other major sites (who are stuck with many CAs). It also doesn't offer a layer of indirection away from CAs, which again, is not an issue for Google (they already have a layer of indirection in the form of their own CA), but is less ideal for the rest of us. It's better than only being able to hardcode pins in the browser binary, but it's a shame that it doesn't take on some of the other pain that's come up with pinning.
- JetSpiegel 12y ago
  If by "control the client in form of Chrome" you mean about a third of marketshare, suure.
- rakoo 12y ago
  AFAIU the difference between TACK and HPKP is: - For TACK, the pinned key is a custom key created just for that, and is transmitted in TLS - For HPKP, the pinned key is a CA cert key (one of the CA on the chain), and is transmitted in HTTP I think pinning the CA cert key makes more sense, because this is what they were created for: certs certify, the matter is in how you transport them. OTOH putting all the pinning information directly in the certificate makes more sense to me. We should have every domain owner running its own CA, with a cert that has all required pinning data, signing all TLS keys of the servers, and then sending the minimal chain "server cert" <- "CA cert", and then browsers would pin that cert.

moxie 12y ago

At this point Google pretty much controls the future of web-oriented internet protocols, since they control the client in the form of Chrome, as well as the server in the form of Google properties. What they do is basically what goes. People inside of Google were putting together HPKP at the same time that we were putting together TACK, so that was pretty much the end of TACK. HPKP is really simple for Google (just pin their own CA), but isn't as clean for most other major sites (who are stuck with many CAs). It also doesn't offer a layer of indirection away from CAs, which again, is not an issue for Google (they already have a layer of indirection in the form of their own CA), but is less ideal for the rest of us. It's better than only being able to hardcode pins in the browser binary, but it's a shame that it doesn't take on some of the other pain that's come up with pinning.

JetSpiegel 12y ago
If by "control the client in form of Chrome" you mean about a third of marketshare, suure.
rakoo 12y ago
AFAIU the difference between TACK and HPKP is: - For TACK, the pinned key is a custom key created just for that, and is transmitted in TLS - For HPKP, the pinned key is a CA cert key (one of the CA on the chain), and is transmitted in HTTP I think pinning the CA cert key makes more sense, because this is what they were created for: certs certify, the matter is in how you transport them. OTOH putting all the pinning information directly in the certificate makes more sense to me. We should have every domain owner running its own CA, with a cert that has all required pinning data, signing all TLS keys of the servers, and then sending the minimal chain "server cert" <- "CA cert", and then browsers would pin that cert.