Pond is a personal project published this weekend by Adam Langley. Adam is wicked smart and manages both Google's SSL infrastructure and Chrome's SSL implementation (and all the nifty SSL features Chrome throws in, like NPN and DNSSEC Stapled Certs). So when he tweeted about Pond, I knew it was worth a very close look. Pond is a new encrypted messaging protocol and implementation, akin to encrypted E-Mail but with some differences. This blog post is less a critical analysis of it's security or design, and is really just some initial thoughts on the architecture. It's light on the introduction, so you may want to read the project's README for background.

Permitted Senders

Firstly, Pond can be thought of similar to email. It's asynchronous, which means you can send messages to someone even if they're not 'online', and a server will receive and store them on the user's behalf. The user can in turn connect to their server and retrieve messages when their client is online. However, the first big difference between Pond and E-mail is you cannot 'pond' someone who has not permitted it, where 'pond' is me verbing the noun. This is a huge, huge difference between Pond and E-Mail, and honestly I think makes Pond much less useful than I'd like. The reason behind this is Spam, and that's not a bad reason. I'm a bit young to have been around when the 'require email to have a proof of work' arguments were ensuing, but a cursory survey indicates one argument against it was based around legitimate bulk email services. I don't know if that's relevant to Pond, so perhaps it's worth revisiting this debate.

Anyway, Pond enforces the notion of allowed senders, by using a group signature scheme. The group signature scheme allows your pondserver (analogous to mailserver) to verify that the person ponding you is a member of your allowed group, but cannot verify who exactly in the group it is. If you want to revoke the ability of someone to pond you, you can do that, but everyone on your accepted list will learn that you revoked someone.

Because messages are forward secure and the protocol is based on OTR, you the user must communicate a KeyExchange message to you intended acceptable contact out of band on a secure channel. The KeyExchange message includes less sensitive things like your server address, and private things like the private key for that particular user to participate in the group signature.

Message Sizes

All messages that are exchanged between the client and the server are 16KB - whether the user is checking his messages, sending a message, making a revocation, or otherwise. Pond currently does not support messages larger than 16KB. I wish I had a blog post written on how remailers handle oversized messages - it's not pretty. This is a hard problem. Both Mixmaster and Mixminion will chunk oversized messages into the constant-sized fragments; although Mixminion will apply a K of N scheme to allow reconstruction from a subset of fragments.

The issue with oversized messages is that they can allow a user to be deanonymized by sending them oversized messages. Send a user a 500MB message, and then watch all Remailer/Pond users to see who retrieves a 500Mb message. This is easier when the attacker is the sender of the large file but can work regardless if the attacker knows a large file is going to be sent. There's not a great solution for this problem - but it's a pretty important one to at least try to solve. It's fairly easy to anonymously/pseudonymously send text, we have a number of techniques. But sending media: images, video, pdfs - we don't have a great system for.

Future Directions

Some things I think would be worth looking much closer at:

• Does the omission of the KeyID in the OTR Protocol hurt anything?
• The implications of a KeyExchange structure being disclosed after a number of messages are exchanged.
• Is there a server DoS possibility by asserting the server must confirm the group signature of the client? Can a proof of work be inserted to ameliorate this?
• The use of ACKs makes me nervous and remind me of Read Receipts. And no one likes those. Could there be another way to ratchet DH values? Maybe prefill the server with encrypted-to-the-contact value or values to give them?
• Does the Pond Server or Client leak distinguishing information in the form of time skew? Probably, but most things do, so don't hold it against Pond.

Also, I think something else that would be worth considering is changing the notion of contacts you can communicate with, to contacts you can communicate large messages with. The changes, which are not trivial, would look like this:

1. The 16KB size is upped to something more like 128KB.
2. Your accepted contacts become the "permitted large senders" list. These users are permitted to send you messages larger than 128KB. It'd be nice to restrict them to 32KB, but this may not be possible while asserting that the server cannot read the messages for a user.
3. A server will either send the list of queued messages if the contents of the list is >128KB or whole messages if less.
4. Messages larger than 128KB are not downloaded by default - the user can choose to delete them on the server, explictly download them as one-time-large chunk, or perform a de- and re-encryption on the server to be able to download the message in 128KB chunks.
5. When an unaccepted contact wants to pond you, the server will conduct the initial steps of the DH Key Exchange on behalf of the user, packages up the sensitive parts for the user, and queue them for delivery to the user also.

That list is very handwavey - I haven't really thought through the implications of things like the de- and re-encryption on the server; or the change in threat model. For instance, if a server is compromised after an untrusted person ponds you, the attacker should not be able to read those queued messages; but if a new untrusted person ponds you post-compromise, the attacker would be able to read that message. That may be unacceptable. The IMAP/Newsgroup nature of getting a list of messages and choosing to download individual ones might be a horrible idea too. Pond is experimental. I'm happy to throw out a bunch more experimental ideas and try to figure out why they're bad ideas.

Also, I'd like to take this opportunity to thank Adam for his work. This is experimental software and an experimental protocol. But experiments are good.

Update: If you're reading this on the front page, be sure to click through to see Adam's comment response.

if 1 * 2 < 3:
    print "hello, world!"