On 19 Nov 2013, at 12:30, Ralf Skyper Kaiser <[email protected]> wrote: > Pinning does not require any protocol change in its simplest form. It can be > done with just minor changes on the client side.
Agreed - in its simplest form you could use it on the c2s connection to ensure the server’s certificate hasn’t unexpectedly changed and there’s nothing to stop xmpp clients implementing it. But this is only a small part of it. XMPP is federated, so how does a user ensure that the ongoing s2s connection isn’t compromised? Do you have to rely on your server admin to pin the certificate of every remote server their users might want to talk to? What if a user sends a message to a new server? Do we deny access until the server admin has accepted the certificate? Otherwise should we connect anyway and inform the user somehow that the remote connection can’t be trusted, or do we let them think everything’s fine? And then what about the c2s connection at the other end. How do we know that hasn’t been compromised? There are so many edge cases here that I can’t see how it could be implemented in a cohesive and user friendly manner without some serious thought and protocol involved. I haven’t been following this thread very closely so some of these points may have been discussed already. The fact is that it really isn’t as simple as the web browser case. I’m just wondering whether pinning in its simplest form actually buys very much. The only use case I can currently think of for this simple implementation is for a user in an oppressive regime who wants to use a service located in a safer country and wants to be able to trust their connection to the outside of that regime (i.e. the trusted hop is the one from client to server) but it still requires that the initial connection wasn’t compromised or that they can get the key via other means. I think we also need to be careful not to downplay DNSSEC and DANE too. They are infinitely better than most of what’s happening today, so saying things like "DANE does not cut it” could be disingenuous and may deter people from implementing anything because it’s not “perfect”. As Peter said in the manifesto: it’s "This commitment to encrypted connections only the first step toward more secure communication using XMPP”. Let’s not try to run before we can walk. — Ash
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
