418424 - absent email signature disclaimer is unsatisfactory

Status: NEW

(MailNews Core :: Security: S/MIME, enhancement)

Description

[Martin Sch]

When I get a encrypted and not signed mail and click on the lock, thunderbird says: "This message does not include the sender's digital signature. The absence
 of a digital signature means that the message could have been sent by someone 
 pretending to have this email address. It is also possible that the message 
 has been altered while in transit over the network. However, it is unlikely 
 that either event has occurred."
                
I'm very glad that it is unlikely that a man in the middle has altered the email.  How does thunderbird calculate this likelihood? I mean if I worked in an russian embassy, does thunderbird say it could very well be that the email has been changed?

Or is the message of the kind: in general, the world is good, so don't think about email security?

Comment 1

[Daniel Veditz [:dveditz]]

The last sentence of that message is mostly wishful thinking. In order to encrypt a message the sender, any sender, needs only the public key from the recipients email certificate. Everyone sending encrypted mail to the same recipient will use the same public key -- anyone with access to your certificate (which may or may not be hard to come by, depends on how much signed mail you send) could create a new substitute encrypted message.

They would not be able to decrypt the message first in order to make a slight alteration, they'd have to guess and substitute a message they made up. Saying the message could be "altered while in transit" seems to imply the former. If the message contained information only the sender knew then it's still secure, but without the signature you can't be sure it was really that sender.

Currently it looks like the sender has to separately choose to both encrypt and sign the message (unless they've set up their account to always sign). Thunderbird really ought to select signing by default if encryption is chosen (there may already be a bug filed on that, I haven't checked.)

Comment 2

[Martin Sch]

Sorry for my entry beeing more ironic than technically clear.
The point is: the program should not make any assumptions on how likely it is that the email has been changed. The sentence "However, it is unlikely 
 that either event has occurred." should be removed.

Comment 3

[Kai Engert [:KaiE:]]

I think the intention of that sentence was to express that it's still possible the email was sent by the shown sender, but we simply don't know.

Maybe we could rephrase the paragraph like this:

It is unknown who sent this message, because the message
does not include the sender's digital signature.
The message could have been sent by the shown sender, or it could
have been sent by someone pretending to have this email address.
It is also possible that the message 
has been altered while in transit over the network.

Comment 4

[Kai Engert [:KaiE:]]

I think we should not enforce that encrypting requires signing.

In the past, we had that requirement, and some people were unhappy, so we relaxed it.

You might sit at a computer without your personal cert, but still want to send something encrypted.

Or you might want to intentionally remain anonymous when sending the encrypted email.

Comment 5

[Nelson Bolyard (seldom reads bugmail)]

> You might sit at a computer without your personal cert, but still want 
> to send something encrypted.

Well, you're out of luck, because the sender is always implicitly a recipient 
of encrypted emails he sends.  Therefore, the sender must have at least an 
encryption cert of his own to send encrypted emails.

The disputed text is an attempt to disclaim that encryption implies sender 
authentication, which testing has shown in a common misperception.
But including it has the unwanted effect of sounding a warning for encrypted
email that does not appear for unencrypted email, making newbs fear that 
encrypted email is less likely to truly identify its sender than is 
unencrypted email.  

Perhaps it is best to simply say that the chance that the From information
is false is absolutely no different than for unencrypted email.  That should
at least make it clear that this is no worse than unencrypted email.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Nearly all spam has forged From addresses, and for some users, such spam is 
the majority of email they receive.  So, we cannot say that it is 
statistically improbable that the From address is forged for any piece of 
unsigned email.  And even for signed email, the sender's From address is not
verified unless it is "triple wrapped".  IINM, there is an RFE for triple- wrapping that is awaiting a code and UI review. :)

Comment 7

[Martin Sch]

As far as I understood S/MIME, to decrypt a message it is necessary to have the receivers private key and the senders public key.

If I can decrypt the mail with my private key that means that it's me and the mail was for me. And if I decrypt it also with the senders public key that means it has been encrypted by that person which gave me the public key. 

So how could a third person send me an encrypted mail without having the private key of the sender?

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 7:

To encrypt a message to send it to you, the S/MIME standard requires the sender 
only to have a copy of your public key.  Some S/MIME clients also require the 
sender to have a copy of a public key for himself.

To decrypt a message that has been sent to you, encrypted with your public key, it is only necessary for you (the recipient) to have your own private key.

Comment 9

[Kai Engert [:KaiE:]]

(In reply to comment #5)
> > You might sit at a computer without your personal cert, but still want 
> > to send something encrypted.
> 
> Well, you're out of luck, because the sender is always implicitly a recipient 
> of encrypted emails he sends.

Sure, but technically the sender is not a mandatory recipient, it should work fine to send without encrypting to self.

But I agree. I forgot we are strict. But I'd like that we change that eventually.


> Therefore, the sender must have at least an 
> encryption cert of his own to send encrypted emails.

By current application policy, yes.
Technically, no.



Sorry that I started to talk about encryption, I was inspired to so by some comments.

I think, when we talk about sender identity, we should simply not talk about encryption at all (in order to avoid confusion).

Comment 10

[Kai Engert [:KaiE:]]

My proposal is to reword the information as in comment 3.

Thoughts?

Comment 11

[Martin Sch]

#3 is fine...

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

comment 3 works for me.

I suggest: make a patch and request UI review

Comment 13

[Bryan Clark (DevTools PM) [:clarkbw]]

Sorry to have to ask for this, but could someone attach a screenshot of this dialog?

It's hard to get a handle on this message without seeing the context and I don't have this kind of mail to play with.  

I'm still looking around if there is a guideline for messages like this, but here's my gut instinct for a short message.  ( Very short sentence to let people know what the dialog is indicating, then provide the text of what that indication means afterward. )

How far off is this example?
This message was sent _encrypted_ but _unsigned_
There is no guarantee that this message came from the sender identified or was delivered without being tampered with.

Comment 14

[Martin Sch]

Attachment: Message window

This is the screen shot of the message.

Comment 15

[Bryan Clark (DevTools PM) [:clarkbw]]

I think the key to this change is going to be displaying encryption / keys differently in the message view.  see bug 449691 for new message reader concepts.  

Instead of a dialog we should be showing this kind of information inline in mostly text form instead of icons.
{{
 Regular Message Header
 This message is encrypted
 This message was _not_ signed
}}
{{ Message Body }}

Comment 16

[Ronald Killmer]

An update of Bug links. There is a Tracker bug for all Tb 3.0 Message Reader Pane enhancements. https://bugzilla.mozilla.org/show_bug.cgi?id=456814

I am adding this bug to the tracker.

Comment 17

[Wayne Mery (:wsmwk)]

This issue should be tested in the 115 environment becaues the message reader is being largely rebuilt for version 115. 115 becomes available in July. Testing beta 3-4 weeks from now is possible.

Note also this bug blocks meta Bug 456814 which is being closed.