GSoC 2017 - Encrypted lists draft

Hi Mailman developers.
My name is Jan Jancar and I study IT Security at the Masaryk university in Brno, Czech republic. I'm interested in this years Mailman GSoCproject, as encryption/security is a topic I'm familiar with and interested in.
I'm currently working on an Elliptic Curve domain parameter generator <https://neuromancer.sk/git/ecgen.git/about/>, as well as some other crypto/security related projects, and my site <https://neuromancer.sk> runs on Python. I have started working on SMTPS/STARTTLS support for Mailman Core as my GSoC micro-project and currently it's almost done:
https://gitlab.com/J08nY/mailman/commits/mta-smtps-starttls
Tests not yet done, as the SMTP test layer doesn't currently support SMTPS, more changes to it will be required.
I've read through some past discussions on this list about PGP integration, went through Mailman Core code and started writing a draft of a project proposal (appended). An up to date version is also on:
https://neuromancer.sk/page/gsoc/mailman
I also have a question regarding project requirements:
- What priority does accommodating naive users (without PGP setup) have for this project? As I haven't found a solution that wouldn't have a significant security impact, other than: install gnupg and setup a keypair.
Please let me know what you think about my proposal so far, thanks!
Jan
#######################################################################
# Mailman - encrypted lists
## Threat model
### Assets
- Message body
- Message metadata (headers + existence)
- Subscriber's identity (list of subscribers of a given list + their
public keys as described in this proposal)
- Existence of subscription for a given address
- Existence of subscription for a given key
- Keyrings (and keypairs in them, as described in this proposal)
Adversary
We assume that an adversary:
- Can read, write, alter, drop any data passed between:
- Mailman Core and it's outgoing and incoming MTA
- outgoing and incoming MTA and lists subscribers
- HyperKitty and Mailman Core (mailman-hyperkitty)
- Is not a subscriber of the list / can not subscribe to the list, as it it's moderated.
- Can not gain access into a subscriber's mailbox as well as his private part of a PGP key
- Can not gain physical access to the machine running Mailman Core or HyperKitty. (RAM access, Coldboot mitigation out of scope)
- Can not get access to the machine running Mailman Core as the Mailman core user or root
- Can gain filesystem access to HyperKitty's archive
Optional assumptions, these can be somewhat protected against and thus become real assumptions, see Attacks and Mitigations:
- Can get filesystem access with enough permissions to access (read/write) Mailman Core queues with Mailman offline
- Can get filesystem access to keyrings described in this proposal
Design
- On top of PGP/MIME
List
- has a list keypair stored in *core keyring*
- has a list archive keypair, which is stored in *archive keyring*
- public key from lists archive keypair also stored in *core keyring*
User workflow
#### List key
- User gains knowledge of lists public key:
- Through Postorious
- Sends mail to
list_id
-key@domain.tld, receives the lists public key, signed by users that chose to publicly sign it. _TODO:_ not the best solution, the problem of binding the list key to a list, and in general key management, is key for this project (see what I did there? :)
Subscription
- Public key a required argument on list subscription, confirmation token sent encrypted with given key to subscribed address, signed confirmation token required (binds users public key with email address used for subscription)
List moderation
- Subscription moderation required for an encrypted list, otherwise, what's the point?
Commands
Required to be signed by user's private key, otherwise discard/bounce (configurable)
New command for key management the correct subscriber of the list). Users who do this have to
key
change
- would require signature with old key, also a new key as an argumentsign
- would require one argument, list's public key signed with users private key, this list key with users signature will be distributed as the list public key (if the signature is valid and from
understand that their signature of the lists public key will be public, thus their subscription will also be public. _TODO:_ It may be possible to allow non-subscribers to sign the lists public key, thus subscibers get some deniability of being a subscriber.
Posting
- Based on list configuration, posting should be encrypted with list pubkey and signed with users privkey
Unsubscription
- Same as now, signature required as for other commands
Technical details
- Will use OpenPGP at a low-level(OpenPGP packet manipulation) to:
- keep the original user's signature
- re-encrypt the message to the list's recipients (in configurable size batches)
- re-encrypt in a way that strips key-ids (not to compromise privacy)
- additionally sign with the list's private key (configurable)
- currently most promising python lib -> https://github.com/mitchellrj/python-pgp
- All possible, see rfc4880
- Considered SELS http://sels.ncsa.illinois.edu/ or similiar proxy
encryption scheme (see references), however:
project idea
- In SELS the list server has no access to the message plaintext, which is great for confidentiality but not for list archiving/moderation/many Mailman features.
- In SELS the list server generates the users private key or at least has to have some information derived from subscribers private keys to work.
- In SELS, many tasks are offset from the list server to the list manager, which actually enables the level of confidentiality the list server has in that model, however seems very impractical.
- General conclusion, SELS doesn't satisfy Mailman's needs for this
What and where?
Mailman Core
- *core keyring* - (gnupg keyring) contains list keypairs, and list archive public keys
- *users keyring* - (gnupg keyring) contains users public keys (for all lists in a given Mailman instance)
- rules in chain, will enforce list configuration such as:
- discard/bounce non-encrypted
- discard/bounce non-signed
- handlers
- to decrypt PGP/MIME message content
- to strip additional header data leaks
- to re-rencrypt and sign PGP/MIME message content for subscribers, in batches
- runners
- possibly a new runner to send dummy messages to subscribers to mitigate traffic analysis (anonymity is not a requirement here/nor a goal, but message existence and list traffic pattern is data that can not be "encrypted" yet can leak)
- REST api
- list key management
- user key management
- _TODO:_ this gives the BASIC AUTH required to access the REST api pretty huge permissions, a more granular access control would be beneficial
- mta
- SMTPS/STARTLS support
- models/db
- address <-> key fingerprint (to find key in *users keyring*)
- list <-> list key fingerprint
- list <-> list archive key fingerprint
- commands
key
command for key management
- new module -> security
- provides interface to manage the *core* and *users keyrings* to rest of Mailman core
Mailman client
- binding of
- list key management REST api
- user key management REST api
- binding of
HyperKitty
- *archive keyring* - (gnupg keyring) contains list archive keypairs
- decrypts messages received from Mailman-HyperKitty using list archive private keys
Mailman-HyperKitty
- has access to the *core keyring* with list archive public keys, uses them to encrypt before sending to HyperKitty
Postorius through Postorious, with just mail + password, as when done through list
- list configuration
- list key management (possibly too dangerous if not run behind HTTPS, and even then), only accessible to list owners
- list subscription
- public key a required argument
- user key management
- _TODO:_ doesn't have the same level of security when done
(signed), what do?
- list configuration
Performance
- Message encryption an obvious bottle-neck
- Working with OpenPGP packets brings a speedup since the message itself is encrypted only once for a batch, but many PKESK packets will need to be created (this is unavoidable).
- Current Mailman Core architecture with runners being separate processes adapts to this nicely
Attacks and mitigations
User -> MTA
- sniffing, altering:
- Messages encrypted with list pubkey
- dropping:
- No mitigation
- writing:
- List configured to require subscribers signature
- sniffing, altering:
MTA -> Mailman
- sniffing, altering, dropping, writing:
- same as above
- sniffing, altering, dropping, writing:
Mailman -> MTA
- sniffing, altering:
- Messages encrypted with users public keys
- dropping:
- No mitigation
- writing:
- Messages signed with list private key (in addition to any user's original signature)
- sniffing, altering:
MTA -> User
- sniffing, altering:
- Messages encrypted with users pubkey
- dropping:
- No mitigation
- writing:
- Messages signed with list private key (in addition to any user's original signature)
- sniffing, altering:
Replay attacks the original and replayed message would be the same, which would alert
- Since user signature is kept, when the list is set to discard non-signed messages a replay attack without list subscribers noticing is not possible (as the signature couldn't be stripped). The signature of
the subscribers that the message was replayed.
list <-> list pubkey binding
- _TODO:_ very important, have some ideas
filesystem access:
- Mailman Core queues
- Put Mailman queue_dir or possibly the whole var_dir into an encrypted fs, mount on start (admin enters passphrase), unmount on quit
- Mailman core keyring/HyperKitty archive keyring
- Use a passphrase encrypted keyring, enter passphrase manually on Mailman start, use gpg-agent. _TODO:_ gpg-agent doesn't have infinite ttl support, try merge upstream?
- Mailman Core queues
References
- SELS: A Secure E-mail List Service - Khurana, Slagell, Bonilla: https://pdfs.semanticscholar.org/fbc2/f88ccc19eaf864171554e52af66b31bb1e91.p...
- SELS slides - Khurana: http://www.ncsa.illinois.edu/People/hkhurana/UIUCSecurity.pdf
- From Proxy Encryption Primitives to a Deployable Secure-Mailing-List Solution - Khurana, Heo, Pant: http://www.ncsa.illinois.edu/People/hkhurana/ICICS.pdf
- Multiplex Encryption: A Practical Approach to Encrypting Multi-Recipient Emails - Wei, Ding, Chen: http://www.mysmu.edu/faculty/xhding/publications/m-enc.pdf
- On the Security of a Multi-party Certified Email Protocol - Zhou: https://pdfs.semanticscholar.org/faa0/2c9e25afcee3e357a321ca323bfbeddefd9c.p...)
participants (1)
-
Jan Jancar