Closed Bug 448964 Opened 16 years ago Closed 1 year ago

Mail should be signed by default

Categories

(MailNews Core :: Security, enhancement)

Product:
MailNews Core
Component:
Security
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: paul, Unassigned)

References

Details

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: 

In order to improve email security, especially now some governments and even private companies are regularly monitoring the contents of all email communication, email should be encrypted by default.

Tools already exist to do this, such as GPG. Thunderbird should ship with these tools and the account creation wizard should create the necessary certificates and keys. Email should by default be signed and include the public key, and received keys should be automatically saved and used to encrypt future mails.

This way all users will be able to take advantage of encryption with almost no effort or technical knowledge. As users communicate, more of their email will be encrypted by default. This will also prevent organisations from monitoring those who use encrypted email, since large numbers of people will be using it without specific intent.

If this is felt to be too strong a response, a compromise might be to include the necessary software and features and to allow the user to enable them in the account creation wizard, with an explanation message recommending their use. Even if the user selects not to encrypt emails when possible, keys should be generated and collected. Furthermore, the default behaviour when replying to encrypted emails should be to encrypt the reply.

Reproducible: Always
Making encryption a default behavior on Thunderbird would require though that *all* possible receiving e-mail clients (also other than Mozilla applications, including all webmail clients) need to be able to handle encrypted messages... Realistically, I don't see this given.
It would not. Messages would not be encrypted unless a public key had been received from the recipient first, in which case they must be using encryption and be able to read encrypted messages too. If they never send a key, mails would still be sent in plain text to them, with the sender's public key attached.

That is the beauty of this scheme - it would not rely on changes in any software or use of encryption by anyone, but would automatically enable it for anyone using TB when communicating with anyone capable of receiving encrypted mail (particularly other TB users).

It would be an excellent marketing point, as no other email client can set up encrypted email automatically AFAIK.
(In reply to comment #2)
> Messages would not be encrypted unless a public key had been
> received from the recipient first, in which case they must be using encryption
> and be able to read encrypted messages too. If they never send a key, mails
> would still be sent in plain text to them, with the sender's public key
> attached.

Yes, that could be a viable path of action.

(In reply to comment #0)
> Thunderbird should ship with these tools and the account creation wizard
> should create the necessary certificates and keys.

Auto-creation of keys is bad, because the trust chain will be broken.
Auto-created GPG keys are worthless, since they're not signed by others. Auto-creating S/MIME certs would provide encryption, but no authentification.

> Furthermore, the default behaviour when replying to
> encrypted emails should be to encrypt the reply.

Yes.

Adding Ben, since we discussed this a bit on the summit.
Also moving to MailNews core.
Status: UNCONFIRMED → NEW
Component: General → Security
Ever confirmed: true
Product: Thunderbird → MailNews Core
I really doubt that this would be a good idea. To wit:

1. Public/private key encryption has one monstrous problem: I have to share my private key with all points I use to access it, which essentially destroys one of the key advantages of IMAP (I want to read my email no matter where I am).
2. Alice sets up an account and sends mail to Bob, which includes Alice's public key. Alice sets up another account on a second computer. Bob sends mail to Alice using her public key. Alice looks on it at the second computer and... can't read it, because the second creation used a different private key. Good UX becomes almost impossible here.
3. For the average user, the information that most needs to be encrypted will be coming from web sites: email invoices, banking statements, etc. These services will need the user's public key in order to encrypt stuff. The end result will be that my grandmother's email saying she's coming over next week gets encrypted while my shipping confirmation is not.
4. As Mnyromyr states, key creation itself is a thorny issue.

In summary, you're opening up UX holes and other problems for ultimately low value. TB does not handle PGP natively mostly because of UX issues, let alone forcing one to use such a service transparently. I think this will lead to very bad results.
Disclaimer: I am neither a security nor a UX expert.
(In reply to comment #3)
> Auto-creation of keys is bad, because the trust chain will be broken.
> Auto-created GPG keys are worthless, since they're not signed by others.
> Auto-creating S/MIME certs would provide encryption, but no authentification.

Well, encryption is the main goal here, authentication is another issue entirely. The basis of the problem is that mail is regularly snooped on, and people using encryption stand out. Even if there is no authentication, that is no different to the current situation.

(In reply to comment #4)
> 1. Public/private key encryption has one monstrous problem: I have to share my
> private key with all points I use to access it, which essentially destroys one
> of the key advantages of IMAP (I want to read my email no matter where I am).

Portable TB? ;-)

I take your point though. People who use IMAP/webmail currently have no good way to use encryption too, which is a failing of IMAP/webmail itself and which is easily avoided by not using encryption on those accounts. Again, TB could recognise when an IMAP account is being used and default to off or issue an information message to allow the user to decide.

> 2. Alice sets up an account and sends mail to Bob, which includes Alice's
> public key. Alice sets up another account on a second computer. Bob sends mail
> to Alice using her public key. Alice looks on it at the second computer and...
> can't read it, because the second creation used a different private key. Good
> UX becomes almost impossible here.

A general encryption problem, and although you don't say it presumably IMAP related too since POP3 usually does not store email once it has been downloaded. An easy way to expert certificates or copy accounts to other machines would help.

> 3. For the average user, the information that most needs to be encrypted will
> be coming from web sites: email invoices, banking statements, etc. These
> services will need the user's public key in order to encrypt stuff. The end
> result will be that my grandmother's email saying she's coming over next week
> gets encrypted while my shipping confirmation is not.

Let web sites worry about that. I agree though - they use SSL but then send the details via unencrypted email anyway. Sounds like someone needs to set up an open source project to fix this.

> In summary, you're opening up UX holes and other problems for ultimately low
> value.

I wouldn't call privacy "low value".

As I stated, this would not fix everything, but would at least help Jo Average protect her privacy. Right now it's fairly pointless sending anyone an email with your public key unless you know they are using GPG, but if it was included as standard it would be worth attaching the key to every email and the move to an encrypted conversation would be automatic for both parties. Even if by default all it does is generate a key pair... It's a start, and I expect many other open source email clients would follow.
QA Contact: general → security
(In reply to comment #2)
> It would not. Messages would not be encrypted unless a public key had been
> received from the recipient first, in which case they must be using encryption
> and be able to read encrypted messages too. If they never send a key, mails
> would still be sent in plain text to them, with the sender's public key
> attached.

I'm still a bit in doubt with making that the default behavior in terms of the user experience. If the public key is attached to all e-mails, it may be quite confusing for the recipient seeing some cryptic base64 block attached to the message, depending on how the receiving e-mail client displays the key. Such an addition may be considered "buggy behavior" by someone not familiar with mail encryption. Thus, first promoting a wider awareness and the use of encryption before thinking about making it the default may be a better approach than just throw it at the people and expect them to understand it.

[Same disclaimer as comment #5, I'm neither a security nor a UX expert.]
Again, I have to disagree. The key can be sent as a MIME attachment, which will not be visible as part of the main body text.

An alternative would be to supply a header, which would not be shown at all to the user, which could act as an indication that the sender has a public key that the recipient could request. The request could be automatic if the key could be stored on a public server, or perhaps by return header indicating that the next sent email should have the key attached.

The user could be notified of the availability of a public key with a drop-down message, similar to the ones in Firefox for missing plugins or the password manager, if you want to keep it optional.

The goal should be to provide the tools required and make using encryption as easy as one click, all set up and ready to go by default. Currently no other mail client that I am aware of offers this.
There's no way we could make encrypting (or even signed) mails the default. Next to nobody would actually be able to read what you send. 

Reporter: I'm very curious - did you actually even try to send a single S/MIME signed or encrypted mail before filing this bug? (Yes, we support that!)

If replies to signed/encrypted doesn't follow suit, that's a separate issue.
I sign all emails and have my public key attached. It doesn't seem to cause any problems at all.

You seem to be confused - I wasn't suggesting email should be encrypted by default.
Magnus,
> Next to nobody would actually be able to read what you send. 

Please read the first two comments from the reporter carefully. They answer that and your other objections.
He's talking about GPG, not S/MIME. S/MIME is useless against governments or other very powerful attackers.

jcranmer wrote:
> 1. Public/private key encryption has one monstrous problem: I have to share my
> private key with all points I use to access it, which essentially destroys one
> of the key advantages of IMAP (I want to read my email no matter where I am).

No, it does not. All you need to do is to put your key on all machines where you want to access your mail. You also need to know the IMAP password on all these machines. In both cases, this is a one-time action. You can use your IMAP mailbox transparently on both machines thereafter.

> 3. For the average user, the information that most needs to be encrypted will
> be coming from web sites: email invoices, banking statements, etc.

I strongly disagree. I don't get bank statements via email (which stupid bank does that?), and even if I did, they are only mildly sensitive. What's most sensitive is the private communication with my close friends and wife/husband - this can contain really sensitive information which can destroy *humans*, not just bank accounts.

This may not be the case for you, but for many people, including average people, at least in traces, which are dangerous enough. I think this is the biggest reason for using GPG.

> 2. Alice sets up an account and sends mail to Bob, which includes Alice's
> public key. Alice sets up another account on a second computer. Bob sends mail
> to Alice using her public key. Alice looks on it at the second computer and...
> can't read it, because the second creation used a different private key. Good
> UX becomes almost impossible here.

Indeed. That is the core problem here. I have no good solution yet.

If Alice changes her key randomly whenever setting up new machines / TB profiles, Bob can't distinguish that from an attack. If that happens a few times, they'll stop to be concerned about key changes, they will not longer think that it's an attack. At this point, the whole GPG system gets pretty useless, because an attacker can just subvert his own generated key and pretend to be Alice (and Bob, i.e. MITM). This destoys the whole GPG system, because even knowledgeable users have to accept constant key changes from others.

Somebody (David Ascher? dmose?) proposed using Weave for storing the keys. This may be a solution, but has other downsides: 1) relying on a central service 2) depending the security of the private (!) key on Weave cryptography and security, and 3) the Weave private key also needs to be retrieved somehow, so we're back to square one. Only when the private key for Weave is also stored on the server would this work seamlessly, and then all depends on the password (at *best*).

I see this (how to ensure that users keep the same private key for their whole life, and how do they get it from one machine / installation to the next) as the main conceptual problem blocking this feature.
Note that I am assuming an "SSH model" for GPG keys: First key seen is assumed to be correct, all later mails must use that key or it's considered an attack.
There's no chance average users will sign each other's keys - they simply don't understand the background, and I doubt they have the patience to learn it.
(In reply to comment #10)
> You seem to be confused - I wasn't suggesting email should be encrypted by
> default.

Updating the summary then.

And if we're talking about GPG, isn't this a dupe of bug 22687 (at least to start with).

>  S/MIME is useless against governments or other very powerful attackers.

It is? Isn't that just a question of using a strong enough key?
Summary: Mail should be encrypted/signed by default → Mail should be signed by default
Mails should be encrypted by default if possible (when we have a key for the recipient).

> >  S/MIME is useless against governments

> It is? Isn't that just a question of using a strong enough key?

No. This is a long topic though and has been discussed on m.d.security. Just briefly: Because governments have access to root CAs and S/MIME doesn't consider a changed key to be a problem (doesn't even warn), as long as it's signed by a CA.
Summary: Mail should be signed by default → Mail should be signed/encrypted by default
> Isn't this a dupe of bug 22687

No, it depends on that, but doesn't mean to enable it by default, and for that, we need to solve the problems mentioned in comment 11, so this is different.

I do remember having proposed and discussed this before, I just don't remember whether on a newsgroup or a bug.
Depends on: pgp
I think the high complexity of PGP (exchanging notes with long numbers at WOT signing parties is not something most users will do) compared to the minor potential of (any?) government to view an S/MIME encrypted e-mail(*) strongly favors S/MIME.

(*) If it's only the US government, they have strong safeguards against abuse and the US citizens are generally very sensitive to personal freedom. Not a non-problem, but extremely minor IMO.

I think we should indeed sign all e-mails by default (as I do), but we should not encrypt them by default (for many of the above-stated reasons).
> If it's only the US government, they have strong safeguards against abuse

hahahahaha

(And it's also other governments.)

> high complexity of PGP (exchanging notes with long numbers at WOT
> signing parties is not something most users will do)
> compared to ... S/MIME ... strongly favors S/MIME.

Please see comment 12 again. I agree that key signing parties are out of question for normal users.
Compares to GPG in the SSH model, S/MIME is far more complex, because it requires registering with a CA, which we have little chance of doing seamlessly and by default.
Anyways, S/MIME vs. PGP is a philosophical and political debate which does not belong here. I think we should limit the bug to GPG, as the bug filer suggested.
To get this back on track a bit, I am not suggesting that all mail should be encrypted all the time or anything like that. All I'm saying is that GPG should be bundled with TB and set up during the account creation procedure. After that, any public keys received should be collected and if a request is made to start encrypting a conversation, then encryption should be used for replies.

It would not break anything or cause any nasty user interface issues. All that would happen is that when the user receives an email with a request to start an encrypted conversation (assuming the sender does not have their key already), the reply is automatically encrypted and the user's public key attached. Add a padlock icon to show that the mail is encrypted, just like with web sites.

A confirmation request could be displayed perhaps, with a simple explanation which notes the potential issue of not being able to read the mail outside TB.

At the very least, I see no reason why GPG could not be included with TB and set up during account creation, even if it's not used at all by default. At least the option would be there.
Summary: Mail should be signed/encrypted by default → Mail should be signed by default
(In reply to comment #10)
> You seem to be confused - I wasn't suggesting email should be encrypted by
> default.

I beg to differ:
(In reply to comment #0)
> In order to improve email security, especially now some governments and even
> private companies are regularly monitoring the contents of all email
> communication, email should be encrypted by default.

In any case, I would not have any problems with /signing/ by default [1];
encryption is another matter entirely. As a first step, though, PGP would need
to be added--this is the single most heavily-voted for bug in TB (417 versus
#2, 287). As noted in bug 22687, there is an impressive barriers to getting
this to work, as what would be needed is something simple, but security often
makes simple difficult.

[1] Okay, to clarify: I have no problems with the theory of signing messages by
default as opposed to the wholesale encryption. Theory and practice don't mesh
well in this area, because what would need to happen would be (AFAIK)
unprecedented UX. In any case, there's no hope for this feature by TB 3, and
probably a dim one even for "TB.next"
As it's not advisable to autogenerate keys, we have to let that be done by the user. But we should (try to) detect, if
- incoming mail is signed/encrypted and tell so
- GPG etc. is installed locally and tell that it's needed
- make installing of GPG etc. as easy as usefully possible, i.e. point users to the right information and where to get it, but don't impose fancy autogeneration upon users who don't know what's happening.
After all, it's about trust: I can't trust something I don't understand. That's just believe.

Two examples:
1. - we recognize an incoming mail as GPG-encrypted
   - we are not configured for this
   - but we detect user has GPG installed 
   - when showing the mail:
     - ask user if he wants to configure us for GPG and 
       where to find his key data
2. - user starts editing a mail
   - we detect he has GPG installed, but we're not configured for this:
     - ask user if he wants to configure us for GPG and 
       where to find his key data
   - really start editing mail now

If we have GPG configured and all recipients have a key, sending encrypted should be default. Else sending signed should be the default. Only mails explicitly set to not signed nor encrypted should go out like that.

All this can be done without actually having to install GPG or anything else, all we need is a supersmart internal Enigmail version. ;-)
Karsten, this is more or less the state as-is. If you know what GPG is and have it configured and use it, you can install EnigMail.
I think this bug is exactly asking to let average users use GPG, even if they don't understand it. The burden is on us to make it secure without them understanding cryptography.
And, FWIW, SSH shows that it's possible.
Lets keep in mind that in this case, using inadvisable standards for encryption is OK, so long as it is more secure than Plain Text. Its not so much an issue of how perfect this can be, but rather how much more secure we can make emailing.
* Changing Version because enhancements are always implemented first in Trunk.

* I think that whatever the decision about this bug, it should be common to Thunderbird and SeaMonkey; but if the respective owners of both mailers make different choices, then separate bugs will of course have to be opened, probably this bug for the common backend parts and two dependent bugs for the separate frontend parts.

* I am not a partisan of changes giving the user a false sentiment of security. In particular, if the public key is sent with the message, a would-be MITM attacker could still alter the message and substitute his own key: the interception won't be detected unless the addressee tries to reply directly to the [well-known] original sender, using the public key for enciphering, and the original sender cannot read the reply. Of course, this particular argument falls if some way is found to communicate the key (or part of it: password, passphrase, etc.) by separate means, which could vary depending on circumstances: face-to-face contact, username/password established previously by HTTPS, etc.

Similarly, a key system which can be broken by brute force in a fairly short time using up-to-date technology should IMHO not be regarded as acceptable, *especially* for nontechnical users (and by "nontechnical" I include a certain university professor I know, from a Computer Science faculty, who recommends sending so-called confidential information as attachments enciphered via zip. <shudder/>)
Version: unspecified → Trunk
> Messages would not be encrypted unless a public key had been received from the recipient first,
> in which case they must be using encryption and be able to read encrypted messages too.

Not necessarily. Multiple clients (Thunderbird + Webmail + Cellphone with IMAP) are commonplace today.
Slow down there Tony. Let's not call GPG itself in to question. As far as I know GPG has never been cracked. It's 100% safe to send your public key in a clear channel. Many security professionals put the public key up on their websites so that encrypted mail can be sent to them directly on the first message. 

* The key injected by your MITM scenario would allow the victim to send encrypted messages to the attacker. If you are sending e-mail to the wrong address then you have bigger problems that technology cannot solve for you. Let's not delve in to fantasy land.

It would be awesome if Mozilla had a central key repository where they could independantly share and verify the public keys of all users of Thunderbird but that's entirely different issue requiring a whole bunch of support. Let's just start with getting the average user on board with encryption. We need everyone on the same page. It doesn't help that even people here on this board don't understand the technology or the dire need for it. For every contact in your address book that does not have a key associated to it you will need to perform a key ceremony. This can be as simple as exchanging signed messages with keys attached. Or the user can choose to use a double blind secure drop in meatspace. I don't care. Let's just make the default behaviour easy to use.
(In reply to adam_kauffman from comment #28)
> * The key injected by your MITM scenario would allow the victim to send
> encrypted messages to the attacker. If you are sending e-mail to the wrong
> address then you have bigger problems that technology cannot solve for you.
> Let's not delve in to fantasy land.

Have you read documents like <http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html>? Security is *very* hard to get completely correct. The underlying cryptographic primitives of PGP may be unbroken, but that doesn't mean that their use is guaranteed to give every guarantee.

> Let's just start with getting the average user on board with encryption. We
> need everyone on the same page. It doesn't help that even people here on
> this board don't understand the technology or the dire need for it.

Here's a little story I want to tell you, that comes from a security researcher professor. This professor realized that since his group dealt with cryptography all the time, it only made sense that all of their internal group communication should be encrypted. They called off the experiment after a few days because there was too much hassle in getting everything working in a scenario with very diverse clients. And this is not a group of people who don't know their way around a computer; this is a group of people whose daily job is working with security.

The challenges involved in getting always-encrypted email are immense, and I'm not even talking about the difficulty of UI here. As a brief listing:

1. Generation, signing, authentication of keys. Cryptographic security relies on the idea that keys are time-limited.
2. Support for S/MIME or PGP (I've noticed you implicitly assume PGP, but I would be willing to guess that S/MIME is actually supported out-of-the-box by more clients than PGP). Note however that webmail clients do not support S/MIME or PGP--this includes big names like Gmail. And I am also willing to bet that most clients on mobile devices also do not support encrypted or signed email functionality.
3. Key stewardship. People rely on security for authentication guarantees, which implies that keys should require some sort of user action to use (i.e., retrieving from a password-secured keystore). This implies that, in particular, many webmail clients are going to be unable to access keys for encryption/signing--I've talked to the security people at Mozilla about this, so this isn't a response from someone who "doesn't understand the technology."

In effect, encrypting email by default would break email for a significant fraction of the population, which means we would lose many of our users. And if we don't have users, then we have no impact.

As far why we don't bundle PGP with Thunderbird by default, the answer is simple: the licenses are incompatible.
Firstly, the topic is GPG not PGP. The difference is mainly licensing:
http://www.gnupg.org/

We don't need to fix all the worlds problems all at once. Many of the problems you see with the solution exist already and we aren't introducing any new secuirty problems that don't already exist with common e-mail. To throw out a solution because it only fixes one problem is not a valid argument. 

Let's define the goal:
Encrypted during transit.

Keep it simple. I don't care if the key changes daily and I can't verify the sender. E-mail spoofing is currently simple and this is a step in the right direction. I just want my communications to travel through the internet in a scrambled form. It exists in plain text on my PC and it exists in plain text on the other end too. That's okay. If you are serious about all the concerns you have then none of us should be using e-mail at all for anything ever. Let's lay the groundwork for progress to take place. Baby steps. Rome wasn't built in a day.
The problem here is simple: Without key verification on secure channels, *and* with potentially changing keys, things go down.

1. Marie sets up Thunderbird on computer A. Thunderbird makes key A.
2. Marie sends me a message, with key A.
3. I accept key A as from Marie. (And in fact it is.) I send her encrypted mail, all is fine.
4. This continues for a year. Marie and me get close, exchange very private matters.
5. Marie gets a new computer and sets up Thunderbird on computer B. Thunderbird makes key B.
6. Marie sends me a message, with key B.
7. I accept key B as from Marie. (And in fact it is.) I send her encrypted mail, all is fine.
8. Ethan manages to get access to Marie's mailbox, e.g. by intercepting mail
   before/after it, or by hacking her hotmail account.
9. Ethan sets up key C for Marie's email address.
   He sends me mail from Marie's address, posing as Marie.
10. I accept key C as from Marie. (But in fact is not.) I send her encrypted mail, for key C.
11. Ethan is asking me a sensitive question, posing as Marie, and I answer.

How am I to differentiate case 6/7 from case 9/10? I cannot. Not without verifying Marie again. Which normal users won't do.

Normal users don't realize that case 6/7 is a serious security breach. Adam Kauffman demonstrates that even people in the computer security business do not realize the grave danger that such a model poses.
(FWIW, I can't believe somebody from Symantec would write something like comment 30.)

Essentially, you're proposing to change PGP to an SSH model, *without* insisting that the keys stay the same. That's critical part in SSH, that case 6/7 above is considered a security breach, without which it doesn't work. However, end users do set up new computers all the time, and they don't understand the implications of new keys, so I don't know how to solve that. As much as I'd like to bring PGP/GPG to the masses.
Let me repeat. This problem already exists. Your scenario requires that Ethan has access to Marie's e-mail. There is nothing that can save you from this scenario. You have lost at this point. Game over.

The goal I stated is still achieved: The e-mail traveled through the internet in an encrypted form. When Marie get's this message she won't be able to read it without the key that Ethan made. Hopefully she takes action to reclaim ownership of her account at this point. This sort of thing will happen just as frequently as it currently does. Zero change there.

My goal is encrypted transmission not completely secure e-mail. Completely secure e-mail may not be possible. Let's stop talking about it.
If you're concerned with the key authentication then you need to open a different ticket requesting a Mozilla key server. It is a sperate part of the puzzle and it's off topic in this thread.
> Ethan has access to Marie's e-mail. There is nothing that can save you from this scenario.
> You have lost at this point. Game over.

Wrong. This is precisely what PGP protects from.

IF only Maria has her private key and I am sure that the public key belongs to Maria (and it's the same key always), and I sign and encrypt emails to her, and vise versa, and Ethan has access to all mails going to and from from Maria, then Ethan still doesn't know what Maria and me are talking about. This is what PGP promises, and it does work. Your proposal fails that, indeed.

OTOH, encryption is *useless*, if you're not sure that you're sending to the right party. If I encrypt, but use Ethan's key instead of Maria's, that's rather stupid.

I don't want to be rude, but seriously, you don't understand how PGP works, and thus are missing the point. Please read up on PGP first.
Thanks Ben. The scenario was "by intercepting mail
before/after it, or by hacking her hotmail account." 

If Ethan intercepted mail it would be encrypted. If he hacked the account he can send his own mail as her. I was merely saying that this is a mute point and totally off topic.

There is talk of "grave danger" but how is this any different than how e-mail currently works? How does this situation get worse by adding encryption? Why are you ignoring the possibility of using a keyserver?

Thunderbird could hook in to a keyserver like http://keyserver.pgp.com/ for both key storage and central verification but I'm trying to say that is a different issue for a different ticket and shouldn't be discussed here. Maybe I am wrong. In the end, people will make mistakes and you will never be secure. That does not mean we shouldn't try to make progress.
(In reply to adam_kauffman from comment #35)
> If Ethan intercepted mail it would be encrypted. If he hacked the account he
> can send his own mail as her. I was merely saying that this is a mute point
> and totally off topic.

If you accept that your proposed encryption scheme need not cover the actual account storage, then the current email architecture already satisfies your goal. In most email setups, you will send your message via an encrypted connection to your account's SMTP server, which will then transmit directly to the destination SMTP server, which will then be deposited into an account which would only be retrieved via another encrypted connection. The only people with plaintext access to the email in such a scenario would also have plaintext access to the account to begin with, satisfying your definition of security.

If you are slightly more paranoid, then I suggest rot13'ing your message body: it is secure against anyone who would try to grep all messages they see get transmitted over any cleartext transmission and is less annoying for most users.

> There is talk of "grave danger" but how is this any different than how
> e-mail currently works? How does this situation get worse by adding
> encryption? Why are you ignoring the possibility of using a keyserver?

Email security works today and comes with specific guarantees about message authenticity that are important to some subgroups of people. However, those guarantees are conditioned on assumptions about trust models. Designing an encrypted-by-default scheme without taking these things into account properly destroys present guarantees of security.
I post here because I had the same (closed) idea:
https://bugzilla.mozilla.org/show_bug.cgi?id=892793

No one needs a garantuee of a perfect security. The main goal is to avoid using simple text filters or viewing mails without any time and effort for the attacker/hoster/government.

Every lock and key service is able to open your door, but its save enough against 99% of the others to guard your privacy. Same goal.
See Also: → 1243449
No longer depends on: pgp
Severity: normal → S3

-> WONTFIX. Users in general would not be happy. It needs to be opt-in.

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.