Hi Phillip,
Thanks for the feedback.
At Sat, 18 Jul 2015 22:28:58 -0400,
Phillip Hallam-Baker wrote:
I don't think this is a good time to do mailing lists in OpenPGP.
If now is not a good time to add mailing list support to OpenPGP, then
I'll retract my proposal. What is the reason that now is not a good
time to discuss this issue? Do you think this should wait until after
4880bis is finished and we should then recharter?
A mailing list is essentially a form of multi-access drop box. There
is a list of people who can write to the drop box and a list of
people who can read.
The only thing that distinguishes a mailing list from a drop box is
the way the data is organized. But I think it much easier to organize
the contents of a shared drop box to be a mailing list than to try to
do anything on top of SMTP, let alone add security. The OpenPGP bit is
fine, its the SMTP bit that is the problem.
I don't understand this. Isn't a mailing list normally on top of
SMTP? When you say that the OpenPGP bit is fine, but that the SMTP
bit is the problem, what do you mean? Are you arguing that we should
abandon SMTP altogether and use some other transport? I think this
will be a hard fight and not one that the OpenPGP WG should take on.
The reality is that people are trying to do secure mailing lists over
SMTP and it is currently hard.
There are two basic ways a dropbox type scheme can be made to work
with standard public key
* There is a shared public key and everyone knows the private key.
This is changed each time a person drops off the list.
I think this is fine for small, technically apt groups, but I don't
this is scales or is suitable for more casual use. Alternatively, I
may just not be aware of all of the tools that make this easy. If so,
I'd appreciate some pointers.
* Each person has an individual public key pair and the mailing list
is encrypted and sent out to each of them.
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.
The other possibility is that each poster encrypts to all recipients.
This works, but has horrible management issues. In particular, the
posters need to synchronize the list of subscribers and keys. This is
not easy. There is another management problem as well, which is less
obvious. The mailing list participants might want the list of
recipients to be hidden. In GnuPG, this is done using the
--hidden-recipient option. In this case, the public-key encrypted
session key packets don't contain the recipients' keyids. Making sure
all posters remember to use this option is hard. This is also not
scalable: the recipients will need to decrypt (on average) half of the
public-key encrypted session key packets before they find the packet
for them.
My proposal solves these problems. There is no reencryption.
Distribution takes advantage of existing infrastructure, namely, key
servers. The packet format includes mailing list options and provides
an optimization so that normally only a few public-key encrypted
session key packets need to be decrypted when hiding the recipients.
My proposal is also largely backwards compatible with existing OpenPGP
implementations. In particular, it is completely backwards compatible
for recipients and requires the mailing list administrator to
reencrypt posts from posters if they are not using a compliant OpenPGP
implementation.
Now, my proposal is not perfect. In particular, posters still need to
encrypt the session key for all of the subscribers, which can take a
while if the list is large. But, this represents a security trade-off
and users can decide if this cost justifies the added security
relative to the convenience of a reencryption gateway.
Thanks,
Neal
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp