ietf-clear
[Top] [All Lists]

[clear] Comparing CSV and SPF

2005-04-04 15:09:12
On Mon, 2005-04-04 at 16:29 -0700, David MacQuigg wrote:
At 09:30 AM 4/4/2005 -0700, Doug Otis wrote:

The SRV record does not require the administrator to enter any address
whatsoever.  SRV records are strictly name based associations.  This
also ensures only a single DNS lookup is needed to resolve the
authorization and authentication associated with the SMTP client's
connection.  This simplifies the maintenance of these records, and
lowers the risk of publication error.

I don't see how CSV avoids entering IP addresses, or how it simplifies 
maintenance, especially for a large domain with hundreds of public mail 
servers.  Don't you need both an SRV record (name) and an A record (IP 
address) for each one of those servers?  Fundamentally, you always have to 
make an association between a name and an address.

The SMTP clients will already have an A record.  The SRV record simply
uses the name of the A record as a Target.  Therefore, DNS
administrators do not enter an address for the SRV record, just the
name.  The association is between HELO and Target name, not addresses.

Would it not be simpler to have one record list all the mail-serving IP 
blocks for an entire domain?  Take a look at the SPF record for 
rr.com.  They list all their mail servers in 12 blocks of 256 IPs 
each.  That would allow maybe 2000 servers to be moved freely among the 
3072 possible IP addresses, so there isn't a maintenance problem that I can 
see.

With CSV, there is an assurance all required information will be within
a single DNS lookup.  You REALLY don't care about all the other SMTP
clients that may be used.  You only want to know about the current SMTP
client.  Addresses are not static, not even blocks of addresses.  Large
blocks of addresses also requires parsing using a script language.
Prior to the effort to distill these thousands of addresses to CIDR
notation, there was 78 DNS lookups to obtain the address list for rr.com
when using name references.  Hand manipulating thousands of addresses is
still a maintenance headache.  By using name associations, changing the
individual address record will update all related records, whether these
are the MX or the SRV records.  No special tools are required.

This SRV record, used in conjunction with a reputation service, may
provide DoS protections.  SPF, for example, requires more than one
hundred DNS lookups, as a minimum, to ensure all clients that may send
from a particular domain can be resolved.  Rather than retaining just an
manually generated address listing, (which is error prone) SPF has opted
to extend the number of queries to allow references by name for specific
clients.  SRV already provides this name based reference feature.

The latest developments involve an "SPF compiler" to produce a simple list 
of IP blocks from the more complex SPF "source record".  This works for 
most mechanisms, but there will still be problems with some.  My guess is 
that the troublesome mechanisms will eventually be deprecated, and SPF will 
arrive at an optimum by backing off on some of their over-design.

Start with a square stone, chip away at the corners, and eventually you
will reinvent the wheel. For HELO, SRV already provides this "compiled"
list of addresses.  This is done at the lowest level of complexity
possible; the single SMTP client.  In addition, the need to list all
associated addresses vanishes when DomainKeys is used, as the signature
can better associate all related sources.  Bulk emailers simply sign
their mail to achieve the same result, while not having problems with
forwarded accounts, etc.

The use of the SRV record avoids complexity by keeping within the
designed scale of DNS by attempting to only resolve the client
associated with the HELO, rather than answer a much more expansive (and
impossible) question regarding all the possible clients that send a
specific mailbox-domain.

It seems like the choice now is between CSV with a large number of 
single-server records, and SPF with far fewer records but the potential for 
abuse of its whiz-bang features.  What I'm looking for is an optimum that 
has the safety of CSV and just a few of the features of SPF.  The ability 
to authorize hundreds of servers in a domain, using one cacheable DNS 
record, seems like a feature that CSV could use.  It would be easier on DNS 
than digging down six levels to query every server, and I don't see any 
potential for abuse.

The HELO should prevent any digging.  When CSV is not supported, there
may be a desire to do a few more queries.  This is not any different
than any other scheme that attempts to establish domain wide assertions.
I have offered some examples of how CSV can be extended to include some
features when combined with signatures in draft-otis-mass-reputation:

Domain Assertions for Signatures

   [ID-CSV] provides a means to make domain-wide assertions.  Currently,
   only the use of CSV itself is defined.  The Port field of the CSV-CSA
   record defined in [ID-CSVCSA] can be extended to make signature
   related assertions.  These assertions could be used to prevent
   [RFC2822] FROM from being spoofed.

   +--------------+----------------------------------------------------+
   |   Bit Value  | Meaning                                            |
   +--------------+----------------------------------------------------+
   |       1      | Explicit: All authorized names have specific       |
   |              | CSV-CSA records.                                   |
   |       2      | All Messages Signed.                               |
   |       4      | All Messages Signed by HELO domain.                |
   |       8      | FROM Signed by HELO domain.                        |
   |       -      | Other bit values are reserved for expansion and    |
   |              | must be set to zero. This range of values should   |
   |              | be ignored by the recipient when their function is |
   |              | unknown.                                           |
   +--------------+----------------------------------------------------+

   Asserting that "all messages signed" allows other domain signatures
   to be used, but makes an assurance that all messages sent by the MTA
   will be signed.  Asserting all "messages signed by HELO domain" makes
   an assurance all messages sent by this MTA can be identified by a
   parent domain signature.  The "FROM Signed by HELO domain" assertion
   indicates that [RFC2822] FROM headers with a mailbox-domain being a
   parent of the HELO domain must be signed by the parent domain or
   should be refused.  This mechanism provides a means to prevent
   phishing and should be selectively used by only those experiencing
   the phishing problem.  This assertion may cause messages that have
   been been altered, or re-signed by other domains, to be refused.


This was only to start a discussion how this simple binary structure
within CSV-CSA can be extended for policy related assertions.

It seems to me the fundamental advantage of CSV over SPF is that CSV 
doesn't try to associate domain names with IP addresses outside of that 
domain.  The disadvantage, and it doesn't seem fundamental, is that you 
can't set up just one simple record to authorize all the servers in a domain.

Funny, that seems to be its advantage.  It provides DoS protection, in
conjunction with domain based reputations, that SPF can never provide.

-Doug



<Prev in Thread] Current Thread [Next in Thread>