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