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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp