Re: [openpgp] mailing list: managing the subscriber list

["Neal H. Walfield" <[e-mail]>]

Hi Rick,

Thanks for your thoughtful response!

At Mon, 11 Jan 2016 12:01:44 +0100,
Rick van Rein wrote:
> You are getting into a topic that has my interest.  To me, a mailing
> list is just an example of encryption things to a group.
> 
> I read your proposal of back-then, but it is not wholly clear to me:
>  * You want to protect the list of subscribers you say; are these the
> email addresses or key identities that you wish to protect?

Using SMTP, it is clearly effectively impossible to protect the email
addresses [1].  But, the difference between the resources required to
downgrade TLS connections and passively observe SMTP traffic and the
resources to casually traverse some publically and permanently stored
data decades later is huge.  Thus, even though I realize it is not
possible to completely protect the email addresses, I don't want to
make it too easy to get them.

  [1] "Neither Snow Nor Rain Nor MITM...  An Empirical Analysis of
  Email Delivery Security" by Zakir Durumeric, David Adrian, Ariana
  Mirian, James Kasten, Elie Bursztein, Nicolas Lidzborski, Kurt
  Thomas, Vijay Eranti, Michael Bailey, and J. Alex Halderman.
  IMC’15, October 28–30, 2015.

  http://conferences2.sigcomm.org/imc/2015/papers/p27.pdf

Likewise, I want to make it possible to protect the key ids as much as
possible, which can be done using hidden recipients (i.e., using 0x0
for the key id in the PK-ESK packet).

>  * You say that you don't like re-encryption; is this for reasons of
> efficiency, or for reasons of passing the plaintext through the control
> of the list owner (who is likely to subscribe and therefore receive the
> text anyway)?

There are two types of re-encryption that I think are inappropriate:

  - when the mailing list software decrypts and reencrypts each
    message before forwarding it on to the list of subscriber, and,

  - using cryptographic reencryption (ala SELS [2], i.e., the mailing list
    owner has a secret key, each subscriber has a secret key that is
    an offset of that secret key, and the mailing list software
    adjusts encrypted messages by each recipient's offset to
    re-encrypt it).

  [2] http://sels.ncsa.illinois.edu/

The problem with the mailing list software having access to the
cleartext is that the mailing list server becomes part of the trusted
computing base (TCB), which is often undesirable, because we'd like to
have some untrusted party provide and manage our infrastructure.
Note: this has nothing to do with the list owner, who, I assume, is
part of the TCB.

The problem with reencryption algorithms is that a subscriber can't
reuse her own secret key.  Instead, she gets a new secret key (sent
via email, which she has to import) for each mailing list
subscription.  This means she can't easily use a smartcard; it makes
it harder to read the mail on multiple devices; and, it encourages
what are, IMHO, bad security practices (it normalizes using a secret
key provided by a third party).  Finally, it is possible to recover
the mailing list's secret key if the mailing list software and a
subscriber collude.

> Since mailing lists are sort-of a hack in the mail system, you might
> consider doing it entirely differently.  For instance, downloading list
> mail over IMAP, which gives subscribers the initiative so they don't
> need to present an email address.  Sending might be done over SMTP or
> even over IMAP.  Being searchable, this also makes for a great document
> repository :)
> 
> As for re-encryption efficiency, you could decide to re-package the
> session key to (only authorized) public keys; one way you could find
> those is from STARTTLS with an OpenPGP credential, but that would impose
> restrictions on the mail client, or require it go through a SOCKS proxy
> or such.  Towards the latter, we are working on a TLS Pool that could
> make it straightforward to build such a proxy, http://tlspool.arpa2.net
> and which implements OpenPGP over TLS.

(I'm not clear on what you mean by repackaging the session key.  Do
you have some pointers?)

These are good suggestions and I appreciate the tips!  You're probably
right that a good solution can more easily be found by disregarding
backwards compatibility.  But, in this project, I'm trying to
determine the best mechanism that doesn't require users to change
their habits or upgrade their software (other than their OpenPGP
implementation and then, only for posters, not list subscribers).


I hope my response doesn't sound too destructive; it was not the
intent.  I really appreciate your comments and the opportunity to
formulate some previously implicit arguments.

Thanks!

:) Neal