ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity
Files
3ad4e307b64bcf8baa984e10a4e7549dbeaea31d
bind9/doc/draft/draft-danisch-dns-rr-smtp-02.txt
Mark Andrews be063aae54 new draft
2003-06-05 01:48:37 +00:00

1345 lines
54 KiB
Plaintext
Raw Blame History

This file contains invisible Unicode characters
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
INTERNET-DRAFT Hadmut Danisch
Category: Experimental Jun 2003
Expires: Dec 1, 2003
A DNS RR for simple SMTP sender authentication
draft-danisch-dns-rr-smtp-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 memo suggests a new DNS RR type to provide a very simple
light-weight authentication scheme for the domain part of the
sender address for SMTP mail transport. It is designed to be a
simple and robust protection against e-mail fraud and especially
spam. It is easy to implement and administer, compatible with all
legislations known by the author, and cheap. It also focuses on
security and privacy problems and requirements in context of spam
defense, and touches non-technical problems of defense against
spam.
Hadmut Danisch Experimental [Page 1]
INTERNET-DRAFT DNS RMX RR Jun 2003
Table of Contents
1. Threat description . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Mail sender forgery . . . . . . . . . . . . . . . . . . . 4
1.2. Spam . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Problem analysis . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Shortcomings of strong authentication mechanisms . . . . . . . . 4
4. DNS based sender address verification . . . . . . . . . . . . . 5
5. RMX entry types . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1. Overall structure . . . . . . . . . . . . . . . . . . . . 5
5.1.1 Description . . . . . . . . . . . . . . . . . . . . 6
5.1.2 Zone File Syntax . . . . . . . . . . . . . . . . . 6
5.1.3 Encoding . . . . . . . . . . . . . . . . . . . . . 6
5.2. IPv4 and IPv6 address ranges (Type1/2) . . . . . . . . . . 7
5.2.1 Description . . . . . . . . . . . . . . . . . . . . 7
5.2.2 Zone File Syntax . . . . . . . . . . . . . . . . . 7
5.2.3 Encoding . . . . . . . . . . . . . . . . . . . . . 7
5.3. Hostname (Type 3) . . . . . . . . . . . . . . . . . . . . 7
5.3.1 Description . . . . . . . . . . . . . . . . . . . . 7
5.3.2 Zone File Syntax . . . . . . . . . . . . . . . . . 8
5.3.3 Encoding . . . . . . . . . . . . . . . . . . . . . 8
5.3.4 Additional Records . . . . . . . . . . . . . . . . 8
5.4. APL Reference (Type 4) . . . . . . . . . . . . . . . . . . 8
5.4.1 Description . . . . . . . . . . . . . . . . . . . . 8
5.4.2 Zone File Syntax . . . . . . . . . . . . . . . . . 8
5.4.3 Encoding . . . . . . . . . . . . . . . . . . . . . 9
5.4.4 Additional Records . . . . . . . . . . . . . . . . 9
5.5. Future Entry Types . . . . . . . . . . . . . . . . . . . . 9
6. Message Headers . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Compatibility with old mail receivers . . . . . . . . . . 10
7.2. Compatibility with old mail senders . . . . . . . . . . . 10
7.3. Compatibility with old DNS clients . . . . . . . . . . . . 10
7.4. Compatibility with old DNS servers . . . . . . . . . . . . 10
8. Message relaying and forwarding . . . . . . . . . . . . . . . . 10
8.1. Problem description . . . . . . . . . . . . . . . . . . . 10
8.2. Trusted relaying/forwarding . . . . . . . . . . . . . . . 11
8.3. Untrusted relaying/forwarding . . . . . . . . . . . . . . 11
9. Enforcement policy . . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . . 12
10.1. Draft specific considerations . . . . . . . . . . . . . . 12
10.1.1 Authentication strength . . . . . . . . . . . . . 12
10.1.2 Where Authentication and Authorization end . . . . 13
10.1.3 Vulnerability of DNS . . . . . . . . . . . . . . . 13
10.1.4 Additional data attack? . . . . . . . . . . . . . 15
10.1.5 Open SMTP relays . . . . . . . . . . . . . . . . . 15
10.1.6 Unforged Spam . . . . . . . . . . . . . . . . . . 16
Hadmut Danisch Experimental [Page 2]
INTERNET-DRAFT DNS RMX RR Jun 2003
10.1.7 Empty Sender address . . . . . . . . . . . . . . . 16
10.1.8 Reliability of Whois Entries . . . . . . . . . . . 16
10.1.9 Hazards for Freedom of Speech . . . . . . . . . . 17
10.2. General Considerations about spam defense . . . . . . . . 17
10.2.1 Action vs. reaction . . . . . . . . . . . . . . . 18
10.2.2 Content based Denial of Service attacks . . . . . 18
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . . 18
11.1. Draft specific considerations . . . . . . . . . . . . . . 18
11.1.1 No content leaking . . . . . . . . . . . . . . . . 19
11.1.2 Message reception and sender domain . . . . . . . 19
11.1.3 Network structure . . . . . . . . . . . . . . . . 19
11.1.4 Owner information distribution . . . . . . . . . . 19
11.2. General Considerations about spam defense . . . . . . . . 20
11.2.1 Content leaking of content filters . . . . . . . . 20
11.2.2 Black- and Whitelists . . . . . . . . . . . . . . 20
12. Deployment Considerations . . . . . . . . . . . . . . . . . . . 20
12.1. The economical problem . . . . . . . . . . . . . . . . . 21
12.2. The POP problem . . . . . . . . . . . . . . . . . . . . . 21
12.3. The network structure problem . . . . . . . . . . . . . . 22
12.4. The mentality problem . . . . . . . . . . . . . . . . . . 22
12.5. The identity problem . . . . . . . . . . . . . . . . . . 23
12.6. The multi-legislation problem . . . . . . . . . . . . . . 23
Implementation and further Information . . . . . . . . . . . . . . . 23
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Hadmut Danisch Experimental [Page 3]
INTERNET-DRAFT DNS RMX RR Jun 2003
1. Threat description
1.1. Mail sender forgery
Security surveillances found a significant increase in the number
of e-mails with forged sender addresses. As a consequence, damage
caused by such e-mails increased as well. In the majority of
examined e-mails the domain name of the envelope sender address was
forged, and the e-mail was sent from an IP address which does not
belong to a network used by the actual owner of the domain.
1.2. Spam
A common and well known problem is the dramatic increase of
unsolicited e-mail, commonly called "spam". Again, the majority of
examined e-mails had forged sender addresses. The abused domains
were mainly those of common webmailers as hotmail or yahoo, or
well-known companies.
2. Problem analysis
The real cause for forged e-mail is the lack of the Simple Mail
Transfer Protocol SMTP[1] to provide any kind of sender
authentication, authorisation, or verification. Efforts have been
made to block such e-mails by requiring the sender address domain
part to be resolvable (e.g. latest sendmail configurations). This
method provides protection from e-mails with non-existing sender
domains, and indeed, for some time it blocked most spam e-mails.
However, since attackers and spam senders began to abuse existing
domain names, this method was rendered ineffective.
3. Shortcomings of strong authentication mechanisms
Without any doubt, SMTP needs to be improved and reengineered in
the future in order to resist against these kinds of threat.
Cryptographical or organisational security mechanisms have to be
designed an implemented for some sort of SMTPng.
Unfortunately, it is impossible to seamlessly switch to a new
protocol, since most of the SMTP servers and client programs can't
be replaced or updated easily and quickly. Any kind of security
mechanism has to be simple and backward compatible in order to be
accepted. That's why extensions like SMTP with TLS are not widely
spread.
Hadmut Danisch Experimental [Page 4]
INTERNET-DRAFT DNS RMX RR Jun 2003
4. DNS based sender address verification
To gain at least some improvement in e-mail authenticity while
keeping as much SMTP compatibility as possible, a method is
suggested which doesn't change SMTP at all.
When the sender has issued the "MAIL FROM:" SMTP command, the
receiving mail transfer agent (MTA) can - and modern MTAs do -
perform some authorization checks, e.g. run a local rule database
or check whether the sender domain is resolvable.
The suggested method is to let the DNS server for the sender domain
provide informations about which IP addresses are authorized to use
the domain within a sender's address. After receiving the "MAIL
FROM:" SMTP command, the receiving MTA can verify, whether the IP
address of the sending MTA is authorized to send mails with this
domain name. Therefore, a list of authorized IP addresses is
provided by the authoritative DNS server of that domain.
This version of the draft defines three distinct methods to
describe IP address authorizations:
- An IPv4 or IPv6 network address and mask
- A fully qualified domain name referring to an A record
- A fully qualified domain name referring to an APL record
RMX records could look like this:
rmxtest.de. IN RMX host:relay.provider.com
danisch.de. IN RMX apl:relays.rackland.de
relays.rackland.de. IN APL 1:213.133.101.23/32 1:1.2.3.0/24
where the machine with the example address 213.133.101.23 and the
machines in the example subnet 1.2.3.0/24 are the only machines
allowed to send e-mails with an envelope sender address of domain
danisch.de. Since the APL records do not necessarily belong to the
same domain or zone table as the RMX records, this easily allows to
refer to APL records defined by someone else, e.g. the internet
access or server hosting provider, thus reducing administrative
overhead to a minimum. In the example given above, the domain
danisch.de and several other domains are hosted by the service
provider Rackland. So if the relay structure of Rackland is
modified, only the zone of rackland.de needs to be modified. The
domain owners don't need to care about such details.
5. RMX entry types
5.1. Overall structure
Hadmut Danisch Experimental [Page 5]
INTERNET-DRAFT DNS RMX RR Jun 2003
5.1.1. Description
Similar to APL, an RMX record is just a concatenation of zero or
more RMX entries. The entries within one record form an ordered
rule base, i. e. they are processed one ofter another until the
first entry matches. This entry determines the result of the query.
Once a matching entry is found, the RMX processing is finished.
This method is known from many other rule based security
mechanisms.
For any domain name there should not exist more than a single RMX
entry. Due to the structure of DNS, it is nevertheless possible to
have more than a single RMX entry. Multiple RMX entries are treated
as a single record consisting of the concatenation of all records.
While the entries in a record are ordered, the records are not
ordered and may be processed in arbitrary order. If the order of
the entries matters, it is the zone maintainer's responsibility to
keep those entries in a single record.
5.1.2. Zone File Syntax
An RMX record may consist of zero or more entries, where the
entries are separated by whitespace. Each entry consists of a tag,
determining the entry type, a colon, and the entry data.
Example:
danisch.de. IN RMX apl:relays.rackland.de ipv4:1.2.3.0/24
5.1.3. Encoding
Each entry starts with an octet containting the entry type and the
negation flag:
+---+---+---+---+---+---+---+---+
| N | Entry Type Code |
+---+---+---+---+---+---+---+---+
N If this bit (MSB) is set, an IP address
matching this entry is not authorized,
but explicitely rejected. See entry
type descriptions for details.
Entry Type A 7bit number simply determining the entry
type.
Currently, entries do not have an explicit length field, the entry
Hadmut Danisch Experimental [Page 6]
INTERNET-DRAFT DNS RMX RR Jun 2003
length is determined implicitely by the entry type. Applications
are required to abort if an unknown entry type is found, instead of
skipping unknown entries.
5.2. IPv4 and IPv6 address ranges (Type1/2)
5.2.1. Description
These entry types (IPv4 = Type 1, IPv6 = Type 2) contain a bit
sequence representing a CIDR address part. If that bit sequence
matches the given IP address, authorization is granted or denied,
depending on the negation flag.
5.2.2. Zone File Syntax
The entry is prepended with the tag "IPv4" or "IPv6". The colon is
followed with an IPv4 or IPv6 address in standard notation,
optionally followed by a slash and a mask length. Examples:
danisch.de IN RMX ipv4:213.133.101.23 ipv6:fe00::0
IN RMX ipv4:10.0.0.0/8 ipv6:fec0::0/16
IN RMX !ipv4:1.2.3.4
5.2.3. Encoding
After the entry type tag as described above, one octet follows
giving the length L of the bit sequence. Then a sequence of exactly
as many octets follows as needed to carry L bits of information (=
trunc((L+7)/8) ).
+---+---+---+---+---+---+---+---+
| N | Entry Type Code (1 or 2) |
+---+---+---+---+---+---+---+---+
| Length Field L |
+---+---+---+---+---+---+---+---+
| Bit Field |
/ ((L+7)/8) Octets /
+---+---+---+---+---+---+---+---+
5.3. Hostname (Type 3)
5.3.1. Description
This entry type simply contains a regular DNS name, which is to be
resolved as a host name (fetch the A record or IPv6 equivalent). If
the given IP address matches the result, authorization is granted
or denied, depending on the negation flag.
Hadmut Danisch Experimental [Page 7]
INTERNET-DRAFT DNS RMX RR Jun 2003
It is still to be defined how to treat unresolvable entries.
5.3.2. Zone File Syntax
The entry is prepended with the tag "host", followed by a colon and
the hostname. Examples:
danisch.de IN RMX host:relay.provider.de
IN RMX !host:badmachine.domain.de apl:relays.domain.de
5.3.3. Encoding
After the entry type tag immediately follows a DNS encoded and
compressed [2] domain name. Length is determined by called the
decompression function of the resolver library.
+---+---+---+---+---+---+---+---+
| N | Entry Type Code (3) |
+---+---+---+---+---+---+---+---+
| Encoded and Compressed DNS |
/ Name as described in RFC1035 /
+---+---+---+---+---+---+---+---+
5.3.4. Additional Records
In order to avoid the need of a second query to resolve the given
host name, a DNS server should enclose the A record for that domain
name in the additional section of the additional section of the DNS
reply, if the server happens to be authoritative.
5.4. APL Reference (Type 4)
5.4.1. Description
This entry type simply contains a regular DNS name, which is to be
resolved as an APL record index (fetch the APL record). If the
given IP address positively matches the APL, authorization is
granted. Details of the semantic (espially when the negation bit is
set) are still to be defined.
It is still to be defined how to treat unresolvable entries.
5.4.2. Zone File Syntax
The entry is prepended with the tag "host", followed by a colon and
the hostname. Examples:
danisch.de IN RMX apl:relays.rackland.de
Hadmut Danisch Experimental [Page 8]
INTERNET-DRAFT DNS RMX RR Jun 2003
5.4.3. Encoding
After the entry type tag immediately follows a DNS encoded and
compressed domain name. Length is determined by called the
decompression function of the resolver library.
+---+---+---+---+---+---+---+---+
| N | Entry Type Code (4) |
+---+---+---+---+---+---+---+---+
| Encoded and Compressed DNS |
/ Name as described in RFC1035 /
+---+---+---+---+---+---+---+---+
5.4.4. Additional Records
In order to avoid the need of a second query to resolve the given
host name, a DNS server should enclose the APL record for that
domain name in the additional section of the additional section of
the DNS reply, if the server happens to be authoritative.
5.5. Future Entry Types
In future, more entry type might be defined, e.g. data used for
challenge response authentication, a URL or DNS name ponting to
some kind of service for authentication and authorization, entries
pointing to other directory services (e.g. LDAP), or public key
informations to require signatures on the message header or body.
6. Message Headers
An RMX query must be followed by any kind of action depending on
the RMX result. One action might be to reject the message. Another
action might be to add a header line to the message body, thus
allowing MUAs and delivery programs to filter or sort messages.
In future, the RMX result might be melted into the Received: header
line.
The details of such entries are to be discussed. As a proposal the
following form is suggested:
X-RMX: RESULT addr ADDRESS by HOST on DATE
where
RESULT is one of "Granted", "Denied", "NotInRMX", "NoRMX",
"TempFail", "BadData", "Trusted".
Hadmut Danisch Experimental [Page 9]
INTERNET-DRAFT DNS RMX RR Jun 2003
ADDRESS is the IP address where the RMX query was based on.
HOST is the name of the machine performing the RMX query.
DATE is the date of the query.
7. Compatibility
7.1. Compatibility with old mail receivers
Since the suggested extension doesn't change the SMTP protocol at
all, it is fully compatible with old mail receivers. They simply
don't ask for the RMX records and don't perform the check.
7.2. Compatibility with old mail senders
Since the SMTP protocol is unchanged and the SMTP sender is not
involved in the check, the method is fully compatible with old mail
senders.
7.3. Compatibility with old DNS clients
Since the RMX is a new RR, the existing DNS protocol and zone
informations remain completely untouched.
7.4. Compatibility with old DNS servers
If a server can't provide RMX records or a zone doesn't contain
them, the check can't be performed, while compatibility is still
guaranteed.
8. Message relaying and forwarding
8.1. Problem description
Message forwarding and relaying means that an MTA which received an
e-mail by SMTP does not deliver it locally, but resends the message
- usually unchanged except for an additional Received header line
and maybe the recipient's address rewritten - to the next SMTP MTA.
Message forwarding is an essential functionality of e-mail
transport services, for example:
- Message transport from outer MX relay to the intranet
- Message forwarding and Cc-ing by .forward or .procmail-alike
mechanisms
- Mailing list processing
Hadmut Danisch Experimental [Page 10]
INTERNET-DRAFT DNS RMX RR Jun 2003
- Message reception by mail relays with low MX priority,
usually provided by third parties as a stand-by service
in case of relay failure or maintenance
- "Forwarding" and "Bouncing" as a MUA functionality
In all these cases a message is sent by SMTP from a host which is
not covered by the original sender domain's RMX records. While the
RMX records would forbid accepting this message, it still must be
accepted. The following subsections explain how to cope with that
problem.
8.2. Trusted relaying/forwarding
In some cases the receiving MTA trusts the sending MTA to not fake
messages and to already have checked the RMX records at message
reception. As a typical example, a company might have an outer mail
relay which receives messages from the Internet and checks the RMX
records. This relay then forwards the messages to the different
department's mail servers. It does not make sense for these
department mail servers to check the RMX record, since the RMX
records have already been checked and - since the message was
relayed by the outer relay - always would deny the message. In this
case there is a trust relationship between the department relays
and the outer relay. So RMX checking is turned off for trusted
relays. In this example, the department relays would not check
messages from the outer relay (but for intranet security, they
could still check RMX records of the other departments sub-domains
to avoid internal forgery between departments).
When a relay forwards a message to a trusting machine, the envelope
sender address should remain unchanged.
8.3. Untrusted relaying/forwarding
If the receiving MTA does not trust the forwarding MTA, then there
is no chance to leave the sender envelope address unchanged. At a
first glance this might appear impracticable, but this is
absolutely necessary. If an untrusted MTA could claim to have
forwarded a message from a foreign sender address, it could have
forged the message as well. Spammers and forgers would just have to
act as such a relay.
Therefore, it is required that, when performing untrusted
forwarding, the envelope sender address has to be replaced by the
sender address of someone responsible for the relaying mechanism,
e.g. the owner of the mailing list or the mail address of the user
who's .forward caused the transmission. It is important to stress
that untrusted relaying/forwarding means taking over responsibility
Hadmut Danisch Experimental [Page 11]
INTERNET-DRAFT DNS RMX RR Jun 2003
for the message. It is the idea of RMX records to tie
responsibility to message transmission. Untrusted relaying without
replacing the sender address would mean to transmit without taking
responsibility.
The disadvantage is that the original sender address is lost.
Therefore, whenever a sender address replacement happens, the
Received-Line must contain the old address. Many of today's MTAs
already insert the envelope recipient address, but not the sender
address into the Received header line. It seems reasonable to
require every Received line to include both the sender and
recipient address of the incoming SMTP connection.
9. Enforcement policy
Obviously, for reasons of backward compatibility and smooth
introduction of this scheme, RMX records can't be required
immediately. Domains without RMX records must temporarily be
treated the same way as they are treated right now, i.e. e-mail
must be accepted from anywhere. But once the scheme becomes
sufficiently widespread, mail relays can start to refuse e-mails
with sender addresses from domains without RMX records, thus
forcing the owner of the domain to include a statement of
authorization into the domain's zone table. Domain owners will
still be free to have an RMX record with a network and mask
0.0.0.0/0, i.e. to allow e-mails with that domain from everywhere.
On the other hand, mail receivers will be free to refuse mails from
domains without RMX records or RMX records which are too loose.
Advanced MTAs might have a configuration option to set the maximum
number of IP addresses authorized to use a domain. E-mails from a
domain, which's RMX records exceed this limit, would be rejected.
For example, a relay could reject e-mails from domains which
authorize more than 8 IP addresses. That allows to accept e-mails
only from domains with a reasonable security policy.
10. Security Considerations
10.1. Draft specific considerations
10.1.1. Authentication strength
It is important to stress, that the suggested method does not
provide high level security and does not completely block forged e-
mails or spam. It is not a reliable and completely secure security
mechanism. It is to be considered as a very cheap and simple light
weight mechanism, which can nevertheless provide a significant
improvement in mail security against a certain class of attacks,
until a successor of SMTP has been defined and commonly accepted.
Hadmut Danisch Experimental [Page 12]
INTERNET-DRAFT DNS RMX RR Jun 2003
10.1.2. Where Authentication and Authorization end
RMX records do not cover the local part of the e-mail address, i.e.
what's on the left side of the @ sign. Authentication and
authorization are limited to the sending MTA's IP address. The
authentication is limited to the TCP functionality, which is
sufficient for light weight authentication. The RMX records
authorize the IP address of the sending host only, not the
particular sender of the message. So if a machine is authorized to
use sender addresses of more than a single domain, the
authentication scheme does not prevent that any user on this
machine can send with any of these domains. RMX is not a substitute
for the host security of the involved machines.
The proposed authentication scheme can be seen as a "half way
authentication": It does not track back an e-mail to the effective
sender. It tracks only half of the way, i. e. it tracks back to the
domain and it's DNS administrators who authorized that particular
sender IP address to use it for sending e-mail. How the party
responsible for that domain performs user authentication, whom it
grants access to, how it helds people responsible for abuse, is
completely left as the private business of those who are in charge
of that domain. So this draft does not interfere with the domain's
individual security policy or any legislation about such policies.
On the other hand, the proposed authentication scheme does not give
any statement about the nature and quality of the domain's security
policy. This is an essential feature of the proposal: E-mail
authentication must be deployed world wide, otherwise it won't do
the job. Any security scheme interfering with the local
legislations or the domain's security policy will not be accepted
and can't effectively deployed. Therefore, the security policy must
remain the domain's private business, no matter how lousy the
policy might be.
In order to achieve this and to make use of the only existing world
wide Internet directory scheme (DNS), the approach of this proposal
is to just ignore the local part of the sender address (i.e. what's
left of the @ part) and limit view to the domain part. After all,
that's what we do anyway when delivering to a given address with
SMTP.
10.1.3. Vulnerability of DNS
DNS is an essential part of the proposed authentication scheme,
since it requires any directory service, and DNS is currently the
only one available. Unfortunately, DNS is vulnerable and can be
spoofed and poisoned. This flaw is commonly known and weakens many
network services, but for reasons beyond that draft DNS has not
Hadmut Danisch Experimental [Page 13]
INTERNET-DRAFT DNS RMX RR Jun 2003
been significantly improved yet. After the first version of this
draft, I received several comments who asked me not to use DNS
because of its lack of security. I took this into consideration,
but came to the conclusion that this is unfeasible: Any
authentication scheme linked to some kind of symbolic identity (in
this case the domain name) needs some kind of infrastructure and
trusted assignment. There are basically two ways to do it: Do it
yourself and trust nobody else, or let someone else do it. There
are methods to do it the former way, e.g. to give someone some kind
of authentication information after a first successful e-mail
exchange, e.g. some kind of cookie or special e-mail address. This
is certainly interesting and powerful, but it does not solve the
problem on a world wide scale and is far to complicated and error
prone for the average user, i. e. 99% of the users.
The latter method to let someone else do the symbolic name
assignment and create the authentication framework is well known.
It context of public key cryptography, this is called a Public Key
Infrastructure (PKI). On of the best known facts about PKIs is
that, until now, we don't have any covering a significant part of
the Internet. And we won't have any in near future. The complexity
is far too high, it is too expensive, and it involves cooperation
of every single user, which is simply unrealistic and extremely
error prone. So what do we have we can use? All we have is the DNS
and the Whois database. And we have countries who don't allow
cryptography. So the proposal was designed to use DNS without
cryptography. It does not avoid DNS because of its vulnerability,
it asks for a better DNS, but accepts the DNS as it is for the
moment. Currently there are two main threats caused by the DNS
weakness:
- A spammer/forger could spoof DNS in order to gain false
authorization to send fake e-mails.
- An attacker could spoof DNS in order to block delivery from
authorized machines, i. e. perform a Denial of Service attack.
The first one is rather unrealistic, because it would require an
average spammer to poison a significant part of the DNS servers of
its victims. A spammer sending messages to one million receipients
would need to poison at least 1-10% which is 10,000 to 100,000
receipient's DNS servers. This should be unfeasible in most cases.
In contrast, the second threat is a severe one. If an attacker
wanted to block messages from one company to another, he just needs
to poison the recipients DNS server with a wrong RMX record in
order to make the recipient's SMTP machine reject all messages. And
this is feasible since the attacker needs to poison only a single
Hadmut Danisch Experimental [Page 14]
INTERNET-DRAFT DNS RMX RR Jun 2003
DNS server. But does this make SMTP more vulnerable? No. Because
the attacker can already do even more without RMX. By poisoning the
sender's DNS server with wrong MX records, the attacker can also
block message delivery or even redirect the messages to the
attacker's machine, thus preventing any delivery error messages and
furthermore getting access to the messages.
As a consequence, e-mail delivery by SMTP requires a better DNS
anyway. The requirements are not significantly expanded by RMX.
10.1.4. Additional data attack?
While writing a test implementation, a certain kind of attack came
into my mind. I'm still not sure, whether this attack is possible
on any DNS server, but I believe it should be mentioned:
Imagine an unauthorized sender is sending a forged mail (e.g.
spam). At connection time, before querying the RMX record, the
receiving MTA usually performs a PTR query for the IP address of
the sending MTA. If the sender has control over the authoritative
name server for that particular IP address, the sender could give a
normal PTR answer, but could append a wrong RMX, APL, or A record
in the additional section of the query. A subsequent RMX query
could receive wrong DNS data if the DNS server used by the
receiving MTA accepted those forged records.
10.1.5. Open SMTP relays
Open SMTP relays (i.e. machines who accept any e-mail message from
anyone and deliver to the world) abused by spammers are a one of
the main problems of spam defense and sender backtracking. In most
cases this problem just vanishes because foreign open relay
machines will not be covered by the RMX records of the forged
sender address. But there are two special cases:
If the spammer knows about a domain which authorizes this
particular machine, that domain can be used for forgery. But in
this case, the IP address of the relay machine and the RMX records
of the domain track back to the persons responsible. Both can be
demanded to fix the relay or remove the RMX record for this
machine. An open relay is a security flaw like leaving the machine
open for everybody to login and send random mails from inside. Once
the administrative persons refuse to solve the problem, they can be
identified as spammers and held responsible.
The second special case is when a domain authorizes all IP
addresses by having the network 0.0.0.0/0 in the RMX/APL record. In
this case, open relays don't make things worse. It's up to the
Hadmut Danisch Experimental [Page 15]
INTERNET-DRAFT DNS RMX RR Jun 2003
recipient's MTA to reject mails from domains with loose security
policies.
10.1.6. Unforged Spam
This proposal does not prevent spam (which is, by the way, not yet
exactly defined), it prevents forgery. Since spam is against law
and violates the recipients rights, spam depends on untracability
of the sender. In practice the sender forges the sender address
(other cases see below). This proposal is designed to detect such
forgeries.
However, the RMX approach is rendered ineffective, if the sender
doesn't forge. If the sender uses just a normal address of it's own
domain, this is just a plain, normal e-mail, which needs to be let
through. Since it is up to the human's taste whether this is spam
or not, there's no technical way to reliably identify this as spam.
But since the sender domain is known, this domain can be
blacklisted or legal steps can be gone into.
10.1.7. Empty Sender address
There is a design flaw of current SMTP and SMTP programs: The empty
sender envelope address. This is used for delivery of error
messages, and most MTAs accept messages with an empty sender
address. Obviously, RMX records can't be checked for empty sender
addresses.
It is a design flaw to inherently allow anonymous mails. This flaw
must either be fixed, or other methods have to be developed. For
example MTAs could accept such mails only if they reference the
Message-ID of another e-mail which has recently been delivered.
10.1.8. Reliability of Whois Entries
Once the RMX infrastructure gets deployed, what's the security
gain? It allows to determine the domain which's DNS zone
authorized the sending machine. What's that good for? There are
some immediate uses of the domain name, e.g. in black- and
whitelisting. But in most cases this is just the starting point of
further investigations, either performed automatically before
message acceptance, or manually after spam has been received and
complainted about.
The next step after determining the domain is determining the
people responsible for this domain. This can sometimes be achieved
by querying the Whois databases. Unfortunately, many whois entries
are useless because they are incomplete, wrong, obsolete, or in
Hadmut Danisch Experimental [Page 16]
INTERNET-DRAFT DNS RMX RR Jun 2003
uncommon languages. Furthermore, there are several formats of
address informations which make it difficult to automatically
extract the address. Sometimes the whois entry identifies the
provider and not the owner of the domain. Whois servers are not
built for high availability and sometimes unreachable.
Therefore, a mandatory standard is required about the contents and
the format of whois entries, and the availability of the servers.
After receiving the MAIL FROM SMTP command with the sender envelope
address, the receiving MTA could check the RMX record and Whois
entry. If it doesn't point to a real human, the message could be
rejected and an error message like "Ask your provider to fix your
Whois entry" could be issued. Obviously, domain providers must be
held responsible for wrong entries. It might still be acceptable to
allow anonymous domains, i. e. domains which don't point to a
responsible human. But it is the receivers choice to accept e-mails
from such domains or not.
10.1.9. Hazards for Freedom of Speech
Currently, some governments try to enforce limitations of internet
traffic in order to cut unwanted content providers from the
network. Some of these governments try to hide a whole country
behind firewalls, others try to force Internet providers to poison
DNS servers with wrong A records for web servers, e.g. one county
administration in Germany tries to do so. If message reception
depends on DNS entries, the same governments will try to block not
only HTTP, but SMTP also.
However, since most MTAs already reject messages from unresolvable
domain names this is not a new threat.
10.2. General Considerations about spam defense
After discussing security requirements of the proposal, now the
security advantages of the RMX approach over content based filters
will be explained. Basically, there are three kinds of content
filters:
- Those who upload the message or some digest to an external
third party and ask "Is this spam"?
- Those who download a set of patterns and rules from a third
party and apply this set to incoming messages in order to
determine whether it is spam.
- Those who are independent and don't contact any third party,
but try to learn themselves what is spam and what isn't.
Hadmut Danisch Experimental [Page 17]
INTERNET-DRAFT DNS RMX RR Jun 2003
The message filters provided by some e-mail service providers are
usually not a kind of their own, but a combination of the first two
kinds.
10.2.1. Action vs. reaction
Content filters suffer from a fundamental design problem: They are
late. They need to see some content of the same kind before in
order to learn and to block further distribution.
This works for viruses and worms, which redistribute. This doesn't
work for spam, since spam is usually not redistributed after the
first delivery. When the filters have learned or downloaded new
pattern sets, it's too late.
This proposal does not have this problem.
10.2.2. Content based Denial of Service attacks
All three kinds of content filters, but especially the second and
the third kind are vulnerable to content based Denial of Service
attacks.
If some kind of third party (e.g. non-democratic government,
intellectual property warriors, religious groups, military, secret
services, patriots, public relation agents, etc.) wants certain
contents not to be distributed, they could either poison the
pattern/rule databases or feed wrong sets to particular receivers.
Such pattern/rule sets are the perfect tool for censoring e-mail
traffic and denial of service attacks by governments and other
parties, and a similar threat are virus filters. E. g. the content
industry could demand to teach all virus and spam filters to delete
all e-mails containing the URL of an MP3 web server outside the
legislations. Software manufacturers could try to block all e-mails
containing software license keys, thus trying to make unallowed
distribution more difficult. Governments could try to block
distribution of unwanted informations.
This proposal does not have this problem.
11. Privacy Considerations
(It was proposed on the 56th IETF meeting to have a privacy section
in drafts and RFCs.)
11.1. Draft specific considerations
Hadmut Danisch Experimental [Page 18]
INTERNET-DRAFT DNS RMX RR Jun 2003
11.1.1. No content leaking
Since the RMX approach doesn't touch the contents of a message in
any way, there is obviously no way of leaking out any information
about the content of the message. RMX is based solely on the
envelope recipient address. However, methods to fix problems not
covered by RMX might allow content leaking, e.g. if the acceptance
of a message with an empty sender address requires the reference to
the message id of an e-mail recently sent, this allows an attacker
to verify whether a certain message was delivered from there.
11.1.2. Message reception and sender domain
Message delivery triggers RMX and APL requests by the recipient.
Thus, the admin of the DNS server or an eavesdropper could learn
that the given machine has just received a message with a sender
from this address, even if the SMTP traffic itself had been
encrypted.
However, most of today's MTAs do query the MX and A records of the
domain after the MAIL FROM command, so this is not a real new
threat.
11.1.3. Network structure
Since RMX and its associated APL records provide a complete list of
all IP addresses of hosts authorized to send messages from this
address, they do reveal informations about the network structure
and maybe the lifestyle of the domain owner, since a growing number
of domains are owned by single persons or families. E.g. the RMX
records could reveal where someone has his job or spends his time
at weekends.
If such informations are to be kept secret, it is the user's job to
not sent e-mails from there and to relay them from non-compromising
IP addresses.
11.1.4. Owner information distribution
As described above, RMX depends partly on the reliability of the
whois database entries. It does not make anonymous domains
impossible, but it requires to keep the database entries "true", i.
e. if a whois entry does not contain informations about the
responsible person, this must be unambigously labeled as anonymous.
It must not contain fake names and addresses to pretend a non-
existing person. However, since most Internet users on the world
feel extremely annoyed by spam, they will urge their MTA admin to
reject messages from anonymous domains. The domain owner will have
Hadmut Danisch Experimental [Page 19]
INTERNET-DRAFT DNS RMX RR Jun 2003
the choice to either remain anonymous but be not able to send e-
mail to everyone in the world, or to be able but to reveal his
identity to everyone on the world.
It would be possible to provide whois-like services only to
recipients of recent messages, but this would make things too
complicated to be commonly adopted.
11.2. General Considerations about spam defense
11.2.1. Content leaking of content filters
As described above in the Security chapter, there are spam filters
which inherently allow leakage of the message body. Those filters
upload either the message body, or in most cases just some kind of
checksum to a third party, which replies whether this is to be seen
as spam or not. The idea is to keep a databases of all digests of
all messages. If a message is sent more often than some threshold,
it is to be considered as a mass mail and therefore tagged as spam.
While the digest itself does not reveal the content of the message,
it perfectly reveals where a particular message has been delivered
to. If a government finds just a single unwanted message, if a
software manufacturer finds a single message with a stolen product
license key, if someone finds a message with unpatriotic content,
it takes just a single database lookup to get a list of all people
who received this particular message. Content filters with digest
upload are the perfect "Big Brother".
11.2.2. Black- and Whitelists
Some proposals against spam are based on a central database of
white- or blacklisted IP addresses, Sender names, Message IDs or
whatever. Again, there is a central database which learns who has
received which e-mail or from which sender with every query. This
allows tracking relations between persons, which is also a breach
of privacy.
12. Deployment Considerations
Is there a concise technical solution against spam? Yes.
Will it be deployed? Certainly not.
Why not? Because of the strong non-technical interests of several
parties against a solution to the problem, as described below.
Since these are non-technical reasons, they might be beyond the
Hadmut Danisch Experimental [Page 20]
INTERNET-DRAFT DNS RMX RR Jun 2003
scope of such a draft. But since they are the main problems that
prevent fighting spam, it is unavoidable to address them. This
chapter exists temporarily only and should support the discussion
of solutions. It is not supposed to be included in a later RFC.
12.1. The economical problem
As has been recently illustrated in the initial session of the
IRTF's Anti Spam Research Group (ASRG) on the 56th IETF meeting,
sending spam is a business with significant revenues.
But a much bigger business is selling Anti-Spam software. This is a
billion dollar market, and it is rapidly growing. Any simple and
effective solution against spam would defeat revenues and drive
several companies into bankrupt, would make consultants jobless.
Therefore, spam is essential for the Anti-Spam business. If there
is no spam, then no Anti-Spam software can be sold, similar to the
Anti-Virus business. There are extremely strong efforts to keep
this market growing. Viruses, Worms, and now spam are just perfect
to keep this market alive: It is not sufficient to just buy a
software. Databases need to be updated continuously, thus making
the cash flow continuously. Have a single, simple, and permanent
solution to the problem and - boom - this billion dollar market is
dead.
That's one of the reasons why people are expected to live with
spam. They have to live with it to make them buy Anti-Spam
software. Content filters are perfect products to keep this market
alive.
12.2. The POP problem
Another problem is the history of mail delivery. Once upon a time,
there used to be very few SMTP relays which handled the e-mail
traffic of all the world, and everybody was happy with that. Then
odd things like Personal Computers, which are sometimes switched
off, portable computers, dynamicly assigned IP addresses, IP access
from hotel rooms, etc. was invented, and people became unhappy,
because SMTP does not support delivery to such machines. To make
them happy again, the Post Office Protocol[3] was invented, which
turned the last part of message delivery from SMTP's push style
into a pull style, thus making virtually every computer on the
world with any random IP address a potential receiver of mails for
random domains. Unfortunately, only receiving e-mail was covered,
but sending e-mail was left to SMTP.
The result is that today we have only very few SMTP relays pointed
Hadmut Danisch Experimental [Page 21]
INTERNET-DRAFT DNS RMX RR Jun 2003
to by MX records, but an extreme number of hosts sending e-mail
with SMTP from any IP address with sender addresses from any
domain. Mail delivery has become very asymmetric. Insecurity,
especially forgeability, has become an essential part of mail
transport.
That problem could easily be fixed: Use protocols which allow
uploading of messages to be delivered. If a host doesn't receive
messages by SMTP, it shouldn't deliver by SMTP. Mail delivery
should go the same way back that incoming mail went in. This is
not a limitation to those people on the road who plug their
portable computer in any hotel room's phone plug and use any
provider. If there is a POP server granting download access from
anywhere, then the same server should be ready to accept uploading
of outgoing messages.
But as I saw from the comments on the first version of this draft,
people religiously insist on sending e-mail with their domain from
any computer with any IP address in the world, e.g. when visiting a
friend using her computer. It appears to be impossible to convince
people that stopping mail forgery requires every one of them to
give up forging.
12.3. The network structure problem
A subsequent problem is that many organisations failed to implement
a proper mail delivery structure and heavily based their network on
this asymmetry. I received harsh comments from Universities who
were unable to give their network a good structure. While they do
have a central mail relay for incoming mail to the universities
domain, they developed a structure where every member of the
University randomly sends e-mails with that University's domain as
a sender address from home or everywhere in the world with any
dynamically assigned IP address from any provider. So this domain
is to be used from every possible IP address on earth, and they are
unable to operate any authentication scheme. Furthermore, they were
unable to understand that such a policy heavily supports spam and
that they have to expect that people don't accept such e-mails
anymore once they become blacklisted.
As long as organisations insist on having such policies, spammers
will have a perfect playground.
12.4. The mentality problem
Another problem is the mentality of many internet users of certain
countries. I received harsh comments from people who strongly
insisted on the freedom to send any e-mail with any sender address
Hadmut Danisch Experimental [Page 22]
INTERNET-DRAFT DNS RMX RR Jun 2003
from anywhere, and who heavily refused any kind of authentication
step or any limitation, because they claimed that this would
infringe their constitutional "Freedom of speech". They are
undeviatingly convinced that "Freedom of speech" guarantees their
right to talk to everybody with any sender address, and that is has
to be kept the recipient's own problem to sort out what he doesn't
want to read - on the recipient's expense.
It requires a clear statement that the constitutional "Freedom of
Speech" does not cover molesting people with unsolicited e-mail
with forged sender address.
12.5. The identity problem
How does one fight against mail forgery? With authentication. What
is authentication? In simple words: Making sure that the sender's
real identity meets the recipients idea of who is the sender, based
on the sender address which came with the message.
What is identity? It is the main problem. Several countries have
different ideas of "identity", which turn out to be somehow
incompatible. In some countries people have identity cards and
never change their name and birthday. Identities are created by
human birth, not by identity changes. Other countries do not have
such a tight idea about identity. People's temporary identity is
based on nothing more than a driving license and a social security
number. With this background, it is virtually impossible to create
a trustworthy PKI covering all Internet users. I learned that it is
extremely difficult to convince some people to give up random e-
mail sending.
12.6. The multi-legislation problem
Many proposals about fighting spam are feasible under certain
legislations only, and are inacceptable under some of the
legislations. But a world wide applicable method is required.
That's why the approach to ask everone on the world to sign
messages with cryptographic keys is not feasible.
Implementation and further Information
Further informations and a test implementation are available at
http://www.danisch.de/work/security/antispam.html
and
http://www.danisch.de/software/rmx/
Hadmut Danisch Experimental [Page 23]
INTERNET-DRAFT DNS RMX RR Jun 2003
References
1. J. Klensin, "Simple Mail Transfer Protocol," RFC 2821 (April 2001).
2. P. Mockapetris, "DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION,"
RFC 1035 (November 1987).
3. J. Myers, M. Rose, "Post Office Protocol - Version 3," RFC 1939
(May 1996).
Author's Address
Hadmut Danisch
Tennesseeallee 58
76149 Karlsruhe
Germany
Phone: ++49-721-843004
E-Mail: rfc@danisch.de
Comments
Please send comments to rfc@danisch.de.
Expiry
This drafts expires on Dec 1, 2003
Hadmut Danisch Experimental [Page 24]
View Git Blame Copy Permalink