[Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project]

[Daniel Kahn Gillmor]

On 05/11/2013 03:17 AM, Abhilash Raj wrote:

> After the Barry's comment on my proposal I decided to cut down the
> proposal to implement use of OpenPGP  signatures for posting
> privileges instead of both signed and encrypted list.
> Most of the infrastructure for encrypted list will be created along
> with this project so that later on it can also be implemented easily.

I think this is the right decision.  Some of the discussion below is
only relevant for the larger-scope project.  but some of it is relevant
to your revised-scope project as well.  I've tried to indicate the
latter concerns by flagging them with ***SIGNED_POSTS***

> Sender encrypts the message to list's pub key. List's pub-private
> keypair is uploaded by the list's owner when he creates the list.
> Subscribers gets to download the list's pub-key when he subscribes to
> it.

You're saying here that the list has a secret key (i'll call that
LK_sec) and the corresponding public key is well-known (i'll call that
LK_pub).

in OpenPGP terms, keys have "usage flags" or "key capabilities":

https://tools.ietf.org/html/rfc4880#section-5.2.3.21

It sounds like you're saying that we should mark this key as "encryption
capable", which is usually indicated with two bits set: 0xc

***SIGNED_POSTS***

Might there be a reason for the list to have a keypair associated with
it even for cleartext messages?  e.g. might the list send out signed
messages that users might want to verify?

>> what if the decryption succeeds but there is no message signature inside it?
> 
> In that case a notification is sent to the sender with only the
> headers of the decrypted message that the signature of the message
> does not match. If it is not sent by him he is asked to ignore the
> notification.

you say "with only the headers" -- is there ever a time when a bounce
message might contain the message content?

>> what if the signature appears to be valid, but was made 3 years ago (or
>> in the future)?
> 
> Is that a problem if he has not revoked his signature yet?

***SIGNED_POSTS***

Well, it could be a replay of an old message from 5 years ago from
another list member.  Should it be sent to the list again?

>> what if the signature appears to be valid, and recent, but is the same
>> signature that was used on a previous e-mail to the list?
> 
> Can there be same signatures for different messages? I think the
> digital signature is created by encrypting the message-hash, so if the
> contents of the message are changed then signature cannot be valid.

***SIGNED_POSTS***

it could be a replay of a recent message, which would naturally use the
same signature.  But the headers could be modified.  For example, the
Message-ID isn't contained in the signature.

>> what if the signature is cryptographically valid, but the list member's
>> key has expired?
> 
> Well a expired key cannot be used to sign messages. If this situation
> happens this means it was signed in past some time ago. We can bounce
> the message and notify the user about this.

***SIGNED_POSTS***

What if the message signature has a date that precedes the key expiry?

>> what if only part of the message is signed?
> My guess is that you are referring to inline-pgp. I read this article
> which talks about the inline-pgp as a bad messaging format. I think we
> should not support this. So if the message is partially signed it
> should probably bounce back.

***SIGNED_POSTS***

Both inline PGP and PGP/MIME can have partial message signatures.

I happen to agree that supporting inline PGP is problematic, so i'm
willing to ignore it for now if that's the consensus of the project.  be
aware that you will find some pushback here, though, because there
remain some broken MUAs that not only can't generate PGP/MIME, but can't
display a clearsigned PGP/MIME e-mail to their users.

When you think of PGP/MIME, you probably think of messages like message
A below:

A└┬╴multipart/signed 3099 bytes
B ├─╴text/plain 1527 bytes
C └─╴application/pgp-signature attachment [signature.asc] 1027 bytes

But consider a MIME message D of the following form

D└┬╴multipart/mixed 7346 bytes
E ├┬╴multipart/signed 3099 bytes
F │├─╴text/plain 1527 bytes
G │└─╴application/pgp-signature attachment [signature.asc] 1027 bytes
H └─╴text/plain inline 424 bytes

the text in part F is signed by the signature in part G.  So you could
argue that the subtree rooted at E is "a signed message in some sense.

What kind of messages look like D?  where do they come from?  (hint:
examine the MIME structure of this message itself)


>>>  * The messaged is moved in between queues in the encrypted form
>>> encrypted by a symmetric key algorithm which uses list's secret key to
>>> encrypt the message.
>>
>> this doesn't make sense to me.  when i hear "list's secret key" i tend
>> to think people are talking about asymmetric encryption, but it seems
>> here that you're talking about symmetric encryption.  Maybe it would
>> help to enumerate exactly what secrets each entity holds (and maybe what
>> public data is associated with those secrets, in the case of the
>> public/private keypairs used by asymmetric crypto).  If you give those
>> secrets names, you can refer to them more concisely and precisely.
> 
> Sorry to sound so confusing. What I actually meant was that we use
> public-private key encryption via OpenPGP so send and receive signed
> and encrypted messages. Now each list has a public-private keypair
> which the list owner uploads when he creates the list.

I'm with you so far...

> During processing of the message inside mailman it is decrypted and
> sometimes stored on disk as python pickles in various queues which is
> bad for security reasons. I propose that when it is being stored on
> disk it can be encrypted using a symmetric key encryption algorithm so
> that only one who has access to list's secret key can decrypt it.

And here you've lst me again.  the lists's secret key (LK_sec) is by
definition for use in asymmetric cryptographic schemes.  why are you
saying "using a symmetric key encryption algorithm" here?

> When the message is being sent to the subscribers it is encrypted with 
> the user's pub-key so that only he can decrypt it.

This hand-waves around the difficult question: how do we know what the
user's pub-key is?

>> what happens to the original sender's signature?  is it stripped?  or
>> does it remain, nested within the list's signature?  How are list
>> members expected to verify these signatures?
> 
>  The original sender's signature is stripped. I guess the list
> subscribers just have to trust that the list owner. We cannot expect
> each member of the list to have every other member's pub-key to
> separately verify himself that the message is indeed from the sender.

there are other options.  for example, the list could *add* its
signature to the message without stripping the signature of the original
author, so that recipients could verify one or the other or both.

***SIGNED_POSTS***

This is also relevant in the reduced-scope project; is it possible that
the mailing list might want to re-sign existing signed messages so that
people who receive mails from the mailing list can verify that they
really came from the mailing list?

>> What happens if a user's public key is found to be expired or revoked?
>> How does mailman become aware of revocations, of extensions of the
>> expiration date, or of new keys or certificates for any given user?
> 
> If the user has his key uploaded to a public key server and wants( he
> will be given option of whether ot not to) mailman to check , mailman
> can periodically check for revocation and expiration of the key.
> Though i don't know how will that be done.

***SIGNED_POSTS***

Why would mailman *not* check the public keyservers?  why should this be
an option?

If you're going to be using the OpenPGP public keyservers as a
regular/possibly-heavy-duty client, i recommend asking any questions you
have about the interaction with the keyservers over in the development
list for SKS (which is currently the dominant keyserver implementation):

 SKS development list <sks-devel at nongnu.org>

The protocol used is HKP, and there is a major global pool of gossiping
keyservers that you can talk to.  for more details about the pool, see:

 https://sks-keyservers.net/

>  New keys will be added by user only from postorius after a
> confirmation link is sent to him on the address the key verifies.

***SIGNED_POSTS***

Will that confirmation link be sent in the clear, or will it be
encrypted to the user's public key?

if the answer is "encrypted", what if the user's key is not
encryption-capable?  If the user is trying to change keys, will the
confirmation message be encrypted to the user's old key or to their new one?

Mailman has traditionally been accessible to people who do not browse
the web by making use of its e-mail interface.  will there be a way to
add or adjust keys via e-mail as well?

-----------

What about the monthly "you're subscribed to this list" e-mails mailman
sends out?  What about "reset your password" e-mails?

Regards,

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1027 bytes
Desc: OpenPGP digital signature
URL: <http://mail.python.org/pipermail/mailman-developers/attachments/20130516/9cbced1f/attachment.pgp>