DKIM T. Finch Internet-Draft University of Cambridge Expires: February 24, 2006 August 23, 2005 Threats to email addressed by DomainKeys Identified Mail (DKIM) draft-fanf-dkim-rationale Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 February 24, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract XXX Document revision $Cambridge: hermes/doc/antiforgery/draft-fanf-dkim-rationale.xml,v 1.2 2005/08/23 19:16:44 fanf2 Exp $ Finch Expires February 24, 2006 [Page 1] Internet-Draft DKIM Rationale August 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Identitifying an accountable entity . . . . . . . . . . . . . . 3 2.1. Using IP addresses for accountability . . . . . . . . . . . 3 2.2. Using domain names for accountability . . . . . . . . . . . 3 3. Using cryptography to provide stronger identification . . . . . 3 3.1. Vulnerabilities of email signatures . . . . . . . . . . . . 4 3.2. Network attacks . . . . . . . . . . . . . . . . . . . . . . 4 4. Survey of email identities . . . . . . . . . . . . . . . . . . 4 4.1. Hostname (RFC 2821 EHLO) . . . . . . . . . . . . . . . . . 4 4.2. Return path (RFC 2821 MAIL FROM) . . . . . . . . . . . . . 4 4.3. Sender (RFC 2822 Sender:) . . . . . . . . . . . . . . . . . 4 4.4. Author(s) (RFC 2822 From:) . . . . . . . . . . . . . . . . 5 4.5. Re-sender(s) (RFC 2822 Resent-Sender: and Resent-From:) . . 5 5. The Signer identity . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Relationship with standard identities . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative references . . . . . . . . . . . . . . . . . . . 5 7.2. Informative references . . . . . . . . . . . . . . . . . . 6 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . . 6 Appendix B. Contributors . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Finch Expires February 24, 2006 [Page 2] Internet-Draft DKIM Rationale August 2005 1. Introduction XXX [DKIM] 2. Identitifying an accountable entity an accountable entity is someone who is willing to accept the consequences of emitting email that the recipients don't like e.g. blacklisting, filtering email has many identities, but they are all fairly weak; the IP addresses currently strongest 2.1. Using IP addresses for accountability volatile addresses, shared addresses mismatch between message route and origin 2.2. Using domain names for accountability more information available as a basis for reputation simpler black/white list management some success already with domains from URLs used by spammers/phishers 3. Using cryptography to provide stronger identification Use of signatures as a tool to provide a strong identity; other applications of crypto sigs are irrelevant or incidental (non- repudiation, message integrity, etc.) o problems with existing solutions o why we want to stuff the signature in the message header o and use the DNS for key distribution o see Finch Expires February 24, 2006 [Page 3] Internet-Draft DKIM Rationale August 2005 3.1. Vulnerabilities of email signatures public archives expose sigs to offline attack; message modification in transit - however usually done by good guys not bad guys! (mailing lists) how to make signature robust against reasonable modifications and resistant to attack? contradictory requirements 3.2. Network attacks signature added to message after submission; low-level network attacks most likely during submission out-of-scope for DKIM - see [RFC2476] [RFC2554] [RFC3207]. 4. Survey of email identities how they might be strengthened and/or why they are difficult to use as they are Identity names are clarified by reference to the relevant commands described in [RFC2821] or header fields described in [RFC2822]. 4.1. Hostname (RFC 2821 EHLO) routinely misconfigured or a total lie out-of-scope for DKIM - see e.g. [CSA]. 4.2. Return path (RFC 2821 MAIL FROM) original message data often not present in bounce messages so a signature in the message can't be used to secure this -> security tag in the address itself out-of-scope for DKIM - see e.g. [BATV]. 4.3. Sender (RFC 2822 Sender:) often not displayed to recipients so strengthening it may not be all that useful problems with the way it is currently used e.g. mailing lists problems related to authors also apply to sender (except for multiple authorship) Finch Expires February 24, 2006 [Page 4] Internet-Draft DKIM Rationale August 2005 4.4. Author(s) (RFC 2822 From:) roaming users should still be supported e.g. where the accountable identity is the ISP that runs the smart host not domain of author(s) multiple authorship is awkward to handle especially because of the preceding 4.5. Re-sender(s) (RFC 2822 Resent-Sender: and Resent-From:) not widely used; invisible if re-sending is actually forwarding; [RFC0822] / [RFC2822] incompatibility 5. The Signer identity we can work with simpler semantics by introducing a new identity (though DKIM provides some complexity here with d=/s=/i=) may multiple signers occur if message is re-sent? separately accountable, separate times and places unlike authorship which is joint 5.1. Relationship with standard identities tied to traditional identities with SSP 6. Security Considerations This entire document discusses security weaknesses in Internet email and how they might be mitigated. 7. References 7.1. Normative references [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [DKIM] Allman, E., Callas, J., Delaney, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM)", draft-allman-dkim-base-00 (work in progress), July 2005. Finch Expires February 24, 2006 [Page 5] Internet-Draft DKIM Rationale August 2005 7.2. Informative references [RFC0822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [RFC2476] Gellens, R. and J. Klensin, "Message Submission", RFC 2476, December 1998. [RFC2554] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. [BATV] Levine, J., Crocker, D., Silberman, S., and T. Finch, "Bounce Address Tag Validation (BATV)", draft-levine-mass-batv-00 (work in progress), September 2004. [CSA] Otis, D., Crocker, D., and J. Leslie, "Client SMTP Authorization (CSA)", draft-ietf-marid-csv-csa-02 (work in progress), February 2005. Appendix A. IANA Considerations This document specifies no actions for IANA Appendix B. Contributors Michael Thomas provided a list of deployment problems with existing cryptographic email security protocols and how these are addressed by DKIM. <4300FC01.80406@mtcc.com> Ned Freed pointed out the distinction between the use of cryptographic signatures as a tool and as a higher-level service. <01LS5XOD9DPU000092@mauve.mrochek.com> Finch Expires February 24, 2006 [Page 6] Internet-Draft DKIM Rationale August 2005 Author's Address Tony Finch University of Cambridge Computing Service New Museums Site Pembroke Street Cambridge CB2 3QH ENGLAND Phone: +44 797 040 1426 Email: dot@dotat.at URI: http://dotat.at/ Finch Expires February 24, 2006 [Page 7] Internet-Draft DKIM Rationale August 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Finch Expires February 24, 2006 [Page 8]