INTERNET-DRAFT                                           Hadmut DanischCategory: Experimental                                         Oct 2003Expires: Apr 1, 2004 The RMX DNS RR and method for lightweight SMTP sender authorization                   draft-danisch-dns-rr-smtp-03.txtStatus 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.htmlAbstract   This memo introduces a new authorization scheme for SMTP e-mail   transport. It is designed to be a simple and robust protection   against e-mail fraud, spam and worms. It is based solely on   organisational security mechanisms and does not require but still   allow use of cryptography. This memo also focuses on security and   privacy problems and requirements in context of spam defense. In   contrast to prior versions of the draft a new RR type is not   required anymore.Hadmut Danisch                Experimental                      [Page 1]INTERNET-DRAFT                 DNS RMX RR                       Oct 2003                           Table of Contents1.  General Issues . . . . . . . . . . . . . . . . . . . . . . . . .   42.  Problem and threat description . . . . . . . . . . . . . . . . .   4    2.1.  Mail sender forgery  . . . . . . . . . . . . . . . . . . .   4          2.1.1  Definition of sender forgery  . . . . . . . . . . .   4          2.1.2  Spam  . . . . . . . . . . . . . . . . . . . . . . .   5          2.1.3  E-Mail Worms  . . . . . . . . . . . . . . . . . . .   5          2.1.4  E-Mail spoofing and fraud . . . . . . . . . . . . .   5    2.2.  Indirect damage caused by forgery  . . . . . . . . . . . .   6    2.3.  Technical problem analysis . . . . . . . . . . . . . . . .   6    2.4.  Shortcomings of cryptographical approaches . . . . . . . .   73.  A DNS based sender address verification  . . . . . . . . . . . .   7    3.1.  Overview . . . . . . . . . . . . . . . . . . . . . . . . .   7    3.2.  Envelope vs. header sender address . . . . . . . . . . . .   9    3.3.  Domain part vs. full sender address  . . . . . . . . . . .   94.  Mapping of E-Mail addresses to DNS names . . . . . . . . . . . .  10    4.1.  Domain part only . . . . . . . . . . . . . . . . . . . . .  10    4.2.  Full address . . . . . . . . . . . . . . . . . . . . . . .  11    4.3.  Empty address  . . . . . . . . . . . . . . . . . . . . . .  115.  Mandatory entry types and their syntax . . . . . . . . . . . . .  11    5.1.  Overall structure  . . . . . . . . . . . . . . . . . . . .  11    5.2.  Unused . . . . . . . . . . . . . . . . . . . . . . . . . .  12    5.3.  IPv4 and IPv6 address ranges . . . . . . . . . . . . . . .  12    5.4.  DNS Hostname . . . . . . . . . . . . . . . . . . . . . . .  13          5.4.1  Road warriors and DynDNS entries  . . . . . . . . .  13    5.5.  APL Reference  . . . . . . . . . . . . . . . . . . . . . .  14    5.6.  Domain Member  . . . . . . . . . . . . . . . . . . . . . .  14    5.7.  Full Address Query . . . . . . . . . . . . . . . . . . . .  15    5.8.  DNS mapped authorization . . . . . . . . . . . . . . . . .  15    5.9.  RMX reference  . . . . . . . . . . . . . . . . . . . . . .  166.  Optional and experimental entry types  . . . . . . . . . . . . .  16    6.1.  TLS fingerprint  . . . . . . . . . . . . . . . . . . . . .  16    6.2.  TLS and LDAP . . . . . . . . . . . . . . . . . . . . . . .  16    6.3.  PGP or S/MIME signature  . . . . . . . . . . . . . . . . .  16    6.4.  Transparent Challenge/Response . . . . . . . . . . . . . .  17    6.5.  SASL Challenge/Response  . . . . . . . . . . . . . . . . .  177.  Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . .  17    7.1.  Alternative encoding as TXT records  . . . . . . . . . . .  17    7.2.  RMX Records  . . . . . . . . . . . . . . . . . . . . . . .  17          7.2.1  Overall structure . . . . . . . . . . . . . . . . .  18          7.2.2  Record encoding . . . . . . . . . . . . . . . . . .  18          7.2.3  Encoding of IPv4 and IPv6 address ranges  . . . . .  18          7.2.4  Encoding of DNS . . . . . . . . . . . . . . . . . .  18          7.2.5  Encoding of unused and full query . . . . . . . . .  19          7.2.6  Additional Records  . . . . . . . . . . . . . . . .  198.  Message Headers  . . . . . . . . . . . . . . . . . . . . . . . .  19Hadmut Danisch                Experimental                      [Page 2]INTERNET-DRAFT                 DNS RMX RR                       Oct 20039.  SMTP error messages  . . . . . . . . . . . . . . . . . . . . . .  2010.  Message relaying and forwarding . . . . . . . . . . . . . . . .  20    10.1.  Problem description . . . . . . . . . . . . . . . . . . .  20    10.2.  Trusted relaying/forwarding . . . . . . . . . . . . . . .  21    10.3.  Untrusted relaying/forwarding . . . . . . . . . . . . . .  2111.  Security Considerations . . . . . . . . . . . . . . . . . . . .  22    11.1.  Draft specific considerations . . . . . . . . . . . . . .  22          11.1.1  Authentication strength  . . . . . . . . . . . . .  22          11.1.2  Where Authentication and Authorization end . . . .  22          11.1.3  Vulnerability of DNS . . . . . . . . . . . . . . .  23          11.1.4  Sneaking RMX attack?   . . . . . . . . . . . . . .  25          11.1.5  Open SMTP relays . . . . . . . . . . . . . . . . .  25          11.1.6  Unforged Spam  . . . . . . . . . . . . . . . . . .  25          11.1.7  Reliability of Whois Entries . . . . . . . . . . .  26          11.1.8  Hazards for Freedom of Speech  . . . . . . . . . .  26    11.2.  General Considerations about spam defense . . . . . . . .  27          11.2.1  Action vs. reaction  . . . . . . . . . . . . . . .  27          11.2.2  Content based Denial of Service attacks  . . . . .  2712.  Privacy Considerations  . . . . . . . . . . . . . . . . . . . .  28    12.1.  Draft specific considerations . . . . . . . . . . . . . .  28          12.1.1  No content leaking . . . . . . . . . . . . . . . .  28          12.1.2  Message reception and sender domain  . . . . . . .  28          12.1.3  Network structure  . . . . . . . . . . . . . . . .  29          12.1.4  Owner information distribution . . . . . . . . . .  29    12.2.  General Considerations about spam defense . . . . . . . .  29          12.2.1  Content leaking of content filters . . . . . . . .  29          12.2.2  Black- and Whitelists  . . . . . . . . . . . . . .  3013.  Deployment Considerations . . . . . . . . . . . . . . . . . . .  30    13.1.  Compatibility . . . . . . . . . . . . . . . . . . . . . .  30          13.1.1  Compatibility with old mail receivers  . . . . . .  30          13.1.2  Compatibility with old mail senders  . . . . . . .  30          13.1.3  Compatibility with old DNS clients . . . . . . . .  30          13.1.4  Compatibility with old DNS servers . . . . . . . .  30    13.2.  Enforcement policy  . . . . . . . . . . . . . . . . . . .  3114.  General considerations about fighting spam  . . . . . . . . . .  31    14.1.  The economical problem  . . . . . . . . . . . . . . . . .  31    14.2.  The POP problem . . . . . . . . . . . . . . . . . . . . .  32    14.3.  The network structure problem . . . . . . . . . . . . . .  33    14.4.  The mentality problem . . . . . . . . . . . . . . . . . .  33    14.5.  The identity problem  . . . . . . . . . . . . . . . . . .  33    14.6.  The multi-legislation problem . . . . . . . . . . . . . .  34Implementation and further Information . . . . . . . . . . . . . . .  34References . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  34Draft History  . . . . . . . . . . . . . . . . . . . . . . . . . . .  35Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . .  35Hadmut Danisch                Experimental                      [Page 3]INTERNET-DRAFT                 DNS RMX RR                       Oct 20031.  General Issues   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 RFC 2119 [1].2.  Problem and threat description2.1.  Mail sender forgery   The amount of e-mails with forged sender addresses has dramatically   increased. As a consequence, damages and annoyances 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.2.1.1.  Definition of sender forgery   As discussions, comments to prior versions of this draft, and   different approaches to stop forgery showed, different perceptions   of "mail forgery" exist. For example, there are mechanisms to   verify e-mail addresses for mailing lists, web servers, or to stop   spam, which do send a message with a random number to the given   address and expect the user to send a reply. Here, someone is   considered to be allowed to use a particular e-mail address, if and   only if he is able to receive informations sent to this address,   and is able to reply to such a message. While this definition   appears to be quite plausible and natural, it can't be used for a   simple technical solution. Sending back a challenge and expecting a   reply is simply too much overhead and time delay, and not every   authorized sender is able or willing to reply (e.g. because he went   offline or is not a human).   Within the scope of this memo, sender forgery means that the   initiator of an e-mail transfer (which is the original sender in   contrast to relays) uses a sender address which he was not   authorized to use. Being authorized to use an address means that   the owner (administrator) of the internet domain has given   permission, i.e. agrees with the use of the address by that   particular sender. This memo will cover both the permission of the   full e-mail address and the domain part only for simplicity.   Within context of Internet and SMTP, the sender address usually   occurs twice, once as the envelope sender address in SMTP, and once   as the address given in the RFC822 mail header. While the following   considerations apply to both addresses in principle, it is   important to stress that both addresses have distinct semantics andHadmut Danisch                Experimental                      [Page 4]INTERNET-DRAFT                 DNS RMX RR                       Oct 2003   are not neccessarily the same. The envelope address identifies the   initiator of the transport, while the header identifies the author   of the message content. Since this memo deals with the message   transport only and completely ignores the message content, the   method should naturally be applied to the envelope sender address.2.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.   Unfortunately, there is no accurate definition of spam availabe   yet, and neither are the concise technical criterions to filter or   block spam with technical mechanisms. There are efforts to design   content based filters, but these filters are expensive in   calculation time (and sometimes money), and they do not reliably   provide predictable results. Usually they give false positives   and/or require user interaction. Content filters in general suffer   from a design problem described later in this memo.  Therefore,   this proposal does not use the content based approach to block   spam.   As analysis of spam messages showed, most of spam messages were   sent with forged envelope sender addresses. This has mainly three   reasons.  The first reason is, that spam senders usually do not   want to be contacted by e-mail. The second reason is, that they do   not want to be blacklisted easily. The third reason is, that spam   is or is going to be unlawful in many countries, and the sender   does not want to reveal his identity. Therefore, spam is considered   to be a special case of sender forgery.2.1.3.  E-Mail Worms   Another example of sender forgery is the reproduction of e-mail   worms. Most worms do choose random sender addresses, e.g.  using   the addresses found in mailboxes on the infected system. In most   cases analyzed by the author, the e-mails sent by the reproduction   process can also be categorized as forged, since the infected   system would under normal circumstances not be authorized to send   e-mails with such e-mail addresses. So forgery does not require a   malicious human to be directly involved. This memo covers any kind   of e-mail sender address forgery, included those generated by   malicious software.2.1.4.  E-Mail spoofing and fraudHadmut Danisch                Experimental                      [Page 5]INTERNET-DRAFT                 DNS RMX RR                       Oct 2003   Forging e-mail sender addresses for fraud or other kinds of   deception ("human engineering") has also dramatically increased.   There are many known cases where single or mass e-mails were sent   with wrong sender addresses, pretending to come from service   provider, software manufacturers etc., and asking the receiver to   install any software or patches, or to reply with any confidential   information. The Internet is becoming more and more a scene of   crime, and so are it's services, including e-mail. It is obvious   that crime based on e-mail is eased by the fact that SMTP allows   arbitrary sender address spoofing.2.2.  Indirect damage caused by forgery   As observed by the author, mass mails and worms with forged sender