Internet DRAFT - draft-church-dns-mail-sender
draft-church-dns-mail-sender
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:<user@example.org> 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:<user@example.com>
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]
