Florian Zeitz wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1So this is my take on summing up the problems and some thoughts about them: First up, what do we want? (Often been asked never really answered in this thread IMHO) I personally think we want something with similar (in user experience) properties to ESession (Jargon free encryption): * Encryption should be straightforward to set up/enable (just a click of a button, or automagically when support has been determined over disco) * Identity should be easy to verify * Encryption and Identity Verification should be separate things (i.e. You can talk over an encrypted connection with someone, while you don't know who he is)
Those seem like good goals.
Next up problems arising from this when using TLS: The main problem is verifying certificates (which is what this thread should be about). As far as I can see there are mainly two ways this could be done: 1. Make it possible to use a SAS/shared secret that can be compared to verify the certs 2. A CA
I agree with you that each of these may be appropriate in different contexts.
A CA seems to have many problems. It would need to certify that a JID belongs to a certain certificate. This needs to be verified in a reliable way. psa suggested to do that automatically. Now I may be wrong, but I'm under the impression that if somebody can pretend to be sending a message to you from a certain JID he should also be able to do that to a certification service too.
This is really a question about properly designing the cert generation process. First of all it is difficult to spoof packets in XMPP (it's easy for a rogue server, but if your account is hosted on server with evil admins then you have bigger problems). Second, the process might involve two different media (e.g., you send a message to the CA via XMPP, receive a link, click the link to visit a website, fill out a form, receive a second XMPP message with a request code, paste that request code into the web form, the CA generates your cert and presents it to you via the web, and you paste that into your Jabber client). Or your client could do all that automagically using x:data forms.
Another problem I see when using a CA (and doing it in an automated fashion) attacks a basic aspect of XMPP: decentralization. Such a CA would have to be central and therefore is a single point of failure.
We don't all need to use a single CA. We might begin by using xmpp.net but then encourage other CAs to get involved.
Using SAS OTOH doesn't seem to be a good method if you want to have bots or other services communicate over an encrypted session. Probably the best idea is using each when applicable. For normal user-to-user communication SAS are probably the best method. While some have argued that having to talk to somebody out-of-band is sometimes not possible, or to hard I personally consider it the only possibility if you don't have a third trusted party. As for the argument Peter brought in that he doesn't have the information to contact somebody out-of-band I'd personally argue that if you don't have that information you can never be sure who the person you're talking to really is. You may or may not always talk to a MITM or a real person you just can't tell. If you have non-human entities (set-top boxes etc.) you might want to use a CA and have that CAs certificate on each system that needs to verify an identity of an entity in your infrastructure. I'd consider this he easiest and most practicable solution. (Note that it might be worthwhile to issue xmpp.net certificates for this purpose so that there is one CA whose certificate all clients have).
Doesn't that introduce a single point of failure? ;-)
Another issue with certificates in general (that Justin Karneges already brought up) is that there should be only one certificate per JID. That means you have to get this certificate to all machines you use thataccount with.
Yes, that is a challenge.
One solution would be to store the certificate on theserver (doesn't really sound like a good idea).
I'm curious to see how that would really work.
The other would be to leave it to the user to transfer the certificate from machine to machine, which probably falls in to the "to hard" category.
Agreed.
Finally some words on the ESession debate: ESession is very nice to use as end-user and the protocol seems nice too. It's a shame that so many work writing the XEP and implementing it has went into it, when it should have been obvious from the start that it would not be considered secure basically due to the fact that it is new. OTOH it really is just that, not proven to be secure. XTLS would be relatively straight forward to define and implement because it is heavily based on technologies already, or soon to be in use. So XTLS sounds like the better option for now.
I have slowly come to that conclusion, too.
And some very last words on deniabillity: While I like Peter Saint-Andre think that courts just wont care (after all it seems to be enough if some copyright enforcement people claim a certain IP has downloaded copyrighted material (where I personally would argue that logs of that could be easily forged)) I still think it is nice to have. After all the alternative is that it is completely verifiable that it was you that made a certain statement, which is something you definitely don't want.
I'm neutral about deniability as a requirement. /psa
smime.p7s
Description: S/MIME Cryptographic Signature
