Hacker News new | past | comments | ask | show | jobs | submit login

Browser support. We've got major internet sites on board waiting to deploy it, but despite some early indications of support, the browsers have not been forthcoming. We even tried writing the code for them, but to little avail.

My sense is that Google is all-in on Certificate Transparency right now, and doesn't want anything to distract from that. However, I think a successful CT deployment is a long time coming still, and TACK could have been out two years ago. My sense is that Mozilla is just understaffed and/or waiting to follow Google's lead in this area.

Ultimately, this is the frustrating thing about trying to improve the state of secure communication today. Most of the levers are in the hands of the browser vendors, which makes it difficult for those of us on the outside to help iterate things forward.




You can see the CT peoples' comparison of CT to other technologies here: http://www.certificate-transparency.org/comparison

One serious concern I see about TACK from the browser's perspective is the support burden of dealing with server admins' lost TACK keys. HPKP has similar risks, but it seems to manage this risk in a way that is more comfortable for browsers to deal with. However, I also think that at least at Mozilla we've become more worried about the risks of HPKP than we were originally, and so there are plans to build the same kind of mechanism for dealing with DoS due to HPKP that a browser would need to build for TACK. It may be too late to get browsers to do TACK because they seem pretty committed to HPKP already and it is harder to convince them to do both. However, if you still want to try then I'd suggest presenting more clearly how browsers could deal with the "I lost my TACK key" scenerio.

The other major negative thing about TACK is that it requires the server admin to do work that can't be automated in a way that is reasonable (because the TACK key should not live on the web server). HPKP leaves more of an open door for future web servers to automatically apply it automatically (e.g. by generating pins for the end-entity, intermediates, and root keys in the chain, on the assumption that the server admin will never lose control of the private key of the end-entity at the same time he/she needs to switch CAs) or with very simplified UI.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: