public-key: the wrong model for email?

[Ed Gerck]

Bill Stewart wrote:

> At 10:19 PM 9/15/2004, Ed Gerck wrote:
> 
>> Yes, PKC provides a workable solution for key distribution... when you
>> look at servers. For email, the PKC solution is not workable (hasn't 
>> been)
>> and gives a false impression of security. For example, the sender has no
>> way of knowing if the recipient's key is weak (in spite of its length)
>> or has some "key-access" feature. Nonetheless, the sender has to use 
>> that key.
> 
> 
> I don't understand the threat model here.  The usual models are
 > ...

Good list, even though missing some points that are important here,
mentioned below.

The disclosure threat is that the message may be disclosed AFTER it is
decrypted (this may happen even without the recipient being at fault).
I am NOT talking about the disclosure threat. Except for the disclosure
threat, the threat model includes anything that is not under control
or cannot be directly verified by the sender.

The obvious strategy for the sender is to trust the least possible
(ideally, nothing) regarding message security.

Public-key encryption for email makes this difficult from the start.
With all the public-key fancy foot work (eg, CA certs, CRL, OCSP, etc.),
the sender still has to trust the public-key generated by the recipient
regarding its basic property to encrypt messages that can only be
decrypted by the recipient when the message arrives.

Yes, the sender can do a challenge-response using that key and confirm
that the recipient has the private-key. But what the sender does not
have, and cannot have, is any assurance that his messages are only
decryptable by the recipient. The sender has no way of knowing if the
recipient's public-key is weak (in spite of its great length), or has
some "key-access" feature, or bug, or has been revoked in the mean
time [1]. Trusting the recipient helps but the recipient may not even
know it (in spite of the recipient's best efforts).

This problem also affects SSH and anything that uses public-key crypto,
including smart-card generated keys. For email, however, it can break
message security in spite of the sender's and recipient's best efforts.

Since the sender is the party who bears most, if not all, the risk, my
question was whether email security could benefit by using a different
model. Public-key crypto could still be used, but possibly not as it
is today. Again, the problem is both technical and business-wise.

> If you _still_ want more control, set up a web server,
> and instead of sending your actual secret message, send
> Encrypt ( Key=Alice, Message="
>         ----- BEGIN PGP SIGNED MESSAGE
>         Alice - I've sent you an encrypted message at
>                 https://bob.example.net/cookie123456.PGP
>                 This URL will self-destruct in 5 business days.
>                         - Bob
>         ----- END PGP SIGNED MESSAGE
>         ")

The attacker could read the first message and download the second message.
It could make it detectable, though (but not necessarily traceable).

Cheers,
Ed Gerck

[1] The security fault happens when you (in spite of all your best efforts) send
an email message using a public-key that is revoked (eg, because the private-key was
compromised) at the time the message is received, due to various delays such as in
message transport, certificate revocation, and compromise discovery. You simply have
no way of knowing, even if the key was not listed in a CRL at the very second you
sent the message, whether the key has not been compromised at the time the message
is received. It gets worse. If the private-key is compromised any time after the
message is sent, the message can be decrypted from a cache copy somewhere -- even
if the recipient keeps the decrypted copy safe.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com