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