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

[Julian Mehnle]

Douglas Otis wrote:
> On Dec 30, 2007, at 7:15 PM, Frank Ellermann wrote:
> > 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?

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.

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!

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 summa- 
rize the SPF project's conclusion as follows for the benefit of others:

> > 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:

http://www.openspf.org/auth/draft-otis-spf-dos-exploit_Analysis#rebuttal
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://mipassoc.org/pipermail/ietf-dkim/attachments/20080102/3d714c01/attachment.bin