SSL and the future of authenticity 3: Trust agility concept

Moxie moves on with his Defcon talk to introduce and explain the notion of trust agility and outline trust requirements under DNSSEC1 authenticity model.

I think it’s a good idea to look back at what happened to Comodo. Well… nothing happened to Comodo. But why? Why did nothing happen? What could we have done? If I decide that I don’t trust Comodo – and I don’t – the very best thing that I can do is remove them from the trust database (trustdb) in my web browser; I could say, okay, they are no longer a trusted authority. The problem is that if I do that, somewhere between a quarter and a fifth of the Internet just disappears, totally breaks, I can’t visit those sites anymore. And sure I could take an ideological stance to never visit those sites again because they are mixed up in the Comodo cabal of whatever, but really that’s no appropriate response. And the thing to remember is that this is as true for browser vendors as it is for you or me: you know, a browser vendor cannot remove Comodo from their trust database, because they’re just gonna be breaking somewhere between a quarter and a fifth of the Internet for all of their users. They are in the exact same situation that you and I are. The truth is that somewhere along the line we need a decision to trust Comodo, and now we are locked into trusting them forever.

Trust agility

Trust agility

And I think that this is the essence of what we’re looking at today, that we can buoy down all the problems that we had with certificate authorities to a single missing property, and I call this property trust agility. The idea is that trust agility provides two things: one that a trust decision can be easily revised at any time. You know, there’re many people that say “Oh, Moxie doesn’t trust anybody”. That’s not true. I mean there’re plenty of organizations that I could identify today that I trust to secure my communication – for me, you know: Tor, Riseup, EFF, Carnegie Mellon. But what seems insane is to think that I could identify an organization or a set of organizations that I would be willing to trust not just now but forever, regardless of whether they continue to warrant my trust and without any incentive to continue behaving in a trustworthy way. The second property of trust agility is that individual users can decide where to anchor their trust. This could be the same thing as saying individual browsers can decide where to anchor their trust. And I think this is important.

There are plenty of organizations that I trust to secure my communication: Tor, Riseup, EFF, Carnegie Mellon.

Right now, there’s this idea it’s a scoping problem, that VeriSign and Comodo are in the same scope and that if we just separated this scope, then if VeriSign did something particularly egregious, a site like Facebook could switch to a different certificate authority, and this would actually have some significance because VeriSign would be unable to continue signing certificates for Facebook, which is currently not the case. But, you know, I think if it’s been a struggle to get websites to deploy https for SSL, to begin with – it seems a little bit farfetched to think they’re going to continue making really active decisions in our best interests. And what’s worse in this increasingly globalized world, it doesn’t seem like it’s really possible to make trust decision for everybody; that, you know, different people live in different context with different threats, have different needs and probably trust different individuals. And so, what’s more, it’s our data that’s at risk – not the site administrator, not the company that’s operating this web service. It’s the users’ data, and I feel like it should be the users or the browsers who could decide who to trust.

Model where the user initiates trust transaction

Model where the user initiates trust transaction

This property that individual users decide where they can anchor their trust is really just a simple but powerful inversion of the way the things already work. Currently there’s three entities involved into one of these transactions: there’s the client, the server and the authority. And this trust relationship is initiated by the server. The server talks to an authority and says “Hey, please certify me”. The authority responds and the certificate is eventually given back to the user through the site. And what we are talking about here is just doing a simple inversion where it’s the user – or the client – that initiates this trust transaction and talks to the authority saying “Please certify this site for me”, the authority certifies that site and responds back to the user (see image). The reason this is so powerful is because now this means the users can decide what authority they need to talk to, which means this issue of scoping is not such a big deal, right? The fact that the Department of Homeland Security can sign sites in China is not an issue because users in China will just ignore it and talk to some Chinese authority, or they might decide they don’t trust China either and they talk to some NGO2 or something else instead. I think that these two components of trust agility are really powerful, and I think that they are exactly what’s missing from the CA system today, and that is where all the problems have come from.

Server’s certificate obtained directly from DNS record

Server’s certificate obtained directly from DNS record

So I want to take a few minutes to talk about DNSSEC because there’s been a little bit of talk recently about using DNSSEC to replace the authenticity piece of SSL. And the basic idea is this: you take your SSL certificate on your site and you shove it into your DNS record. So you have a cert, you put it in your DNS record, and when a client goes to contact a site, it does a DNS lookup, it gets back a DNS response with not only the IP address, but also the server’s certificate embedded in the DNS response (see image). That way, when they connect to the server, the certificate they see is the same thing they got in the DNS response. And this thing is going to be authentic because it’s signed, because we’re using DNSSEC.

Now, this scheme has a really immediate appeal, and I think it’s because people tend to mentally associate DNS with the word ‘distributed’, and ‘distributed’ sounds really good right now, it sounds like exactly what we need. After suffering under the centralized yoke of certificate authorities for all these years, it would feel good to just wipe them off the page or replace them with a distributed system instead.

But when you start to look closely at the way that DNS works and DNSSEC works, it’s information that is distributed, the information in the DNS records is distributed across the various zones on the Internet. But the trust is incredibly centralized and hierarchical, and this is actually exactly how the CA system works today, right? The information, the certificates are distributed across the web servers of the sites that are serving them on the Internet, and the trust is highly centralized in this hierarchy of certificate authorities.

So the next question is, okay, if it’s still centralized trust, maybe there’s something about the people that we have to trust, or maybe there’s some increased trust agility here that would be appealing. So let’s look at the trust requirements. There’re three main classes of people that you have to trust under DNSSEC.

The first is the registrars. I feel like the CA’s are sketchy, these people are taking it up a notch. Firstly, I think it should be laughable that the current first step in deploying DNSSEC is to create an account with GoDaddy – I think that should be laughable.

Trust Requirements:

– The Registrars

– The TLDs

– The root

The second class of people that we have to trust here are the TLDs – these are the companies that manage the top-level domains. So, in the case of .com and .net – the largest TLDs on the Internet – the company that manages those is VeriSign: same player, same game. If you look at other TLDs like .org and .edu, the companies that manage them are probably not companies that you’ve ever heard of. I would at least suggest that if you were to think who’s a really trustworthy company, who really has a strong sense of integrity, these companies are probably not the first that would come to mind. Take a minute to look at the organizations that manage the other TLDs and look at the executive boards, look at the people managing operations and ask yourself – are these the people that I want to trust with all of my secure communication in the future? There’s also the country code top-level domains, so does everyone that’s using TLDs like .io, .cc, .ly trust the corresponding governments for these countries to secure all of their communication? What about TLDs like .ir and .cn? Should the citizens of these countries have to trust their governments with all of their secure communication to local sites? You know, we’ve seen the current picture of what countries around the world are capable of intercepting secure communication based on the EFF ‘SSL Observatory’ data. That picture would encompass pretty much all the countries in the world under DNSSEC. And if the recent domain seizures are an indication of the future, it seems like these TLDs could be dangerous.

Really trustworthy companies are probably not the first that would come to mind.

And the third class of the people that we have to trust here is the root, and that’s ICANN3. While ICANN has made a great effort to be a sort of global organization, as far as I know – and I could be wrong – fundamentally, they’re just a California 501(c)(3) non-profit, which, as far as I know, means that they have to abide by laws in the United States. And, you know, this legislation that’s been coming up recently, like COICA4, PROTECT IP5 and this kinda thing – to me a real lesson here isn’t whether this passes or not, because there’s been some kind of heroic efforts to prevent this legislation from going through, but I think the thing to take away from this is that they’re trying to pass legislation that messes with this stuff, and maybe one day they’ll succeed, and I think ICANN would be subject to regulation in that case.

The worst part about all of these organizations is that this system actually means reduced trust agility; that today – even as unrealistic as it might be – I could still choose to remove VeriSign from my list of trusted certificate authorities, but there’s nothing that I can do to stop VeriSign from being the company that manages the .com and .net TLDs. So if we sign up to trust these people, we’re signing up not to trust them just now, but forever, regardless of whether they should continue to warrant our trust, with no ability to change our mind about whether we should continue trusting them, without any incentives to continue behaving appropriately.

Read previous: SSL and the future of authenticity 2: certificate authorities
Read next: SSL and the future of authenticity 4: Perspectives and Convergence models

1DNSSEC (Domain Name System Security Extensions) is a suite of Internet Engineering Task Force (IETF) specifications for securing certain kinds of information provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks. It is a set of extensions to DNS which provide to DNS clients (resolvers) origin authentication of DNS data, authenticated denial of existence, and data integrity, but not availability or confidentiality.

2NGO (Non-governmental organization) is a legally constituted organization created by natural or legal persons that operates independently from any form of government.

3ICANN (Internet Corporation for Assigned Names and Numbers ) is a nonprofit private organization headquartered in the United States, that was created to oversee a number of Internet-related tasks previously performed directly on behalf of the U.S. government by other organizations, notably the Internet Assigned Numbers Authority (IANA), which ICANN now operates.

4COICA (Combating Online Infringement and Counterfeits Act) was a bill introduced by Senator Patrick Leahy on September 20, 2010. It proposes amendments to Chapter 113 of Title 18 of the United States Code that would authorize the Attorney General to bring action against any domain name found “dedicated to infringing activities”, as defined within the text of the bill.

5PROTECT IP Act (Preventing Real Online Threats to Economic Creativity and Theft of Intellectual Property Act, or PIPA) is a proposed law with the stated goal of giving the U.S. government and copyright holders additional tools to curb access to “rogue websites dedicated to infringing on counterfeit goods”, especially those registered outside the U.S.

Like This Article? Let Others Know!
Related Articles:

Leave a comment:

Your email address will not be published. Required fields are marked *

Comment via Facebook: