3 ms·

I like it! This is long overdue, and I want an actual implementation. That said, I think the spec as currently written is much too slow to accept newly-seen pin

I like it! This is long overdue, and I want an actual implementation. That said, I think the spec as currently written is much too slow to accept newly-seen pins and much too eager to expire old ones. In section 3.2, it says > 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.

NateLawson 14y ago
Those are interesting comments you should probably email to the authors. Contact info should be on their website. 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.
- ivanr 14y ago
  I am not convinced the current spec addresses that particular attack well. The second visit could happen while the victim is still in the coffee shop. Perhaps a 24 hour delay on the pin activation would be more appropriate. 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.
  - NateLawson 14y ago
    If the second visit happens then, the activation is still only valid for the delta between first/last seen times. So if it's over a couple hours in the coffee shop, it's deactivated by the time you go home. TACK can definitely benefit from being paired with Convergence, so you don't have to "start cold" the first time you visit a site. 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.

NateLawson 14y ago

Those are interesting comments you should probably email to the authors. Contact info should be on their website. 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.

ivanr 14y ago
I am not convinced the current spec addresses that particular attack well. The second visit could happen while the victim is still in the coffee shop. Perhaps a 24 hour delay on the pin activation would be more appropriate. 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.
- NateLawson 14y ago
  If the second visit happens then, the activation is still only valid for the delta between first/last seen times. So if it's over a couple hours in the coffee shop, it's deactivated by the time you go home. TACK can definitely benefit from being paired with Convergence, so you don't have to "start cold" the first time you visit a site. 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.