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

["Neal H. Walfield" <[e-mail]>]

At Tue, 12 Jan 2016 00:24:07 +0100,
Rick van Rein wrote:
> > 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.

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

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

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.

> Note that it should also possible to take the subkey and hang it under
> 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

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

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.

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

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

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

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.

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

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.

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

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