ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Mailing lists

2015-07-25 06:11:19
Hi Daniel,

Thanks for your comments!

At Wed, 22 Jul 2015 01:30:36 +0200,
Daniel Kahn Gillmor wrote:

On Mon 2015-07-20 12:02:42 +0200, Neal H. Walfield wrote:
There are two possibilities here.

First, the mailing list software reencrypts the message.  This means
that the plaintext is handled on the server and that either the
private key material is directly on the server or it is on a smartcard
permanently attached to the server.  In the former case, the key
material can be stolen and in the later case, an attacker can send out
fake messages until the break-in is discovered.  This implies absolute
trust in the provider.  These issues limit the applicability of this
solution.

I think the goal of an attacker in most scenarios isn't key recovery,
but cleartext recovery.  an attack on the remailer service doesn't need
access to the key even if it's on a smartcard, they just want to
compromise the server enough to read the messages after the server
decrypts and before it encrypts.

I wonder if key recovery is as unimportant as you suggest.  If I were
an attacker, I wanted to spy on a mailing list, and I got local access
to the box doing the reencryption, I'd rather get the private key and
get out than maintain a presence on the box.  This would seem to
reduce the chance that I was discovered.  But, perhaps I'm
misunderstanding something.

This approach is clunky, and i agree that your approach is superior to
it for key management.  however, both of these approaches also leak the
size of the subscriber list (as well as historical join and leave dates)
in the public keyring.

Good point.  This can be mitigated by adding cover traffic.
Concretely: we update the subscriber list with a fixed frequency
(e.g., everyday at midnight) and we add / remove a number of
subscribers drawn from an exponential distribution (or vice versa).
If there aren't enough real new subscribers, then we add some dummy
subscribers.

Of course, an adversary can more or less figure out the subscriber
list by watching the SMTP traffic.  My understanding is that although
it is possible to encrypt SMTP traffic, no one actually verifies the
keys, which makes the whole thing susceptible to MITM attacks.  Of
course, a MITM attack requires significantly more resources than
simply analyzing data that is explicitly stored in a public database.

if they're re-using their normal
encryption-capable subkeys (or if they have User IDs attached) then
anyone who has access to the list's OpenPGP certificate is going to know
who all of the subscribers are.

I think what you are saying is that all posters know who all of the
subscribers are (rather than just the list admin).  I'm not sure this
is really a problem in practice.  It's normal that subscribers know
more or less who the posters are.

I haven't seen anyone re-tread this idea to use more modern crypto, but
i think it might work.

The idea is (roughly, from memory) that you're using some sort of
discrete-log-based encryption key (e.g. el gamal, encryption-capable
ECC), and the list has a public key.  All correspondence to the list is
encrypted to the list's public key.

Thanks for pointing this out.  I wasn't aware of this work.

Of course, none of this avoids the problem of a large "private" list
actually having the security of the weakest link in the group :/

True.  But that is a people problem and there is nothing we can do
about that at the OpenPGP level.


I spent some time reviewing the PLES paper that you linked to and I
see major security and usability problems with it.

The first problem is a security problem.

  - Since the user has a new private key for each mailing list, it is
    not practical to store all the keys on a smart card.  Thus, the
    keys will probably be stored on the user's hard drive.  This
    significantly lowers the practical upper bound of the security of
    the system.

The rest of the problems are usability problems.

  - When the user subscribes to a mailing list, the list manager sends
    the subscriber the private key.  The subscriber needs to import
    this.  I don't think current MUAs make this easy.

  - If the user wants to use the key from multiple machines, she needs
    to import it on all of them.  It is currently not easy to securly
    move one private key from one machine to another.  Moving many
    keys would be a serious pain.

  - It encourages a bad mind set: we tell users that private keys
    should never be exported and yet here is a counter example.


You identified two weaknesses with my proposed approach:

  - It exposes the subscriber list to subscribers (including
    historical join / leave times).

  - It exposes the size of the subscriber list to the world.

I think these weaknesses are genuine, but not severe.  Regarding the
first issue, in practice, subscribers know who the other subscribers
are (or, at least the posters).  With respect to the second issue,
this can be mitigated using cover traffic (although this would place a
large burden on the keyservers).  Nevertheless, there is no way to
stop a well funded adversary who can monitor SMTP traffic, which is a
problem for both systems.


Do you still think we should drop my proposal?


Thanks,

Neal

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp

<Prev in Thread] Current Thread [Next in Thread>