Internet DRAFT - draft-otis-smtp-name-path
draft-otis-smtp-name-path
individual D. Otis
Internet-Draft Trend Micro, NSSG
Expires: October 16, 2006 April 14, 2006
SMTP Name Path Registration
draft-otis-smtp-name-path-00
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 October 16, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a safe means to register delivery paths used
by a domain's messages. Message handling might be negatively
affected without an apparent relationship between the sending system
and the various email related source domains contain within either
the message envelope or the message itself. Name based associations
can be achieved within a single DNS transaction. The alternative has
been to assemble a list of IP addresses for all systems employed to
send messages for a domain. The IP address list approach may require
hundreds of DNS transactions that endanger the network. The safer
Otis Expires October 16, 2006 [Page 1]
Internet-Draft Name Path April 2006
name based method accommodates an unlimited number of sending
systems, without the overhead and size issues created by a list of IP
addresses.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Name Path Registration . . . . . . . . . . . . . . . . . . . . 3
4. Implementation Examples . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7.1. Normative References . . . . . . . . . . . . . . . . . . . 7
7.2. Informative References . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 9
Otis Expires October 16, 2006 [Page 2]
Internet-Draft Name Path April 2006
1. Introduction
Two experimental drafts [I-D.schlitt-spf-classic] and [I-D.lyon-
senderid-core] endanger networks by permitting a sizeable exploit
devoid of a defensive strategy. See [I-D.otis-spf-dos-exploit]. A
safe SMTP name path registration alternative to the SPF script method
requires one or two steps. The first step verifies the EHLO of the
MTA with a single DNS transaction; see [I-D.crocker-csv-csa]. Once
the EHLO is verified, and when the EHLO is within the domain-name in
question, no second step is needed. Otherwise, the second step
attempts to establish a domain-name association by making a forward
reference PTR RRset lookup from the domain in question.
These PTR RRsets would simply list the parent domain of the providers
used by the owner of the email-address domain. A dummy domain of
"*." would be used to indicate the list represents an open-ended set.
An RRset list that only includes a "." label indicates the path list
is complete or "closed-ended" and no other domain is associated with
the domain. A failure to verify the EHLO or to find an association
with the message domain-names may also delay acceptance of the
message. The EHLO verification does not create any amplification
effects, is comparatively easier to administer, and provides an
identifier useful for DoS related protections prior to committing
additional resources such as establishing a name path.
2. Definitions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Terminology: Terminology conforms to [I-D.crocker-email-arch].
Open-ended: Not all valid elements are included in the set.
Close-ended: All valid elements are included in the set.
3. Name Path Registration
Although many view path registration as a means to reduce spoofing, a
reduction only occurs when the relevant email-address domain owner
expresses closed-ended paths. Closed-ended paths may cause refusal
of messages when the sending system can not be associated with the
message source domain-name. Valid messages may be handled by
mediators that can not be contained within a path registration. This
limitation makes closed-ended paths generally unacceptable, as this
Otis Expires October 16, 2006 [Page 3]
Internet-Draft Name Path April 2006
reduces the integrity of email delivery. The primary value of path
registration is from the special handling afforded in exceptional
cases when no association can be made between a message domain-name
and the sending system. This specialized handling may involve the
application of white-listing, immediate/delayed acceptance, or
ensuring the message is fully vetted prior to acceptance.
Part of the effort of restoring trust in email is adding DKIM
[I-D.allman-dkim-base] cryptographic signatures to the messages where
the signature verification process itself must be defended.
Cryptographic techniques represent a moderate consumption of
resources where messages must be fully received before the validity
of a signature can be verified. The added overhead makes a
cryptographic process more vulnerable to Denial of Service attacks.
In addition, any cryptographic scheme is also prone to replay attack.
Defensive schemes MUST be used in conjunction with DKIM and these
schemes MUST identify sources based upon either the readily available
IP address or verified EHLO to be effective without also endangering
the network. Using the IP address may cause collateral blocking when
servers are shared, and can not share a common name-based block-list
of abusers. Fortunately, SMTP offers a solution for the Denial of
Service attack, collateral blocking, the detection of possible
message replay, and sharing name-based block-lists. At the beginning
of an email exchange session, the host-name of the sending system is
provided in the EHLO. EHLO verification MUST become a requisite for
immediate message acceptance, and SHOULD BE associated with the
signing-domain when the message is signed. Verifying the EHLO
permits the same name-based reputations vetting the message sources
to also be used in conjunction with name-based reputations defending
the cryptographic process.
The following is a table of labels that locate the name path
registrations (domain-name lists) for a specific message identity.
The domain-names list is returned by the PTR RRsets and represent
parent domains of MTAs utilized by the domain found in the message
identity. The inclusion of "*." domain indicates an open-ended list
of domain-name associations which might modify the handling of
messages when a domain association is not discovered. When only a
"." domain is returned, this represents a closed-ended list where the
identity domain is the only member.
When there are many domain-names being evaluated within a domain,
there could be an advantage first requesting the "_oa" PTR domain-
name list which might provide an association for other identities.
When no association can be discovered for an identity not defined for
"_oa" list, a request for the list specifically defined for the
identities should be made.
Otis Expires October 16, 2006 [Page 4]
Internet-Draft Name Path April 2006
+----------------------+-----------------------+
| PTR Label | domain-name Reference |
+----------------------+-----------------------+
| _oa._smtp.<domain> | Originating Address |
| _mf._smtp.<domain> | [RFC2821].MailFrom |
| _dkim._smtp.<domain> | DKIM signing-domain |
+----------------------+-----------------------+
+--------------------------------------------------------+
| "_oa" Identities based on RFC2822 header field domains |
+--------------------------------------------------------+
| Resent-Sender: |
| Resent-From: |
| Sender: |
| From: |
+--------------------------------------------------------+
+---------------------+----------------------------+
| Special PTR Domains | Meaning |
+---------------------+----------------------------+
| *. | Part of an open-ended list |
| . | An empty close-ended list |
+---------------------+----------------------------+
4. Implementation Examples
The following is an illustrative example for the following received
message:
EHLO mx-01.example.com
MAIL FROM: <it-dept@example.net>
RCPT TO: <sam@example.org>
DATA
DKIM-Signature: d=example.gov; s=congress;
a=rsa-sha1; c=simple; q=dns;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00...
To: <staff@example.org>
From: <fred@alumni.example.edu>
...
Don't forget the lunch meeting.
.
QUIT
The following EHLO verification and path registration records fully
validate this message:
Otis Expires October 16, 2006 [Page 5]
Internet-Draft Name Path April 2006
_client._smtp.mx-01.example.com. IN SRV 1 2 1 mx-01.example.com.
_oa._smtp.alumni.example.edu. IN PTR *.
_oa._smtp.example.biz. IN PTR .
_mf._smtp.example.net. IN PTR example.com.
_mf._smtp.example.net. IN PTR *.
_dkim._smtp.example.gov. IN PTR example.com.
_dkim._smtp.example.gov. IN PTR example.net.
This example shows the record used to verify the HELO/EHLO, and the
path for message related source domain-names. The path registration
for the "_oa" identity at "alumni.example.edu", which includes the
[RFC2822].From in the example, indicates this to be an open-ended
list. Perhaps no outbound services are provided by the
"alumni.example.edu" domain. The path registration for an "_oa"
identity at "example.biz" indicates an empty list where no other
domain is associated with this domain. The path registration for the
"_mf" identity at "example.net" [RFC2821].MailFrom indicates the use
of "example.com" services and is marked as being a open-ended list.
An open-ended list is indicated by the "*." label which advises that
the information is not comprehensive. This example also shows that
"example.gov" sends signed messages through MTAs that also EHLO
within both the "example.com" and "example.net" domain.
5. IANA Considerations
The label prefixes "_client._smtp.", "_oa._smtp.", "_mf._smtp." and
"_dkim._smtp." referencing the different SMTP name path extension
will require registration by IANA.
6. Security Considerations
This document describes an option that improves upon the safe use of
a path registration mechanism. It is expected that the EHLO verified
name is checked against block-lists of reported abusers. When either
the EHLO can not be verified, or an association with a message domain
can not be established, delayed message acceptance provides another
defensive strategy which allows time for abuse to be reported. Delay
in acceptance can be accomplished with a Transient Negative
Completion, in conjunction with "Requested action aborted: error in
processing" SMTP response; see [RFC2821].
Otis Expires October 16, 2006 [Page 6]
Internet-Draft Name Path April 2006
7. References
7.1. Normative References
[I-D.crocker-csv-csa]
Crocker, D., "Client SMTP Authorization (CSA)",
draft-crocker-csv-csa-00 (work in progress), October 2005.
[I-D.crocker-email-arch]
Crocker, D., "Internet Mail Architecture",
draft-crocker-email-arch-04 (work in progress),
March 2005.
[I-D.otis-spf-dos-exploit]
Otis, D., "SPF DoS Exploitation",
draft-otis-spf-dos-exploit-00 (work in progress),
April 2006.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
April 2001.
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
April 2001.
7.2. Informative References
[I-D.allman-dkim-base]
Allman, E., "DomainKeys Identified Mail (DKIM)",
draft-allman-dkim-base-01 (work in progress),
October 2005.
[I-D.lyon-senderid-core]
Lyon, J. and M. Wong, "Sender ID: Authenticating E-Mail",
draft-lyon-senderid-core-01 (work in progress), May 2005.
[I-D.schlitt-spf-classic]
Schlitt, W. and M. Wong, "Sender Policy Framework (SPF)
for Authorizing Use of Domains in E-MAIL, version 1",
draft-schlitt-spf-classic-02 (work in progress),
June 2005.
Otis Expires October 16, 2006 [Page 7]
Internet-Draft Name Path April 2006
Author's Address
Douglas Otis
Trend Micro, NSSG
1737 North First Street, Suite 680
San Jose, CA 95112
USA
Phone: +1.408.453.6277
Email: doug_otis@trendmicro.com
Otis Expires October 16, 2006 [Page 8]
Internet-Draft Name Path April 2006
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 (2006). 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.
Otis Expires October 16, 2006 [Page 9]
