updated the nickid page

10 files changed, 86 insertions, 62 deletions

diff --git a/pages/home/en.haml b/pages/home/en.haml
index ff266d0..754458f 100644
--- a/pages/home/en.haml
+++ b/pages/home/en.haml
@@ -47,7 +47,7 @@
       %tr
         %td June
         %td 2014
-        %td #{link('email')} with #{link 'federated trust' => 'identity'} identity validation.
+        %td #{link('email')} with #{link 'automatic key validation' => 'nickid'}.
       %tr
         %td
         %td 2015
diff --git a/pages/menu.txt b/pages/menu.txt
index 931efd7..ffb3971 100644
--- a/pages/menu.txt
+++ b/pages/menu.txt
@@ -5,7 +5,7 @@ services
   chat
   technology
     infosec
-    identity
+    nickid
     routing
     critiques
 about-us
diff --git a/pages/services/email/en.haml b/pages/services/email/en.haml
index af2eb67..ff2aa9b 100644
--- a/pages/services/email/en.haml
+++ b/pages/services/email/en.haml
@@ -12,7 +12,7 @@
 
   The LEAP approach to email is to support communication with the legacy email infrastructure while also adding optional layers to the protocol that bring email more in line with modern security practices.
 
-  *Opportunistic Content Encryption:* Whenever possible, all outgoing email will be encrypted to all the recipients. Encryption keys will be automatically discovered and verified using the #{link 'LEAP Identity' => 'identity'} service.
+  *Opportunistic Content Encryption:* Whenever possible, all outgoing email will be encrypted to all the recipients. Encryption keys will be automatically discovered and verified using the #{link 'LEAP Identity' => 'nickid'} service.
 
   *Client-encrypted Mail Storage:* Incoming clear-text mail will get encrypted to the user's public key, stored in their cloud storage space, and sync'ed locally for direct access by a mail client.
 
diff --git a/pages/services/en.haml b/pages/services/en.haml
index 94f8a01..56787f3 100644
--- a/pages/services/en.haml
+++ b/pages/services/en.haml
@@ -1,6 +1,6 @@
 %h1.first User Services
 
-%p LEAP's multi-year plan to secure everyday communication breaks down into discrete services, to be rolled out one at a time. When we introduce a new service, integrated support will be added to both the user-facing #{link 'client'} and the server-side #{link 'platform'}. All communication content will be client-side encrypted, and as much of the metadata as possible. Most importantly, all LEAP services will be based on our plan for #{link 'federated secure identity' => 'identity'} and #{link 'unmappable routing' => 'routing'}.
+%p LEAP's multi-year plan to secure everyday communication breaks down into discrete services, to be rolled out one at a time. When we introduce a new service, integrated support will be added to both the user-facing #{link 'client'} and the server-side #{link 'platform'}. All communication content will be client-side encrypted, and as much of the metadata as possible. Most importantly, all LEAP services will be based on our plan for #{link 'federated secure identity' => 'nickid'} and #{link 'unmappable routing' => 'routing'}.
 
 %h2 Roadmap
 
diff --git a/pages/services/technology/client/en.haml b/pages/services/technology/client/en.haml
index c4f82b5..0bc365e 100644
--- a/pages/services/technology/client/en.haml
+++ b/pages/services/technology/client/en.haml
@@ -81,7 +81,7 @@
     If the user chooses to enable the EIP service, then all their internet traffic passes through the service provider. A nefarious provider could sniff this traffic, if it was using a cleartext protocol like plain HTTP.
   %li
     %b Notary Keys:
-    The LEAP Client will come with a set of public keys for the notaries used for #{link 'identity discovery and validation' => 'identity'}. If a supermajority of these notaries conspire or get hacked then the security of the identity system will be compromised.
+    The LEAP Client will come with a set of public keys for the notaries used for #{link 'identity discovery and validation' => 'nickid'}. If a supermajority of these notaries conspire or get hacked then the security of the identity system will be compromised.
   %li
     %b Client Software:
     Unless the user builds the client software from the source code, the user will trust LEAP Encryption Access Project for the client builds and code updates.
diff --git a/pages/services/technology/en.haml b/pages/services/technology/en.haml
index bc60a94..e261ad0 100644
--- a/pages/services/technology/en.haml
+++ b/pages/services/technology/en.haml
@@ -15,8 +15,8 @@
   Easy to use client for secure communication.
 
 %p
-  %b #{link 'Secure Identity' => 'identity'}:
-  Federated system to automate validation of cryptographic identity.
+  %b #{link 'NickID' => 'nickid'}:
+  A system for automatic discovery and validation of cryptographic identity.
 
 %p
   %b #{link 'Map Resistant Routing' => 'routing'}:
diff --git a/pages/services/technology/identity/en.haml b/pages/services/technology/identity/en.haml
deleted file mode 100644
index 27c8b8b..0000000
--- a/pages/services/technology/identity/en.haml
+++ /dev/null
@@ -1,45 +0,0 @@
-%h1.first The sad, sorry state of cryptographic identity
-
-%p Existing forms of secure identity are deeply flawed. These systems rely on either a single trusted entity (e.g. Skype), a vulnerable Certificate Authority system (e.g. S/MIME), or keys that cannot be made human memorable (e.g. OpenPGP, OTR). When an identity system is hard to use, it is effectively compromised because too few people take the time to use it properly.
-
-%p The broken nature of existing identities systems (either in security or in usability) is especially troubling because identity remains a bedrock precondition for any message security: you cannot ensure confidentiality or integrity without confirming the authenticity of the other party.
-
-%h1 NickID
-
-%p The cornerstone of the LEAP design is a system to make digital identity for messaging both secure and easy to use. We call this system NickID, since the goal is for the individual to be able to think of cryptographic identity in terms of a domain qualified nickname just as they do with email addresses.
-
-%p NickID is based on a federated structure where the difficult work is pushed to the service providers. Each provider is responsible for the due diligence of properly signing the keys of other providers, akin to the distributed web of trust model of OpenPGP. Providers also are responsible for signing the keys of their users, akin to the Certificate Authority model.
-
-%p When a user sends or receives a message, their software will discover the other party's key and trace a chain of signature's back to the user's service provider. NickID allows for identity that is verified through an end-to-end trust path from any user to any other user in a way that can be automated and is human memorable (e.g. identity in the form user@example.com).
-
-%h1 Users are not websites
-
-%p What about WebID or BrowserID (Mozilla Personas)? These are both interesting cryptographic identity standards that are gaining support and implementations. So why do we need something new?
-
-%p These protocols, and the poorly conceived OpenID Connect, are designed to address a fundamentally different problem: authenticating a user to a website. The problem of authenticating users to one another requires a different architecture entirely. There are some similarities, however, and in the long run a Federated Web of Trust could be combined with something like BrowserID/Personas.
-
-%h1 Attacks and countermeasures
-
-%p Attacks on this system can be prevented with a simple “network perspectives” approach that keeps each service provider honest. Let's enumerate the attacks and how to prevent them. Suppose two providers, A and B.
-
-%p
-  %b Attack 1 - Intercept Outgoing:
-  provider A signs an impostor key for provider B and distributes it to users of A (in order to intercept outgoing messages sent to B).
-
-%p
-  %b Attack 2 - Intercept Incoming:
-  provider A signs an impostor key for one of its own users, and distributes to users of B (in order to intercept incoming messages).
-
-%p
-  %b Attack 3 - Association Mapping:
-  A provider tracks all the requests for key discovery in order to build a map of association.
-
-%p To prevent these attacks, NickID will support independent notaries who sole purpose is to answer a single question: "Do you see the same key that I see?"
-
-%p In order to prevent attack 1, the user's client software will not blindly trust that it has encountered the correct provider key for B. Instead, it will get confirmation from the notaries that they also received the same key (or a key signed by the same key).
-
-%p In order to prevent attack 2, the user's client software will regularly query the notaries for their own key. If the notaries see a different key, the user is alerted that their provider is attempting to intercept their messages.
-
-%p In order to prevent attack 3, the user's client software will be able to use the response of a notary as the initial key discovery, and to proxy a request to one notary through another. Each notary request will be encrypted to the public key of that notary.
-
-%p For this to work, client software that supports NickID will come pre-seeded with a list of notaries and their public keys. Although this sounds like a repeat of the problems associated with the Certificate Authority system, the notaries are actually quite different. Rather than placing irrevocable trust in an authority, clients are only using the notaries for a very narrowly defined ability to provide network perspective.
diff --git a/pages/services/technology/infosec/en.haml b/pages/services/technology/infosec/en.haml
index 386ce10..35c9ddf 100644
--- a/pages/services/technology/infosec/en.haml
+++ b/pages/services/technology/infosec/en.haml
@@ -39,7 +39,7 @@
 %ul
   %li
     %b Authenticity:
-    Message security rests entirely on a foundation of authenticity. Without proper validation of encryption keys, you cannot be assured of confidentiality or integrity. Unfortunately, current system of establishing message authenticity are so difficult to use that most users simply ignore this step. LEAP will address these problems with a system of #{link 'strong and automatic identity validation' => 'identity'}.
+    Message security rests entirely on a foundation of authenticity. Without proper validation of encryption keys, you cannot be assured of confidentiality or integrity. Unfortunately, current system of establishing message authenticity are so difficult to use that most users simply ignore this step. LEAP will address these problems with a system of #{link 'strong and automatic identity validation' => 'nickid'}.
   %li
     %b Usability:
     There are plenty of high security tools that are nearly impossible for the common user to use correctly. If the tool is too difficult, it will not be widely adopted and will likely be used incorrectly by those who do adopt it. LEAP with address these problems with the #{link 'LEAP client' => 'client'} that is tightly coupled with the server-side software and is autoconfiguring.
diff --git a/pages/services/technology/nickid/en.md b/pages/services/technology/nickid/en.md
new file mode 100644
index 0000000..817f46e
--- /dev/null
+++ b/pages/services/technology/nickid/en.md
@@ -0,0 +1,63 @@
+The sad, sorry state of cryptographic identity
+==============================
+
+Existing forms of secure identity are deeply flawed. These systems rely on either a single trusted entity (e.g. Skype), a vulnerable Certificate Authority system (e.g. S/MIME), or keys that cannot be made human memorable (e.g. OpenPGP, OTR). When an identity system is hard to use, it is effectively compromised because too few people take the time to use it properly.
+
+The broken nature of existing identities systems (either in security or in usability) is especially troubling because identity remains a bedrock precondition for any message security: you cannot ensure confidentiality or integrity without confirming the authenticity of the other party.
+
+NickID
+============================
+
+The cornerstone of the LEAP design is a system to make digital identity for messaging both secure and easy to use. We call this system NickID, since the goal is for the individual to be able to think of cryptographic identity in terms of a domain qualified nickname just as they do with email addresses.
+
+With NickID, we want to be backward compatible with existing public key infrastructures, like OpenPGP and OTR, but also add additional support for automatic validation that happens invisibly in the background without the need for user intervention. NickID does this with three levels of automatic validation:
+
+**Level 1 — TOFU of user keys:** The first and lowest level of validation is to naively accept the key of another user when you first encounter it. This is often called "trust on first use" or TOFU and is used commonly by SSH (and, in common practice, how many people use OTR and OpenPGP). This level of validation is backwards compatible with existing infrastructure, but has many obvious flaws. When you TOFU a user key, you are making a bet that possible attackers against you did not have the foresight to specifically target you with a false key during discovery. TOFU of user keys can be considerably strengthened by using network perspective and by anonymizing the discovery process, but you still have problems with key expiration, ambiguous mapping between email and keys, and with attackers flooding the discovery process (for example, by filling keyservers with bogus keys).
+
+**Level 2 — TOFU of provider keys:** We can improve considerably on Level 1 with a single addition: if a service provider signs the keys of it's users, then we do not need to TOFU user keys for that provider, we just need to TOFU the provider's key. Once we have trusted the provider's key, we know to always choose the key for a user that was most recently signed by the provider. If the provider publishes their key using webfinger or DNS, then we can also piggyback (temporarily) on the X.509 Certificate Authority system to validate the provider's key. A service provider is also much less likely to lose their private key, a significant problem with TOFU of user keys.
+
+**Level 3 — Federated Web of Trust:** Although Level 2 is pretty good, we can do better by adding a Federated Web of Trust (FWOT). The system works like this: each service provider is responsible for the due diligence of properly signing the keys of a few other providers, akin to the distributed web of trust model of OpenPGP, but with all the hard work of proper signature validation placed upon the service provider. When a user communicates with another party who happens to use a service provider that participates in the FWOT, the user's software will automatically trace a chain of signature from the other party's key, to their service provider, to the user's own service provider (with some possible intermediary signatures). This allows for identity that is verified through an end-to-end trust path from any user to any other user in a way that can be automated and is human memorable. Unlike Level 2, a FWOT does not rely, even temporarily, on the X.509 infrastructure. Also, FWOT can include better mechanisms for dealing with revocation of bad actors, renewal of keys, and emergency re-key events if a provider's keys are lost. On the down side, FWOT is more complicated and would need to deploy specific countermeasures to keep an attacker from abusing the system (see below).
+
+The service provider determines what level of automatic validation is possible. If the service provider does nothing, then only Level 1 is possible. If the service provider signs user keys, then Level 2 is possible. If the service provider signs other providers' keys, then Level 3 is possible.
+
+Discovery mechanisms
+==================================
+
+It is important to not collapse concept of discovery with the concept validation. Although there is some overlap, they should be thought of as entirely distinct.
+
+Currently, no single discovery mechanism has emerged as a dominant method for key discovery. There are several proposed standards, but few people are using any of them. NickID will take an agnostic approach by allowing providers to use whichever standard they choose.
+
+To discover a key, a NickID agent will try these methods, in this order:
+
+* **Webfinger**: Webfinger includes a standard mechanism for distributing a user's public key via a simple HTTP request. This is very easy to implement on the server, and very easy to consume on the client side.
+* **DNS**: There are multiple competing standards for key discovery via DNS. When and if one of these emerges predominate, NickID should attempt to use this method when available. DNS discovery, however, has some problems. DNS discovery of keys is much harder to implement, because the service provider must run their own customized authoritative nameserver. Also, since keys can be too big for domain UDP packets, any future-proof DNS method relies on an HTTP request, thus undermining the potential benefit of decentralization you might get from using DNS rather than webfinger.
+* **Keyservers**: As a fallback, NickID agents will try the existing keyservers when other mechanisms are not supported. This should be avoided when possible, because current keyservers are vulnerable to be flooded with bogus keys. This can be improved by prioritizing responses from keyservers that add mailback verification during key registration (currently not supported by many, but easy to add).
+
+
+Users are not websites
+==============================
+
+What about WebID or BrowserID (Mozilla Personas)? These are both interesting cryptographic identity standards that are gaining support and implementations. So why do we need something new?
+
+These protocols, and the poorly conceived OpenID Connect, are designed to address a fundamentally different problem: authenticating a user to a website. The problem of authenticating users to one another requires a different architecture entirely. There are some similarities, however, and in the long run a Federated Web of Trust could be combined with something like BrowserID/Personas.
+
+FWOT attacks and countermeasures
+==========================================
+
+Most attacks on a FWOT can be mitigated with a simple "network perspectives" approach that keeps each service provider honest. Let's enumerate the attacks and how to prevent them. Suppose two providers, A and B.
+
+**Attack 1 - Intercept Outgoing:** provider A signs an impostor key for provider B and distributes it to users of A (in order to intercept outgoing messages sent to B).
+
+**Attack 2 - Intercept Incoming:** provider A signs an impostor key for one of its own users, and distributes to users of B (in order to intercept incoming messages).
+
+**Attack 3 - Association Mapping:** A provider tracks all the requests for key discovery in order to build a map of association.
+
+To prevent these attacks, NickID will support independent notaries who sole purpose is to answer a single question: "Do you see the same key that I see?"
+
+In order to prevent attack 1, the user's client software will not blindly trust that it has encountered the correct provider key for B. Instead, it will get confirmation from the notaries that they also received the same key (or a key signed by the same key).
+
+In order to prevent attack 2, the user's client software will regularly query the notaries for their own key. If the notaries see a different key, the user is alerted that their provider is attempting to intercept their messages.
+
+In order to prevent attack 3, the user's client software will be able to use the response of a notary as the initial key discovery, and to proxy a request to one notary through another. Each notary request will be encrypted to the public key of that notary.
+
+For this to work, client software that supports FWOT will come pre-seeded with a list of some of the notaries and their public keys. New notaries are then discovered and validated using consensus of these root notaries.
diff --git a/pages/services/technology/routing/en.haml b/pages/services/technology/routing/en.haml
index 35d52ed..9ea5671 100644
--- a/pages/services/technology/routing/en.haml
+++ b/pages/services/technology/routing/en.haml
@@ -4,12 +4,10 @@
 
 %p Unfortunately, existing technologies for secure routing, such as StartTLS for email or chat, are insufficient in today's environment and easily thwarted. StartTLS also does little to protect a service provider from being required to keep association records of its users.
 
-%h1 Map resistant routing
+%h1 Graph Resistant Routing (Grr!)
 
 %p One of the major goals of LEAP is to make message routing that is resistant to social graph mapping.
 
--# The LEAP design includes an improved method of encrypted transport negotiation and an system for aliased message routing to protect the social graph from even the service providers themselves.
-
 %p How would this work? Imagine users Alice and Bob. Alice wants to correspond with Bob but doesn't want either her service provider or Bob's service provider to be able to record the association. She also doesn't want a network observer to be able to map the association.
 
 %p When Alice first sends a message to Bob, Alice's client will initiate the following chain of events on her behalf, automatically and behind the scenes.
@@ -23,16 +21,19 @@
   %li Alice's client receives this alias, and records the mapping between Bob's public address and his private alias.
   %li Alice's client then relays the original message to Bob's alias.
 
-Subsequently, whenever Alice or Bob want to communicate, they use the normal public addresses for one another, but behind the scenes their clients will rewrite the source and recipient of the messages to use the private aliases.
+%p Subsequently, whenever Alice or Bob want to communicate, they use the normal public addresses for one another, but behind the scenes their clients will rewrite the source and recipient of the messages to use the private aliases.
 
-This scheme is backwards compatible with existing messaging protocols, such as SMTP and XMPP.
+%p This scheme is backwards compatible with existing messaging protocols, such as SMTP and XMPP.
 
 %h1 Limitations
 
-%p There are four major limitations to this scheme:
+%p There are five major limitations to this scheme:
 
 %ol
   %li
+    %b Alias unmasking attacks:
+    because each service provider maintains an alias map for their own users, an attacker who has gained access to this alias map can de-anonymize all the associations into and out of that particular provider, for the past and future.
+  %li
     %b Timing attacks:
     a statistical analysis of the time that messages of a particular size are sent, received, and relayed by both service providers could reveal the map of associations.
   %li
@@ -45,8 +46,13 @@ This scheme is backwards compatible with existing messaging protocols, such as S
     %b Client problem:
     if the user's device is compromised, the record of their actual associations can be discovered.
 
-%p At this point, we feel that it is OK to live with these limitations in order to be backward compatible with existing messaging protocols. The first two attacks are only possible by a very powerful adversary. One so powerful that association mapping is probably the least of your worries.
+%p At this point, we feel that it is OK to live with these limitations for the time being in order to simply the logic of the user's client application and to ensure backward compatibility with existing messaging protocols.
 
-%p This scheme is designed to prevent the casual, mass surveillance of all communication that currently takes place in repressive and democratic countries alike, by both governments and corporations. It greatly reduces the capacity for association mapping of both traffic over the wire and in stored communication. It is not designed to make a particular user anonymous in the face of a powerful adversary.
+%p Possible future enhancements could greatly mitigate these attacks:
+
+%ol
+  %li We could use temporarily aliases that rotate daily, perhaps based on an HMAC counter, based on a shared secret between two users.
+  %li The 'alias service' could be run by a third party, so that associations within a single provider are also resistant to mapping.
+  %li A service provider with sufficient traffic could be in a very good position to be able to aggregate and time-shift the messages it relays in order to disrupt timing attacks.
 
-%p However, a service provider using this scheme that has sufficient traffic will be in a very good position to be able to aggregate and time-shift the messages it relays in order to disrupt timing attacks—once researchers have a better understanding of how to effectively counter timing attacks.
\ No newline at end of file
+%p Ultimately, however, most of these attacks are a problem when faced with an extremely powerful adversary. This scheme is not designed for these situations. Instead, it is designed to prevent the casual, mass surveillance of all communication that currently takes place in repressive and democratic countries alike, by both governments and corporations. It greatly reduces the capacity for association mapping of both traffic over the wire and in stored communication. It is not designed to make a particular user anonymous in the face of a powerful adversary.