Transcript
Perlman: I’m going to talk about identity, which is a buzzword. I hate buzzwords, because people think that they’re conveying information when they say I do identity. It’s like, there are so many pieces of it. This talk will explain all the various pieces, or a lot of them, and the various challenges with them.
What is identity? It’s a buzzword. Most people think they know what it means. If you talk about, I’m working in the identity space, they think they know what it means. There’s a lot of dimensions to it, like, what is your name? How do you prove you own that name? How do I know your name? How do you make human authentication convenient?
What does a browser need to know in order to authenticate a website? Will blockchain solve the identity problem? Because I’ve heard that’s what inspired this talk, really, was someone was saying, just use blockchain and you’ll solve the identity problem. I was thinking, really, what do you think the identity problem is? What do you think blockchain is, whatever? I’ll talk about that. We’ll discuss all these issues.
Names for Humans, and Email Addresses
Names for humans, they’re not unique. They should be. Mine is. I’m sure I’m the only Radia Perlman on Earth. You don’t have a single name. You have a different username on every site you visit. You have lots of unique identities. Sometimes, if you’re lucky, you can use the same username on more than one site. Email addresses are sometimes used as unique identifiers. They’re unique. An email address might be reassigned, so if you are John Smith at your company, and you leave, and they hire someone else, they might get the email address, John Smith.
Even though there’s a spec someplace that says, never ever reassign an email address to somebody else, just because things are written into a spec doesn’t mean they’re true. An email address can be shared by multiple people. It’s common for a human to have lots of email addresses. In a company, the first John Smith gets the email address john.smith, maybe even John. The next John Smith they hire has to be some variant, like Johnny Smith, or john.q.smith or something.
If you want to send email to somebody, you look in the corporate directory, and there’s six different possible email addresses, how do you know which one to send to? Then, it’s hard enough to delete spam, just under regular circumstances, but suppose there’s a really important other John Smith at your company, and you get this obscure stuff, how do you know whether it’s spam or some important thing that you have to forward to them?
I got a taste of that once, recently where I got this obscure email, it says, please refer to below GDS, with some Excel spreadsheet. Of course, I deleted it. I got this around five more times, and I deleted it each time wondering, how did I get on this obscure mailing list? Then, it got forwarded to me again, and they said, everyone has replied except Radia. It’s like, was I supposed to respond to this thing? I reply all, and I said, “I’m confused, what is this about?”
The person said, please check with SC3 team, and gave me some email address. I forwarded the entire thread to whoever that was. I said, do you know what this is about, they said to ask you? The person said, if I understand correctly, you’re asking about the availability of part number PNXHY in COV. This is literally what they sent to me, me a human being. I said, I have no idea what these two things are, the entire email is totally mysterious to me. Then they figured out after a while that there’s another Radia at Dell, and Outlook when you type Radia, fills it in, and people just assume Outlook knows what it’s doing.
This happened to me with a name like Radia, imagine people with more common names, this must happen to them all the time. The way I would solve the problem, if I were a hiring manager, and I’d be hiring somebody, and I’d say, “Your resume is really impressive. We need someone just like you, but we already have a John Smith, so we can’t hire you.” Then parents would get more creative like mine. I don’t know how you can be pregnant for 9 months and have all this time to think about names and you say, John. When I sent the email to the other Radia at Dell, and I said, “We both have the same name.” They never responded.
Website Names
Website names. There’s DNS names that we’re all familiar with, things like dell.com. There’s some registry organization that administers names within that top level domain. There’s .com, or .org, .tv. There’s over 1500 top level domains. That means you can purchase a name from any of those 1500 top level domains. It’s not like, there’s this evil monopoly here, or anything. If the string that you want as your name is available within that top level domain, usually, you can get it, though some things like .edu and .gov are fussy, or they have to prove that you really have a right to the name.
Yes, if you get something like drugs.com, that you don’t sell drugs, or at least on the internet, or something, and you think it’ll be valuable, then you can sell the name for lots of money, or there’s lawsuits and things. Let’s just assume that a website gets a DNS name. The theory is so beautiful. I work in cryptography and protocols. It’s something that I really assumed we’d solved. Everyone uses HTTPS all the time.
The crypto is wonderful. The protocols are wonderful. If you want to talk to x.com, you say, prove you are x.com. It sends you a certificate. You do cool cryptography. Then you have a cryptographically protected conversation. What could go wrong? We’ve solved that. In reality, usually, the user doesn’t start with the DNS name. They instead do a search and they get this obscure URL string, like that’s a URL string. Again, we’re humans, we shouldn’t see things like that.
I wanted to renew my Washington State driver’s license, so I knew it could be done online. I did an internet search for renew Washington State driver’s license, and I got the search results. I clicked on the top listed site. It didn’t occur to me that the top search wouldn’t be correct. This was the top search. If I’d been paying attention, it did say Ad, but often the real thing goes first anyway. The DNS name looked fine to me, even if I had bothered looking at it, which I’m not sure whether I did. I clicked on it and I got this website, which was very well organized, and look how happy the people are in that. It couldn’t possibly be a scam.
I clicked on Renew License, and it asked me everything I expected, which was my license number, my address, and my credit card number. I was pleased that I had successfully done that chore for the day. I wouldn’t have thought anything of it. I probably would have wondered in a month or so when I didn’t get my license and try to figure out what happened. The criminals that were putting up these websites were too greedy. The first day they charged 3.99, the next 9.99, next day 19.99, at which point, the bank fraud department called me and said, are these legitimate charges? I realized what happened. I said, ok, this is what probably happened. They said, fine, and they disallowed the charges, and they gave me a new credit card number. I was not harmed in any way.
As a matter of fact, this is such an incredibly useful example, because we focus on the cryptographic algorithms that provably secure cryptographic algorithms and protocols and all that, but there’s this really missing piece, which is assuming that humans will a priori know the DNS name that they’re supposed to go to. Don’t blame the user, scam sites can appear first. They can have perfectly reasonable looking DNS names to a human.
They can either appear first because they pay the search engine companies, or they understand the ranking algorithm and can game the system. This particular scam, at the time, it had several different names, like washingtondmv.org, and whatever. Also, for all 50 states, ohiodmv.org, and so forth. I do believe the particular scam has gotten shut down now. I’m a little disappointed because I wanted to get more screenshots.
There should be an easy way for users to report scams, but I didn’t know what to do. Once I realized that was a scam, who do I tell? I happened to know Vint Cerf at Google. I sent him an email saying, what do I do? I don’t know if that helped. Eventually, they seemed to have figured it out and shut that down. The site I should have gone to was that. Why should I as a human know that that was the right site, DOL, departmentoflicensing.washington.gov? People have told me, you should have known it was .gov. No, I support the humans right to not know obscure things like that.
In my book, the security book, I wrote this little paragraph. Once I wrote it, I said, yes, this captures everything. Everyone should memorize it and take it to heart. I’ve seen it on quote words. “Humans are incapable of securely storing high-quality cryptographic keys, and they have unacceptable speed and accuracy when performing cryptographic operations. They are also large, expensive to maintain, difficult to manage, and they pollute the environment. It is astonishing that these devices continue to be manufactured and deployed, but they are sufficiently pervasive that we must design our systems around their limitations.”
User Authentication
User authentication, a human has zillions of username-password pairs, how do you cope? Let’s say that you follow best practices. You make long, complex passwords. There’s different rules for each site. Some sites, your password can be no longer than this, must contain special characters, must not, whatever. You should, of course, change your password frequently. You shouldn’t have to. You shouldn’t reuse passwords at multiple sites, or even use similar passwords at different sites.
This is just not possible. Creative minds can make it worse. Password rules, they won’t divulge what the rules are until you are actually resetting a password. If you can’t quite remember what you had set your password to, if you could at least say, can you tell me what your rules are for passwords? Maybe that would help, but they won’t tell you until you’ve totally given up then you have to go through this arduous password resetting thing.
If you forget your password and go through the annoying, alternate proof of your identity, you’re not allowed to reset your password to what it had been before, even though that password was perfectly ok to use, except you’d temporarily forgotten it. This instruction I saw recently, password must be at least 8 characters, containing at least one uppercase letter, one lowercase letter, at least one number, at least one supported special character, and no unsupported special characters.
Security questions, who comes up with these? This was actually a list that I went through at some site: father’s middle name. My father didn’t have a middle name. Second grade teacher’s name. I couldn’t remember my second-grade teacher’s name when I was in second grade. Veterinarian’s name. I don’t have a pet. Favorite sports team. What’s a sport? My middle name. I do have a middle name, it’s Joy, so I typed in J-O-Y. It said, not enough letters.
How to make things somewhat usable, you can use an identity provider. That means like you say, you authenticate with Facebook, meaning you have to link your identity at site x with your Facebook identity, and then Facebook will vouch for you at site x. If someone guesses your Facebook password, they can impersonate you everywhere. If the identity provider is broken into, all users are compromised everywhere, so that’s scary. You could use a password manager.
Browsers like Chrome helpfully remember all your username passwords everywhere. I love it. I use it all the time. It’s terrifying, because the company knows all of your username and passwords in the clear, because it will tell you what they are. Or you could maintain a file somewhere of username-password pairs. You can even encrypt it with a single good password or don’t even bother encrypting it. In order to use it, you’re going to have to decrypt it, so malware on your machine can now steal all your usernames and passwords.
What about biometrics? I hate it when people say, if your fingerprint gets compromised, you have nine other fingers. It’s like, what are you talking about? You can’t use biometrics assuming they’re secret. You can’t say, I’m Radia, see, this is what my fingerprint looks like. They can be useful for local authentication, like unlocking your iPhone. This is a little bit deeper, but it’s something I’m really passionate about, which is trust rules for PKI. You’ll see what I mean.
We have a certificate authority that signs a message saying this name has this public key. It should be that when you get a DNS name, when a website gets a DNS name, it also gets a certificate. It doesn’t do it that way. Instead, the website purchases the DNS name from, let’s say, .com, in this case, my favorite website, which is rentahitman.com. It’s a real website. It was intended as satire. It has little services like, you can type your credit card here, and it will let you know whether it’s been compromised or something.
Occasionally, they get people that earnestly want to hire a hitman. If these people look serious, they send them off to the FBI. The website gets a DNS name like rentahitman.com. Then it has to go to a totally different organization to get a certificate saying, “Would you please, you CA person, here I’m paying you money for a certificate. I would like you to sign this certificate that vouches that I own the name, rentahitman.com, and this public key.
” Why should the CA believe you that you have that DNS name? There’s no standard for how to do this, but there’s various ad hoc mechanisms. One example is, you say, sign this certificate that I have this DNS name. When you get the DNS name, there’s a DNS entry in there with your IP address. The CA looks up that name and DNS, finds the IP address, and sends a message to that IP address, and if you can receive that, sort of like getting a PIN on your phone, it assumes that you own the name. Then it’s willing to sign your certificate. If being able to receive at a specific IP address is secure, we don’t need any of this fancy crypto and certificates and stuff. Just put your IP address and DNS.
Standards
Standards. I’m always curious how standard A compares to standard B. It doesn’t seem like anyone else does that, when there’s things that are similar. If I ask an expert, who’s an expert in A, how it compares with B. They say, A is awesome and B sucks. You ask a B person, you get the opposite answer. If there’s things that are better about B that come out after all the arguing, no problem, the A people steal the ideas. Nobody cares about the technical content of their specific, they just want credit for it.
I tell people that it’s natural to think of standards bodies as well-educated technologists that are carefully weighing engineering tradeoffs. A much more accurate way to think of them, I claim, is as drunken sports fans. Standards bodies, here’s an example where instead of inventing something new, which is what standards bodies tend to do, even if there’s something perfectly reasonable out there.
Here’s an example where a standards body adopted a syntax that was invented by a different standards body. Ordinarily, I would applaud them. In this case, what’s a certificate? It matches a name to a public key. Someone signed something saying that Radia’s public key is that. The IETF’s PKIX group decided to base certificates on X.509, which was a different sports team, which should have been fine.
Why should it matter? The problem with X.509 is that it maps an X.500 name to a public key. What’s an X.500 name? It’s a perfectly reasonable hierarchical namespace. An example of an X.500 name is like DNS names. It’s in the opposite order, but that’s ok. Instead of just string.string, it has a string type.
The most significant one is C=countryname, and then O=organizationname. Then underneath that, you can have as many levels of organization unit name. Then the bottom thing is common name. X.509 would have been fine if internet protocols and internet users were using X.500 names, but they don’t, they use DNS names.
What good is something that maps a string that the application and the user is unfamiliar with to a public key? This is an example and this is what browsers in the beginning did. The human types foo.com, or clicks on a URL containing that DNS name, the site sends a certificate with an X.500 name, C=US, O=AtticaPrison, OU=DeathRow, OU=ParticularlyVilePrisoners, CN=HorriblePerson.
One strategy that was used by some early implementations was, ignore the name and the certificate, but validate the math of the signature. What security does that give? Just the warm fuzzy feeling that someone paid someone for a certificate. People invented at least three different ways of encoding a DNS name into a PKIX certificate. One was having, instead of C=, they had a new component type, which is DC for domain component, and encode something like labs.dell.com as DC=com, DC=dell, DC=labs. Or there’s a field in the PKIX thing called the alternate name, and you could put the DNS name there.
Or you could use the bottom of the X.500 name, the common name part as the DNS name. Are three ways better than one? No, because suppose a CA checks to make sure that you own the DNS name that’s in the alternate name field, but doesn’t check one of the other places? Suppose a browser is checking one of the other places? I think today’s browsers tend to accept DNS names encoded in either the CN or the alternate name and ignore the rest of the X.500 name. I don’t know what all the various implementations do. I don’t know what all the CAs do either.
Certificate Expiration
Certificate expiration, what purpose is there in certificates expiring? Typically, the expiration time is months or years. If somebody cracked the private key of the website, they would be able to impersonate the website for months. That might as well be forever. You can’t depend on, because they expire, we don’t really have to worry about the private key leaking out because it will expire.
The only thing it does is it assures a continued revenue stream for commercial CAs, because you have to keep buying a new one. Short-lived certificates, like minutes, that are acquired on demand, like you would get when you’re using an identity provider, even those are not called certificates. They do make sense. These dire warnings you get in browsers about the certificate has expired, panic, exit the building immediately, or whatever. Even worse, when the browser doesn’t specify the problem is that the certificate expired, they just say, user panic, something horrible happened about mumble-mumble.
Certificate Revocation
Certificate revocation, this is a way to quickly invalidate Alice’s certificate. There’s basically two ways, either the CA periodically posts a list of invalid certificates. Or it’s actually more secure if it publishes the valid ones, even though that’s probably a longer list, because if somebody stole the CA’s key and quietly minted a few certificates, the CA would never know.
That’s why that would be a little bit more secure. Or you could have an online revocation server where your browser can go and check to say, is this certificate still valid? The only excuse for expiration times in certificate is that generally revocation mechanisms aren’t implemented. Even though in theory, we know how to do this, apparently, it’s not really widely done.
There’s this great story about Verisign and Microsoft. Somebody managed to convince Verisign to issue them a certificate with the name microsoft.com, and some public key that was not Microsoft. No one knows who it was that did it. They probably weren’t good guys, because it was done with a stolen credit card. They got the most secure kind of certificate, which was for code signing. Now it’s Microsoft’s problem, but it wasn’t their fault. What they did was they issued a patch to their certificate, signed code checking thing, that specifically ignored that public key, and got that out before anyone actually tried to use that certificate.
PKI Models
As I said, this part is a little bit subtle, but I want people to understand it. These are trust models for PKI. One model is what I call the monopoly model, which is, you choose one beloved, universally trusted organization, embed their public key in everything. Everybody has to get certificates from them, permanently, because once you embed it in everything it’ll be really hard to change it. It’s simple to understand and implement if you’re just coding things.
What’s wrong with it? There’s monopoly pricing, because the more widely deployed it is, the harder it will ever be to reconfigure everything so they can charge more. Getting a certificate from some remote organization will be insecure, or expensive, or both. It would be very hard to ever change the CA key, to switch to a different CA, or if that CA’s private key were compromised. That one organization can impersonate everyone.
Now let’s talk about what’s deployed, and it’s worse, it’s what’s in browsers, and I call it an oligarchy. They come configured today, your browser, with hundreds of trusted CA public keys. If you try to go to Bank of America, whoever you’re talking to can give you a certificate signed by any of those 500 organizations, and your browser will tell you, yes, everything’s fine. It does eliminate monopoly pricing but it’s less secure because any of those organizations can impersonate anyone.
This is what we use all the time. Beyond the oligarchy model, you can make it a little bit more flexible, by considering the configured CAs, they’re known as trust anchors, but allow trust anchors to issue certificates for other public keys to be trusted CAs. Your browser could accept a chain of certificates. Let’s say X1 is a trust anchor, and Bob the server can send a chain X1 says this is X2’s key, X2 says this is X3’s key, X3 says this is Bob’s key.
Now we’ll get to what I call the anarchy model, otherwise known as the web of trust. The user personally configures whatever trust anchors she wants, and nobody tells her who to trust. Anyone can sign a certificate for anyone else. Whenever you have a gathering of nerds, like an IETF meeting, you have a PGP key signing party with some ritual where you say who you are, and whatever, and people can sign certificates.
Then there are public databases of certificates that are both world readable and world writable, so you can donate whatever certificates you’ve signed. If you want to find somebody’s public key, you look to see if you’ve configured them into your machine. If not, you try to grapple together a chain of certificates from one of your trust anchors to the name that you are looking for.
The problems with that, it’s not going to scale, just too many certificates. It would be computationally too difficult to find a path, if this was the way that we did stuff on the internet, billions of certificates. Even if you can miraculously find a chain that mathematically works, why should you trust the chain? If I’m in the chain, I’m really honest, but I’m also really gullible. More or less, anyone can impersonate anyone with this model.
Now I’ll talk about how I think it should work. Instead of thinking of a CA as trusted or not trusted, a CA should only be trusted for a portion of the namespace, so the name by which you know me should imply what CA you trust to certify the key. If you know me as radia.perlman.dell.com, you would assume a CA associated with dell.com would certify the key for that identity, or roadrunnermumble.socialnetworksite.com, you trust the social network site to vouch for that key.
Whether these are the same carbon-based life form is irrelevant. In order to do that, we need a hierarchical namespace and we have it, DNS. Each node in the namespace would represent a CA, or be represented by a CA. The top-down model, you assume everyone is configured with the root key, and then the root certifies .com and .com certifies xyz.com, and so forth, and you would just follow the namespace stem. Everyone would be configured with the root key. It’s easy to find someone’s public key, you just follow the namespace, but you still have a monopoly at the root, and the root can impersonate everyone.
Bottom-Up Model (Recommended)
Now I’m going to talk about the model that I recommend. It’s so obvious to me, it’s the right thing, and somehow, we’re not doing it. This was invented by my co-author, Charlie Kaufman, the co-author on the Network Security book, around 1988. It’s just astonishing to me that somehow the world hasn’t caught on to it. There’s two enhancements to the top-down model. I’ll explain what these two things are, Up certificates and Cross-certificates.
An Up certificate says that not only does the parents certify the key of the child, but the child certifies the key of the parent. You don’t have to have everyone configured with the root key. For instance, everybody at Dell, Dell manages all our laptops and things, could be configured with dell.com, as the trust anchor, and anything in the namespace, dell.com, you just go down. Anything else, it would have to go up a level until it got to an ancestor.
You start at the configured trust root. If you’re in the namespace, follow the namespace down, otherwise, you go up a level until you get within the namespace of the target name. This way, the trust anchor doesn’t need to be the root. If the global root changes, it doesn’t affect users, just whoever’s managing the dell.com CA, would have to do whatever magic it is to revoke the parent. It doesn’t affect me, as a user, I don’t have to change my key, or change my trust anchor. A compromised global root would not affect trust paths within the namespace of dell.com.
The other thing that’s useful is cross-certificates where any node can certify any other node’s key. You might think I’m reinventing the anarchy model, but I’m not. There’s two reasons for this. One is that you don’t have to wait for the entire PKI of the world to get connected, you could have two organizations, each with their own little PKI. As long as they cross-certify each other, then users in each namespace can find the keys in the other namespace. Or, even if the whole world were connected, you might want to bypass part of the hierarchy because you don’t trust the root or something like that.
You only follow a crosslink if it leads you to an ancestor of the target name. The advantages of this is that, you can build a PKI in your own organization, you don’t have to get a commercial CA and pay them for certificates. Security within your organization is entirely controlled by your organization, because the chains will not go through CAs that are not in your namespace. No single compromised key requires massive reconfiguration. It’s easy to compute paths. The trust policy is natural and makes sense.
Malicious CAs can be bypassed so that damage can be contained. Bottom-up almost got adopted. It was implemented in Lotus Notes. Charlie was the security architect for Lotus Notes. It worked just fine. Lotus Notes has unfortunately gone away. DNSSEC, Charlie went to the working group meetings and got them to put in the uplinks and the crosslinks, and then once he succeeded, he stopped going to IETF. A few meetings after that, someone said, what are these uplinks and crosslinks here for? Can anyone think of any reason for it? No one could, so they said, let’s take them out. PKIX, he made sure that they put in a field called name constraints, which allows you to build this model, but nobody uses it, so it might as well not be there.
What We Have Today
What we have today, PKIX is the oligarchy thing where any of the 500 CAs configured into your browser are trusted for anything. That doesn’t seem very secure. It does have this useless name constraint field, useless because no one implements it as far as I know. An example of why this is bad, is suppose there’s a company that wants to provide lots of services, so laptops.company.com, itconsulting.company.com? It could get a single certificate for company.com, and then put the private key from that certificate in all of these various servers, but that’s not very secure.
You don’t really want to have lots of copies of your private key. Or you could pay a commercial CA for zillions of certificates, one for each of these things in your namespace. Or you could become one of the trusted CAs, but that’s a hassle to do that. Too bad, you can’t get a single cert saying you are a CA but only for names in the namespace, company.com. DNSSEC is name based.
A company can sign certificates in its own namespace, so that’s great. It is top-down so the root could impersonate anyone, but it is much better than the oligarchy model. Start with, what problem are you solving? Too often, there’s a new thing that gets invented and people start writing up standards with format and jargon. Or they say, here’s the thing, what can I build with it? The right approach, again, is start with what problem you’re solving. What are various ways of doing it? What are the tradeoffs?
Blockchain
There was this assertion that distributed identities with blockchain solves the identity problem. What exactly is the identity problem? What is blockchain? Why do you think it’s helpful? What is blockchain? It’s not actually well defined. One way of thinking of it is that it’s a magic thing that solves everything, especially if it’s security related. Or more realistically, it’s an append only-database, world readable, and it’s stored and maintained by lots of anonymous nodes expensively.
What is this distributed identities using Blockchain thing? I’ve simplified the concept down to what it really means conceptually. Names will be hierarchical, with the top being, which blockchain is going to register your name? It’s just like a top level domain, and then a string, which is the rest of the name. Each namespace uses its own independent blockchain. Within the namespace, names are first-come, first-served, nobody in charge. What you do is, if you want a name, you look in that blockchain, look for all the strings that have been chosen, and you choose one that hasn’t been chosen yet, and you grab it by putting that name and a public key on the blockchain.
What subset of identity is this actually solving? Only obtaining a name and asserting its public key. Getting a unique ID is not a problem. We have lots of unique IDs. The current DNS is somewhat distributed. It isn’t a single evil monopoly because you can choose which top level domain to deal with. Blockchain is very expensive, among other issues, but names become meaningless strings, even more so than today.
Given that your name is QVN whatever, how am I supposed to know how to talk to you? Even if I did magically know your name, how do I map that to a DNS name, so I can reach you, I can find your IP address? It does avoid CAs because of whoever claims the name also puts the public key on the blockchain. You don’t need certificates. Since the name is a meaningless string, you could have just used public keys as your unique identifier, and do away with the blockchain. It’s far simpler and less expensive.
What doesn’t it solve? Mapping between your name and what a human wants to talk to, or mapping between the syntax and a DNS name, or, you have to invent and deploy a new DNS-like thing? Or users remembering their own private key or other credentials. Or, revocation, what do you do if your private key is stolen or you forget your private key? I was giving a talk and I claimed they did not solve this, and some said, they did. I said, really? How did they solve this? He showed me a spec someplace where it said, “Saving the private key is essential. You can’t lose it. All access and control will be relinquished. Don’t lose a private key, please.” The solution is, ask users very nicely not to lose their key.
Blockchain Names vs. Current DNS
Blockchain names versus current DNS. For some reason, DNS stands on its head to prevent enumeration of all the names. I don’t know why I should care, whereas blockchain is a world readable database. Certainly, DNS could also allow you to enumerate all the names. Currently, when user U contacts website W, W sends a certificate.
A certificate is so much smaller than the entire blockchain, which here it’s assuming that your browser can look through the whole blockchain to find out the public key associated with that name. Back to identity, nothing is quite right today. Names really are just meaningless strings, which can trip people up like I got tripped up.
Getting a certificate is messy and insecure. The trust paths of certificate is really world, make it name based. If we were to deploy DNSSEC, it would be so much better over PKI. The DNSSEC people said, do not call this a PKI, or else the PKIX people will kill us. Human authentication is unusable and insecure. Blockchain and distributed identities are not going to help. It is amazing things work as well as they do. We don’t know how to solve all these problems.
Summary
Always start with what problem am I solving, and compare various approaches and do the best one. Rather than saying, blockchain, how can I use it? Or, how can I somehow inject it into this application? I gave a talk once where I said that, and then an engineer came up to me and said, “That sounds good but my manager really wants me to use blockchain.” I said, “Fine. Do what I said.
Look at various alternatives, choose the best one and build that. Then tell your manager you used blockchain, he’ll never know the difference.” In my book, Interconnections, I have these little boxes that I call real-world examples to illustrate a point I’m trying to make. When I’m talking about scalability, I talk about the wineglass clicking protocol, which works fine with 5 people, but if you have 11 people, everyone has to click everyone else’s glass, it really doesn’t scale well.
The point I was trying to make in the book for this particular anecdote was, you should know what problem you’re solving before you try to solve it. This anecdote is 100% true and will forever cement in your mind that you should know what problem you’re solving first. When my son was 3, he ran up to me crying, holding up his hand saying, “My hand.” I took it and I kissed it a few times. “What’s the matter, honey, did you hurt it?” He said, “No, I got pee on it.”
See more presentations with transcripts
