[messaging] Metadata free instant messaging protocol, with basic spam throttling

[Nadim Kobeissi]

This was a really awesome post! Mike's posts are consistently blowing my 
mind. :-)

I wonder if applying Mike's suggested protocol to voice calls requires 
having the entire call go through Tor.
This feels like it could be problematic given that voice calls depend 
much more on low latency than text messages.

For one, it definitely seems feasible to handle the ZRTP key 
establishment phase using Mike's protocol (over Tor, using tokens + 
group signatures), but how would the streaming of the actual call 
ciphertext bytes take place? Unlike text messaging, which are 
asynchronous and push-based, voice call ciphertexts are synchronous 
bi-directional streams. So you can't just include the payload in the 
initial group-signed message like you would in text messaging.

If both parties are using Tor, then you could certainly just have two 
anonymized clients streaming encrypted bytes at each other through 
STUN/TURN servers after the initial metadata-free key exchange, and that 
would be fine. But can Tor really handle the low latency required by 
voice calls? Is there another way to do this? I'm curious to hear your 
thoughts.

Regards,
NK

------ Original Message ------
From: "Moxie Marlinspike" <moxie at thoughtcrime.org>
To: messaging at moderncrypto.org
Sent: 2014-09-29 9:11:00 PM
Subject: Re: [messaging] Metadata free instant messaging protocol, with 
basic spam throttling

>
>Thanks Mike, this is a great writeup. This has come up in conversation
>with with Trevor, Mike Perry, and some other folks over the past few
>weeks, so maybe it's something in the water.
>
>In some ways, I think approaching this for calls is easier than 
>messages
>as a first cut. For messages, there are currently "linkable" counters
>and metadata in axolotl headers that are part of the message (axolotl's
>"header keys" extension isn't used in TextSecure because of transport
>space constraints), which we'd have to deal with first.
>
>Some other constraints we have to deal with:
>
>1) Clients need to be relatively free to re-register at will. People
>uninstall and reinstall all the time, or unregister and then 
>re-register
>for push messages. So if a server signs some stuff at setup time, it's
>worth considering that we can't constrain that to be the only time.
>
>2) I've been really hesitant to introduce any disk writes into the
>message/signal delivery path. Right now rate limiting is done by
>building a leaky bucket into a memcache key indexed off the user's
>authenticated identifier. The whole path is read-only at the moment,
>and that's pretty important to me. If we're interested in designing
>stuff that larger providers could adopt, I believe they will have
>similar concerns. So I think we need to stay away from the disk if we
>can, which means we need something bounded that we can put in memory.
>
>3) Token reuse can cause linkability. It sounds like you're suggesting
>a token assignment and release strategy, but to my understanding, that
>means a token could be used to initiate with multiple recipients. Maybe
>that's alright, but it starts to create problems. If a journalist calls
>their mom, their partner, their colleagues, and then their source using
>the same token, it might not be a huge leap to figure out who the token
>belongs to, and thus who their source is.
>
>4) We have to be careful with signatures. We probably can't have a
>certificate that signs the whole message/signal, because then we lose
>deniability. Maybe that'd be alright for calls, but we have to be
>careful with messages. On the other hand, the server can't just sign a
>simple statement attesting to the sender's id which gets passed in the
>signal/message, because then it could be replayed by the recipient to
>spoof a call to someone else.
>
>5) We have to be careful with system-wide periodic tasks. One could
>imagine having every client get a new batch of blinded tokens every 24
>hrs, which would be timestamped to limit how many could potentially 
>need
>to be kept in memory as "used" server-side, but any periodic task that
>*all* clients perform frequently is potentially rough when you begin to
>consider how few seconds there are in the day. We're already paying
>that price for contact intersection, but the request processing is
>pretty simple.
>
>I think this kind of thing (partial metadata hiding) is possible if we
>can figure something out for the rate limiting, but the rate limiting /
>abuse monitoring appears to be the hard part so far.
>
>- moxie
>
>--
>http://www.thoughtcrime.org
>_______________________________________________
>Messaging mailing list
>Messaging at moderncrypto.org
>https://moderncrypto.org/mailman/listinfo/messaging