At the European Identity Conference a little while back, Andre Durand gave a downright spiritual keynote on Identity in the Cloud. His advice for dealing with the angst of moving highly sensitive identity information into the cloud? Ancient Buddhist wisdom.
All experiences are marked by suffering, disharmony, and frustration.
Suffering and frustration come from desire and clinging.
To achieve an end to disharmony, stop clinging.
(I can’t wait to hear his pearls of wisdom at the Cloud Identity Summit later this month… I’ll be there speaking on UMA. You going?)
This resonated with another plea I’d just heard from Chris Palmer at the iSEC Partners Open Security Forum, in his talk called It’s Time to Fix HTTPS.
Chris’s message could be described as “Stop clinging to global PKI for browser security because it is disharmonious.” He reviewed the perverse incentives that fill the certificate ecosystem, and demonstrated that browsers therefore act in the way that will help ordinary users least.
Why, he asked, can’t we convey more usable security statements to users along the lines of:
“This is almost certainly the same server you connected with yesterday.”
“You’ve been connecting to almost certainly the same server all month.”
“This is probably the same server you connected with yesterday.”
“Something seems fishy; this is probably not the same server you connected with yesterday. You should call or visit your bank/whatever to be sure nothing bad has happened.”
Perhaps I was the only one not already familiar with his names for the theory that can make these statements possible: TOFU/POP, for Trust On First Use/Persistence of Pseudonym. Neither of these phrases gets any serious Google search love, at least not yet. But I love TOFU, and you should too. (N.B.: I’m not a big fan of lowercase tofu.) The basic idea is that you can figure out whether to trust the first connection with a nominally untrusted entity by means of out-of-band cues or other met expectations — and then you can just work on keeping track of whether it’s really them the next time.
The neat thing is, we do this all the time already. When you meet someone face-to-face and they say their Skype handle is KoolDood, and later a KoolDood asks to connect with you on Skype and describes the circumstances of your meeting, you have a reasonable expectation it’s the right guy ever after. And it’s precisely the way persistent pseudonyms work in federated identity: as I’ve pointed out before, a relying-party website might not know you’re a dog, but it usually needs to know you’re the same dog as last time.
Knowing of the desire to cling to global PKI in an environment where it’s simply not working for us, Chris proposes letting go of trust — and shooting for “trustiness” instead. If it successfully builds actual Internet trust relationships vs. the theoretical kind, hey, I’m listening. There’s a lot of room for use cases between perfect trust frameworks built on perfect certificate/signature mechanisms and plain old TOFU-flavored trustiness, and UMA and lots of other solutions should be able to address the whole gamut.
Surely inner peace is just around the corner.
“Third, as we desire the natural order of mind
to be free from clinging, we must be free from greed.” (from the Buddhist ‘meal gatha’)
TOFU/POP – quite so. It’s crazy that we have devised systems that basically have amnesia, and forget who they last talked to. But of course, there’s no revenue stream if you take the TOFU approach.
TOFU/POP may be useful in certain use cases and scenarios, especially when you can have reasonable expectation that a trust failure (and subsequent damages) can ultimately be arbitrated. In standard commercial situations, such arbitration may involve e.g. liability waivers (through banks or credit card companies) or a judicial process.
However, I cannot see this approach work reasonably well in situations where trust failures would be too costly – obviously, health care or national security come to mind.
Gerry B.– Yep, agreed, where lives are on the line and where the various parts of the ecosystem are in (dare I say it) harmony about the value of providing “hard” authentication each time, that sounds like the right answer.
TOFU-flavored trustiness would require the browser to keep track where I am going….. this won’t particularly work well for folks who preach incognito browsing….
For higher assurance, we need “Validate on first use”. Where we ask for additional proof during the first connection. Maybe through a different channel or by reputation.
I’d claim that VOFU is in practise stronger than what we typically use today – namely (forget to) validate on every use.
(And those who want incognito browsing are unlikely to want to authenticate to anything. But they might be happy to keep their TOFU history on that encrypted USB stick along with their other browser history.)
TOFU history on a stick — delicious… And VOFU is a great idea too. One of the reasons the “artifact” or pull model (as proposed in the OpenID Artifact Binding, e.g.) is becoming appealing to me for use in UMA is that it allows for out-of-band pulling of metadata from a domain in a way that lets you confirm that you’ve got the right entity. It’s valuable for a certain level of authentication (assuming DNSSEC/no cache poisoning all around) even without digital signatures.
Great post. There used to be a pseudonym-like plugin for FF that would let you give an ssl cert a nickname.
I’d like your thoughts on how we do mutual https authentication. I have posted a response to Adam Shostack’s blog post (http://emergentchaos.com/archives/2010/09/use-crypto-not-too-confusing-mostly-asymmetric.html) which is how I found this post here: http://www.wikidsystems.com/WiKIDBlog/following-adams-advice. We essentially check the ssl cert for the user each time then get a new one-time passcode.
Interesting. This does look sort of like the approach Chris Palmer was calling for in his presentation on fixing HTTPS. Doing the check each time helps distribute the actual value of the security over the life of that online relationship, vs. front-loading all the checking. And paying attention to usability is always a good idea. :)