[Standards-JIG] Re: The Great Encryption Debate
ian.paterson at clientside.co.uk
Tue Aug 9 13:59:13 UTC 2005
> But what security gives https: to Aunt Tillie?
Much more than http: An attacker has to go to far greater lengths (e.g.
phishing or man-in-the middle).
I only mentioned https: because it is the only Internet security
protocol Aunt Tillie uses. Hopefully we can do slightly better than
https: For examples:
- XMPP clients should default to secure communication (unlike browsers
which default to http: and are then insecurely redirected)
- Aunt Tillie typically uses her IM contacts list to establish
communications with known correspondants (she's more likely to click on
a link in an email or on a Web page than to use her browser's
bookmarks). Clients can associate key fingerprints with contacts etc.
> IMHO it would be better to design things for a
> user a bit smarter than Aunt Tillie
I don't think it has much to do with being smart. Most people (I'm no
exception) can't be bothered to read what's in front of them, however
intelligent they are, let alone go to the lengths of verifying a
fingerprint. We won't change human nature anytime soon.
> IMHO talking about security for
> Aunt Tillie makes no much sense.
I'm not suggesting we can make Aunt Tillie 100% safe. But we can make
her safer. She is worthwhile because, IMHO, today she represents more
than 99.9% of all IM users.
> And then we my try to make some of the features accessible
> to Aunt Tillie (making things less secure for her than for
> the primary target, of course).
I totally agree that we have to address both targets and offer different
But we should initially concentrate on Aunt Tillie since it is *much*
harder to give her security than to give it to the careful minority. It
should then be relatively easy to extend the solution(s) we come up with
for her even to cover the needs of the paranoid. [Don't you find that
once you've solved the hard problem in an elegant way, everything else
usually falls naturally into place?]
If there were one perfect solution for Aunt Tillie then someone would
have found it already. There are plenty of 100%-transparent partial
The opportunistic "transitive property of trust" solution David Chisnall
described on Tue 02/08/2005 19:38 is interesting. Here is a summary:
Alice and Bob want to exchange keys. Before resorting to out-of-band
fingerprint confirmation, they may exchange lists of hashes of the JIDs
they have already exchanged keys with. If Bob finds that both he and
Alice have exchanged keys with two entities that are online: Charlie
(who he trusts) and Dave. Bob can ask Charlie to confirm Alice's
fingerprint. Alice might prefer to confirm Bob's fingerprint with Dave -
assuming she bothers to indicate a preference. Alice would only be
vulnerable to a man-in-the-middle attack if Dave was the attacker (Bob
would only need to trust Charlie).
Unfortunately Bob and Alice have to disclose part of their rosters to
I'm continually drawn by Dave's second solution (JSF certificate
authority signs server certs, servers sign the certs of their users).
But this doesn't help for e2e (since it can't trust the servers).
IMHO the JSF is going to have to bite the bullet soon and produce a JEP
that recommends some key-signing schemes (prefereably with a submission
protocol that allows keys to be signed automatically in-band) to be
incorporated into clients so that they can offer Aunt Tillie
More information about the Standards