Forbid the combination of BCC with encryption (rfc2633).

NEW
Unassigned

Status

MailNews Core
Security: S/MIME
P2
normal
16 years ago
2 years ago

People

(Reporter: Stephane Saux, Unassigned)

Tracking

(Blocks: 1 bug)

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [kerh-coz][psm-smime])

(Reporter)

Description

16 years ago
 
(Reporter)

Comment 1

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

Priority: -- → P2
Target Milestone: --- → 2.2

Comment 2

16 years ago
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?
(Reporter)

Comment 3

16 years ago
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

16 years ago
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

16 years ago
>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. 

Updated

16 years ago
Blocks: 74157

Updated

16 years ago
OS: Windows 2000 → All
Hardware: PC → All
(Reporter)

Comment 6

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

Updated

16 years ago
Keywords: nsbeta1+
(Reporter)

Comment 7

16 years ago
nsbeta1-
Keywords: nsbeta1, nsbeta1+ → nsbeta1-

Updated

16 years ago
QA Contact: alam → carosendahl

Comment 8

16 years ago
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.
(Reporter)

Updated

16 years ago
Target Milestone: 2.2 → Future

Comment 9

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

Updated

16 years ago
Keywords: nsbeta1

Updated

16 years ago
Keywords: nsbeta1-

Updated

13 years ago
Component: Security: S/MIME → Security: S/MIME
Product: PSM → Core

Updated

12 years ago
Whiteboard: [kerh-coz]
Target Milestone: Future → ---
QA Contact: carosendahl → s.mime

Updated

10 years ago
Version: psm2.2 → 1.0 Branch

Updated

10 years ago
Summary: Encryped/and or signed emails should not include bcc recipients encryption certs. → Encrypted/and or signed emails should not include bcc recipients encryption certs.
Version: 1.0 Branch → Trunk

Updated

9 years ago
Component: Security: S/MIME → Security: S/MIME
Product: Core → MailNews Core

Updated

8 years ago
Assignee: kaie → nobody
Whiteboard: [kerh-coz] → [kerh-coz][psm-smime]

Comment 10

7 years ago
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.
Summary: Encrypted/and or signed emails should not include bcc recipients encryption certs. → Forbid the combination of BCC with encryption (rfc2633).

Updated

7 years ago
Duplicate of this bug: 119545
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.
You need to log in before you can comment on or make changes to this bug.