Radical Protocol Analysis

facilitated by DKG

The Problem

• Big corporations are deciding what the protocols we use on the Internet will do.
• These have social consequences that we should try to understand.
• dkg started looking closely at X.509 certificates that are used for TLS. He found that this created an inherent social centralization because each X.509 certificate is issued by a single signer, which promotes centralization: we can't kick out misbehaving CAs easily because each cert has a single issuer only.

• Other participants: Many kinds of protocols that have consequences:
  • Mesh routing
  • DNS
  • Centralization/decentralization
  • Internet censorship issues: technology platforms reshaped what political interventions were possible
  • Data portability
  • SSL/TLS.

Bruce Schneier on power dynamics online Distributed systems on the Internet in the past, tendency toward centralization lately. Bruce uses the term "Feudalism" to describe what we are seeing lately. VPNs, wireless encryption. Standardization work is frustrating. OAUTH was well-intentioned but was harmed by standards body work and had unintended consequences, power dynamics opposite of those intended: anarchist-created tech standard had centralizing consequences.

• DKG: "OpenID had similar unintended consequences."

• The power dynamics of the protocols define what is possible, despite how awful it is to participate in the standards making process.

Rethinking how ICANN works: public comment and participation.

• Standards bodies:
  • W3C
  • ICANN
  • IETF
  • IEEE

EFF's Response

EFF has joined standards bodies and activities to prevent harm. Trying to stop a standards activity is very difficult - being the only one in the room opposed to what everyone else in the room wants to do. Are areas where we can find common ground.

Some Assumptions

• Whether or not it is important to hide what services you are connecting to, not just content of what you are transmitting.
• Whether people view preventing large-scale Internet censorship as a design goal, or just localized small-scale snooping, etc.

Some Solutions

• NPN: Next Protocol Negotiation
• TLS WG
• OpenPGP WG.
• You can learn a lot just by getting on the mailing list, coming to understand a technology by hearing people's discussions about them. Discussions can be pretty terse and assume a lot of background knowledge.
• ICANN has meeting every 4 months in a different continent for broader participation.
  • Multi-stakeholder, consensus driven, bottom up... though mainly mailing list and wikis.
  • Open to anyone to write their policy documents.
  • ICANN is explicitly consensus driven, anyone can join and BLOCK.
    • i.e. Verisign can block decisions affecting their monopoly on .com.
  • Once you get involved and participate for 2-3 years, they will pay for you to travel and participate in meeting.
  • People can have huge impact on meetings from their homes, just via mailing lists and wikis.
• W3C is relatively easy to join and there are different methods for participation.
  • You can always read all mailing lists and make comments and contribute.
  • Members pay big fees to join but you can participate without being an official paying member.
• TLS WG discussion has changed quite a bit in response to Snowden leaks.
  • Historically mostly discussion by vendors such as appliance vendors that implement TLS, like for terminators that make use of TLS more scalable.
  • Traditional concerns about upgrades and backwards-compatibility: if they sell a device that's deployed in the field then it often can't be upgraded easily, so vendors push back on changes that might cause backwards-compatibility problems.
• Vendors don't prioritize security or freedom, they have other concerns about customers' concerns that are not necessarily about end-user security.
  • One TLS WG participant works for interception equipment vendor that provides corporate equipment to spy on employees by intercepting their traffic on networks ("SSL proxies").
  • If you propose an exception that breaks SSL proxies, this vendor gets upset. Worth understanding who is involved and what their interests are.
  • If you argue with these people

Culture clash

• People from activism community, human rights community, journalism thinking about end user security.
• Corporate IT is thinking about security from point of view of the corporation, often thinking their role is to pro-actively spy on all employee communication (i.e. for insider trading.)
• DLP: data loss prevention. Comes from "loss prevention," euphemism for shoplifting.
  • DLP, preventing leaking or sale of proprietary or personal information. Used to justify employee surveillance.

DNSSEC

Specific concrete examples of protocol design questions that are active, open, unresolved right now.

Example

• DNSSEC as an example of a protocol change that's been underway for 10 years, recently become feasible to actually deploy.
  • "We're securing DNS" — against what, against whom?
  • We're securing the authenticity of DNS, which itself derives from centralized, hierarchical root zone.
  • Controlled by ICANN and delegated to sub-authorities.
  • Further delegation hierarchically, with authority flowing from centralized root.
  • DNSSEC says that we want to be able to prove that information was approved by centralized authority.
  • DNSSEC does not provide any confidentiality.
  • May actually harm confidentiality because of enumerability problem.
    • (Allows people to determine which names exist, get a complete list of all the names in the system.)
  • When you go to a network service, you have to talk to the DNS system to find out the address of the service.
  • That leaks information about your intent and interests.
  • This allows people to spy on metadata about communications which they might actually not have been able to see otherwise (e.g., because they might be able to tap traffic to DNS servers, but not tap traffic to actual servers that you connect to).
  • DKG explains why DNSSEC design allows enumeration of zone contents.
  • DNS does not preserve confidentiality of the request.
    • This improves caching possibilities.
  • Signed negative response for entire ranges of names, so you can ask about a whole set of names to infer which names actually do exist by a process of elimination.
  • DNS is not just for storing names and addresses, can store other things like keys for email addresses.
  • Are other proposals proposed to improve confidentiality and improve enumerability situation.
    • [But it wasn't even a design goal in DNSSEC! So people's intuition about the exact nature of "security" and the privacy benefits that we will get is not necessarily right.]

Mesh Networks

• Mesh networks often installed on top of IEEE standards: radio and networking standards.
• Different routing protocols enforce social standards.
• Choosing strongest path reinforces power dynamics, who has most resources in community.
• Pragmatic need for mesh networking: better usability for some situations, in developing world communities - central infrastructure is hard.
• Distributed infrastructure can be easier to build out piece by piece. Large parts of Berlin did not have broadband, full of squatters and poor people, companies don't care.
• Philosophical motivation: build infrastructure for as many people as you can.
• Implicit trust because you're passing traffic through every node in the community.
  • How trustworthy will other users actually be?
  • Will they spy on you or attack you?
• Some mesh networks promote people explicitly meeting each other as a part of the setup process to try to reinforce social ties, which might encourage trust and ethical behavior.
  • Likewise in rural communities.
  • Can be more trust in rural communities where social infrastructure depends on mutual support.
• Interesting conceptual question about whether you can trust corporations (whose customer you are), neighbors (whom you know? whom you don't know?), and one more than the other or not?
  • What do we mean by "trust", anyway?
  • What characteristics of a relationship or of another party are we relying on in a particular case?
  • For example, DKG distinguishes different kinds of "attacks" by a network, which are actually different in that they have different consequences and there are different countermeasures that we use to defend against them.
  • Similarly we might allow a particular person to do one thing for us, but not be prepared to allow them to do another thing.
  • Like DKG doesn't want his family members to write his software even though he trusts them in another sense.
  • So he suggests focusing on more specific aspects of a relationship and what can go wrong or what the specific things are that someone could do.
• In a mesh, idea to introduce randomness to spread out risk (like TOR network.)
  • though TOR network has "Guard Nodes:" if all traffic is random, attacker node can anticipate (and then detect) with high probability access to both entry and exit nodes at least once.
  • But if you don't want attacker to EVER know, "Guard Nodes" are subset - small set of entry nodes you always use. Thus probability is low.
• DNS can be used to point to local services, not just internet.

Distinguishing between mesh as local set of services vs. mesh as mechanism for Internet access

• On a mesh network if you control any single node along the path you can observe all of the (non-anonymized) traffic that flows past you, and you would be in a position to monitor, censor, block, rewrite the traffic.
• On mesh network, randomness is more about building community than security.
• Mesh networks aspire to build local content and share locally to support to community.
• But no mesh appears to achieve this on a large scale and sustainably, because users are tempted to use more convenient centralized services.
• Almost all content from South America ends up getting hosted in the U.S. and goes round-trip, almost nothing is hosted anywhere in South America, even for other South Americans.

Final thoughts

• Threat models are dynamic: my best friend today could be my enemy tomorrow, partnerships end, political developments shift.
• Protocols can change and shift, and have extension points.
• If we can think about how these things can operate differently, we can push for change.
• If this isn't working for you, we need to make noise about it.
• Can find allies within standards bodies.
• The only use case of browser people is storing credit card information, they should not be the only ones who define how the future of crypto works.
• Most protocols fail to get adopted.
• Most protocols in use today are used in ways that initiators did not anticipate, and protocols were not originally designed for.
• Discussions around certificate authority take place in CAB Forum, only major browser vendors allowed to participate.
• Four parties in TLS PKI:
  • CA
  • subscriber (site)
  • browser vendor
  • relying party (end user).
• Incentives and business relationships are not aligned very well.
• Hard to influence CAs' selections of algorithms, for example.
• Microsoft announced they will phase out SHA-1, so policy may change.