When you post something about a vulnerability in another messenger and completely misrepresent it, in a way that implies that you don’t understand the cause of it at all, it gives me no confidence in your system.
The root cause is nothing to do with phone numbers. It depends on two things:
- Being able to send messages to someone from some public identifier. Any messenger that doesn’t require an interactive flow for pairing devices (as some military systems do) has this feature.
- Receiving read receipts from messages. Signal allows you to turn off read receipts if you are concerned about information leaks from them.
If you actually wanted to convince people your system was better you would:
- Show that you don’t issue read receipts (which will put some people off because they are useful).
- Show how you mitigate this kind of attack, by rate limiting this kind of message, adding jitter to responses, and so on.
Email-based flows tend to not be vulnerable to this kind of attack because they do most of the processing on the server, so you’d only be able to probe the server. But you wouldn’t bother because email has so little metadata protection that you don’t need to bother with an attack like this. From what I know of DeltaChat’s group chat protocol, I suspect there is a way of triggering a similar attack by sending broadcast invalid messages and timing the error response. If you really wanted to convince people that your system is better, you’d show a security analysis that explains why I’m wrong, rather than just say ‘I don’t understand this attacks but the researchers who published it didn’t bother trying to attack the protocol I use and so I’m sure it is secure!’ That is exactly the attitude to security that makes me distrust DeltaChat.
Oh and before anyone jumps in with anything about XMPP: this attack is completely trivial on XMPP. Send an invalid iq stanza to the client’s bare JID and time the response. And this is impossible to fix without redesigning the protocol because unknown iq stanzas must be forwarded to the client to enable future extension and clients must respond with errors.
