INTERNET-DRAFT A. Church Expires: February 2, 2003 August 2, 2002 Authoritative Mail Sender DNS Resource Record draft-church-dns-mail-sender-02.txt Status of this Memo This document is an Internet Draft and is subject to all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract This document defines a new experimental DNS resource record type, Authoritative Mail Sender (MS), which can be used to verify the authenticity of the domain name provided in the sender address of a mail message and help to prevent forgery of sender addresses. 1. Introduction / Motivation Forged headers have long been a problem with E-mail, as they can allow a malicious user to effectively hide their identity; in addition to simple forgery, senders of unsolicited bulk E-mail ("spam") often take advantage of this method to foil attempts at either blocking their messages or complaining about their mail to them or their service providers. To counter this problem, this document defines a new DNS resource record type, Authoritative Mail Sender, which allows a domain to define hosts which are authorized to send mail for users in that domain, and can be used by a receiving MTA to confirm that the domain in the sender's mailbox address given Church Expires February 2, 2003 [Page 1] Internet-Draft Mail Sender RR for DNS August 2002 in an E-mail message is in fact valid. 2. The MS Resource Record The Authoritative Mail Sender RR has mnemonic MS and RR type value ???(*). The RDATA for an MS RR consists of a string of octets to be used in authenticating a sending MTA (see section 3 for details). MS records cause no additional section processing; there must be only one MS record associated with a particular domain name. (*) A number needs to be assigned by the IANA. 3. Use of the MS RR 3.1. Direct sending (no relays) The MS RR can be used by MTAs to establish whether the sending MTA of a particular message is authorized to send messages for the domain given in the message's sender's mailbox address. A transaction would typically proceed as follows; in this example, we assume that the mailbox provided as the sender address is "user@example.org": Sending MTA connects to receiving MTA Sending MTA sends message from "user@example.org" Receiving MTA queries DNS for MS records for "example.org" If no DNS data is available for the domain: Receiving MTA refuses message(*) Else if no MS records are available: Receiving MTA delivers message Else: Receiving MTA issues cryptographic challenge based on DNS data (see section 3.2) Sending MTA responds to challenge If the response is appropriate: Receiving MTA delivers message Else: Receiving MTA refuses message (*) This should not be a permanent refusal, but rather a "try again later", if DNS data is not available because of a timeout (as opposed to nonexistence of the domain). 3.2. The cryptographic challenge Authenticity is determined by the receiving MTA sending a cryptographic challenge to the sending MTA based on the data in the MS record. For example, if a public-key system is used, the MS record might contain the public key to be used in a challenge. In this case, the receiving MTA would issue a randomly generated string Church Expires February 2, 2003 [Page 2] Internet-Draft Mail Sender RR for DNS August 2002 as the challenge, which the sending MTA would encrypt with its private key; the receiving MTA would then decrypt the encrypted string with the public key from the MS record and compare the result to the original challenge. The authentication would be successful if the strings matched. 3.3. Relays on the receiving end In many large private networks, such as corporate internal networks, multiple levels of MTAs are used, with a firewall MTA receiving mail from outside the internal network and forwarding it to another MTA which handles the actual delivery of the mail. In such a case, use of the algorithm described in section 3.1 as is will cause all external mail to be rejected if internal hosts have access to DNS data. Thus, a receiving MTA may define a set of trusted sending MTAs from which it will accept mail from any sender (or from any sender outside a particular domain or set of domains). 3.4. Relays on the sending end In cases such as that described above, as well as (for example) service providers which provide SMTP relays for their customers, the original sending MTA may not be the same one as the one which makes the delivery to the remote MTA. However, as long as the relay MTA can properly respond to an MS challenge for the domain, the sender address will be accepted. (If the relay MTA handles multiple domains, it will need to check the sender address to determine the proper MS respnse.) 3.5. Implementation notes for SMTP The term "sender address" refers to the SMTP envelope address, i.e. the address provided in the MAIL command and typically seen in the Return-Path message header. This mechanism could be implemented using an ESMTP parameter to the MAIL command, for example MS. In this case, a session might proceed as follows (S: lines are sent by the sending MTA, R: lines by the receiving MTA): ... S: MAIL FROM: MS R: 399 YWJjZGU= S: dnd4eXo= R: 250 OK [or] 599 Bad MS response ... The presence of the MS parameter indicates that the sending MTA is prepared to respond to an MS challenge. The receiving MTA sends this challenge as a base64-encoded string using a continuation reply code (399 in this example). The sending MTA then computes an appropriate Church Expires February 2, 2003 [Page 3] Internet-Draft Mail Sender RR for DNS August 2002 response for the given challenge and envelope sender domain, and sends this again as a base64-encoded string. Finally, the receiving MTA checks whether the response is valid for the domain and issues either a standard "OK" reply or an error reply (599 in this example) indicating that the response is invalid. If the sending MTA did not support MS, but the domain had an MS RR associated with it, the session might proceed as follows: ... S: MAIL FROM: R: 598 MS required ... The receiving MTA issues an error reply to the MAIL command (598 in this example) indicating that the sender must respond to an MS challenge to be permitted to use the given sender address. It has been suggested that the AUTH command [2] is appropriate for this purpose; however, AUTH operates on a session basis, rather than a per-message basis, and authentication must be complete before the MAIL command is issued. The mechanism defined in this document requires knowledge of the hostname in the sender address, and thus cannot be used with AUTH. 4. Security Considerations Although not a problem specific to MS records, an attacker could potentially exploit the transaction sequence given in section 3.1 to cause a denial of service on the receiving MTA, by providing as the sender's domain a domain whose DNS the attacker controls, and deliberately delaying or refusing replies to MS queries. For this reason, receiving MTAs should place a reasonable timeout on queries for MS records. The MS data is only as trustworthy as the server which serves it; misconfigured or insecurely configured servers may be susceptible to injection of false data by attackers. Therefore, receiving MTAs should not rely on the presence of an MS record alone as affirmative proof of authenticity, unless the accuracy of the DNS data itself can be separately verified (e.g. via DNSSEC [3]). Any cryptographic authentication mechanism is only as secure as the secret(s) used with it. Proper care should be taken to protect the secrets used in constructing an MS challenge and response from being obtained by unauthorized parties. Since weak cryptographic mechanisms may be subject to brute-force attacks, an appropriately strong mechanism should be used for authentication. MTAs should also provide warning to administrators Church Expires February 2, 2003 [Page 4] Internet-Draft Mail Sender RR for DNS August 2002 if multiple invalid attempts at using a given sender address are detected. 5. Issues to be considered Is it appropriate to define or suggest a particular cryptographic algorithm in this document? (My inclination would be no, since anything one could possibly suggest would soon be out of date as the state of the art advances.) Is the description in section 3.2 accurate and sufficient? Are there any other pointers that should be given in this document with respect to cryptographic issues? Is it possible, feasible, or desirable to check message headers, such as the From header, as well as or in place of the envelope sender? Ordinary users typically do not know what the Return-Path header is for (if they even know it exists), and consider the contents of the From header to be the "authoritative" message sender. However, attempting to control the From header may have undesirable side effects, such as inability to preserve the original sender when forwarding mail or sending through a mailing list. References [1] Mockapetris, P., "Domain Names - Implementation and Specification", RFC 1035, November 1987. [2] Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [3] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. Author's Address Andrew Church Primabera Isejuku #315 10-1 Isejuku, Ichikawa-shi Chiba 272-0106, Japan E-mail: achurch@achurch.org Change History Version 02: Redefined MS record to contain cryptographic authentication data rather than host names, and modified algorithm to use authentication rather than source host address checking. Added "notes on SMTP implementation" and "issues to be considered" sections. Church Expires February 2, 2003 [Page 5] Internet-Draft Mail Sender RR for DNS August 2002 Version 01: Expanded section 3 to cover cases where relay MTAs are used, at the suggestion of Eric Hall, and clarify behavior when no MS records are present. Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Church Expires February 2, 2003 [Page 6]