ietf-mxcomp
[Top] [All Lists]

Re: WG to close ; Re: Make CSV backwards compatible with SPF? (new revisions)

2004-09-22 22:21:47

Douglas,

I will be among the first to implement a solution that make sense.  In
regards to your CSV,  I commend you for excellent written proposals,
however,  I offer the following reasons for why they have an element that
prohibit consideration for implementation.

CSV is a solution based on two methods: CSA vs. DNA.  I understand all the
arguments for your design, however, I don't think you (among others) have
completely understood the deployment and real operations paradigm that makes
CSV conflictive:

First, this applies to all proposals.  The EHLO/MAIL FROM validation is
useless if RCPT TO is invalid.  We already covered this in our emails a few
months back.   I believe I concluded that it should be mentioned in the
specs.

Second,  it is possible to use CSA only for True Negatives.

What are true negatives?.

Here is my extended terminology for establishing the level of trust in the
email arena:

    False Positives - a Pass that was deemed incorrect upon inspection
    True Positives - a Pass that was deemed correct upon inspection
    False Negative - a Reject that was deemed incorrect upon inspection
    True Negative - a Reject that was deemed correct upon inspection

For example:

A EHLO check that results in a REJECTION is a 100% Trusted result.  This can
be fundamentally proven with local domain EHLO checks, i.e.,  An anonymous
IP trying to use your own domain(s) for the EHLO command is an easy spoof
check.

However, an EHLO check that results with a PASS is not a 100% trusted result
and needs further scrutiny.

This is where you use DNA as a well to check the trust of the result. What I
am saying, you only need to do this for a PASS, not a rejection.   What this
means is that your lookup method needs to take into  account this overhead
reduction concept.   Currently, the lookup says to do DNA first, then CSA.
I say CSA first because .....

Third,  DNA is too exclusive.

CSV will not get adopted unless it has ready DNA sites. The problem I have
is how to offer it to customers from a marketing standpoint.   We can't make
a claim for "new anti-spam technology using CSV" with a footnote that says
"requires double A batteries (DNA) in order to work."   If they are only 1
DNA site (MAPS for example), then this will critical some issues that need
to get worked out.  So at this point in time,  CSV is put on the back
burner.

I think overall, it will continue to have this DNA stigma.  But I think we
can use CSA by itself.  The same applies to SPF for EHLO "True Negatives"
checks.   But SPF suffers from its relaxed provisions.  SPF HELO checks can
only be TRUE or FALSE, not soft or neutral.  It is not logical.

Sincerely,

Hector Santos, CTO
Santronics Software, Inc.
http://www.santronics.com
305-431-2846 Cell
305-248-3204 Office


----- Original Message -----
From: "Douglas Otis" <dotis(_at_)mail-abuse(_dot_)org>
To: "Matthew Elvey" <matthew(_at_)elvey(_dot_)com>
Cc: "MXCOMP" <ietf-mxcomp(_at_)imc(_dot_)org>; "John Leslie" 
<john(_at_)jlc(_dot_)net>
Sent: Wednesday, September 22, 2004 11:44 PM
Subject: WG to close ; Re: Make CSV backwards compatible with SPF? (new
revisions)



On Wed, 2004-09-22 at 17:16, Matthew Elvey wrote:

The goals were obtainable, but obviously not in the time frame alloted.
Perhaps diligently expressing concerns with various aspects of using
script within DNS, I deserve a fair amount of the blame for this
failure.  Some still see this as a wonderful innovation however.

When submitting CSV to the graybeards, DNS security was a primary
concern and they requested ensuring a random port was an added security
consideration.  A technical review was not something SPF/Sender-ID
advocates desired.  Not wanting to point out problems without offering
solutions was the motivation for creating the MPR draft.

Recognizing where a suite of protocols are weak and working on these
problems seems more fundamental than creating new features or complex
impediments when knowing every chink will be exploited.  These concerns
seem to pale when compared to promises from a large company destine to
change the landscape.  It is also ironic, as this type of amorphous
scripting in mail has largely caused the current situation.  Although
the goals were relatively well defined, there was still an ongoing
debate whether this was actually to prevent spam, spoofing, phishing or
whatever seemed to "fit" the solution touted.

SMTP is a well crafted battle-scarred solution with a few odd bits
broken.  The EHLO name, acting as a type of post-mark is an obvious
example of something broken ever since machines used more IP addresses
than fit in a DNS query.  I know by being outspoken, this has been a
disappoint to Dave Crocker.  Both Dave and John Levine deserve a great
deal of credit for having a great deal of understanding in both the
inter-operation of the protocols and the IETF.

And now more of the same...
In a simple environment exchanging messages end-to-end, the risks
would
be low.  There are risks accepting these types of records when a
process
walks through redirects, includes and arbitrary labels for several
record types.

Huh?  The question is about the record given, which has none of these
problems.

There is a good overview here.
http://www.securityfocus.com/guest/17905

I conclude from your statement that given the proposed record, foo.com
would be pretty safe from being blacklisted by an SPF reputation
service.
I don't see a specific example of what would lead a reputation service
to blacklist foo.dom that could not befall a CSV system.
Do you claim a server running CSV (and not using DNSSEC, of course) is
not vulnerable to a poisoned cache?

By limiting the mechanism to a single DNS lookup to a single DNS server,
the exposure is much less.  The goal and results are the same, the
structure of the lookups are different.

For what it is worth, SPF "requires" more than a single record be read
perhaps from many different DNS servers.  This opens a sizable can of
worms.  This creates a setup for an attack, especially when needing a
parser to process the records.  A "safe" record is thus not as safe
owning to this.  Yes, the simple record in your example itself would not
have been useful for such an exploit.  The danger lies in the general
requirement to explore many different domains to resolve an address list
being compiled.  This problem vanishes had the list been of names rather
than addresses.

As I said in private email, I'm trying to nail down as mainstream an
example as possible.  I can't think of one, given this record.

Given a record *without* -all, or with entries like ?comcast.net, I can
see how a domain could well get blacklisted.

Few large organizations would wish to deal with the results of full
fledged SPF and closed records.

<snip>
The label used to select the SPF record is normally based upon the
mailbox domain to select a full set of outbound MTAs.  The EHLO name
can
be made to match any such mailbox domain provided one of the machines
is
permitted in this SPF record set.  This would be bad.

I asked for an example.  I see no example here.  I can't extrapolate
from what you have said to come up with an example, either.
Perhaps you're avoiding providing one.

Example: Mailbox.tld has SPF records that define the entire address
space for three of their providers where they outsource some of their
mail, and their own.  I contend reputation should be based upon what you
have control over.  That would mean it would not be to your advantage to
include the machines of these other providers in a reputation
assessment.

mailbox.dom spf cidr isp1, cidr isp2, cidr isp3, cidr for self.

ehlo.dom spf cidr for self

A compromised host in one of the ISPs or even perhaps some clever shell
program issues EHLO with mailbox.dom rather than the intended ehlo.dom.

The advantages of using this common DNS script structure vanish when you
wish to limit your exposure for EHLO reputation assessments.

<snip>

One, you want to use existing SPF records that were not intended to
provide the narrow selection of machines administered by the MTA
operators.  Two, there is no means to restrict this list after the
fact.

1) Sort of.
2) Nonsense. We ignore records or record components that don't meet our
   rules.
Would you argue that there is no means to restrict a CSV "Client SMTP
Authorization SRV Record" from having illegal values (e.g. a Weight of
8)?

The rules that accept only closed SPF components still do not achieve a
goal of assessing only the administrator accountable.

<snip>

Your approach was to prune the record set used just for the EHLO
domain.

I don't think so.  It's not clear what you mean by that, so I'm not
sure, but your sentence doesn't make sense to me; I don't know what
you're trying to say.

Just removing open elements will not achieve the desired goal as it does
not provide the same set.

That pruning can not differentiate between machines within a
delegated domain or machines within the administered domain. This
would
be bad.

I don't see where I'm saying something from which one could conclude
that a record for aol.com would be non-differentiable from one for
dhcp234.234.dialup.aol.com.

SPF does not have the concept of administrative versus authorized.
There is nothing in the syntax that would allow the differentiation.  In
addition, the EHLO name can express any label to select any record.

Once the IETF has expended their considerable efforts to endorse a
method that is well considered and robust, I doubt there will be any
trouble with the adoption of the standard.  The problem of spam is
that
great.

Certainly, if those things are all true, then the following is true as
well.  Todays events suggest otherwise.

Today is not a stellar day.

<snip>

Sorry, but I fail to see the point in using a TXT record and a parser
to
obtain a list of addresses through a dangerous and expensive set of
lookups, when it can be done in one lookup safely.  Also where it will
not accidentally allow other domains to spoof the EHLO identity.  This
exclusion is needed to establish accountability.

I have not suggested a dangerous or expensive set of lookups.

It is my opinion these DNS scripts are dangerous from the standpoint of
both security and network integrity.

I have not not suggested a scheme that would readily allow other domains
to spoof the EHLO identity.

By attempting to reuse the same SPF records for both EHLO validation and
the mail channel authorization, this exposes the EHLO reputation to a
larger set of MTA servers.  Labels to these records is not a means to
prevent their use for either purpose.

I even asked you to provide an example disproving this and you were
unable to.

The line from Cool Hand Luke comes to mind.  It is not because I have
not tried.

-Doug