On 21 November 2014 08:13, Nadim Kobeissi <[email protected]> wrote: > To me this is kind of a deal-breaker. If WhatsApp's servers and executives > can decide to revoke my "encryption permit" at any time, silently, > server-side and without me knowing, what's the point, at all, of having > Axolotl in the first place? Are we hoping that WhatsApp will play nice even > when faced with a court order? > > I wonder if WhatsApp can remove this server control of who gets encrypted > chats and who doesn't without having to make sure that all of its clients > exclusively use Axolotl.
I'm disappointed in this design but no more so than not having OOB key verification in the initial launch. And I'm not surprised and I'm willing to give them a bit of time on it. It's the simplest thing that works, and we can't expect a deployment as large as WhatsApp to have a 'flag day' where all its clients support Axolotl and all users can start using it right away and there's hard fail errors everywhere. Phased rollout of features and incremental availability is part of the game at that scale. I think that out of band key verification (which is the only thing that can prevent MITM) should lock a contact into using Axolotl - it's that simple.[0][1] I'm absolutely confident there will be a way to override it, and I'm sure there will be debates about the UI making it too easy to do (like clicking through SSL warnings) vs making the UI to confusing, but it should be surfaced to the user. 'This user migrated to a new device that doesn't support encryption' or 'This user has migrated to a new device and/or a new key'. > The issue here is > that even if key authentication is implemented, WhatsApp servers still > retain the capacity to selectively disable encryption on a case by case > basis. If this is the case after OOB key verification is implemented.... it would indeed be very bad. I'm hopeful it will not - we'll have to wait and see though. The difference between "WhatsApp can MITM my conversations by giving me a fake key" vs "WhatsApp can MITM my conversations by saying 'Alice/Everyone doesn't support encryption'" is still important though. While they can be seen as technically equivalent[2], I think legally they are not, because of the points Nathan raised, and because I think it'd be easier for RepressiveGov or TLA to argue "You have a switch to disable crypto, use it." How could this be solved in a world where some clients will not support Axolotl[3]? Well, we're trying to solve a problem anticipating legal arguments or government pressure. That means we're speculating wildly. But let's do it anyway, it's fun! Probably by moving the logic to the client. Assuming you're not already speaking Axolotl to Bob, Alice receives a new message from Bob saying "Hi I'm Bob, [here's my key/I don't support encryption]". Now the burden moves from "Just tell them encryption isn't supported" to "Modify the messages of users communicating with my target while they're in transit." But it's still a small kill switch. How do you improve that? Hrm. The first thing that comes to mind is Bob sends a signed message "I don't support encryption". But signed with _what_! What can we get running on those Nokia 900s! <_< >_> What about RSA-512? ECC in Binary Groups with a 170bit key? The goal of using this weak crypto is not to provide security - it can't be achieved without OOB verification if you assume a malicious server - it's to make the legal defense better. And that's wild speculation. -tom [0] Technically speaking this is by no means simple because of multi-device support. First you need to sync all your WhatsApp devices to authenticate each other's device keys. Then you need to either support a mode where one of the user's devices supports Axolotl but another doesn't OR decide that in that case the user doesn't get crypto. And when you do out-of-band key verification, you need to transfer all that information or transfer information that authenticates that information. (And don't forget allowing Bob to receive an (authenticated-by-Alice) message saying 'please also encrypt to my Nexus5'. And don't forget allowing Bob to receive an (authenticated-by-Alice) message saying 'I just got a Nokia 900, please stop encryption its tiny heart can't handle it.') [1] I'm _also_ going to assume that the client honestly does all the things it claims to do - if we reject that assumption, there's no point because the crypto could be backdoored, key escrow, whatever. [2] I wonder if this will make the debate simpler? If you think "It doesn't matter because they could give fake keys" then you're not allowed to say whatever crazy shenanigans I come up with are a bad idea - because WhatsApp could just serve fake keys and my shenanigans can't account for that. =P [3] The more difficult version of this problem is "How can this be solved in a world where some clients will never be upgraded, and I have to support the protocol they use currently, forever." _______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
