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