119384 - [s/mime] warn when using BCC with encryption

Status: RESOLVED FIXED

(MailNews Core :: Security: S/MIME, defect, P2)

Description

[Stephane Saux]

Comment 1

[Stephane Saux]

If the encryption cert for a bcc address was included, the bcc identity could be
inferred from the emails in the cert.

Comment 2

[Kai Engert (:KaiE:)]

My understanding is:
- the smtp sending code opens only a single connection to the server, regardless
how many recipients
- the smtp server cares for delivering to everyone, and removes the bcc line
before sending.

If we wanted to support this feature perfectly, we had to prepare and send out
different enveloped message in multiple steps, right?

If yes, does it make sense to start small, and just warn the user when trying to
combine bcc with s/mime, or just forbid this combination at all?

Comment 3

[Stephane Saux]

I think that not including the encryption certificate for any of the bcc address
is the right thing to do.

The rational for including all the encryption certs, is to allow all recipients
to do a "reply all" on the received message and have all the certs in the
original message to complete the task (as long as the ca chain is trusted.)

Not including the encryption cert for any of the bcc address doesn't in anyway
prevent any of the recipients, not even the bcc recipients (who presumably have
their own cert) to reply to all (the set of non-bcc recipient).

There is no need for a warning.

The only trick part is that we need to be able to identify email addresses that
are only on a bcc line.  Scott, is there any issue with that?

Comment 4

[Kai Engert (:KaiE:)]

I just that the summary is different from what I imagined it would say.

Note that for real privacy, leaving out the encryption certs is not enough.

An smime message is encrypted with a symmetric message encryption key. That
message encryption is encrypted for each recipient. For each recipient, be it a
BCC, CC or TO recipient, there is a separate entry. In order for BCC recipients
being able to read the message, there must be such an entry for them contained
in the message. However, the existence of those entries gives a hint to the real
recipients of the message.

I think we should do all or nothing.

If we decide we really want to hide the information about BCC completely, we
need to be complete and remove the "encrypted decryption keys for each BCC
recipient" from the message. But that in effect means, different versions of the
smime message needs to be sent out. And to make things even more complicated, if
multiple people are on BCC, no single BCC recipient must be able to find out who
else was on the BCC list. In fact that means, if the number of BCC is "nbcc", we
need to produce "nbcc+1" different versions of the smime message, and send out
each one with a separate SMTP transaction.

Comment 5

[Scott MacGregor]

>The only trick part is that we need to be able to identify email addresses that
>are only on a bcc line.  Scott, is there any issue with that?

That should be easy for us to figure out. In
nsMsgComposeSecure::BeginCryptoEncapsulation we pass in a nsIMsgCompFields
object which has methods for accessing the bcc recipients. 

Comment 6

[Stephane Saux]

S/MIME bugs are automatically nsbeta1 candidates. (this is a bulk update - there
may be some adjustment of the list).

Comment 7

[Stephane Saux]

nsbeta1-

Comment 8

[Julien Pierre]

I think this is an important S/MIME issue. I agree with Kai's comment #4, and I 
think we should implement the approach of sending nbcc + 1 S/MIME messages.

Comment 9

[Kai Engert (:KaiE:)]

Bug 119545 also has a requirement to send out multiple different S/Mime messages
for different recipients.

Comment 10

[Kai Engert (:KaiE:)]

I'm changing the topic of this bug.
I'm changing the proposed solution.

In order to make an encrypted message readable for recipients on the BCC list, their keys must be included inside the message header. This can make it obvious that additional recipients were involved. A TO/CC recipient might be able to derive who the BCC recipients are.

Bug 119545 cites rfc2633, which requires that multiple separate emails must be send, when BCC is instended.

In my opinion, we should help the user to clear this confusion, and for the sake of simplicity, we should require users to do it on their own.

In other words, my new proposal is:

Whenever a user has at least one BCC recipient, and at the same time the "encrypt message" feature is in use, and the user attempts the message, 
then:
- don't send the message
- explain to the user that this combination does not make sense
- ask the user to either
  - remove BCC 
  - change BCC into CC
  - don't encrypt


If we wanted to be really smart (but this requires more work, and should therefore be postponed to a separate bug), then we could offer a fourth option:
  - remove BCC, then forward a copy of the message to the BCC people

In other words, this 4th option would:
- remove the BCC people
- send the message (to everyone except BCC)
- copy to sent folder (if configured in options)
- open a new message window, which is intended to forward the original message
- for each formerly removed BCC recipient, add a TO recipient to this message
- keep the new message open

The user could then inspect the message, if desired add additional information (e.g. "For your information, I just sent this message, see the attachment"), and can hit "send" on their own.

Comment 12

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

The user intends to send the message, encrypted, to all the people in To, CC, BCC, in such a way that nobody knows who in the BCC list received the message. Assuming that we have certificates for all the recipients, this is totally possible and we should just do what the user intends. We should only prompt the user to do something different when there is no way to satisfy his expectations (e.g. we are missing at least one encryption certificate.) IIRC, Outlook does this correctly, at least when used with Exchange.

In fact, the unencrypted case has exactly the same issue, because some servers are reported to not strip the BCC header. In other words, the "nbcc+1" solution should be done whenever BCC is used, regardless of whether encryption is present.

Comment 13

[Magnus Melin [:mkmelin]]

For OpenPGP, fixed in bug 1655088.

Comment 14

[Magnus Melin [:mkmelin]]

And then we re-enabled it, with a warning in bug 1671891.
https://hg.mozilla.org/comm-central/rev/dddfa1d24896#l1.194 needs to be changed though - other than that the code works out for s/mime as well.

Comment 15

[Magnus Melin [:mkmelin]]

Attachment: Bug 119384 - [s/mime] warn when using BCC with encryption. r=lasana

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/51a5f55b0318
[s/mime] warn when using BCC with encryption. r=lasana

Comment 17

[Magnus Melin [:mkmelin]]

Comment on attachment 9240260 [details]
Bug 119384 - [s/mime] warn when using BCC with encryption. r=lasana

[Approval Request Comment]
Regression caused by (bug #): not a regression
User impact if declined: won't warn about bcc with s/mime encryption
Testing completed (on c-c, etc.): yes
Risk to taking this patch (and alternatives if risky): low risk

Comment 18

[Wayne Mery (:wsmwk)]

Comment on attachment 9240260 [details]
Bug 119384 - [s/mime] warn when using BCC with encryption. r=lasana

[Triage Comment]
Approved for beta

Comment 19

[Rob Lemley [:rjl]]

Thunderbird 93.0b4:
https://hg.mozilla.org/releases/comm-beta/rev/68135bbe7008

Comment 20

[Wayne Mery (:wsmwk)]

Comment on attachment 9240260 [details]
Bug 119384 - [s/mime] warn when using BCC with encryption. r=lasana

[Triage Comment]
Approved for esr91

Comment 21

[Rob Lemley [:rjl]]

Thunderbird 91.1.2:
https://hg.mozilla.org/releases/comm-esr91/rev/0fbfed4c294e