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

[Moxie Marlinspike]

Tor doesn't support UDP, so it can't be used for VoIP (at least the RTP
phase of VoIP).  I'm mostly interested in tackling PMH at the
application layer first, before dealing with the network layer.  If we
can solve that, then we can plug something in on the network, whether
it's Tor or something else.

- moxie

On 09/29/2014 08:46 PM, Nadim Kobeissi wrote:
> 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
> 
> _______________________________________________
> Messaging mailing list
> Messaging at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/messaging
> 

-- 
http://www.thoughtcrime.org