[Standards-JIG] Re: The Great Encryption Debate
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
> necessarily buy it. He'd avoid a lot of grief if his trust
> 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
> 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
> 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
> if boyfriend Bob is chatting to Charline (the server would return
> Bob in
> the list of potential trust intermediaries between Alice and
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
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:
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
More information about the Standards