ietf-mxcomp
[Top] [All Lists]

Re: Unified SPF: block versus factored records for HELO and MTAMAark scopes

2004-06-25 04:28:02

Meng,

Two responses, for the price of one:


MWW> OK, speaking of CSV in its current incarnation, can anyone
MWW> give me a concrete example of how the
MWW> authentication/authorization procedure operates?

MWW> In SPF, authentication is simple: you do the SPF TXT lookup,
MWW> you get back the SPF TXT record,

Forgive me, but:

MWW> the computer thinks a bit,
MWW> and you get a well-defined PASS or FAIL or NEUTRAL, etc
MWW> response.

That sounds quite a bit about the old joke about the blank space in a
board that is otherwise filled with equations. The scientist responds
to a query by pointing to it and says "that's where a miracle
happens".

So, yes, your description does indeed sound simple, but that to be
because you left out all of the interesting stuff.


MWW> In CSV,
MWW> http://www.jlc.net/MARID/CSV/draft-ietf-marid-csv-intro-00.html#anchor11
MWW> suggests that you do authentication by doing a A lookup of
MWW> the HELO name;

It's not a "suggestion". It is a "specification". The differences is
important. CSV is very simple and constrained. It is entirely based on
the SMTP HELO.

If you are using some other identity, then you are not using CSV. That
is why the specification has a title that says "client smtp". The HELO
is the only place that that client is able to declare its identity.


MWW> I would request that the next draft of the CSV proposal
MWW> contain some examples and walkthroughs.

My co-authors have thoughtfully added a rather nice description of the
usage sequence in Section 1 of <draft-ietf-marid-csv-intro-00>.

More detailed examples are almost always often helpful, so perhaps you
could describe what sorts of cases you would like to see described?


 - - - - -


MWW>   client ip         factored query         block query
MWW>   ---------   --------------------------   ---------------
MWW>   192.0.2.1   lookup(aol.com, 192.0.2.1)   lookup(aol.com)


As your discussion highlights, there is some complexity to the desired
lookup- and storage- compression efficiencies that folks might seek.
The usual implication of such an observation is that folks should be
careful about standardizing particular choices, until there is
experience with the physics of the service.

In any event, as Roy noted, CSV does a forward query based on a domain
name. The incoming IP Address may be used by a higher-level CSV
process, to do some comparing.

So the "factored query" that you describe does not show up in CSV. For
that matter, it is not a DNS query, since you do not get to specify
two lookup keys in a DNS query. You specify one, a domain name.

According to the example you give, the CSV style of query therefore
looks like the column marked "block query".

In the typical case, returned information will include a set of IP
Addresses in the Additional Information field. How the DNS client
chooses to organize and use this information is its own business. That
choice is not forced upon them by the protocol.

At best what you scenario suggests is that a CSV-category module
should do its own caching and do it more cleverly than a
run-of-the-mill system DNS cache.


I suspect the confusion in your comments is between protocol versus
implementation.  Clearly, one would want the implementation to have a
feature along the lines you described, since that gives nice caching
behavior.

As I understand it, the working group is doing PROTOCOL specification
-- specifically a DNS record, though we seem to range rather farther,
in order to understand what we need the record FOR.  We are not doing
implementation standardization.  As long as the protocol does not
behave in a way that prevents good implementation, then the it is not
the working group
optimization that you are suggesting.

So I am not understanding what difference in protocol behaviors you
are distinguishing between SPF and CSV, with respect to the functions
raised for this thread.  (As I noted in a separate note, the scope of
SPF is something I've been finding confusing, so I'm forced to use the
CSV scope for this note.)

d/



MWW> On Thu, Jun 24, 2004 at 04:41:14PM +0100, Roy Badami wrote:
MWW> | 
|     Meng>> antispam engines.  Factored records which require a new
|     Meng>> lookup for every cache negative are, in their world, not
|     Meng>> lightweight by comparison.
MWW> | 
MWW> | But, AIUI, CSV in it's current incarnation involves doing an SRV
MWW> | lookup on the domain name; how is this more heavyweight than doing a
MWW> | TXT lookup.  CSV looks just as cacheable to me as SPF, but uses more
MWW> | compact records...
MWW> | 

MWW> I was mainly comparing cache negatives.

MWW> Scenario: 5 spams that all say MAIL FROM:<forgery(_at_)aol(_dot_)com>

MWW> Let each spam come from a different IP.

MWW>   client ip         factored query         block query
MWW>   ---------   --------------------------   ---------------
MWW>   192.0.2.1   lookup(aol.com, 192.0.2.1)   lookup(aol.com)
MWW>   192.0.2.2   lookup(aol.com, 192.0.2.2)      cached
MWW>   192.0.2.3   lookup(aol.com, 192.0.2.3)      cached
MWW>   192.0.2.4   lookup(aol.com, 192.0.2.4)      cached
MWW>   192.0.2.5   lookup(aol.com, 192.0.2.5)      cached

MWW> In this scenario, factored queries do not benefit from
MWW> local DNS caching.

MWW> So, the theory is: a spam run against a single receiver
MWW> domain may originate from X distinct IPs.

MWW> That spam run may forge Y distinct domain names.

If X >>> Y, a block format is better than factored.

If Y >>> X, block and factored formats are equivalent within
MWW> one order of magnitude.

MWW> Scenarios in which factored formats beat block formats hands
MWW> down tend to be contrived.

MWW> The current threat model is lots of zombies, hence lots of
MWW> IPs.  True, there's nothing to stop them from forging lots
MWW> of domains, too.  That's where the MTAMark design proves
MWW> useful --- it scales well, because only one network owner
MWW> has to add records.



d/
--
 Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>

d/
--
 Dave Crocker <mailto:dcrocker(_at_)brandenburg(_dot_)com>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>