Opportunistic Encryption [Was: Keys not trusted]

[Yenot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 11 May 2003 04:55 pm, Ingo Klöcker wrote:
>
> IMO making the usage of unverified keys too easy (i.e. the user
> just has to click away a warning) will result in a weakening and a
> slower growth of the web of trust.

Web-of-trust solutions can work within companies and various
communities, but the web of trust based on public keyservers will
never become a universal solution.  We should support web-of-trust
solutions (i.e. use OpenPGP), but we shouldn't ban opportunistic
encryption in order to force the growth of the Web-of-Trust.

Here's two of the reasons why "The Web-of-Trust" (the implementation
based on worldwide public keyservers) will never be more than part of
the total solution:

1)  Keysigning parties are never going to catch on with the masses.
    It's an expensive operation.  Protocols that require expensive
    operations (purchasing a certificate, attending keysigning
    parties, etc.) will never catch on with the masses.

    In order to protect the masses, we need opportunistic encryption.
    Opportunistic encryption may not prevent active attacks, but it
    kills the common case (eavesdropping).  To eliminate active
    attacks, we have direct key signing, keysigning authorities
    schemes, and the Web-of-Trust.

2)  As implemented today, the Web-of-Trust is bad for privacy.
    Advertising e-mail addresses combined with a list of your closest
    contacts (via signatures) works well for an authentication
    protocol, but it's not a good privacy protocol.

    I'm not the only one with this opinion.  50% of the residential
    phone customers in California, USA pay around $0.28 *every* month
    to keep their phone number unpublished.  The nationwide percent
    in America is only around 24%, but some of the phone monopolies
    extort as much as $6.95/month to keep a phone number unpublished.
    On top of this, I believe there have been multiple battles to stop
    American phone companies from selling name/address/phone lists
    of peoples' closest contacts based on call history. The
    Web-of-Trust forces people to disclose this very same information
    that a large percentage of the population (at least in America) do
    not want published.


Solution:

Allow all forms of authentication including no authentication at all.
Make adding keys and creating local signatures, directly from the
mail client [with or without the help of an external program], as
easy as humanly possible.


3 Authentication Levels:

L1)  No protection (unencrypted, key not available)
L2)  Passive attack protection (encrypted, key not verified)
L3)  Active attack protection (encrypted, key verified)

The difference between (L2) and (L3) could be clearly visable to the
user with clever icons. I strongly believe that we can solve this
problem without confusing the user or giving them a false sense of
security.

Also see analogous problem in current web browser implementations:
http://marc.theaimsgroup.com/?l=cryptography&m=104774889818071&w=2

For getting from L2 -> L3, I think it would be nice if programs like
KMail provided a very simple pop-up showing:
 1) fingerprint of your key
 2) fingerprint of key to be verified
 3) an "OK" button to locally sign the key

I'm fine with Kgpg or some other keymanager providing the pop-up, but
the goal is to not confuse the user. If we automate as much as
possible and allow users to climb the security chain in small,
manageable steps, OpenPGP could actually see widespread use someday.


Outstanding Question:  How to pick an unauthenticated key?

If I'm replying to a signed message (and the reply-to address matches
a UID on the signing key), I would pick the key used to sign the
received message.  If I'm starting a new message, the choice is less
obvious.  When multiple keys with no trust path exist, David Shaw
proposes that we encrypt to all valid keys.  Shaw's solution kills
the common case of passive eavesdropping (i.e. it's better than what
we have now).  Refinements to Shaw's proposal using some form of
caching might be possible.


> IMO KMail is already almost there. The only thing which is missing
> is an easy way to download missing keys. And in KDE 3.2 there will
> be KGpg which allows easy key management. If you think KMail is
> missing a useful feature then please file a wish at bugs.kde.org.

I love KMail and agree that it is almost there.  I could be wrong, but
I don't think the changes discussed above would be a major leap for
KMail or its users. I'll log my requests at bugs.kde.org, but I
thought it would be better to come to a consensus here first
[unlikely, but I have hope].

 - Yenot
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)

iD8DBQE+wPivP247TY29IxARAs0RAKCnksjwu9Ign7xM0+7katfpBDC+2QCfaFLY
EMIjCUMngGajDdJmppuVcVc=
=Z/Ol
-----END PGP SIGNATURE-----