Questions

I had a mail from a friend who asked some pertinent questions which I thought I’d share.

Ease of use and accessibility primarily.  Internally the system boils down to binding an address with a UUID and a public key.  Whilst coming up with a one off registration for a user-name is a simple enough proposition as all the system does is speak in UUIDs, what you do with that key?  How do you “claim” that identity on multiple devices.  You rapidly get down to using a password or password variant.  I’ve had my mobile phone number for 15 years and it’s survived many devices and computers.  The other thing about it, OTR is about anonymity, this isn’t.  Many people would say it’s something they like but it does make their life harder.  Again, same with user id’s, how do you find people? You have to either ship your name around or bind it with an email address to be found.  None of these are an insurmountable problem and one of the things I’ve been thinking about is how you bind something like a phone number with say an email address if we’re less convinced about security around email addresses?  

  •  What networks will it connect to? I’m reluctant to connect to yet one more network. I already have Jabber, Skype, AIM, Google, app.net, Twitter and Facebook.

It’s a fair question, at the moment, ours, as we need to create the tunnel, but notionally the channel messages (the inner encrypted bundle which is just passed through, which we can’t read) could be sent over anything so long as the endpoint knew how to deal with them.  That’s an interesting thought actually. Also, app.net, is an interesting idea, I wonder if we could provision the service via them.

  • Do I really have to do yet one more merge of all my contacts with some new service?

No, it’s automatically built of the devices address book, another reason phones are nice, if we supported a published directory of people, I don’t see why grabbing your facebook list of contacts wouldn’t be straight forward enough and cross referencing that with our directory.

  • Will it be compatible with OTR on the other major networks? If not, I don’t see the compelling driver. If yes, what distinguishes it from the others?

The demonstrable difference is the level of privacy it provides combined with the ease of use.  OTR is clever stuff but it’s not the sort of thing that, your friends (well, your friends might being security geeks :)), family and colleagues (hmm, maybe this isn’t such a good tag line).  The other thing is the openness of the protocol, it’s ability to be examined by people like you.

  • Does it run on its own dedicated servers and such or just piggyback on some other network like AIM? What kind of reliability can I expect?

Some of it has to, directories, keystores, authentication components and SMS gateways  but certainly it could be piggybacked on other networks.  Reliability wise, the processes themselves are dirt simple.  They rely on Amazon (today, insert cloud provider here) to build highly scalable infrastructure components, we’re certainly not going to that ourselves, but we are good at building systems that use highly scalable infrastructure.  That is something we know a lot about.

  • What PKI will it use? PGP web of trust and key servers? X.509? I’d like to reuse identities that I already have that are already widely published. I’m not that keen on having yet another identity in yet another PKI.

It’s a hybrid, checkout here, here and here.  No X.509 Certificates (although we use X.509 for keys, which is really just an ASN.1 representation of a public key) and sign them with their associated UUID and address for simplicities sake.  As for identity, it’s not a new identity (it’s a mobile number), but yes, it does live in our PKI.

Advertisements

2 thoughts on “Questions

  1. I think I’d disagree that OTR is for anonymity. If you check the main page for it (http://www.cypherpunks.ca/otr/), they list their goals. One is being certain of who you’re talking to, and another is the ability to verify messages cryptographically during a conversation.

    If you’re using an ASN.1 data structure to encode a key, and then signing it for integrity, you are doing the moral equivalent of X.509, but you’re implementing unnecessary stuff from scratch. “more code == more bugs” as they say. If you used CN=+44 7777666555 and put it in an X.509 structure, you’d be done, no? You can use lots of different fields in the X.509 structure if you need more specificity.

    It’s not like X.509-based PKIs have an easy time of doing signature verification and certificate chain validation and so on. At least you can avoid some of those mistakes by leveraging something like openpki and openssl. If you don’t leverage existing approaches, you’re condemned to solve all the same problems they solved in PKI the last 20 years.

    1. I don’t mean that OTR is designed for anonymous communication but that it has a loose requirement to identify users with arbitrary identities. So you’re back to building an address book (which you don’t already have) and of course you still need some shared secret. The tradeoff with this model is that once it arrives, it’s ready to go. There is certainly a very valid use case for non-phone clients but the worry is ease of adoption and use.

      Regarding X.509, the issue isn’t actually with the format it’s with the notional hierarchy and practical management of root CA keys. Typically to validate X.509 certificates, platforms require root CA’s, kept in truststores which are centralized notions on the platform. Believe it or not, actually staying away from those reduces the number of attack vectors. Even if we manage our own truststore it’s all quite heavyweight. Silverlight and Java for instance use different encodings even with x.509 and they have to in this model exchange primitives directly. Being able to sign & verify a concatonated byte array of to two values *is* easier than trying to get every platforms x.509 libraries to interoperate, especially when they support different encodings within x.509 and not even the same ones 😦 The other thing about X.509 certificates it that in terms of bytes they are *enormous* and have lots of extraneous data which validation routine require, valid from, valid to, issuer, all of which is moot, you get them live so it’s valid *now* until they are refreshed which has to be done actively and often by the application and they’re all from me. If you have an entire phonebook of those it’s alot of data, where I can assert, to the app that the entire document of keys is valid with one signature. Otherwise each public key is indivudally signed but with the same public key. So if you have a phonebook towards the upper end of Dunbar’s number 230, one signature is 256 bytes, every phonebook refresh (which is important to proactively catch changes to keys to make sure we’re not gaming the system) lookup costs another 50k a throw. The signature on a phone book query is simple enough for it to be reasonable to get right in the implementation as to be worth the saving.

      Regarding chain validation, the hierarchy is extremely short and because of real time interaction with the central system, revocation and rotation of compromised keys.

      It is though a very valid point. The distinguishing thing for me I suppose is the complexity of PKI in general solves an absolute boat load of problems which I don’t want the overhead of having sat around unused.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s