A few of you noticed that I had a stub for the security considerations
in the ESS draft. Below is what I think we might want to put in.
Additions, deletions, and rewording is welcome.
-=-=-=-=-=-=
All security considerations from [CMS] and [SMIME3] apply to applications
that use procedures described in this document.
As stated in Section 2.3, a recipient of a receipt request must not send
back a reply if it cannot validate the signature. Similarly, if there
conflicting receipt requests in a message, the recipient must not send back
receipts, since an attacker may have inserted the conflicting request.
Sending a signed receipt to an unvalidated sender can expose information
about the recipient that it may not want to expose to unknown senders.
Senders of receipts should consider encrypting the receipts to prevent a
passive attacker from gleaning information in the receipts.
Senders must not rely on recipients' processing software to correctly
process security labels. That is, the sender cannot assume that adding a
security label to a message will prevent recipients from viewing messages
the sender doesn't want them to view. It is expected that there will be
many S/MIME clients that will not understand security labels but will still
display a labelled message to a recipient.
A receiving agent that processes security labels must handle the content of
the messages carefully. If the agent decides not to show the message to the
intended recipient after processing the security label, the agent must take
care that the recipient does not accidentally see the content at a later
time. For example, if an error response sent to the originator contains the
content that was hidden from the recipient, and that error response bounces
back to the sender due to addressing errors, the original recipient can
possibly see the content since it is unlikely that the bounce message will
have the proper security labels.
A man-in-the-middle attack can cause a recipient to send receipts to an
attacker if that attacker has a signature that can be validated by the
recipient. The attack consists of intercepting the original message and
adding a mLData attribute that says that a receipt should be sent to the
attacker in addition to whoever else was going to get the receipt.
Mailing lists that encrypt their content may be targets for
denial-of-service attacks if they do not use the mailing list management
described in Section 4. Using simple RFC822 header spoofing, it is quite
easy to subscribe one encrypted mailing list to another, thereby setting up
an infinite loop.
Mailing List Agents need to be aware that they can be used as oracles for
the the adaptive chosen ciphertext attack described in [CMS]. MLAs should
notify an administrator if a large number of undecryptable messages are
received.
When verifying a signature using certificates that come with a [CMS]
message, the recipient should only verify using certificates previously
known to be valid, or certificates that have come from a signed
SigningCertificate attribute. Otherwise, the attacks described in Section 5
can cause the receiver to possibly think a signature is valid when it is
not.
--Paul Hoffman, Director
--Internet Mail Consortium