[ietf-dkim] Re: SSP + SPF records in DNS
dotis at mail-abuse.org
Tue Jan 15 12:10:42 PST 2008
On Jan 14, 2008, at 9:57 PM, Frank Ellermann wrote:
> Douglas Otis wrote:
>> Per the current SSP 41 byte string of "v=ssp1 dkim=strict
>> handling=process t=n:s" a total of 54 bytes is needed
> IIRC I counted only "dkim=strict handling=deny" when I wrote "25",
> but the syntax could be trimmed if necessary to squeeze this info
> into another RR elsewhere with its own size limitations. So far
> nobody thinks it's necessary, but we're not yet ready with Dave's
> two related issues.
The v=ssp1 and 13 bytes were added since you suggested this
information was within a separate RR. The t=n:s was added for
>> When more than two different protocols utilize the same TXT RR and
>> location, newer versions are unlikely to remain viable.
> Yes. On the "SPF devel" list folks discussed that the UDP limit
> will be soon anyway obsolete (= not good enough for IPv6).
What is your estimate for "soon"? Keep in mind, truncated responses
are not problematic for all portions of DNS infrastructure.
>> SPF has an exp mechanism to fetch a macro expanded messages that
>> could be added to a DSN.
> ACK, with that you can get 113 as worst case. JFTR what that
> means: A receiver tried q=SPF (TXT), and after getting nothing
> q=TXT (SPF), or some variation counting as 2 queries. After that
> the sender policy contained 10 mx mechanisms (or 9 mx + 1 ptr), more
> would hit a MUST NOT, so we are at a total of 12 queries. Each mx
> (or the ptr) stays at the limit of 10 names, more hits another MUST
> NOT, for at total of 112.
I never used this as an example because such an attack seemed
unlikely. The critical aspect is 10 to 100 new and different DNS
transactions may occur from cached SPF records when receivers expand
SPF macros for each email-address evaluated. More than one evaluation
may occur per message. When evil SPF records are cached, an
attacker's resources are not being expended.
> After that the final outcome is FAIL, therefore the receiver could
> fetch an exp= modifuer record arriving at 113 queries. An exp= does
> not hit the limit 10, because reporting a given FAIL is more
> important than whining about the 11th exp= query.
> I certainly agree that a policy with 9 or 10 mx can't be sound.
The expansion of macros is where SPF becomes extremely dangerous.
Macro expansion permits a resource free attack to be trigged by spam's
email-addresses. The most dangerous of these macros are those
expanding components of the email-address local-part. By leveraging
the local-part, attacks do not need to wait for negative caching to
expire before recycling targets. Botnets are dangerous even at a gain
of one. SPF provides botnets a reflective attack mechanism that is
not dependent upon the attacker's resources, and that can not be
mitigated with BCP 38 or ACLs. : (
> The intention in RFC 4408 is to make these limits very simple to
> understand (count to ten, no matter what), and to arrive at reliable
> limits (for sound non-attacking policies), i.e. if a policy violates
> these hard limits all SPF implementations are supposed to treat it
> as broken (PermError).
The original recursion depth of 20 records containing any number of
mechanisms was so absurd, it made a 10 mechanism limit for some seem
better than it was. In addition, SPF time-outs were not well
specified and do not ensure outstanding DNS operations conclude before
> It wasn't the intention to sanction "9 or 10 mx" as remotely
> plausible: For starters that would be at odds with a general SHOULD
> following the three MUST NOTs for "ten". I said this before, it's
> perfectly okay if 4408bis introduces additional limits. As long as
> implementors understand what the purposes are (not only anti-DoS,
> also reliable PermError) it's fine.
Keep in mind, IP address path registration strategies are applied to
more than just the MailFrom. Some check IP address path registration
for the PRA, in addition to the MailFrom. Macros provided by SPF
necessitates an entire process be restarted for every email-address
evaluation, even for those within the same domain. Whatever limit
that is placed upon an IP path registration process, this must be
multiplied by all possible evaluations. MailFrom, PRA, and two or
three DKIM signing domains might then increase SPF transactions by
factors of 2 to 5.
>> The macro expansion of SPF records to evaluate DKIM related email-
>> addresses must be avoided.
> SPF could offer an SSP-shortcut anyway *IFF* that makes sense for
> enough receivers supporting both.
SPF could be avoided entirely by adopting TPA-SSP. TPA-SSP can scale
using a single transaction and is easier to manage than:
2) sharing of private keys
3) delegation of domains
>>> the limit of 10 names per mx-mechanism is a hard RFC 4408 limit,
>>> it is no limit of "MX records themselves".
>> However, size constraints of MX responses provides roughly
>> comparable limits.
> Yes, that is how Wayne (the co-author) arrived at this "ten", and we
> were aware that some domains have as much as eight MXs.
However, Wayne imposed a default limit of 5 host-names per MX to limit
DDoS in his library. This strategy causes erratic problems for some
domains, especially when subjected to default SPF records. : (
>> It is also unlikely that call back verification will rapidly
>> attempt to resolve all MX targets that are within different domains.
> CBV is used for the decision to accept a given MAIL FROM, it has to
> be fast (within the relevant timeout of the SMTP client).
CBV mechanisms often employ both low and high level result caching.
CBV use of MX records is also be limited to the number of email-
address evaluations. CBV evaluations consume an attacker's resources
and allow an attack of about a 10x amplification where the MX domain
is contained within email logs. Alternatively, SPF allows an attack
that does not consume an attacker's resources, and where email logs do
not indicate the MX domain. Unfortunately, SPF can also provide a
magnitude of attack orders of magnitude greater than the spam traffic
being used as a trigger. Spam traffic occurs whether or not it is
used to trigger an attack.
>> It would appear DKIM helps solve your concern about forwarding.
> My concerns are somewhat limited to "I got one pseudo-551 caused by
> an SPF FAIL after traditional forwarding since May 2004", and I'm
> not aware of any case where MAIL FROM me vanished in a black hole
> for the same scenario but accepting FAIL as "suspicious".
The concept was to ensure valid DSN are received, and that invalid DSN
are dropped without reliance upon IP address path registration.
> Of course others consider this as serious problem. Likewise I'm not
> much concerned about DKIM's potential mailing list issues, and for
> SSP the caveat is clear enough.
The goal of TPA-SSP was to ensure DKIM addresses are not also checked
using an IP address path registration scheme. TPA-SSP would be one
transaction, whereas SPF could be order of magnitude more.
>> I am in even in favour of eliminating acceptance when there are no
>> MX records.
> If that flies (as a future common practice) describing it in an RFC
> would be simple. For the other way around, an attempt to introduce
> it in an RFC, I doubt that "they" will let you try it. But I like
> the idea (outside of 2821bis).
Agreed. As additional email related policies are added, an MX record
requirement offers a safe solution. IMHO, DKIM should be able to make
this assumption for any signed message, at least.
More information about the ietf-dkim