I think that presence signing would have been a cool feature, but not necessary. It'd be cool to know that when I see Alice online, it's definitely Alice. However, the JEP focused on the important issues of message signing and verification.

Plus, presence signing would have raised the question of how would a client show that Alice is online (signed) versus Alice is online (unsigned). I would guess that this was enough of a headache (for little gain) for the authors to decide to leave it alone. And having left it alone, they clearly stated that.

Yes, the presence signing is way down the list of priorities.

There is a mad desire in the cryptography world to deliver a complete solution. What people fail to realise is that often, a little crypto, applied opportunistically, will deliver 100 times as much effective security as a complete system that is hard to utilise.

Simply because, if the crypto can bootstrap and work without user intervention, it can spread quickly and easily to all. Few people if any face sophisticated attacks, and when or if they do, it is far easier to deal with it once the basics are deployed.

You can see this most clearly in the failure of SSL. When you are reading this, your activity is unprotected by crypto. That's because the early crypto designers thought they knew better than you how to protect your traffic, and consequently denied us all the chance to do so.

Currently, only about 1% of browsing enjoys some basic protection. Even less of email. That's a tragedy of software engineering, and hopefully Jabber won't make the same mistake.

I don't like this talk of "I think that presence signing would have been a cool feature", which implies that it isn't already being done. My favourite Jabber client, Psi, has had this feature for a very, very long time.

In any case, presence signing is actually quite useful. Ignoring that you're really just signing a simple string which nobody should have any interest in forging -- presumably this is your concern with its usefulness -- the signature also holds a timestamp, and of course the Key ID of the person doing the signing! You need the Key ID, otherwise there is no way to encrypt data to that person. It also acts as a flag that the user's client supports this sort of encryption in the first place.

I suppose I don't mind clients autogenerating new keys if they don't have a key already, the only real caveat with this at present is that the key isn't trusted by the other user. All you need for this is to still permit encryption (there is a GPG flag for this) as long as a warning is displayed along these lines:

"The person on the other end of this encrypted chat is using a key which isn't trusted. Do you wish to continue to chat with this user. Continuing means that you are willing to accept that this user may not be the user you wish to talk to!"

After they confirm that, then you can't suffer a MITM attack because a MITM attack would involve the generation of a new key by the MITM, at which point an even _more_ serious warning message could be popped up.

Of course, users who have keys which are fully trusted by the receiving user, should cause no warnings to be displayed at all, and the chat should just proceed as it does in existing clients.

And fully trusted doesn't even mean they have to be marked as trusted by the user themselves. Remember that the web of trust only requires two signers of a key to be trusted before a key itself is trusted. And all you need to get keysigning to be more popular is to remove the geek stigma. And all you need for that to happen is for it to be built into the PIM application on mobile phones. Users could meet face to face and exchange keys by bluetooth, then visually confirm each other's keys to ensure they are the right ones. Easy stuff.

Anyway crypto is perpetually this technology which will be "tomorrow's technology!" I'm not sure that even removing the geek stigma will get rid of the problem, for the same reason that people still leave their car doors unlocked in rural areas. They just don't think their stuff needs protecting.

trejkaz@xaoza.net wrote:

> I don't like this talk ...

(Yes, you are correct.)

> In any case, presence signing is actually quite useful. Ignoring that you're really just signing a simple string which nobody should have any interest in forging -- presumably this is your concern with its usefulness -- the signature also holds a timestamp, and of course the Key ID of the person doing the signing! You need the Key ID, otherwise there is no way to encrypt data to that person. It also acts as a flag that the user's client supports this sort of encryption in the first place.

Right, all of which could be done more appropriately with the simply key delivery packet I proposed. Don't get me wrong, presence signing doesn't do any harm, but overloading its function may not the best way to proceed. Or, it may just be that it works and leave it well alone.

The main issue really is to think about automatic key generation and distribution.

> I suppose I don't mind clients autogenerating new keys if they don't have a key already, the only real caveat with this at present is that the key isn't trusted by the other user. All you need for this is to still permit encryption (there is a GPG flag for this) as long as a warning is displayed along these lines:

Of course. What I'm searching for is *NOT* to avoid keeping in spirit with OpenPGP's web of trust, but to get the maximum number of people up and talking with OpenPGP in *ANY* form.

It is absolutely a given that whoever does the work will move with all due speed to also add the web of trust capabilities. But in the meantime, if the client can set itself up to bootstrap crypto comms, leaving aside web of trust until later, that's a good thing. That's hundreds or thousands of people who are doing straight plain crypto comms who might otherwise be denied the benefit of crypto, and they might not even know it.

Later on they can discover the joys of WoT.

> After they confirm that...

Yup! But remember, nobody does MITM. It's the mallest issue. It's more likely that a sniper will shoot you on the way to work. And much less damaging. Nobody worries about these sort of statistical attacks, nobody wears body armour walking down the street - so why worry in the digital world?

> Anyway crypto is perpetually this technology which will be "tomorrow's technology!" I'm not sure that even removing the geek stigma will get rid of the problem, for the same reason that people still leave their car doors unlocked in rural areas. They just don't think their stuff needs protecting.

That's why I am saying there should be a button that generates a key. If I had my way, the key would be automatically generated and automatically sent. The responding client would then automatically generate a key and automatically send it.

Hey presto, the clients communicate, and there is no user intervention. Now that's a nice way to think.

iang

trejkaz@xaoza.net wrote:

>I don't like this talk of "I think that presence signing would have been a cool feature", which implies that it isn't already being done. My favourite Jabber client, Psi, has had this feature for a very, very long time.

Bad choice of words on my part, especially now that you've pointed out the utility of presence signing. I think Ian has put it more succintly in that the protocol writers recognized the potential attacks, prioritized them, and addressed the highest risk attacks while noting which were not addressed.

As Trejkaz notes it, Psi implemented OpenPGP last year. Perhaps it's not been known as much as I'd like to...

I also write frequently about practical issues and developments in security, you can check the security category of my blog. I've added you in the links.

Cheers,

F.