On Friday 17 May 2013 05:16 AM, Daniel Kahn Gillmor wrote: > 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
For the encrypted lists yes, the key will be marked as 'encryption capable'. The list owner has to upload the public-private keypair for the list. > > ***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? Yes I think this would be a good point to include but we cannot make this a default option. We ask the list owner to upload the pub-private keypair for any new list that is created. If he does not want signing of messages he might not want to deal with keys at all? > >>> 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? No. >>> 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? It cannot be from another list member, before posting we check that the key that signed the message belongs to the sender( the address in the "From" header and key are same). If someone tries to post his own 5yr old message then we should bounce back the message and ask him to resign the message before sending if incase he wants that old message posted. Sounds okay? >>> 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. Is it feasible to check each message against previously posted messages? I mean let's say if the list is 5yrs old then can we check every incoming message against all those previous messages for matching signatures? I think we cannot check if a user picks up his own 5yrs old message and sends it after changing the headers. >>> 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? In this case I think we can keep a threshold for posting. If a message was signed within 2 days of key expiry then it could be allowed for posting. But then the key should have expired also 2-3 days before the message was received. My doubt is that how do we actually decide what is the best policy for us to follow? One person may agree to my point, other may not, third may have a different point and so on and so forth. So how do we decide upon one point? Voting? >>> 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) Are you referring to the quoted texts in this message? Those lines are written by me but the application/pgp-signature part only verifies that the new content is written by you. Also after mailman adds headers and footers each of your fresh posts will also look like D to each subscribers. Is this what you wanted me to see? I think can use this to filter email commands, the message of type D will not be accepted as a valid email command. About the regular posts considering quoted texts I think we have to allow the message of type D. >>>> * 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? Sorry for this part, actually I was of the opinion that list's secret key can be used in any other encryption also as a key, but guess I am wrong. What my intention was is to to move the message between the queues in encrypted format so as to prevent it from getting stored in the disk( in queue as pickles ) in clear text format. And I wanted to use symmetric algorithm as it is faster than asymmetric and needs only one key( no two like pub and private in asymmetric ) for encryption and decryption. The thing I did wrong was to assume we can use the private key( as it is already stored safely ) for encrypting. >> 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? User uploads his pub-key when he signs up for any such list that forces encryption. >>> 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. Yes, that would be better i guess. > ***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? Yes, I think it is a good point. In-case someone wants to verify if the message was indeed sent to mailman by the one mailman says it is from, he can verify the signature. >>> 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? As a user I might not want to use the key I use everywhere to sign the message to a particular list? I guess a keyserver keeps only one key corresponding to one email id? > 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-de...@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? Since here we are not dealing with encryption, we can send the link in clear-text message and then expect him to send a signed reply verify the key. Also the key might not be encryption enabled so we can't always encrypt using it. > 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?s At all times there must be at-least one key associated with a user's account. If he tries to add another key he would send the confirmation through mail signed with his one of his old keys. Similarly while deleting a key he will have to reply signed confirmation from any one of the address that he owns. > 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? He can attach a key, sign with his existing key and add it though email commands( which will be added for key management ). It will be verified like all other email commands for signature and then processed accordingly. > ----------- > > What about the monthly "you're subscribed to this list" e-mails > mailman sends out? What about "reset your password" e-mails? A user may have joined a single list which does not have any options for signing enabled, in that case mailman cannot sign the message with any key, nor the user will be able to send signed replies. > Regards, > > --dkg I am really thankful for your questions and suggestions. I tried to answer them with some thought. Please correct me if I am wrong. > > > _______________________________________________ Mailman-Developers > mailing list Mailman-Developers@python.org > http://mail.python.org/mailman/listinfo/mailman-developers Mailman > FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: > http://www.mail-archive.com/mailman-developers%40python.org/ > Unsubscribe: > http://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40gmail.com > > Security Policy: http://wiki.list.org/x/QIA9 > -- Abhilash _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
