Re: [ietf-dkim] SSP + SPF records in DNS (was: New Issue: Do we need SSP

On Dec 30, 2007, at 7:15 PM, Frank Ellermann wrote:

> Douglas Otis wrote:
>
> > DKIM requires acceptance of the message body.
> Obviously.  Receivers will still reject messages before DATA where  
> that makes sense from their POV, e.g. because they use services  
> explained in the ASRG SIQ and DNSBL drafts, or in the ASRG LMAP  
> draft, i.e. what is now RFC 4405 and RFC 4408.
Schemes based upon IP address path registrations create email delivery  
problems.  Even heavily phished domains publish open-ended IP address  
record sets.
> Hector's SMTP HEAD draft offered a kind of compromise between before  
> vs. after DATA, but it won't help with DKIM, and it's not clear how  
> to combine it with the "selective reject" I-D.
This header first mechanism could permit validation of DKIM signatures  
prior to the acceptance of the message body.  The signature's  
parameter bh= captures the canonicalized body part.  : )
> > DKIM's ability to offer reliable indications of misbehaviour will  
> > bolster that of content filtering results.
> DKIM without SSP (or similar) doesn't have such ability.
Without SSP, DKIM can prevent false positive detection of spoofing for  
heavily phished domains.  While SSP could help automate anti-phishing  
efforts, the message body still requires analysis.  Often deception of  
the recipient is not dependent upon a spoofed email-address.
> > DKIM can help overcome problems created by the unreliable  
> > application IP address path registration strategies.
> DKIM doesn't come near to the envelope sender address, we made sure  
> that it doesn't depend on SMTP.  Backscatter is mainly an SMTP issue  
> (+ RFC 3798 + 3834 + sieve vacation).
Without depending upon _any_ IP address path registration, a single  
TPA-SSP query can indicate whether a signature is authorized, and  
whether a signature is required for MailFrom.
> > DKIM can prove helpful at restoring integrity to SMTP, even after  
> > the dot. : )
> DKIM operates on messages (SDU, 2822), not on envelopes (PDU,  
> 2821).  You can use DKIM on the other side of a UUCP link if you  
> have access on DNS, or whereever you find a "fresh" message/rfc822  
> (e.g. as MIME part), it's not based on SMTP.  For various reasons  
> DKIM does *not* try to solve the SMTP issue backscatter.
TPA-SSP, in one small DNS transaction, mitigates a DSN problem by  
leveraging DKIM's ability to avoid path registration problems.
> > The "everything at once" approach represents a potential overhead  
> > that can well exceed that of accepting messages.
> Receivers are free to say "enough already" when it pleases them, in  
> fact they MUST and SHOULD do this (RFC 4408 10.1).
Evaluation libraries for SPF do not return the amount of DNS traffic  
generated, and many even fail to impose recommended transactional  
limits.  Danger is increased by opening up SPF evaluation to more  
names per message.
> IMO "a", "all", "include", "ip4", "ip6", and "redirect" are  
> essential for a simplified SPF.  The "ptr" is no problem, the  
> Authentication-Results I-D offers a similar test with similar  
> processing limits.
Allowing bad actors to link a succession of resource record  
transactions for each evaluation from any domain represents an unusual  
risk.  Resolving IP addresses for each host discovered, or expanding  
macros based upon various components of an email-address local-part  
significantly increases these risks.  When IPv6 comes into greater  
use, a minimum number of transactions may need to increase. : (
> The "exists" is rather exotic at the moment (in theory SES is a nice  
> idea), and tossing %{l} out, or maybe limit "mx" to at most one per  
> record, because the original RMX idea makes sense, might be possible  
> in a 4408bis.
DNS is designed to return short lists of host names, or IP addresses  
of a host.  Returning all IP addresses employed on behalf of a domain  
breaks this architecture, as illustrated by premature time-outs of SPF  
transactional sequences.  The premature time-outs disable critical DNS  
congestion avoidance.  Path registration by-name could have safely  
leveraged DNS name hierarchy.  A list of authorized parent domains,  
combined with something like CSV, could avoid the dozens or even  
hundreds of sizeable DNS transactions now imposed by the SPF  
evaluation process.
Nevertheless, DKIM is _not_ about IP address path registration.  DKIM  
even avoids IP address path registration issues!
> Nobody is going to learn new TPA-SSP tricks from scratch, unless you  
> go to draconian simplifications like "nobody must send from an MTA  
> to an MX of a 3rd party, when that MTA isn't listed as MX of the  
> sender".  This just won't fly, no matter how long we could argue  
> that it's the idea of an STD 10 "MX" - I'm not even sure that it's  
> the case.
With TPA-SSP, spoofing of MailFrom is mitigated before a DSN is  
considered.  At any point in time, there are more than 30 million  
sources of DSNs issued to MailFroms spoofed at legitimate MTAs.  TPA- 
SSP allows MailFrom domains to either validate or invalid an  
association with DKIM signature, in the same manner used for From  
headers.  Instead of the From header domain, the MailFrom domain is  
queried.
> > reliance upon unreliable IP address path registration can and  
> > should be avoided.
> Without time travel and removing RFC 1123 5.3.6(a) before it was  
> published all you can get is "BTNRP", better than no reverse path  
> (i.e. SPF).  If some senders get their "permitted IP enumeration"  
> wrong that is no problem for receivers, it's a problem for these  
> senders, they fix it.
> [MS issue with new RR types]
DKIM, by using TPA-SPP, can mitigate DSN problems and remain compliant  
with RFC1123 5.3.6(a).  SPF/Sender-ID can not.
> > MS might even view demise of DNS an advantage, as their alternative  
> > is heavily patented.
> Sometimes they're forced to adopt standards if they don't want to  
> lose market share.  Does this issue still exist in Vista, or does it  
> only affect XP and older MS platforms ?
An alternative MS name space was introduced with Vista, and upgraded  
XP.  RPC/DNS translations are at network boundaries and involve both  
reading and publishing.  The latest MS DNS 2003 warns against  
publishing unsupported RRs, (MS DNS represents less than 3% of  
Internet Name servers).  About 1 in 5 domains with a name server  
publish SPF TXT records, and of these, about 1 in 50,000 also publish  
newer 99 RRs.
> > Concerns remained regarding enterprise support of new RRs.
> We all know that the SPF RR has an "MS-compatible" sibling.
>
> At the moment "sender policy framework" stands for "we can do  
> 'sender permitted from' or even 'purported responsible address', and  
> HELO", not much for a wannabe-framework.  It is kind of obvious to  
> add SSP *IFF* it fits.
SPF/Sender-ID assertions pertain to IP address path registrations and  
not to DKIM signatures.  DKIM specifically avoids relating a IP  
address path to that of a DKIM signature.
> RFC 5016 tries to make sure that it won't fit (5.3 point 5), but IMO  
> nobody cares about cryptic abbreviations in a text-like DNS  
> record.   Of course it is good to use readable and/or intuitive  
> terms while talking about such abbreviations... :-)
A rather fundamental reality of the original 576 byte assured MTU and  
the 512 byte DNS message size is being ignored. : (
> > SPF now demands at least 10 linked records be permitted for each  
> > name validated.
> You can have *at most* 10 "redirect".  As you well know, I deleted  
> various synonyms for "intentionally telling what is known to be not  
> true".  If you eat up the overall limit 10 for "redirect" you have  
> no "a", no "mx", no "include", etc.  The "redirect" is a v=spf1 and  
> spf2.0/* feature, adding SSP to the SPF RR introduced by say v=ssp1  
> would define its own syntax, for 25 bytes it doesn't need a  
> "redirect" feature - it would need the 25 bytes in the RR set  
> (shared with SPF).
A chain of SPF records supports bulky manual IP address lists.  Each  
chain may also include a reporting record and subsequent IPv4/IPv6  
address resolution transactions for the included hosts.
> > The impact of IPv6 may cause this sequence to be further extended
> Nonsense, with ten "redirect" you have at least 4500 bytes to  
> enumerate permitted IPs.  You can and should aggregate them to  
> CIDRs, it is no problem if you permit many IPs which are never  
> sending mail as long as they are your IPs or known to behave.
This over-states the available payload and the 10x chaining scheme's  
capacity to scale.
> Besides this "redirect" business has nothing to do with SSP:
>
> Assuming SSP does share the SPF RR, and that for a given SPF RR set  
> the v=spf1 and spf2.0/* records already use the UDP limit (~450),  
> then it would be necessary to split one of these v=spf1 or spf2.0/*  
> records with "redirect" to make room for the 25 bytes in a v=ssp1  
> record.  They could also decide that the PRA experiment is now  
> finished and pull the spf2.0/pra record to make room for v=ssp1.   
> After all SSP is supposed to be "better" than spf2.0/pra, isn't  
> it ?  Of course I'm not convinced that "1st author" is a sound idea.
Adding yet another mechanism to an already bloated approach takes  
unwise to a new extreme, especially as address diversity increases.
> > Using SPF to validate a DKIM domain in some manner might then  
> > impose this 10xplus sequence for each of several possible signatures.
> Nobody proposed to use SPF to "validate a DKIM domain in some  
> manner".  SPF validates envelope sender addresses, it allows "accept  
> and bounce" after a PASS.  SPF is for SMTP, not for DKIM.  If you  
> reject a SSP FAIL at your border you don't need SPF, neither the  
> protocol(s), nor the record(s).
> 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?
> > While not imposing change when consensus is not clear is  
> > understandable, a lack of a discovery record for assured acceptance  
> > can lead to serious DNS related risks.
> 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.  Adding more names to be evaluated further  
enables exploits to threaten major Internet interconnects.  In  
addition, these exploits enable DNS poisoning.  There would be no  
remedy or obvious symptom for this exploit.  Email logs would be  
unlikely to offer any clue without extensive correlation with that of  
DNS resolvers.
> RFC 4408 is still the only RFC I'm aware of mentioning that MX  
> queries can be an issue, with MUSTard and a SHOULD to mitigate it.   
> If that turns out to be not good enough 4408bis will have to fix it,  
> e.g. as noted above.
If path registration is still desired, a scheme using a by-name  
approach would require less effort, be easier to manage, and would  
ensure minimal transactional overhead that is not easily exploited.
Normal use of MX records will not require a comprehensive IP address  
list be generated.  To satisfy SPF, every IP address of every host  
name must be resolved.  SPF allows for 10 MX records in different  
domains.  Each MX record may contain as many as 10 host names.  The  
evaluation process must be fully repeated for each different email- 
address being evaluated within the message.  An evaluation process may  
need to be repeated two or three times per message.  The need to fully  
repeat an evaluation process is necessitated by SPF's macro expansion  
feature.  RFC4408 abuses MX records well beyond any other experimental  
protocol.
> > The entire email policy concept is affected, not just SSP or TPA- 
> > SSP.  The alternative for asserting policy without an assured  
> > discovery record is to walk the DNS tree for A or AAAA records.   
> > The lack of a specific discovery record represents a serious  
> > architectural extensibility defect for SMTP!
> Yes, that's what SPF is for.  Trying to "reinvent" it again is a  
> dubious plan, simplifying it is more attractive.
SPF is strictly about IP address path registration.

TPA-SSP makes _no_ assertion about IP address path registrations.    
TPA-SSP, unlike SPF, provides a means to safely associate MailFrom  
with DKIM policies.
SPF does _not_ offer this ability.  SPF already suffers from extremely  
dangerous feature bloat.  To preserve security, it is crucial that SPF  
not be extended with yet more mechanisms, or in anyway assert DKIM  
policies.
-Doug




_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html