ietf-openpgp
[Top] [All Lists]

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

2016-01-11 17:24:20
Hello Neal,

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.
OK, so your target is to protect from passive observers.  That is clear
enough.
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).
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.

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,

You specified below that this is because you consider the system running
your mailing list to be part of the passive observation infrastructure.
  - 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).

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.

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.

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.
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.

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
you have some pointers?)

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.
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 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

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp