ri/blog

There are two things that I consider to be the optimistic future of the web, in their own very different categories. One is CJDNS, which makes up the cornerstone of Hyperboria and my business model. Another is Mozilla Persona, an identity system that beats OpenID and OAuth for simplicity, clarity, privacy, and possibly security.

But the real question, obviously, is whether the chocolate really goes well with the peanut butter. Hyperboria complicates things, by establishing a separate network that may or may not be reachable, independent of the clearnet. How does Persona work, and what assumptions does it make about network homogeneity, that Hyperboria might violate?

How Persona Works

Persona uses email addresses as unique IDs for logging into websites. When you try to log into a Persona-enabled website, all it really needs to verify is that you really are dortmunder@fleet.gov, ideally without that site ever phoning home your identity to fleet.gov. The site can then associate all your information around your email address.

This is accomplished by making your browser the middleman and coordinator for the authentication process.

  • First, you generate a random crypto keypair, set to expire in 24 hours or less (if it expires, you can always make a new one). This will verify that your browser is the same process across multiple requests.
  • Next, you get your identity provider to sign the keypair, verifying that it represents your email address until expiration. In the case of dortmunder@fleet.gov, fleet.gov is the identity provider.
  • Then your browser builds an “assertion”, which both specifies the site you want to log into (the “audience”), but also proves your ownership of the identity provider-signed certificate.
  • The certificate + assertion combo is sufficient to prove your identity to the Persona-enabled website, allowing you to log in.

More detailed information is available at the protocol overview. For our purposes, we are ignoring the fallback mechanism for now, and just considering the Persona model in its pure form.

The Hyperboria Wrench

Hyperboria is the main CJDNS network, currently consisting primarily of machines connected via UDP tunnels (but we’ve got a few direct connections too). The long-term future in my idealistic vision is when Hyperboria access will be more ubiquitous than the clearnet - such that you might have Hyperboria access, but no clearnet access, instead of vice-versa (most people now) or both (most current CJDNS users).

Therefore, unlike the traditional internet where everyone can talk to everyone else, we now have a split that’s tricky to bridge, with three possible states of accessibility:

  • Clearnet, but no Hyperboria
  • Clearnet and Hyperboria (usually because you’re tunneling CJDNS over the clearnet)
  • Hyperboria, but no clearnet

This means that a machine in Group 1 cannot talk to a machine in Group 3 at all, but Group 2 can talk to either of them (though for P2P applications, NATs tend to get in the way on the clearnet side, as always).

Back to Persona - who talks to who?

We have three players in any authentication. We have the user, the identity provider, and the relying party (Persona-enabled site). Who needs to have access to who, to complete the auth dance?

  • User needs to be able to talk to identity provider to create certificate
  • User needs to be able to talk to relying party to log in and use site
  • RP needs to be able to talk to IdP to verify certificate (by verifying public key)

So not only is every side of the triangle a solid line, but we actually also need SSL to talk to the IdP - which ropes in SSL Certificate Authorities - which ropes in the clearnet itself! That’s pretty bleak.

Workarounds

SSL

The biggest problem, right off the bat, is SSL’s semi-centralized cert system, which ties us to the clearnet. On Hyperboria, this is not only a breaking feature, it’s also redundant, because of the cryptographic security of the underlying platform! We can use self-signed certs, alternative authorities, and other mechanisms to cut our reliance on the SSL CAs, and just live with the redundancy on Hyperboria for the sake of simplicity (in this case, using the same security stack on and off the clearnet).

Access classifications

As for the access classifications - you could definitely go down a real rabbit hole working through all 33 permutations of which-machine-in-which-group, but I personally think it’s better to focus on best practices. Also, we focus on a simple-to-follow rule, using the group number terminology from above:

Group 2 is universally compatible, and Groups 1 and 3 are incompatible with each other.

This means that, as long as one of the points of the User-IdP-RP triangle is in Group 2, then both of its edges are taken care of. Universally compatible, you know. So as long as one machine is Group 2, and the other two machines are compatible (same group, or one of them is a 2), you have the full triangle sorted out.

It seems to me that either the IdP or the RP has a greater responsibility to be universally available, versus the User. In the ideal case, both these managed services are Group 2, which means that the User can be in any group. Most big-name IdPs will be in Group 1 (clearnet only), so it is paramount that the RP be in Group 2. Likewise, a Hype-aware IdP can compensate for a clearnet-only RP. But you’re sunk if either the IdP or the RP is incompatible with the User, as explained above.

The best advice I can offer to administrators is to always be Group 2 - available on both clearnet and Hype. Persona depends heavily on having a complete communication triangle, which means “principled stands” to only support Hyperboria actually make your site less useful to Hyperborians. There’s ultimately nothing you can do if the User and the other Server can’t get along, that’s out of your hands, but you can do your part to not be part of the incompatibility problem.

For RPs, use SSL for any clearnet logins (or if simpler, any logins in general). The above SSL caveats apply. For more information, see the Persona Security Considerations page. This particular vulnerability is obvious enough to be common sense and not explicitly mentioned on that page, but you really don’t want an attacker replaying an assertion bundle in the five minutes before it expires. Not a huge window, but in some circumstances (unsecured cafe wifi, for example), it’s enough.

In conclusion

Persona can work happily on top of Hyperboria - for some combinations of user network, IdP network and RP network. If you want to provide persona support to users, whether as an IdP or RP, then being available on both the clearnet and Hyperboria, is ideal for compatibility and making Persona-over-Hyperboria practical.