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

From: "Neal H. Walfield" <[email-masked]>
Date: Sun, 10 Jan 2016 22:33:48 +0100

Hi,

Back in July, I made a small, informal proposal about adding support
for encrypted mailing lists to OpenPGP:

  http://mailarchive.ietf.org/arch/msg/openpgp/GAIKx4Ud8CcB-D9uPodeGdQgoGc

I now have a bit of free time and have begun fleshing out the design
and adding support for it to GnuPG.

The thrust of the proposal was to add the list of subscribers to an
OpenPGP key and use the existing key distribution mechanisms to ensure
the list is propagated to posters.

There are two main issues: how to store the subscriber list and how to
deal with updates (i.e., subscribe and unsubscribe events).

In my proposal, I suggested storing the subscriber list in a
mailing-list specific key block.  This immediately addresses the
distribution problem: the key servers and the OpenPGP implementations
already solve the key distribution problem.  I see three possible ways
to store the subscriber list.  We store the data in a dedicated
signature subpacket (my original suggestion), in a signature notation,
or use a new packet type.

Subpackets and notations have the disadvantage that the values are
limited to 64k (Sections 5.2.3 & 5.2.3.16).  As such they impose an
artificial limitation, which is particularly relevant if we were to
use them to store the entire subscriber list.  The obvious fix would
be to increase the allowable length of these data structures in
4880bis.

I see two main approaches to dealing with updates.  After each update
either publish the full, updated list (full update mode); or, just
publish the individual events (incremental update mode).

Full update mode is relatively straightforward, but has a significant
disadvantage: since keyservers don't throw away old data, the key
blocks can get big fast.  Concretely, if N people subscribe to a new
mailing list, this will result in N updates, which consume O(N^2)
space.  In incremental mode, N updates only consume O(N) space (but
the hidden constant is likely much bigger).

Incremental update mode's most important weakness is that it can't
easily support hidden subscriber lists.  To hide the subscriber list,
we need to encrypt it so that just authorized posters can read it.
Because a new poster can't read the encrypted list of subscribers, we
have to reencrypt it.  Since the list of subscribers and the list of
posters is normally identical, each new subscription requires
publishing the full list of subscribers.  In other words, incremental
update mode is usually approximately equivalent to full update mode
when encrypting the subscriber list.

Another issue with incremental update mode is that it is possible for
an attacker intercepting the user's key server requests to prevent
some packets from reaching the user.  This attack can be detected by
turning the updates into a hash chain.  Now, a new poster can detect
if there are any missing blocks prior to the most recently received
update.  That is, if there have been four updates, A, B, C and D, and
a requested key block only includes A and C, the user can detect that
at least one update is missing between A and C, but has no way to
determine that D is missing.  In full update mode, C effectively
includes B so a missing B is irrelevant.  In terms of detecting a
missing D, full update mode doesn't help.

Another attack that both approaches are susceptible to, at least for
public mailing lists, is a denial of service attack that results in
enormous key blocks.  To execute this attack, an attacker just needs
to cause many updates.  In practice, this isn't likely to work very
well since the list maintainer has to sign each update and thus such
attacks are likely to be obvious and easily blocked.  Nevertheless,
the mitigation is obvious and still useful in practice: delay and
batch updates.  The delay occurs naturally, because (normally) the
list maintainer has to sign each update.  Batching updates should also
be straightforward since neither approach naturally precludes them.

I think a reasonable approach would be to use a subkey packet for each
subscriber.  The "subkeys" would be bound to the mailing list key in
the usual fashion and unsubscribe events could be handled using
revocations.  Since we only need to save one encryption key per user
and each user's preferences, this fits quite well within the existing
data structures.  A bit of care needs to be taken to ensure that users
can unsubscribe and later resubscribe.  Unfortunately, this approach
doesn't work well with hidden subscriber lists, as far as I can see.

To deal with hidden subscriber lists, I think we have to use full
update mode.  In this case, I think a new packet type is required,
which would be an optionally encrypted message consisting of an array
of encryption keys and user preferences.

To get the best of both worlds, we could support both approaches and
allow the mailing list's requirements to guide the selection, but I'm
not sure that this added complexity is justified.

Alternatively, if we aren't interested in support encrypted mailing
lists to foil mass surveillance and we agree that something like a few
dozen people is the maximum number of people who can keep a secret, we
can just use the existing notation mechanism.

If anyone has any additional thoughts, I'd be happy to hear them.

Thanks!

:) Neal

---

From: Rick van Rein <[email-masked]>
Date: Mon, 11 Jan 2016 12:01:44 +0100

Hello Neal,

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?
 * 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)?

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.

-Rick

---

From: "Neal H. Walfield" <[email-masked]>
Date: Mon, 11 Jan 2016 23:46:05 +0100

Hi Rick,

Thanks for your thoughtful response!

At Mon, 11 Jan 2016 12:01:44 +0100,
> 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).

> of the list owner (who is likely to subscribe and therefore receive the

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.

> 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

---

From: Rick van Rein <[email-masked]>
Date: Tue, 12 Jan 2016 00:24:07 +0100

Hello Neal,

> Thus, even though I realize it is not
OK, so your target is to protect from passive observers.  That is clear
enough.
> for the key id in the PK-ESK packet).
I think that makes a lot of sense, the key ID being very similar to the
email address.

On a side-note though :- it is trivial to use your existing key and
construct another ID for it; you can use the same key material and make
a self-signature with another timestamp.  The result is a different
fingerprint and so another key ID.  That might be helpful with your
obfuscation plans (blinding all but the last two bytes of the key ID).

Note that it should also possible to take the subkey and hang it under
another public signing key.

You said you lack experience in RFC authoring; if you want to take that
route you probably don't want to overload a given key ID field with
other meaning but instead want to define a new one which simply has two
bytes only or which has a variable size, perhaps prefixed with up to 8
bits "0" and 1 bit "1" to mark the start of a variable-sized ending of
the key ID.

>     message before forwarding it on to the list of subscriber, and,

You specified below that this is because you consider the system running
your mailing list to be part of the passive observation infrastructure.
>     adjusts encrypted messages by each recipient's offset to

This approach can work really nicely if the crypto is designed well.  It
is possible to combine (EC)DH keys in very clever ways to achieve such
effects.  Unfortunately, OpenPGP is not interactive enough (it is a
message format spec, after all) to make use of DH for encryption.

> Note: this has nothing to do with the list owner, who, I assume, is

OK, you are mistrusting the hosting provider.  This will be virtually
impossible to do really well, but if it is possible then crypto is the
answer.  A non-technical answer to that is "pay them enough so they will
want to behave".  Another might be to spread the power over a number of
partial providers.  And this quickly brings you to a distributed scheme,
such as a p2p network.

Emails are identified by a Message-ID, for which mid: URIs have been
specified; similarly, attachments can have a cid: URI defined on them. 
No OS resolves those URIs yet, AFAIK, but the long codes they hold might
do nicely as a p2p lookup key (perhaps after hashing).  This defends
from directed attacks, but still not from casual glancing over your
email, which still requires the cryptographic path.
> subscription.

If you know your crypto algorithms well enough, you might be able to
cook up something different... RSA, DH, ECDH are all more potent than
their everyday applications make you believe.
> (I'm not clear on what you mean by repackaging the session key.  Do

It's security-wise equivalent to decrypting and encrypting the email,
but more efficient; you use the receiving-end public key to retrieve the
session key from packet type 1, and then produce another packet type 1
holding the session key encrypted to subscribers' public keys. 
Plaintext doesn't pass through the list host, but the power to decrypt
(namely the session key) does.
> implementation and then, only for posters, not list subscribers).
I think you are targeting an audience that, if it is to wisely use the
list and not leak to "interested extra subscribers" by letting them in
on the list (had you thought of the signup procedure yet? key management
is always the culprit) will be quite able to change habits.

Good luck with it!
 -Rick

---

From: Werner Koch <[email-masked]>
Date: Tue, 12 Jan 2016 08:19:50 +0100

>     message before forwarding it on to the list of subscriber, and,

As soon as you are in the need for a mailing list you have severe opsec
problems which I consider not solvable: You not only need to fully trust
all participants but also need to make sure that _all_ their boxes are
properly secured against attacks.

Adding another box to reencrypt the messages does not change the picture
much more than adding another subscriber.

I heard that Schleuder (schleuder.nadir.org or apt-get install schleuder)
is a matured tool for encrypted group communication.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: "Neal H. Walfield" <[email-masked]>
Date: Wed, 13 Jan 2016 16:30:10 +0100

At Tue, 12 Jan 2016 00:24:07 +0100,
> OK, so your target is to protect from passive observers.  That is clear

I want to protect the subscriber list from passive observers, but the
message contents from active attackers (i.e., the same assurances that
OpenPGP can provide).

> obfuscation plans (blinding all but the last two bytes of the key

I'm not sure how this helps.  AIUI, the key id is used in the PK-ESK
packet so that the OpenPGP implementation doesn't need to try to
decrypt all PK-ESK packets with all available secret keys.  This is
not only potentially slow, but also annoying if the user has multiple
passphrase-protected secret keys or secret keys on smartcards.  In
other words, including the key id in the PK-ESK packet improves
usability for the *message recipient*.  If the message recipient wants
to hide the key id, then the message recipient can use your trick
locally; there is no need to add this to a standard or the mailing
list software implementation.

> another public signing key.

That was one of my concrete proposals for saving the subscribers in my
mail from a few days ago:

  http://mailarchive.ietf.org/arch/msg/openpgp/UuWVSrMu8LEdChEBQgEpBtQR3-Y

> bits "0" and 1 bit "1" to mark the start of a variable-sized ending of

Again, a driving concern is backwards compatibility and, if I
understand your suggestion correctly, you are suggesting a
non-backwards compatible change.  Perhaps this extension is useful to
consider for 4880bis.

> your mailing list to be part of the passive observation infrastructure.

If I did, then I misstated my position.  I consider the system running
the mailing list software to be a potentially active adversary.

> partial providers.  And this quickly brings you to a distributed scheme,

For the purposes of this exercise, I want to trust the mail server as
much as a normal OpenPGP user trusts an SMTP server.  Namely, an
OpenPGP user reveals the list of recipients to the SMTP server and
relies on the server to forward the encrypted message.

I realize that there are other approaches that reveal less meta-data,
but insofar as they exist today, they are not widely adopted.  I don't
want to say that those fights are not worth fighting, but I am looking
for a short-term solution that provides similar security guarantees
that OpenPGP provides for normal encrypted email.

> their everyday applications make you believe.

Unfortunately, I'm not that good of a cryptographer.  But if you have
some concrete suggestions of things to look at or keywords to search
for, I'd appreciate it.

> is always the culprit) will be quite able to change habits.

I'm trying to target all OpenPGP users.  I'm not just interested in
helping those who the subject of a targeted attack, but also those who
are unsophisticated, but are interested in inhibiting mass
surveillance.

Thanks,

:) Neal

---

From: "Neal H. Walfield" <[email-masked]>
Date: Wed, 13 Jan 2016 16:50:26 +0100

Hi Werner,

At Tue, 12 Jan 2016 08:19:50 +0100,
> properly secured against attacks.

As we discussed recently offline, I respectfully disagree and I find
this position difficult to resolve with your stated position of trying
to bring GnuPG and encrypt in general to a wider audience.  This is
also why I'm working on this project in my free time and not on the
clock.

Even if people aren't sufficiently careful, ready-to-use encrypted
mailing listings can hinder mass surveillance (similar to the way
OpenPGP can, I think).  Further, for those who do have the opsec
background and need this protection, a solution that is easier to use
than GnuPG groups + manually updating the subscriber list, is probably
safer.

> much more than adding another subscriber.

I disagree with this as well.  Someone who hosts many mailing lists
(e.g., google or sf) could abuse their position in a much more
substantive way than a single user.

Thanks,

:) Neal

---

From: [email-masked]
Date: Wed, 13 Jan 2016 18:01:12 -0500

On 1/13/2016 at 10:30 AM, "Neal H. Walfield"  wrote:...

...

...

...

> > via email, which she has to import) for each mailing list

=====

What you want to accomplish, can be done, (at the expense of backward
compatibility), by allowing split-shared keys:

[1] You, (or the owner of any list using this),  has one
signing/certifiying master key with 'n' encryption subkeys, with the
ID name of the mailing list.

[2] For Encryption, the message is simultaneously encrypted to each of
the n encryption subkeys.

[3] For Decryption, only one share of any subkey, is needed.

[4] Each subscriber of the list is sent one share of one subkey,
encrypted to the subscriber's own keypair.

[5] If, for whatever reason, you distrust a particular subscriber of
'leaking' a share, you can revoke that subkey, and send a signed
notice to all subscribers, and generate a new subkey, signed by your
master key.

[6] No meta-data of the recipient, is leaked in any of the encrypted
messages.
[7] For further secrecy, 

(a) each recipient generates a 'throw-away' web-based e-mail.

(b) then generates a keypair with a with a bogus ID, and sends that
public key to the list for a share to be sent encrypted to this
'throw-away' e-mail address.

(c) the recipient then discards the throw-away e-mail address, and
generates a new one

(d) then asks to be subscribed to the new one, stating that he/she
already has a shared portion of the decryption key
 to this it, and that no share needs to be sent, just the messages
encrypted to the n subkeys.

(e) If all the recipients are instructed to wait after they have
received their 'share', and send their subscription requests to their
new e-mail addresses, all at some pre-arranged time, (e.g. a day
later), then their identity of the individual e-mail, is difficult to
trace to the specific subscriber.

[8] The determination of the 'n' of the 'n' subkeys, is a
cryptographic issue to which I don't know the answer.

I imagine that there is some minimum size of a 'share' below which it
is feasible to brute force the share, but since there is no limit to
the subkeys one can generate, it seems do-able to decide on a share of
'safe' size and proceed, (although the encrypted message can get
*really* bulky and long, if there are many many subscribers.)

[9] It can be made 'backward' compatible, for new subscribers, if 'n'
is large enough to simply just send a pre-existing  share as
subscribers are added.
just a possible suggestion ...
vedaal