3 ms·

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

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.

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.