|
Re: [ietf-dkim] Re: SSP + SPF records in DNS
2008-01-02 17:01:36
On Jan 1, 2008, at 4:04 PM, Julian Mehnle wrote:
Douglas Otis wrote:
On Dec 30, 2007, at 7:15 PM, Frank Ellermann wrote:
I proposed to put the SSP info into a separate DNS record in the
existing SPF RR set. You don't need to look at any v=spf1 or
spf2.0/* record after a query=spf, you'd look for the v=ssp1 record.
Original proponents failed to limit per message name evaluations.
What prevents DKIM misuse when SPF includes DKIM policy? Why
wouldn't a DKIM specific domain be evaluated using SPF, and seen as
analogous to that of the PRA?
First, you seem to be completely missing Frank's point. In the
above he is talking about sharing the "SPF" (code 99) RR typespace
among v=spf1/spf2.0 and v=ssp1 records, not about applying any
v=spf1/spf2.0/v=spf3 semantics to SSP or DKIM.
Of the small minority of domains publishing SPF records, 99.98% of
these domains publish _only_ TXT RRs. These records typically contain
CIDR listings of IP addresses encompassing the SMTP clients. These
SMTP clients are thereby authorized to issue messages containing the
email-addresses passed to the SPF processing routines.
However, SPF lacks a means to select a subset of IPv4 or IPv6
addresses. A realistic estimate of the text based CDIR payload might
be about 140. These CIDRs must span both IPv6 and IPv4 ranges.
Cascading MX/hostname RRs is limited to 100, depending on limits
imposed upon the hostname resolution process. Some libraries limit MX/
hostname cascades to 50 CIDRs. Any additional RRs placed at the email-
address domain reduces overall CIDR capacity due to the RR property
overhead, in addition to the RR content. In addition, (as if this
would ever happen) any versioning of SPF/PRA records _MUST_ also
occupy the _same_ initial location.
Why should DKIM only use type 99 RRs, when the DKIM WG would not
consider a new RR acceptable? Essentially no one is using RR type 99
now. Any overhead reduction, albeit with larger payloads, is to be
found by leveraging TXT RRs. It it really wise to invite unrelated
TXT resource records into this congested location, already (ab)used by
a PRA evaluation process?
Second, your analogy (which as I said misses Frank's point) to the
re-use of v=spf1 records for PRA evaluation (as propagated by
Microsoft) is broken. Even if some v=spf3 came along and defined a
new "dkim:" mechanism, there would be no general risk of confusion
whatsoever with a separate SSP record scheme, because any additional
and potentially conflicting semantics would be entirely up for
domain owners to declare!
Each email-address evaluation may require processing an entire SPF
record set. This set may span as many as 111 resource record
transactions, ignoring checks for TXT or type 99 and reporting
records. Subsequent processing of any different email-address, even
within the same domain and message, may again span another 111
transactions. Complete reprocessing is needed to support expansion of
macros contained within SPF records. Any suggestion SPF should
include DKIM policy greatly increases the risks related to SPF
exploits that might then leverage the additional evaluations of DKIM
specific email-address. The risk caused by the number of DNS
transactions employed, and a bad actor's ability to cache their
attack. More than 20% of domains override negative caching to
intervals less than an hour. Rampant SPF evaluations can result in a
devastating attack completely free for spamer/attacker. MTAs
employing SPF are unlikely to detect when an SPF exploit is progress,
nor will forensics of MTA logs be of much use. An attack, free in
almost every sense.
IOW, if a domain owner published some "v=spf3 dkim:..." record
according to whatever specification of v=spf3 or "dkim:", it would
be that domain owner's decision. The problem with the v=spf1/PRA
fiasco was that the Sender ID specification (and any implementations
thereof) did NOT leave it up to domain owners what their existing
v=spf1 records were supposed to mean.
I am not going to discuss the details of your FUD about SPF being a
threat to the livelihood of DNS and the internet as a whole, but let
me summarize the SPF project's conclusion as follows for the benefit
of others:
The FUD is an attempt to increase awareness of risks remaining within
the SPF protocol. After all, DDoS are expensive for the victims. : (
OpenSPF's dismissed SPF transactional exploitation concerns based upon
a bad actor's ability to also exploit DNS NS records? Their example
exploit was to return a bogus NS list misdirecting DNS transactions to
other servers. Their example somehow dismissed concerns related to
the traffic generated by SPF's per message/MTA/MUA/recipient
evaluation of a PRA and MailFrom email-address. SPF still allows bad
actors to exploit both SPF _and_ other resource records in tandem.
OpenSPF expressed a rather callus lack of concern regarding their
disabling of DNS congestion avoidance, allowing attacking records to
be cached and then generate random queries, or to the very distributed
nature of their mechanism. SPF provides bad actors a tool that can be
used for staging DDoS attacks, and even poisoning DNS itself. This
exploit is beyond being controlled by firewalls, ACLs, and even
universal implementation of BCP38. : (
Let's say that there are still more pressing problems with DNS
attacks than your idea to abuse SPF to query addresses in ten MX
sets.
This concern extends to macro expansions using the local-part of
the email-address. It is extremely difficult to determine whether
a DDoS had been sourced by SPF.
And that determination is of academic interest at best, because
there are indeed other ways for DNS-traffic-based DoS attacks that
are just as suitable as, if not more than, SPF:
SPF leverages MX records, where MX records themselves offer a moderate
amplification of about 10. SPF limits the number of different MX
records employed to 10, and the resolution of subsequent hostnames to
10 each (10 x 10 = 100 transactions). However, SPF permits references
to MX record to be based upon labels generated by macro expanding
email-address local-parts. : (
Normal use of MX records will seldom cause all hostnames to be
resolved at once when in different domains. Hostname resolution is
normally interspersed with attempts to contact the host, after all.
SPF MX records represents a different situation. Addresses resolved
might have a CIDR mask applied and then immediately compared against
the IP address of the SMTP client. In other words, the SPF MX record
is not used to locate a receiving host, and lacks the typical
processing impediments.
SPF/Sender-ID also does not impose reasonable transactional limits
when considering how these active records might be abused. Once
attacking records have been cached, a spammer/attacker can recycle at
no additional resource cost to them, once their campaign extends
beyond a negative caching interval. An interval often inappropriately
limited by receiving domains. An attack with a gain of 10 using MX
records then transitions to a gain approaching infinity, since spam
enabling the attack is still accepted by appending a "+all" or its
equivalent as the final SPF mechanism.
SPF records might be processed by routines taking shortcuts that fail
to impose even recommended transactional limits. However, SPF also
recommends starting evaluation of a different record set while still
within a DNS back-off interval. Not waiting protects an MTA receiving
process, very much at the expense of the DNS protocol.
Several proponents of SPF remarked they think DNS is broken. DNS is
clearly not well suited for returning massive address lists, at
least. Path registration, if desired, should have been done by-name,
in a manner far more compatible with DNS.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
|
|