From 9a3f1a9ba6938a3c43c3fe3dd1471ba8272931f6 Mon Sep 17 00:00:00 2001 From: Lars Wirzenius Date: Fri, 27 Dec 2019 13:46:40 +0200 Subject: Add: first sketch of a new email system --- email2.md | 332 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 332 insertions(+) create mode 100644 email2.md diff --git a/email2.md b/email2.md new file mode 100644 index 0000000..56759f2 --- /dev/null +++ b/email2.md @@ -0,0 +1,332 @@ +--- +title: Reinventing electronic mail +... + +Introduction +============================================================================= + +I am fed up with Internet email. There's spam, and the email system is +getting centralised in all sorts of bad ways. This idea is about +sketching what a good email system would look like, if it were +re-designed from scratch, using everything we've learnt over the +decades. + +Good aspects +----------------------------------------------------------------------------- + +* Ubiquitous. Approximately everyone on the Internet has email, or can + get it. + +* Anyone can email anyone. This lowers barriers for communication, + globally. It's especially important for free and open source + projects, but also to allow people all over the world to + easily self-organise to build a better world in general. + +* Distributed: sender and recipient don't need to use the same server. + +* Standardised, with many (many!) inter-operable implementations. + +* Supports off-line use. Not everyone can, or wants to, be online all + the time. + + +Problems with the existing email system +----------------------------------------------------------------------------- + +* Spam. Worse, anti-spamming measures drive centralisation, and are + still ineffective, especially for those not using the huge + providers. End result: you either sacrifice privacy or you get tons + of spam. + + - This is a result of the desirable feature that anyone can email + anyone, combined with the fact that sending an email costs + approximately nothing, and that sending a million email also costs + approximately nothing, and aggravated by the fact that spamming + has de facto no real financial or legal repercussions. + +* Scam. There is no widely used method to digitally sign email, and + thus criminals can easily fake messages to look like they come from, + say, Amazon, Netflix, Paypal, or other companies the recipient is + likely to use. Everyone needs to be constantly on their toes to + avoid mistakes. + + - There are standards for digitally signed email, but + +* Becoming centralised to a few huge providers. This is bad for + privacy and can be catastrophic for security. If one of the big + providers gets breached, up to hundreds of millions of people's + communications are at risk. + + - We're moving towards a future where if you host email yourself, + you're suspicious. It's already the case that it can be difficult + for a self-hosted email server to reach people on Gmail. + +* No real privacy, even if you self-host. Email is by default in + clear text, and while there are standards for encryption, they are + not widely used, and tend to also leave metadata (headers) + unencrypted. + +* HTML email is not well standardised, and a security and privacy + risk. Different email clients implement HTML in different ways, and + the web standards are not followed very closely. + + - Worse, there's an assumption that HTML emails can embed images + from the Internet, which results in more security problems (images + are complicated data provided by a potential attacker, and just + viewing them is a security risk), and privacy issued (the image + hoster will be notified when you view the email, see tracking + pixels). + + There's moves to restrict this, but the problems have been known + since soon after HTML email was introduced, and at least some of + the problems still exist. + +* Attachments fill disks. Email is commonly used to share files, + because it's easy and ubiquitous, even if it's not very good at it. + There are services that make this better, but they are mostly + proprietary, and require extra effort. + +* There is no good support for group discussions. Massive dumps of + forwarded discussions are commonplace in most large organisations. + Mailing list managers exist, but they tend to be clunky, and tend to + not be great for having discussions among large groups of people. + They're better at sending out announcements and newsletters. + +* The technologies and standards for email are getting ridiculously + complicated. Email was originally designed for relatively short + messages in English only. To support non-English languages in a + backwards compatible manner, email has gained whole extended + families of ways to encode text and data: uuencode, base64, + quoted-printable, and header encoding, to start with. + + The email tech stack is getting so hard to understand that it's + difficult to even use, never mind implement correctly. Never mind + that the complexity results in more effort to operate and keep + secure the servers. + + +Possible solutions +============================================================================= + +This document tries to outline a possible solution to all the problems +above. + + +Overview +----------------------------------------------------------------------------- + +The shape of possible solution might be something like this: + +* everyone has any number of "email identities", which are roughly + like email addresses; it's easy to create new identities, and to + optionally link them together; each identity has cryptographic keys + encryption and digial signatures + +* all email is encrypted to the recipient's, and signed by the sending + identity + + +Spam +----------------------------------------------------------------------------- + +Spam, or unsolicited bulk email, is probably the first problem to +solve, as the solution will likely constrain other aspects of the +system. + +The reason current email has a spam problem is three-fold: + +* anyone can send email to anyone +* sending any amount of email is basically free +* there is no real consequences from sending unwanted email, except + for the sender's reputation + +What we want from the solution: + +* anyone can send email to anyone who wants to receive it +* sending email should be basically free, if the receipient wants it +* sending email without prior arrangement does not need to be free + +A possible solution might be a kind of digtial stamps. + +* Alice can give Bob a stamp to allow Bob to send email to Alice +* Alice can give her friends permission to give out stamps on her + behalf, to allow friends to introduce new people to Alice + - as a variation, Alice might give permission to her employer to + give out stamps on her behalf to co-workers +* If Bob doesn't have a stamp, but still wants to reach Alice, his + email software can ask Alice's server for one, and this can be made + "costly" in some way so that it's hard for spammers to automate + +When Bob sends an email to Alice, the email will come with a stamp to +allow Alice's response to reach Bob. + + +Stamps +----------------------------------------------------------------------------- + +Digital stamps are not exactly like paper stamps. Paper stamps cost +money, and can only be used once. A digital stamp can be more +versatile: + +* might be used any number of times, or only once +* might be valid indefinitely, or only for a specific time span +* might be valid for any sender, or only for a specific sender, or + require specific keywords in the email, or have other filtering + rules +* might not allow sending an email, but instead might delegate the + power to issue stamps to someone else; the delegation might + constrain the kind of stamps the delegate can issue +* might be cancelled by it's issuer at any time + +Stamps can be created manually via the mail user interface, +automatically when sending email, or when joining a mailing list or +signing up for a service. + +The format of stamps is open, for now. However, they should probably +be compact enough that they can easily be communicated manually. QR +codes might be useful. + + +Generating stamps to reach someone else +----------------------------------------------------------------------------- + +Each email server can issue stamps for an identity hosted on the +server, if the identity has delegated the server that power. This +would probably be a web service provided by the server to someone +requesting a stamp. + +* stamp issuing might be rate limited - per server, or per group of + collaborating server; possibly a group based on the social graph of + the issuer + +* the requestor might need to do some work to raise the cost of + stamps: solve a cryptographic puzzle, or do some similar task; this + would be easy enough that it's not expensive enough if it happens + occasionally, but enough that it stops spammers from doing it en + masse + + + +Signing up for newsletters and services +----------------------------------------------------------------------------- + +Currently, the operator of a newsletter can add any email addresses to +their mailing list. It's more of a convention than a technical +requirement that the recipient must confirm they want the newsletter. +This is abused often by the less scrupulous operators. + +With the stamp model, the recipient would create a stamp (possibly +single-use, or limited to a time period) and provide it to the +operator to be added to the mailing list. The receipient can get off +the mailing list by cancelling the stamp. The mailing list doesn't +need to even have an unsubscription feature. Without a valid stamp, +the newsletter doesn't reach the recipient. Rejecting a stampless +message can be made cheap enough that it's not a problem. + +Likewise, when using a service (buying tickets to an event? flights? +stuff from an online shop?) that may need to send a message, the +customer would provide the service with a stamp for such information +messages. Such a stamp might be time-limited, and might delegate the +power to, say, issue additional stamps to a third party necessary for +providing the service (e.g., Amazon might issue stamps to the courier +to let them reach the customer). + + +Email identities +----------------------------------------------------------------------------- + +An email identity is not an address. Email addresses are tied to +locations (servers, domains). This makes it difficult to move one's +email to another location. + +An identity in the new system is a large randomly generated number +(UUID4). Routing messages is an unsolved problem. + +Each user can have any number of identities they like. + +To an identity some metadata is attached: + +* one or more names +* for each name, zero or more certificates from other identities +* zero or more other identities for the same person (optional) + - FIXME: give rationale for this +* one or more public key pairs for encryption, certificates, + authentication + +Each message is signed by at least one certification key of the +sender, and encrypted with every public key of every recipient. + + +Names +----------------------------------------------------------------------------- + +All names attached to an identity are decided by the identity's owner. +Others can certify that they believe the identity and name belong +together. This is similar to the Secure Scuttlebutt pet name system. + + + +FIXME +============================================================================= + +All of this needs to be thought about. + + +Routing messages +----------------------------------------------------------------------------- + +FIXME: this needs to be solved in some way. The SSB approach probably +doesn't scale. + + +Message format +---------------------------------------------------------------------------- + +FIXME: this needs to be sketched. For now, assume something that's +rougly on par with RFC2822, but with simplicity. Possibly JSON. + + +Group discussions, mailing lists, signing up for services +------------------------------------------------------------------ + +FIXME: this needs to be sketched. + + +Withdrawing or removing sent messages +----------------------------------------------------------------------------- + +Remove sent messages? At least to groups? + + +Encryption +---------------------------------------------------------------------------- + +Allow rotation of keys. Allow multiple keys per identity, at least one +per device. Allow future versions to change encryption algos etc. + +Perfect forward security? + +Revoke sent message? + + +Mobile as a first class citizen +----------------------------------------------------------------------------- + +About half the people using the Internet now are using mobile only. A +new email system should take that into account. + +That said, desktop/laptop computers are still hugely important and +can't be neglected. + +Ideally it would be easy to implement the client software in any +platform, to allow maximum diversity. + + +Specifications, conformance +----------------------------------------------------------------------------- + +All aspects of protocols and messages should be specified in +sufficient detail and clarity to allow independent, inter-operable +implementations. There should probably be a common test suite for +conformance, and some dedicated interoperatibility testing. + -- cgit v1.2.1