[Standards-JIG] Re: The Great Encryption Debate

David Chisnall theraven at sucs.org
Wed Aug 10 17:30:03 UTC 2005

On 10 Aug 2005, at 17:58, Ian Paterson wrote:

> We have to be very conservative when judging what is an invasion of
> privacy. Imagine Alice is Bob's jealous new girlfriend (they haven't
> exchanged keys yet), Bob has denied he ever talked to Charline, but
> Alice wants to confirm that. Bob thought his roster was private,  
> but it
> turns out...

Well, aside from the fact that Bob would probably be better off  
without Alice, this is probably true.  Of course, there's nothing  
preventing a client from popping up a thing saying `Are you willing  
to act as a key signing proxy between Alice and Charline?  This will  
disclose to each party the fact that you have communicated with the  
other' and Bob saying no.

> Yes. I guess that would give Bob a plausable excuse. But Alice  
> wouldn't
> necessarily buy it. He'd avoid a lot of grief if his trust  
> relationships
> really were private.

Well, if she has enough knowledge of the protocol to do this kind of  
sniffing then she ought to have enough knowledge to realise that the  
results aren't reliable...

> We would have to trust each server with the knowledge of all its  
> users'
> relationships... But we already do that anyway. [We can't stop our own
> server knowing who we exchange stanzas with.] So the main new issue
> would be that each server would be storing historical information  
> ready
> for 'harvesting' during a single short-lived attack.

Well, there is one way - direct connections.  If we adopted the  
variant of XMPP that Apple use for Zeroconf networks, but allowed it  
to be sent over a direct c2c SSL connection then this might be  
possible.  I am not sure if this is something sensible to do (it  
introduces all sorts of NAT-related problems), but it's another  
potential solution to the problem.  Other IM networks allow direct  
connections for chat - ICQ originally used it for everything and then  
fell back to using send-through-server if a direct connection were  
impossible (although back then NAT was uncommon).

> Unfortunately, this solution would still allow jealous Alice to  
> discover
> if boyfriend Bob is chatting to Charline (the server would return  
> Bob in
> the list of potential trust intermediaries between Alice and  
> Charline).

This would not necessarily mean that Bob had been chatting to  
Charline though - it would mean that Bob is in both Alice and  
Charline's WoT.  Since the WoT can be quite large, this could just  
mean that Bob talked to someone who talked to someone who talked to  
Charline.  If you take this to seven degrees then it could be anyone  
in the world.

> I confess I've not read up about Webs of trust. Is there always a
> privacy trade-off that doesn't exist with, for example, a centralised
> CA? (Of course I understand centralised CAs have their own significant
> disadvantages.)

I haven't really read up on them.  I came up with the concept  
independently a year or so ago as a thought experiment, and I only  
recently became aware that it was used in the real world.

> I'm sorry to be picking holes in all these very interesting ideas  
> for ID
> schemes. I guess a perfect certification scheme is impossible. So it
> will always be easier to pick holes than to come up with a good idea.

I'd much rather you picked holes in my ideas than the group ran off  
with a half-baked solution.

> P.S. I envision all chat sessions to be secure by default. So people
> would typically have more trust relationships than the number of users
> on their roster.

I would imagine that random chats (not that I've seen them  
implemented on Jabber - they seem more of an ICQ thing) would not be  
encrypted, but chats between people who knew each other would.  This  
adds an interesting dimension to the problem:

How do people get contacts?

As far as I know, there are two ways:
1) Reading about the person's JID
2) Being sent the JID in-band

Now, this raises the interesting point that we can potentially embed  
the public key in both of these.  If we add a form something like this:
<a href="xmpp::{public_key}jid">
Then it becomes possible to add contacts from a web page and  
immediately have secure conversations with them.

If we are sending roster items in-band then we can also add the  
public key.

More information about the Standards mailing list