On Tue, 2004-06-22 at 11:38, Hadmut Danisch wrote:
terry(_at_)ashtonwoodshomes(_dot_)com wrote:
Um, how does the complexity of XML improve security. I can think
of examples where XML enhancements CAUSED exploits, and there are
implementations where the XML implementation poses denial of service
exploit by sheer processing power needed for a full XML parser.
I do trust a parser generated by a parser generator or a common XML
library much more than any hand-coded quick and dirty SPF parser.
There is not automated parsing tool for SPF, and a syntax like SPF
invites for a quick and dirty implementation. Eats valid SPF records.
But that's how buffer overruns are generated.
Any mechanism introduced that stems the flow of UCE will be subjected to
intensive attack. Introducing a required series of DNS queries to
establish permissions increases a data footprint, but also code size may
also adversely impact system resources depending upon OS and structure.
If used in the normal fashion, no parser is required to utilize DNS
answers, so the introduction of a parser increases vulnerabilities. The
less rigid and more extensible the syntax, the greater the
vulnerabilities. As the allowable answer from DNS is small, any chained
records further increases vulnerabilities by increasing both resources
and time required to process a message.
An attacker "jamming" the checking mechanism might set up DNS servers
for domains they control that respond erratically and offer complex
record sets with small TTLs. The attacker then sends messages from
their domains in an attempt to exhaust resources as a means to have
recipients disable the checking processes within the channel. If on
average a small enterprise uses two outside services, then normally
there will be a need to chain these records as it would be prohibitively
difficult to administer otherwise. These outside vendors may in turn
also outsource for yet more chaining.
As example, a mail server is receiving 50 messages per second that
average 4 K bytes in size. If using the SPF/CID mechanism, checking DNS
data is indeterminate as there is no limit for the number of sequential
queries required to converge upon an answer. RFC1035 indicates 5 to 10
seconds should be considered a worst case resolver interval. If there
becomes an average of 10 queries with an average of 5 seconds a query,
then this limits each process to about 1 message about every minute.
These 10 queries will also add to the traffic at 350 bytes per record a
total of 4K bytes of additional traffic for a doubling of the network
load. The mail server may normally handle 1,500 simultaneous processes,
but at 60 seconds per process, the mail server is reduced to only
running 25 messages a second. This may still represent the same amount
of network traffic, just half as much mail gets through the network.
The concern for the process footprint becomes important as this will
impact the number of simultaneous processes able to run on these
machines. Should this mechanism only be usable at the MUA, there will
be no mitigation with respect to network traffic, as the MUA will
consume these same resources, invoke the queries, and even a valid
record does not offer assurance the mail is desired. All of this
checking will provide a marking scheme that may be inaccurate depending
upon the number of users sending from diverse access points, and still
possibly forged, especially if checking is moved to the MUA. If forced
into its strictest mode, it will cause complaints by forcing users to
offer a greater number of return addresses while at the same time
removing tools to consolidate the resulting diffusion of mail. The
recognizable return address becomes a thing of the past.
By insisting records sizes be 20% larger to handle future extensions
where version 1 code must accept any and all additional "unknown" data
added to the record invites uncontrollable growth of these records.
Should an MTA decide a series of 512 byte DNS records is not reasonable
because this addition, then those demanding extensibility will complain
such limitations are non-compliant with their "vital" need for something
else yet to be defined. The further this gets away from the immediately
confirmable information using standard DNS queries, the less likely
there will be any discernible benefit.
How is this a "single shot" at upgrading email? The SMTP protocol
has been evolving for a VERY long time.
That's nonsense. The SMTP protocol was evolving at a time where
the "Internet" consisted of a few hundred users and where e-mail was
just an experiment, where nobody complained if it didn't work for some
time. e-mail was a researchers game, not a highly relevant communication
medium. SMTP had time and chance to evolve.
But to follow your argument: How much time would you like to have for
SPF to evolve? 3 Years? 5? 10?
As they say, there is more than one way to skin a cat. An extensible
protocol does not need to use an extensible record. Mail is one of the
most often used applications. Any feature added should not risk
breaking both the DNS system as well as the application that it is
claiming to improve. If to stop abuse, aim directly at stopping abuse.
Attempting to lessen a technique may change the behavior of the abuser
but will do little else. In addition, any false assurances adds to the
risk of clients being duped with possible suits directed to those that
provided false assurances.
Interesting arguments on extensibility. All valid. Also all valid
for SPFv1 due to the fact that SPFv1 is extensible.
"Extensible"? You mean you can add new, unknown entry types. Is this
"Exensibility"?
Is it possible to add a time limit to an IP address without loosing
backward compatibility?
Can I extend an entry giving permission to the address 1.2.3.4 such that
it is allowed only during business hours, while keeping compatibility
with older version (which would give permission around the clock)?
What if I wish to add, e.g. cryptographic keys or jpeg images to the
records? What if an entry becomes 180,000 bytes long? Are you sure that
all SPF implementations will eat this without problem? No buffer limits?
Is SPF really "extensible"? Or is it just not well defined?
Is that what you call "Extensibility" more than just a gap in the
definition?
Extensibility is the road to never ending change, paved by marketing
hype, that soon requires complete replacement due to lack of foresight.
-Doug