Internet Engineering Task Force (IETF) S. Moonesamy Internet Draft March 23, 2010 Intended status: Informational Expires: September 22, 2010 Security Consideration Issues for Internet Mail draft-moonesamy-mail-security-00.txt Abstract This memo discusses about security consideration issues for Internet Mail. It should not be considered as a replacement for RFC 3552 or Security Consideration Sections in mail standards. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 22, 2010 Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must S. Moonesamy Expires September 2010 [Page 1] Internet Draft Security Considerations for Mail March 5, 2010 include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. S. Moonesamy Expires September 2010 [Page 2] Internet Draft Security Considerations for Mail March 5, 2010 1. Introduction During a discussion about security considerations [RFC3552] for Internet Mail, the use of Internet Mail to facilitate the distribution of hostile content was raised as an issue. It is important to distinguish between transmission and content. The Simple Mail Transfer Protocol [RFC5321] is used for transmission. The Internet Message Format [RFC5322] is used for the content. Both the transmission and the content are restricted to US-ASCII [RFC20]. There is a risk that combinations of US-ASCII control characters could be used to affect the operation of message viewers. In the current mail environment, the number of such "attacks" is low compared to the amount of hostile content that requires the delivery of 8-bit content to the message viewer. Multipurpose Internet Mail Extensions [RFC2045][RFC2046], commonly known as MIME, describes the mechanisms for the delivery of 8-bit data. This document discusses about an approach where the focus is on security considerations issues for the 8-bit content instead of the functionality provided by the Simple Mail Transfer Protocol (SMTP) or through SMTP service extensions for data transmission. 1.1. Comments Given the security issues attributed to Internet Mail, comments about this draft should be delivered to the author by postal mail. [RFC Editor: Please remove this subsection] 2. Mail Security Internet Mail is generally not secure. There is no inherent authentication of the sender. This intrinsic property has enabled people to communicate over long distances at a low cost without constraining the sender and receiver to be connected to the Internet at the same time. With the introduction of media types [RFC2046], there are serious security risks as some media types required interpreters or external programs. The execution of any content delivered by Internet Mail is a dangerous operation as the potential for harm is only limited by what the user can do on the computer. It is not obvious to the end-users that they may be allowing an unknown person to take control of their computer. 2.1. Spoofing the Sender It is trivial to "spoof" the sender. The sending address is usually S. Moonesamy Expires September 2010 [Page 3] Internet Draft Security Considerations for Mail March 5, 2010 not a reliable way to identify the author of the message. Even if that information can be authenticated, appropriate care is recommended as blind faith may increase the probability of other attacks. 2.2. Content Disposition Although automatic execution or rendering of content delivered by Internet Mail can be disabled, that doesn't prevent manual execution. As the saying goes, the user is the weakest link. 2.3. Misinterpreting Content Some implementations rely on the file extension to determine the media type. The content can be misinterpreted as being safe as it is incorrectly assumed that the file extension is a reliable way to identify the actual content. 2.4. Social Attacks Social attacks or "social engineering" remains the easiest form of attack. It is only a matter of convincing the user, whether it is through deceit or by providing the right motivation. Filtering out all binary (8-bit) content does not protect the user from all attacks. Curiousity is after all a basic human trait. The user can be led to an external source to acquire the hostile content. 3. Security Considerations This document emphasizes that the payload can be a security issue. That does not mean that the transmission channel is without risk. It is important for implementers to consider what attacks are possible, which ones are out of scope and why they are out of scope. 4. Internationalization Considerations There is a need for people to communicate in their native language. Some of these languages cannot be written in a Roman-derived script. The changes to the mail specifications for full internationalization opens the door to new security issues. Some of the issues such as those relating to sensorial perceptions cannot be addressed at the transport level. 5. IANA Considerations This document does not require the IANA to take any action. S. Moonesamy Expires September 2010 [Page 4] Internet Draft Security Considerations for Mail March 5, 2010 6. Acknowledgements The author would like to thank Dave Crocker, Ned Freed and John Klensin for providing a better perspective of the mail standards and Stephen Kent for the discussion about security issues. 7. References 7.1. Normative References [RFC20] Cert, V., "ASCII format for Network Interchange", RFC 20, October 1969. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, July 2003. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. Author's Address S. Moonesamy 76, Ylang Ylang Avenue Quatre Bornes Mauritius Email: sm+ietf@elandsys.com S. Moonesamy Expires September 2010 [Page 5]