Revision [3525]
This is an old revision of WebOfTrust made by BrianKoontz on 2015-03-01 01:37:39.
Establishing a "web of trust" for OpenNIC servers
There is currently no way to determine the integrity of an OpenNIC server other than through interpersonal relationships, or knowledge of the OpenNIC principals that hold a high level of trust in the OpenNIC community. With the influx of people volunteering their services to run Tier 2 servers, it is becoming difficult to keep up with which servers are trusted, and which are untrusted. ("Untrusted" in this sense doesn't mean "not trusted," but rather "not enough information available to trust".) New members often ask how they know a certain Tier 2 server can be "trusted." There is probably not a deterministic answer to this. However, I believe we can use and leverage off the "web of trust" model that GPG uses to determine the level of trust one might give to a particular user's public key (i.e., "How sure am I that this key actually belongs to the user I think it belongs to?").
Before I go further, a disclaimer: I am not a cryptographer, nor am I an expert in public key infrastructure. That said, I do read a lot on the topic, and implement several levels of encryption in my own activities, so I encourage you to do the same. This is not a GPG or PKI primer. There are folks much more knowledgeable than I who have written some very good how-tos on this topic. A good place to start would be The GNU Privacy Handbook.
Who do we trust?
The first step to implementing a web of trust is to determine who we trust enough to "anchor" our web of trust. Everybody trusts themselves. But do you trust the person I might put forward as an appropriate anchor? To trust in my decision, you would have to either (1) know me personally and trust me, or (2) know me by reputation and trust that reputation. The weakest link in any web of trust will be the anchor. If the anchor turns out to be untrusted, then any relationships between the anchor and others are immediately suspect.
It's important to establish one or more anchors that are impeccable in terms of trust. I trust the Dalai Lama, and I imagine a large number of people trust him as well, but I doubt he has the time to devote to OpenNIC given all of the other causes in which he engages. So the Dalai Lama would be a great anchor, but probably not a feasible anchor.
Some of us have been with OpenNIC since the "start". (Many probably don't know that OpenNIC has been around for 10 years, but that there was also an OpenNIC "resurrection" a few years ago that many consider to be the "start".) Personally, if I am going to be involved in an organization, I'm going to have a certain level of trust in the people who are considered the principals of that organization. It might be a high level or a low level of trust, but it's a known quantity that can be determined only at the individual level. For instance, I partake of many Google services...but I don't necessarily have a high level of trust for the Google management team. OTOH, I participate in OpenNIC, and I happen to have a very high level of trust in the the following individuals:
- Julian DeMarchi, who worked with us to help bring OpenNIC back to life.
- Jeff Taylor, who has been (along with me) members of OpenNIC since the very early days.
- Alex Hanselka, who has proven to be a trustworthy member of OpenNIC and who currently works a great deal of R&D for OpenNIC, not to mention maintainer of both our mailing list and our IRC channel.
Based on that high level of trust, I personally would have no problem establishing Julian's, Jeff's, and Alex's credentials as the "anchor" for the web of trust. While I've never met Julian personally, he and I have worked closely together the last 5 years; he has root access to some of my servers, and I have root access to some of his (and let's face it, no higher badge of honor exists than to give someone root access to your Unix server!). Likewise, I've never met Jeff personally, but I've interacted with him over a 10+ year timespan. Alex I have met personally. It's possible they are all FBI plants, and that I've been misled this entire time. But there are enough indications over the many years of working with these three that I'm personally satisfied that they are all who they say they are, and that they are persons to be trusted.
Others will have to undertake similar introspection to determine who in the OpenNIC organization they trust. If you don't trust Julian, Jeff, or Alex, and they are the anchors for our web of trust, then the web of trust will be of no use to you. But then again, if you don't trust any of us, it's highly unlikely you'll find OpenNIC a trustworthy source for your DNS needs.
How do we trust?
Without getting into a lot of cryptological details better handled by experts in the field, most people have the ability to develop a "gut feel" for a person. Is this person someone I trust? Would I trust him with my wife (or her with my husband)? Would I trust him to watch my house? Would I trust him to handle my finances? Since the vast majority of OpenNIC interactions occur virtually, most of us will never have the opportunity to meet other OpenNIC members in person. And it would be unlikely that end users of our services would want to go out of their way to meet the server op for the Tier 2 they want to use. Likewise, most server ops have no desire (nor need) to personally meet with end users to exchange trust credentials (whether that would be in the form of handshakes, conversation, or an exhange of driver's licenses).
To positively identify an individual, security experts tell us that you need to verify two of three factors:
- Something a person has (ownership factor)
- Something a person knows (knowledge factor)
- Something a person is or does (inherence factor)
A Tier 2 operator must be willing to provide to a suspicious end user one or more artifacts that satisfy the requirements above before the end user can be sure that the person they are dealing with is, in fact, who they think they are dealing with. Regarding OpenNIC, there is an added level of complexity: A relationship exists between an individual and the server that he or she operates. An end user might not be satisfied with trusting a server's operator, but she might also demand some way to determine if the server itself can be trusted.
Servers can be comprised. Even if one established, with 100% certainty, that an individual runs a given server, there is always the uncertainty that the server itself might have been compromised. IOW, how does one know that the data being served up by a specific server is, in fact, authoritative and accurate? Unfortunately, this discussion wanders off into the domain of DNSSEC and other authentication schemes, and will not be addressed here. To move further, one will have to assume that a server is at any given time serving up authoritative and accurate query replies.
So there are two subquestions that need to be answered: (1) How do I establish trust with an individual? (2) How do I verify the relationship between an individual and the server she purports to operate?
Establishing trust with an individual
This can be done a variety of ways; the GPG Privacy Guide mentioned earlier is an excellent resource. If someone is personally known to you, and you believe that person is trustworthy, then by all means offer to sign their key, and to have them sign yours. But please be judicious with your requests, and don't take it personally if someone does not want to sign your key. Signature requests that are freely granted will undermine the integrity of the ranking process to the point where there will be many servers that end up migrating to the top (most secure) part of the hierarchy. Also, please be aware that a level 1 server isn't necessarily any less secure than a level 5 server; at some point at least two level 2 ops signed their key, so the level 1 op is not unknown.
Verifying the relationship between operator and server
We anticipate storing GPG data in an LDAP scheme, tied to the authorization credentials of the operator.
Leveraging off the GPG web of trust
The concept itself is simple: T2 operators will upload the public GPG key they wish to identify with their server(s). The keys will be cached, and a nightly process will read the digital signatures of every key, create a hierarchy of keys starting with the top anchors, and rank the servers on a scale of 0 (unknown) to 5 (anchor). A T2 operator can opt out of uploading a public key; by default their server(s) will receive a score of 0. Operators with keys signed by two or more of the anchors will be graded at a 4. Operators with keys signed by other operators will be graded one grade lower than the highest two signatures on their key. So if your key has been signed by two ops, both level 4 servers, your server will be graded as a 3. Should one of those ops be downgraded to a 3, your server will conversely be downgraded to a 2. So it is to your benefit to have your key signed by operators known to you to be trustworthy and dependable.
