Re: [Mailman-Developers] OpenPGP Mailman integration discussion [was: Re: GSoc - Requirement from Mentor to complete the project]
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
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
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
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:
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%40gm...
Security Policy: http://wiki.list.org/x/QIA9
-- Abhilash
On 05/23/2013 12:06 PM, Abhilash Raj wrote:
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.
[dkg wrote:] ***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?
sure, but if we introduce this as an option, then we need to make sure that we've thought through all the consequences. If the list has a key for use with administrative requests (e.g. subscription, unsubscription, etc) is that the same key that it would use for message signing? or a different key? What are the advantages of each scheme? Given that the list administrative requests go to different e-mail addresses than the regular posting, how would the User ID(s) look on a single key used for both interfaces provided by the list? Is implementing this option something that would be part of the first phase of the work, or should it be part of a later phase?
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).
sure, but the From: header is forgeable, right? so if Alice knows that Bob was subscribed to list X in the past, and is subscribed to list Y today, then she could dig up his old posts in list X, and forward them (From: header intact!) directly to list Y. Should list Y publish them?
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?
sounds like we agree that a message whose signature is 5 years old is "too old" -- what about 1 year old? 1 month old? 1 week? It sounds like you're proposing a cutoff somewhere; where is the cutoff? is this something that would be adjustable by the list admin? if so, what should the default be? (note also that this assumes that the clock on the server is aligned with the clock used on the machine where the messages were signed; i think this is OK, but maybe there's some scenario where it might cause trouble?)
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?
With the appropriate data structures, such a check isn't infeasible (e.g. you could maintain a binary tree of the digests of all message signatures; then if you have N messages in your archive, you have to do log(N) digest comparisons when a new message comes it to be sure that it isn't a replay of an old message. Maybe the mailman devs can answer this question: does mailman already do something like this to check against message-ids that have already been delivered to prevent duplicate delivery? this sounds like a similar problem to me (just with stronger cryptographic verifiability in the OpenPGP-signed case); if such a system already exists, maybe it could be amended to address these issues in the same way.
I think we cannot check if a user picks up his own 5yrs old message and sends it after changing the headers.
remember it's not just the user re-sending their own message -- it could be *anyone* re-sending the old message. Note also that the OpenPGP signature itself has a timestamp embedded in it, which is not modifiable without invalidating the signature. I think you might be assuming that we're checking the date of the signature via the (forgeable) Date: header on the message; i think it would make more sense to use the OpenPGP signature timestamp. What if the signature timestamp and the Date: header differ by a few seconds? what if they differ by months?
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.
where does the 2 day cutoff come from? i'm asking about a timeline like this: (if < means "is earlier than": X < Y < Z) X: message signature created (according to OpenPGP timestamp) Y: key expired Z: message received by mailman SMTP delivery can take up to 4 days, depending on network and machine failures. but my point here is not to build in a fudge factor around the actual expiration date (which is explicit and i think needs no fudge factor), but rather to point out that the "is the message signature expired" calculation has to do with several different timestamps and how they relate to each other.
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?
This is a good question :) I think you should propose a reasonable approach for handling all these various corner cases, and where your approach has some arbitrary cutoffs (e.g. messages with signatures older than K days will not be accepted for delivery), you make the arbitrary cutoff tuneable by the list administrator and choose a sensible default. Then you solicit and accept patches from people who have a strong argument that your implementation isn't aligned with a reasonable policy they would like to pursue :)
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?
yep, mailman generates messages of this form from PGP/MIME-signed messages. That said, mailman's generated messages aren't usually sent to mailman as input; maybe mailman shouldn't process these as signed messages?
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.
if we allow a message of type D, then Alice could simply find a recent PGP/MIME-signed message from Bob (from somewhere else), wrap it in a multipart/mixed part, append her own footer to it (part H) containing arbitrary text, and send the message on to mailman, using a trivially-forged From: Bob header. If mailman is willing to replay that message (with alice's arbitrary H intact) to all its subscribers, that seems like an easy way around the "signed-messages-only" constraint, which seems like a failure. So what are some other options? 0) mailman could ignore all messages except those that are fully signed (this is probably the easiest) 1) mailman could strip off all outer layers until it finds an inner part that is itself fully signed, and then process that part as though it were the entire message 2) ... other ideas?
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.
you can use the public key for encrypting, and the secret key for decrypting. that still uses asymmetric encryption, though. anyway, this is probably a question for the larger-scope project, so we should probably drop it for now to avoid distracting from the other matters at hand.
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.
so anyone can sign up for the list with any key? if the list is open for arbitrary, unmoderated subscription, then what does it say about the confidentiality of the list? setting aside confidentiality (e.g. in the ***SIGNED_POSTS*** limited-scope), what does it say about the restrictions the list is able to enforce if arbitrary keys can be signed up? If the list admin/moderator has to approve new subscriptions, are they also approving the choice of keys as well? if so, how do you expect a list moderator to tell that the key in question is the right one? What happens if a list member revokes their key, or lets it expire? can that member upload a new one? how does the list know that this key replacement is legitimate, and not being done by an adversary or an impersonator?
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?
ah, this is not the case :) keyservers can store an arbitrary number of keys that are (or claim to be) associated with a single e-mail address. OpenPGP keyservers are functionally agnostic -- they don't make any claims themselves about which keys belong to which e-mail addresses (or other forms of user ID). they just publish all the keys, and expect their clients to do the verification and certification path analysis themselves, based on client-specific perspectives on whose certifications are reliable and whose should be ignored.
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.
does the signed reply need to be of a given form? does it need to contain a particular arbitrary string, like the confirmation (e.g. like the string in example-confirm+8d6e100d2d168ed0837d8d2b2e6e1db2b51b8877@lists.example.org)? how can we be sure that the confirmation verification is safe from replay attacks (from the perspective of both the subscriber and the list administrator)? For example: ---------------------- Let's say Alice wants to sign Bob up to a list X that Bob would find distasteful to be on. Alice creates a phony mailman instance with a list Y that Bob *does* want to subscribe to; Bob tries to sign up for list Y, expecting a challenge that he will sign and respond to. When the request from Bob for List Y comes in, Alice spoofs a subscription attempt "From: Bob" to list X, harvests list X's (legitimate) challenge to Bob, and has List Y replay it to Bob as the challenge for List Y. Bob signs the challenge, returns it to list Y (which is still operated secretly by Alice), and Alice in turn replays Bob's signed response to list X. List X administrators now believe that Bob has legitimately signed up. They even have "cryptographic proof" of his intent to participate in List X! ---------------------- How can such a challenge/response system be designed to protect both Bob and the List X operators from people like Alice? One other question just occurred to me: Once these features (signed-messages-only) are implemented, hould existing (non-OpenPGP-enabled) lists be able to be upgraded to use these new features? Or is this something that is decided at list creation time and never changed? If list upgrading is possible, what sort of work needs to be done on an upgrade? Should this be part of the first phase of work? Even if not, it's worth keeping the possibility of a list upgrade in mind as you're designing the data structures and UI/UX adjustments that you want to make.
I am really thankful for your questions and suggestions. I tried to answer them with some thought. Please correct me if I am wrong.
Thanks, I really appreciate your engagement with these questions. There are a lot of finicky details to keep track of, and you're coming up to speed fast on questions that most people haven't thought about at all. Keep it up! Regards, --dkg
Daniel Kahn Gillmor writes:
Is implementing this option something that would be part of the first phase of the work, or should it be part of a later phase?
He can implement it whenever he wants :-), but if I were his GSoC mentor, he'd be getting paid for something else (ie, the pure authentication part). Barry and Wacky think similarly I believe.
Maybe the mailman devs can answer this question: does mailman already do something like this to check against message-ids that have already been delivered to prevent duplicate delivery?
I don't recall for sure but I don't think so. I tend to think it's too much effort. We do worry about routing cycles and handle that with X-Been-Seen fields. Message-IDs themselves are not very useful; in my own experience repeated message IDs are invariably due to Post-and-Mail issues (which we deal with post-by-post by checking the NoDupes flag on any addressees who appear in the list). Duplicate originals tend to be due to "keyboard bounce" (ie, for some reason the user resends within a number of seconds) or moderation delays -- in both cases usually they end up with different Message-IDs.
Thanks, I really appreciate your engagement with these questions. There are a lot of finicky details to keep track of, and you're coming up to speed fast on questions that most people haven't thought about at all. Keep it up!
+1 !
Also, Abhilash, I believe it would be very helpful to you later to blog about these conversations now.[1] Your blog entries should not be fire-and-forget; you should have separate entries for different topics and go back and update entries as you learn more. It might also be helpful to keep links to the mm-dev archive posts as references in your blog. (I haven't actually practiced that last myself, but it seems plausible.)
It *will* seem like too much effort at first, but (1) people forget things unbelievably fast, and (2) you'll get better at it quickly.
STeve
Footnotes: [1] Maybe you already have, if so, my apologies. I'll go check later. :-)
On Friday 24 May 2013 11:24 AM, Stephen J. Turnbull wrote:
I don't recall for sure but I don't think so. I tend to think it's too much effort. We do worry about routing cycles and handle that with X-Been-Seen fields. Message-IDs themselves are not very useful; in my own experience repeated message IDs are invariably due to Post-and-Mail issues (which we deal with post-by-post by checking the NoDupes flag on any addressees who appear in the list). Duplicate originals tend to be due to "keyboard bounce" (ie, for some reason the user resends within a number of seconds) or moderation delays -- in both cases usually they end up with different Message-IDs.
+1
Also, Abhilash, I believe it would be very helpful to you later to blog about these conversations now.[1] Your blog entries should not be fire-and-forget; you should have separate entries for different topics and go back and update entries as you learn more. It might also be helpful to keep links to the mm-dev archive posts as references in your blog. (I haven't actually practiced that last myself, but it seems plausible.)
It *will* seem like too much effort at first, but (1) people forget things unbelievably fast, and (2) you'll get better at it quickly.
Yes this was also one of my todos. And to be truthful point (1) is very highly applicable to me ;-).
-- Abhilash
Hi!
On Thu, May 23, 2013 at 02:26:46PM -0400, Daniel Kahn Gillmor wrote:
On 05/23/2013 12:06 PM, Abhilash Raj wrote: <snip>
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?
This is a good question :)
I think you should propose a reasonable approach for handling all these various corner cases, and where your approach has some arbitrary cutoffs (e.g. messages with signatures older than K days will not be accepted for delivery), you make the arbitrary cutoff tuneable by the list administrator and choose a sensible default.
Then you solicit and accept patches from people who have a strong argument that your implementation isn't aligned with a reasonable policy they would like to pursue :)
I've just typesetted http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.15-with-pgp-smime_2012-08-28-p... and http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.15-with-pgp-smime_2012-08-28-p... . These document some ideas about threats for a PGP-enhanced mailman implementation. (More documentation is available in http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.15-with-pgp-smime_2012-08-28-p... .)
HTH.
<snip> > > I am really thankful for your questions and suggestions. I tried to > > answer them with some thought. Please correct me if I am wrong. > > Thanks, I really appreciate your engagement with these questions. There > are a lot of finicky details to keep track of, and you're coming up to > speed fast on questions that most people haven't thought about at all. > Keep it up!
+1
Bye,
Joost
-- irc:joostvb@{OFTC,freenode} ∙ http://mdcc.cx/ ∙ http://ad1810.com/
On Friday 24 May 2013 12:03 PM, Joost van Baal-Ilić wrote:
I've just typesetted http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.15-with-pgp-smime_2012-08-28-p... and http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.15-with-pgp-smime_2012-08-28-p... . These document some ideas about threats for a PGP-enhanced mailman implementation. (More documentation is available in http://non-gnu.uvt.nl/pub/mailman/mailman-2.1.15-with-pgp-smime_2012-08-28-p... .)
Thanks Joost. In fact I have read these two audits before. It really helped me in deciding what would be the best for the scope of the project I am trying to do. And what are the various general problems that I would be dealing with along with a plausible solution to many of them. It is a very helpful resource. :)
-- Abhilash
On Thursday 23 May 2013 11:56 PM, Daniel Kahn Gillmor wrote:
On 05/23/2013 12:06 PM, Abhilash Raj wrote:
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.
[dkg wrote:] ***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?
sure, but if we introduce this as an option, then we need to make sure that we've thought through all the consequences. If the list has a key for use with administrative requests (e.g. subscription, unsubscription, etc) is that the same key that it would use for message signing? or a different key? What are the advantages of each scheme? Given that the list administrative requests go to different e-mail addresses than the regular posting, how would the User ID(s) look on a single key used for both interfaces provided by the list?
This part is little difficult to ponder on. Suppose a user signs up for a list. He creates a user account and subscribes to a particular list which needs his pub-key and implements signing. Now for that user his pub-key can be used for sending administrative requests. If he signs up for more than one list it might be a question which of the keys will be used for administrative request? If he signs up for a single list which does not require signing then what? There will not be any key to sign administrative requests.
Is implementing this option something that would be part of the first phase of the work, or should it be part of a later phase?
This probably would be best implemented in the later phase when the till_now_proposed architecture of only signed emails from lists is implemented and is successful.
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).
sure, but the From: header is forgeable, right? so if Alice knows that Bob was subscribed to list X in the past, and is subscribed to list Y today, then she could dig up his old posts in list X, and forward them (From: header intact!) directly to list Y. Should list Y publish them?
Well if somehow( 'coz have no idea how ) we can check that this message was posted anytime before in past on the same list, it would be better that we simple discard the message.
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?
sounds like we agree that a message whose signature is 5 years old is "too old" -- what about 1 year old? 1 month old? 1 week? It sounds like you're proposing a cutoff somewhere; where is the cutoff? is this something that would be adjustable by the list admin? if so, what should the default be?
No, I think if someone tries to send any of his previous message again we can rebound it saying that the same message was posted before. Also the time-stamp from the message signature would indicate that the message was indeed signed long time back and hence should be bounced back without checking if it was a replay of an old message. Here a 'long time' may be a cutoff set by the list owner which may default to one week considering the delay in smtp delivery( which you mentioned to be 4 days at maximum).
(note also that this assumes that the clock on the server is aligned with the clock used on the machine where the messages were signed; i think this is OK, but maybe there's some scenario where it might cause trouble?)
A cutoff of one week should be sufficient to include the small time( at max a day ) mismatch between the server and the system where message was signed. In-case the mismatch is more than that we can bounce the message back asking the sender to either check his clock or resign and send the message.
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?
With the appropriate data structures, such a check isn't infeasible (e.g. you could maintain a binary tree of the digests of all message signatures; then if you have N messages in your archive, you have to do log(N) digest comparisons when a new message comes it to be sure that it isn't a replay of an old message.
Maybe the mailman devs can answer this question: does mailman already do something like this to check against message-ids that have already been delivered to prevent duplicate delivery? this sounds like a similar problem to me (just with stronger cryptographic verifiability in the OpenPGP-signed case); if such a system already exists, maybe it could be amended to address these issues in the same way.
I think we cannot check if a user picks up his own 5yrs old message and sends it after changing the headers.
remember it's not just the user re-sending their own message -- it could be *anyone* re-sending the old message.
I think replay of message should not be allowed at all. Not by the original sender, not by anyone else, not immediately, not some time after. We can put it as an option but I can't imagine any situation where this would be used. Please tell me if you can think of any?
Note also that the OpenPGP signature itself has a timestamp embedded in it, which is not modifiable without invalidating the signature. I think you might be assuming that we're checking the date of the signature via the (forgeable) Date: header on the message; i think it would make more sense to use the OpenPGP signature timestamp. What if the signature timestamp and the Date: header differ by a few seconds? what if they differ by months?
Is the timestamp in the OpenPGP signature not forgeable? Does it not depend on the hardware clock of the system where the message was signed? Although I agree that checking this would be good for filtering the messages signed long time ago in past and being sent now( considering that i don't plan and sign many messages by changing my hardware clock and program it to send it in future as spams. Can we assume this will not happen? )
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.
where does the 2 day cutoff come from? i'm asking about a timeline like this:
(if < means "is earlier than": X < Y < Z)
X: message signature created (according to OpenPGP timestamp) Y: key expired Z: message received by mailman
Again here the decision should be made by the list owner. It may depend on what values are for (Y-Z) and (Z-Y). I think we can allow a message whose signature expired a day before( and the user din't have time to change the key or extend expiration date ). But this 'one day' parameter is to be set by the list owner.
SMTP delivery can take up to 4 days, depending on network and machine failures. but my point here is not to build in a fudge factor around the actual expiration date (which is explicit and i think needs no fudge factor), but rather to point out that the "is the message signature expired" calculation has to do with several different timestamps and how they relate to each other.
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?
This is a good question :)
I think you should propose a reasonable approach for handling all these various corner cases, and where your approach has some arbitrary cutoffs (e.g. messages with signatures older than K days will not be accepted for delivery), you make the arbitrary cutoff tuneable by the list administrator and choose a sensible default.
Then you solicit and accept patches from people who have a strong argument that your implementation isn't aligned with a reasonable policy they would like to pursue :)
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?
yep, mailman generates messages of this form from PGP/MIME-signed messages. That said, mailman's generated messages aren't usually sent to mailman as input; maybe mailman shouldn't process these as signed messages?
What is the structure of message with quoted text( when replying to a mail inline )? Are those signed by the user replying to it? Because such kind of message are always received by mailman.
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.
if we allow a message of type D, then Alice could simply find a recent PGP/MIME-signed message from Bob (from somewhere else), wrap it in a multipart/mixed part, append her own footer to it (part H) containing arbitrary text, and send the message on to mailman, using a trivially-forged From: Bob header.
Just out of curiosity is the forging of headers a trivial thing? Can I send a message with some address not owned by me to say this very list easily? (I don't want to though ,just asking if I can ;-)
If mailman is willing to replay that message (with alice's arbitrary H intact) to all its subscribers, that seems like an easy way around the "signed-messages-only" constraint, which seems like a failure.
So what are some other options?
0) mailman could ignore all messages except those that are fully signed (this is probably the easiest)
The message that we send can be of type D but we should only accept the messages of type A? I think this the best thing to adopt.
1) mailman could strip off all outer layers until it finds an inner part that is itself fully signed, and then process that part as though it were the entire message
That would add some extra logic and computation for signed components in a message, maybe not much difficult to implement but more than nothing. I don't think we should do it, if we are so concerned about security we can expect the senders to follow the policy( of sending only fully signed message of kind A)?
2) ... other ideas?
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.
you can use the public key for encrypting, and the secret key for decrypting. that still uses asymmetric encryption, though. anyway, this is probably a question for the larger-scope project, so we should probably drop it for now to avoid distracting from the other matters at hand.
+1
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.
so anyone can sign up for the list with any key? if the list is open for arbitrary, unmoderated subscription, then what does it say about the confidentiality of the list? setting aside confidentiality (e.g. in the ***SIGNED_POSTS*** limited-scope), what does it say about the restrictions the list is able to enforce if arbitrary keys can be signed up? If the list admin/moderator has to approve new subscriptions, are they also approving the choice of keys as well? if so, how do you expect a list moderator to tell that the key in question is the right one?
Yes anyone can signup but his subscription will be moderated. I don't understand here what do you mean by "choice of keys" and what is a "right" key? I am guessing by right key you mean the key indeed belongs to the owner of the address the key verifies. But already the confirmation email is sent to check that the address is indeed owned by the person before the moderators receive notification to allow the user to get subscribed.
What happens if a list member revokes their key, or lets it expire? can that member upload a new one? how does the list know that this key replacement is legitimate, and not being done by an adversary or an impersonator?
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?
ah, this is not the case :) keyservers can store an arbitrary number of keys that are (or claim to be) associated with a single e-mail address.
So in general terms if I import a key from a public keyserver, I cannot be sure that the pub-key belongs to owner of the address the key verifies? I am confused! I can change the "From" header to you email, then I can upload a key that verifies you address whose private key is with me. I sign a message and send it to mailman. If we allow the usage of keyservers how will mailman distinguish that the message was a fake? Why should we check keyservers by default? Won't it better that we ask the user to either upload his first key and later on to add another key a confirmation will be sent to both the new added address and previous default address and confirmation from both will be required? It looks messy to me though. :-/
OpenPGP keyservers are functionally agnostic -- they don't make any claims themselves about which keys belong to which e-mail addresses (or other forms of user ID). they just publish all the keys, and expect their clients to do the verification and certification path analysis themselves, based on client-specific perspectives on whose certifications are reliable and whose should be ignored.
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.
does the signed reply need to be of a given form? does it need to contain a particular arbitrary string, like the confirmation (e.g. like the string in example-confirm+8d6e100d2d168ed0837d8d2b2e6e1db2b51b8877@lists.example.org)?
Yes
we can ask the user to simply resend the confirmation message signed by him? I mean this is what I can think of as the easiest. We can have anything in the mail sent to him( which will be signed by the secret key of the list he is subscribing to, so no question of fake acceptance message sent to the user)
how can we be sure that the confirmation verification is safe from replay attacks (from the perspective of both the subscriber and the list administrator)? For example:
---------------------- Let's say Alice wants to sign Bob up to a list X that Bob would find distasteful to be on.
Alice creates a phony mailman instance with a list Y that Bob *does* want to subscribe to; Bob tries to sign up for list Y, expecting a challenge that he will sign and respond to.
When the request from Bob for List Y comes in, Alice spoofs a subscription attempt "From: Bob" to list X, harvests list X's (legitimate) challenge to Bob, and has List Y replay it to Bob as the challenge for List Y. Bob signs the challenge, returns it to list Y (which is still operated secretly by Alice), and Alice in turn replays Bob's signed response to list X.
List X administrators now believe that Bob has legitimately signed up. They even have "cryptographic proof" of his intent to participate in List X! ----------------------
How can such a challenge/response system be designed to protect both Bob and the List X operators from people like Alice?
The confirmation email received by Bob will be signed by the secret key of List Y which he gets to download while he was subscribing for the list. He can check it and will find the signature invalid incase Alice sends him another message which has confirmation for a list X.
One other question just occurred to me: Once these features (signed-messages-only) are implemented, hould existing (non-OpenPGP-enabled) lists be able to be upgraded to use these new features? Or is this something that is decided at list creation time and never changed? If list upgrading is possible, what sort of work needs to be done on an upgrade? Should this be part of the first phase of work? Even if not, it's worth keeping the possibility of a list upgrade in mind as you're designing the data structures and UI/UX adjustments that you want to make.
Yes, the upgrade should be must have feature( in future, not in this project ). And yes I will keep this in mind while designing the system and UI that upgrading to signed lists is not much of a hassle.
I am really thankful for your questions and suggestions. I tried to answer them with some thought. Please correct me if I am wrong.
Thanks, I really appreciate your engagement with these questions. There are a lot of finicky details to keep track of, and you're coming up to speed fast on questions that most people haven't thought about at all. Keep it up!
Thanks :)
Regards,
--dkg
-- Abhilash
Abhilash Raj writes:
This part is little difficult to ponder on. Suppose a user signs up for a list. He creates a user account and subscribes to a particular list which needs his pub-key and implements signing.
In Mailman 3, users and subscriptions are separate concepts. We should assume that users and subscriptions are both authenticated, potentially separately. I think that to start with, we can assume that the user key will be used for all user configuration (subscription, etc), and for posting.
The second stage would be to allow a list to require a separate key (subkey) for posting.
The third stage would be to require a separate key for administration (user configuration).
If he signs up for a single list which does not require signing then what? There will not be any key to sign administrative requests.
For starters we'll simply require a separate installation for secure and insecure lists. The whole Mailman instance is secure and all users must have user keys.
This is a proof-of-concept implementation; we think about weaker and more complex security models later.
sure, but the From: header is forgeable, right? so if Alice knows that Bob was subscribed to list X in the past, and is subscribed to list Y today, then she could dig up his old posts in list X, and forward them (From: header intact!) directly to list Y. Should list Y publish them?
Sure, but a secure list should be on a site using DKIM and this will fail the DKIM check, I think.
Alternatively you can set up the list so that the whole post (originator headers included) is sent as an attachment (a signed part of a multipart message). The list can then prepend the trace headers (informational only, not authenticable) from the wrapper message when it forwards the encapsulated message. Outlook users will generally not be able to do this, so it's another proof of concept. :-)
This is like a secure tunnel (eg, using SSH port forwarding).
No, I think if someone tries to send any of his previous message again we can rebound it saying that the same message was posted before.
Sure, but identifying that requires secure headers. See above.
Also the time-stamp from the message signature would indicate that the message was indeed signed long time back and hence should be bounced back without checking if it was a replay of an old message. Here a 'long time' may be a cutoff set by the list owner which may default to one week considering the delay in smtp delivery( which you mentioned to be 4 days at maximum).
SMTP doesn't really work that way; there are no time guarantees (the chain of forward can be arbitrarily long, and each one will retry for up to 4 days in normal configurations). Furthermore, I regularly see spew from Windows boxes with mail written offline. I think the *principle* of using the signature's time-stamp is OK, but the cutoff time should be determined by the list's sense of how long post content can stay "hot".
A cutoff of one week should be sufficient to include the small time( at max a day )
I've seen many cases where timestamp skew on authentic messages was much greater than a day. Again, this is a matter for list policy.
Is the timestamp in the OpenPGP signature not forgeable? Does it not depend on the hardware clock of the system where the message was signed?
It's forgeable, but only by the owner of the private key. The hardware clock could be deliberately skewed, but I can't see how that would create a useful attack on a list. (I guess you could imagine a scenario with a "deadman switch" controlling a message that would be sent if the creator doesn't cancel it, but that's a scenario for Mission Impossible IV, I think.)
(if < means "is earlier than": X < Y < Z)
X: message signature created (according to OpenPGP timestamp) Y: key expired Z: message received by mailman
I don't understand the point of this scenario. X is a valid signature, and there are known to be delays in delivery. X should just be treated as an old signature.
yep, mailman generates messages of this form from PGP/MIME-signed messages. That said, mailman's generated messages aren't usually sent to mailman as input; maybe mailman shouldn't process these as signed messages?
Such messages can be generated in many ways; the fact that Mailman does is just a proof of concept.
What is the structure of message with quoted text( when replying to a mail inline )?
It's a flat body. It has no MIME structure unless the user deliberately creates it (well, in some cases attachments may be automatically forwarded).
Are those signed by the user replying to it?
The interesting question is whether the quote is signed by the OP, and the answer it that no, it can't be. You could choose to send the original signed body (with signature) for verification of the accuracy of your quote, but the quote itself will be signed as part of the reply by the replying agent.
Just out of curiosity is the forging of headers a trivial thing? Can I send a message with some address not owned by me to say this very list easily? (I don't want to though ,just asking if I can ;-)
Yes, all headers are easily forged unless the sending site uses DKIM. The envelope data is also easily forged.
- mailman could ignore all messages except those that are fully signed (this is probably the easiest)
I suspect that some people's legal disclaimer will fall outside the signed text. No can do.
- mailman could strip off all outer layers until it finds an inner part that is itself fully signed, and then process that part as though it were the entire message
I think this is the right way to handle layered messages when signatures are required. The
This hand-waves around the difficult question: how do we know what the user's pub-key is?
I think we can punt on this. "The same way we ever do." Ie, we use a PK certification infrastructure or a web of trust. That's up to the list owner.
What happens if a list member revokes their key, or lets it expire? can that member upload a new one?
Not if they needed approval in the first place. If the list is open-subscription, yes, but a confirmation mail to the subscription address and notification to list owner are required here. I'm not sure if it's possible to use a revoked or expired key in that state, but if so it might be useful to use it "just that one more time".
how does the list know that this key replacement is legitimate, and not being done by an adversary or an impersonator?
See above.
So in general terms if I import a key from a public keyserver, I cannot be sure that the pub-key belongs to owner of the address the key verifies?
No, you can't. Anybody can upload such keys. You need to either rely on a certification authority, or the web of trust.
Note that Daniel already answered that question, in some detail, in the post you were replying to. If you don't understand the answer the first time, reread the answer. Then try to refine your question. It's not just a matter of courtesy to someone who has spent a lot of effort in crafting clear answers; you'll also learn a *lot* faster.
Alice creates a phony mailman instance with a list Y that Bob *does* want to subscribe to; Bob tries to sign up for list Y, expecting a challenge that he will sign and respond to.
When the request from Bob for List Y comes in, Alice spoofs a subscription attempt "From: Bob" to list X, harvests list X's (legitimate) challenge to Bob, and has List Y replay it to Bob as the challenge for List Y. Bob signs the challenge, returns it to list Y (which is still operated secretly by Alice), and Alice in turn replays Bob's signed response to list X.
Probably this requires a version of the Diffie-Hellman handshake, actually.
One other question just occurred to me: Once these features (signed-messages-only) are implemented, hould existing (non-OpenPGP-enabled) lists be able to be upgraded to use these new features?
As an authentication option for administrative mails, I don't see a problem. For post authentication, technically I don't see a great difficulty in switching to "everything must be authenticated" (ie, signed), but socially I think it's a mess. Creation of a new list is the right way to go. That allows birectional gatewaying (with human moderation insecure -> secure). But this is way down on the priority list.
Note that Mailman 2 will never get these capabilities, at least not from the current team.
On 05/26/2013 12:57 PM, Stephen J. Turnbull wrote:
sure, but the From: header is forgeable, right? so if Alice knows that Bob was subscribed to list X in the past, and is subscribed to list Y today, then she could dig up his old posts in list X, and forward them (From: header intact!) directly to list Y. Should list Y publish them?
Sure, but a secure list should be on a site using DKIM and this will fail the DKIM check, I think.
If i understand it correctly, DKIM allows the recipient of a message to verify that it came from the domain it claims to come from, and that the body and a select set of headers have not been tampered with while the message was in transit. Bob's e-mail could come from Bob's own domain, which isn't necessarily the domain associated with the list.
The only way that a DKIM check would fail for the given attack, would be if the DKIM included the To: and Cc: headers and the list was configured to reject mail that either (a) failed or did not have a DKIM signature, or (b) did not include the list's address in either To: or Cc:. Is that what you're suggesting?
Alternatively you can set up the list so that the whole post (originator headers included) is sent as an attachment (a signed part of a multipart message). The list can then prepend the trace headers (informational only, not authenticable) from the wrapper message when it forwards the encapsulated message. Outlook users will generally not be able to do this, so it's another proof of concept. :-)
including well-vetted way to be able to cryptographically verify headers that mailman wants to rely on would be great! I'm not sure that wrap-signing a message/rfc822 part is the right way to achieve those goals, though.
(if < means "is earlier than": X < Y < Z)
X: message signature created (according to OpenPGP timestamp) Y: key expired Z: message received by mailman
I don't understand the point of this scenario. X is a valid signature, and there are known to be delays in delivery. X should just be treated as an old signature.
the point of the scenario is to think clearly about the relationship between key expiry and message/signature validity, which are distinct but associated things. doing decent key management is tricky.
- mailman could strip off all outer layers until it finds an inner part that is itself fully signed, and then process that part as though it were the entire message
I think this is the right way to handle layered messages when signatures are required. The
i tend to agree with you here; but it looks like you might have gotten cut off. did you have more to say on this question?
This hand-waves around the difficult question: how do we know what the user's pub-key is?
I think we can punt on this. "The same way we ever do." Ie, we use a PK certification infrastructure or a web of trust. That's up to the list owner.
I think doing proper key management is a lot trickier than that. both X.509 PKI and OpenPGP "Web of Trust"-style authentication networks have a lot of fiddly bits and ways to get the implementation wrong *and* controls that you might or might not want to expose to the end user.
For example, for X.509:
how do you decide what set of CAs belongs in the trusted root authority list?
do you check CRLs in certificates? if so, how often?
do you use OCSP?
Which X.509v3 extensions do you require for message signatures from which algorithms?
For example, for OpenPGP-style certification networks:
which keys do you assign full ownertrust to?
which keys do you assign marginal ownertrust to?
how do you deal with certifications from multiple marginally-trusted accounts?
how often do you check keyservers for updates?
do you honor embedded keyserver URLs?
And for any key management regime:
what do you do with a message that is signed by a key that claims to belong to party X but you can't verify the key identity?
Are all kinds of key identity verification failures the same, or are some different than others? (e.g. do you handle messages signed by expired keys different from messages from messages signed by revoked keys?)
There are probably more questions for each domain, and more general questions as well. how many of the these decisions do you want to expose to the list administrator? how many do you want to expose to the mailman installation operator? how do you choose good defaults for these choices?
What happens if a list member revokes their key, or lets it expire? can that member upload a new one?
Not if they needed approval in the first place. If the list is open-subscription, yes, but a confirmation mail to the subscription address and notification to list owner are required here. I'm not sure if it's possible to use a revoked or expired key in that state, but if so it might be useful to use it "just that one more time".
What does it mean (socially) to have an open-subscription list that requires signatures from posters?
Alice creates a phony mailman instance with a list Y that Bob *does* want to subscribe to; Bob tries to sign up for list Y, expecting a challenge that he will sign and respond to.
When the request from Bob for List Y comes in, Alice spoofs a subscription attempt "From: Bob" to list X, harvests list X's (legitimate) challenge to Bob, and has List Y replay it to Bob as the challenge for List Y. Bob signs the challenge, returns it to list Y (which is still operated secretly by Alice), and Alice in turn replays Bob's signed response to list X.
Probably this requires a version of the Diffie-Hellman handshake, actually.
i'm not convinced that DH will solve this problem without an additional identifying layer -- the problem is the anonymity of the end point itself, which DH won't solve on its own.
I suspect this could be solved by requiring subscription messages and the like to have a standard format that explicitly includes the globally-unique name of the list within the signed body, so that they could not be replayed. There may be other solutions as well, though.
--dkgDaniel Kahn Gillmor writes:
The only way that a DKIM check would fail for the given attack, would be if the DKIM included the To: and Cc: headers and the list was configured to reject mail that either (a) failed or did not have a DKIM signature, or (b) did not include the list's address in either To: or Cc:. Is that what you're suggesting?
Yes. Validating anything about a given message is a PITA, as you know. I think this is the best we can do with the MTA-level headers (by MTA-level I mean they might be augmented or reordered by MTAs, so we would need a DKIM-like algorithm to sign the header in the MUA anyway).
FYI: In Mailman REJECT is a technical term that implies a notification to sender. In context, I assume you meant "reject, discard, or [maybe] hold".
I don't understand the point of this scenario. X is a valid signature, and there are known to be delays in delivery. X should just be treated as an old signature.
the point of the scenario is to think clearly about the relationship between key expiry and message/signature validity, which are distinct but associated things.
AFAIK key expiry is associated with signing, not with validation. Associating key expiry with validation would mean you basically can't use expirable keys with mail, and especially not with archived mail.
doing decent key management is tricky.
Sure, but this particular case is well-defined AFAIK. It's out of our hands.
- mailman could strip off all outer layers until it finds an inner part that is itself fully signed, and then process that part as though it were the entire message
I think this is the right way to handle layered messages when signatures are required. The
i tend to agree with you here; but it looks like you might have gotten cut off. did you have more to say on this question?
I usually do ;-) but often enough it's sufficient unimportant that I forget. I'm not sure what I intended to say. :-/ Possibly a reference to the idea of encapsulating the whole intended message (especially the "originator headers" per RFC 5322) in a signed part to avoid the whole "can we trust the headers" issue. In this format the important headers would be signed, so we trust them as much as we trust the signature.
I think we can punt on this. "The same way we ever do." Ie, we use a PK certification infrastructure or a web of trust. That's up to the list owner.
I think doing proper key management is a lot trickier than that.
Of course it is. I'm saying it's not in scope, not for this GSoC proposal for sure, and probably not for Mailman.
both X.509 PKI and OpenPGP "Web of Trust"-style authentication networks have a lot of fiddly bits and ways to get the implementation wrong *and* controls that you might or might not want to expose to the end user.
I wonder why they're so fiddly? ;-) And why we should think we can do better?
If you're an avatar of djb or Bruce Schneier, say so, and I'll take your word for it. I *know* I don't know enough to make recommendations here, let alone reify them in software. I'm almost certain Barry, Wacky, Terri, Florian, and Mark don't. Nor Abhilash.
And for any key management regime:
- what do you do with a message that is signed by a key that claims to belong to party X but you can't verify the key identity?
Depends on list policy. Default: HOLD. (I'd like to say REJECT, but you don't know you're not creating backscatter in that case.) DISCARD is a more or less plausible alternative, but I haven't thought about it carefully.
- Are all kinds of key identity verification failures the same, or are some different than others? (e.g. do you handle messages signed by expired keys different from messages from messages signed by revoked keys?)
I would say, "not quite, not very, and no" for those two cases. I'm not sure this needs an option: both express the sender's intention that the key not be used in this way. There might be options about how to handle it (eg, I suspect that in both cases the most common reason for receiving such a message is pilot error by the sender, but it needs confirmation -- so REJECT; there are arguments for DISCARD or HOLD, though).
There are probably more questions for each domain, and more general questions as well. how many of the these decisions do you want to expose to the list administrator? how many do you want to expose to the mailman installation operator?
These general questions are use-case-dependent, and therefore the answer now is "none of them" for the list admin, and "all of them" for the instance admin (who in general will be the same at this point in history). As use cases arise, we can revise the design.
how do you choose good defaults for these choices?
"Fail secure".
What does it mean (socially) to have an open-subscription list that requires signatures from posters?
I don't know, and personally I don't really care. I'm more interested in open-subscription lists that require signatures on admin messages.
I conjecture that it could be useful on anonymized lists to prevent spoofing members who have built up trust in their nicknames over time.
I guess this use case might require leaving the poster's signature in place.
I suspect this could be solved by requiring subscription messages and the like to have a standard format that explicitly includes the globally-unique name of the list within the signed body, so that they could not be replayed.
Didn't I suggest that? I intended to. More forgetfulness....
Steve
participants (4)
-
Abhilash Raj -
Daniel Kahn Gillmor -
Joost van Baal-Ilić -
Stephen J. Turnbull