4 ms·

> It can be made much less accessible because it's not meant to be shared with the remote side. Can be, indeed, but was not in existing implementations, to my

by md_ 5y ago

> It can be made much less accessible because it's not meant to be shared with the remote side. Can be, indeed, but was not in existing implementations, to my knowledge. My point (perhaps I was more clear in my followup comment) was that we shouldn't shed too many tears given the actual implementations did not provide the promised security gains. Were they stepping stones? Maybe. But they didn't (yet) deliver. > A client cert is also not shared among all users behind a NAT, can be durable across roaming across IPs, and is actually meant to be a security measure unlike IPs. Yes, but, bizarrely, IPs actually provide more security against some threats, as I noted. I don't think this is because IPs are a great security measure--they're not!--but because token binding as implemented was pretty weak.

SahAssar 5y ago
I feel like your comparison is not fair. IP-based threat detection is still not defending against malware or bad browser extension, and it basically cannot be improved since it relies on something that is not a security mechanism but rather a fundamental part of internet routing. It does not cooperate well with mobile roaming, VPNs, NATs or other routing mechanisms as TFA pointed out. You're comparing a fundamentally bad design that had decades of "refinement" but cannot go further to a first stab at a good idea that has many ways to improve (storing keys on hardware tokens or TPMs, preforming signing on a TEE). Storing the keys on a hardware token might even make sessions portable without having to enter secrets into an untrusted machine.
- md_ 5y ago
  Yeah, I think I agree with you there. The area for improvement for token binding or something like it is quite promising; not so for using IP signals. I think token binding itself had some design flaws that made it hard to realize these improvements, but that's not to say that I think IP signals are better (or obviate) cryptographic replacements for bearer tokens—I don't think that. I just think it's an irony of token binding's design that the design suggested an implementation which in practice provided less value than IP binding.

by md_ 5y ago

SahAssar 5y ago

I feel like your comparison is not fair. IP-based threat detection is still not defending against malware or bad browser extension, and it basically cannot be improved since it relies on something that is not a security mechanism but rather a fundamental part of internet routing. It does not cooperate well with mobile roaming, VPNs, NATs or other routing mechanisms as TFA pointed out. You're comparing a fundamentally bad design that had decades of "refinement" but cannot go further to a first stab at a good idea that has many ways to improve (storing keys on hardware tokens or TPMs, preforming signing on a TEE). Storing the keys on a hardware token might even make sessions portable without having to enter secrets into an untrusted machine.

md_ 5y ago
Yeah, I think I agree with you there. The area for improvement for token binding or something like it is quite promising; not so for using IP signals. I think token binding itself had some design flaws that made it hard to realize these improvements, but that's not to say that I think IP signals are better (or obviate) cryptographic replacements for bearer tokens—I don't think that. I just think it's an irony of token binding's design that the design suggested an implementation which in practice provided less value than IP binding.