Re: [ietf-dkim] Re: SSP + SPF records in DNS

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  
completeness.
> > 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  
continuing.
> 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:
 1) SPF
 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.
-Doug
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html