Douglas Otis wrote:
[Julian wrote:]
you seem to be completely missing Frank's point.
Indeed, the v=ssp1 (or similar) idea might help with
_some_ (by far not all) of Dave's objections against
the current SSP draft, and needs precisely the same
number of query=spf to get a v=ssp1 record as the
current draft. Not 10, not 100, only _two_ queries.
Eric said that _ssp._domainkey.dom.example is good to
keep the administration of _domainkey.dom.example and
the corresponding _ssp._domainkey.dom.example in one
hand, with that the v=ssp1 idea is at best "plan B"
IFF the current _ssp._domainkey plan is rejected.
Two objections against _ssp._domainkey I have in mind:
1 - It's not trivial in conjunction with wildcards
2 - Queries waste bandwidth and are pointless without
significant deployment (i.e. _ssp publishers).
Of the small minority of domains publishing SPF records,
99.98% of these domains publish _only_ TXT RRs.
Everybody knows that query=spf in practice still means
"query=txt and don't panic if query=spf causes errors",
and that won't change for some years. It would be the
same if SSP is forced to share "type 99".
These records typically contain CIDR listings of IP
addresses encompassing the SMTP clients.
That's irrelevant for SSP. Sharing "type 99" might help
with the two objections against _ssp._domainkeys listed
above assuming that that turns out to be necessary.
I don't say that I *support* these objections - Eric's
argument pro _ssp._domainkey is also very plausible.
A realistic estimate of the text based CDIR payload
might be about 140. These CIDRs must span both IPv6
and IPv4 ranges.
I guess you're now again talking about SPF records, but
I've no clue what "140" might be. ip4:127.0.0.1/24 for
a /24 is 16 bytes, for IPv6 it would be somewhat longer.
For a/24 (IPv4), a//32 (IPv6), or a/24//32 (dual) it's
shorter. Did you count 20 bytes in a:example.org/24//32
and then replace 11 for example.org by 130 to get 140 ?
Some libraries limit MX/ hostname cascades to 50 CIDRs.
There are no "cascades" in SPF, let alone in SSP, and if
a pre-MARID SPF library doesn't implement the post-MARID
RFC 4408 file a bug report, use a fresher implementation,
fix it, or hire somebody to fix it.
Why should DKIM only use type 99 RRs
See above, SSP might if forced, not DKIM.
[Is it]
really wise to invite unrelated TXT resource records
into this congested location, already (ab)used by a PRA
evaluation process?
PRA doesn't look at v=ssp1, nobody with an IQ above zero
uses PRA looking at v=spf1, and pro-PRA arguments for its
spf2.0/pra are limited to "plausible after an erroneous
decision to ignore the envelope sender address" (and then
IMO more plausible than SSP's "first author" approach).
I can't tell how many "type 99" (or rather corresponding
TXT) record users don't have 25 bytes for SSP directly, I
can't tell how many would be willing to pull spf2.0/pra
as "nice try, but now it's over" in favour of SSP, and I
can't tell if 25 is realistic: RFC 5016 4.7 and 5.4 (2)
claim that 25 is not good enough. OTOH a future SSP RFC
is free to obsolete parts of the informational RFC 5016.
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.
If you don't ignore it you get 112 instead of 111. I've
no idea what reporting records are. The 111/112 affects
receivers wishing to evaluate an SPF policy with 10 MX
mechanisms, each with 10 names. For receivers wishing to
evaluate only v=ssp1 that's irrelevant, admittedly they'd
need both query=txt and query=spf for some years.
Again, this is a "plan B" if the two objections against SSP
at _ssp._domainkey listed above turn out to be bad enough.
I can't tell if that's the case.
Rampant SPF evaluations can result in a devastating attack
completely free for spamer/attacker.
In your scenario the attacker (not a spammer) maintains the
MX records, each with 10 bogus addresses of the victim. It
is 1 query=mx to the attacker for 10 query=a to the victim,
that's cheap but certainly not "completely free". Your idea
to use various MX records selected by different local parts
would stabilize this 1:10 amplification, for less traffic on
the attacking NS they'd stick to their evil MX records.
Now that we have discussed it again also on this list let's
drop it *here*. A future 4408bis will have to fix the MX
issue if needed, it's simple enough. E.g. limit the mx per
record to one, deprecate mx in favour of include, or limit
the number of NXDOMAIN - in fact a SHOULD in RFC 4408 can be
implemented by limiting NXDOMAIN as noted on the page cited
by Julian (see the last paragraph of the rebuttal, "a viable
void-lookups limit for SPF might lie between 2 and 5.")
http://www.openspf.org/draft-otis-spf-dos-exploit_Analysis#rebuttal
The FUD is an attempt to increase awareness of risks remaining
within the SPF protocol.
We are aware of it, and "interoperability and implementation
reports" should IMHO state *how* they implement the relevant
RFC 4408 SHOULD.
SPF leverages MX records, where MX records themselves offer
a moderate amplification of about 10.
No, the limit of 10 names per mx-mechanism is a hard RFC 4408
limit, it is no limit of "MX records themselves".
SPF permits references to MX record to be based upon labels
generated by macro expanding email-address local-parts. : (
One fresh malicious MX triggered per mail is enough to get an
MX amplification, that you insist on using local part macros
for this attack is IMO irrational. I'm no fan of SPF's local
part macros, they are odd for UTF8SMTP, and messy for quoted
strings with leading / adjacent / trailing dots, but they are
not essential for an attack scenario.
Normal use of MX records will seldom cause all hostnames to
be resolved at once when in different domains.
"Call back verification" is an example of no "normal use" -
spammers have a reason why they forge "plausible" MAIL FROMs.
spam enabling the attack is still accepted by appending a
"+all" or its equivalent as the final SPF mechanism.
The attacker isn't interested in delivering spam, that could
help to locate the NS of the attacker. Your idea to run a
DoS attack and a spam campaign simultaneously is irrational.
Several proponents of SPF remarked they think DNS is broken.
RFC 1123 broke responsible SMTP forwarding, and it's kind of
odd that determining a DNS zone cut doesn't work, if that's
what your're talking about
This DNS oddity resulted in CSV's tree walk, it might affect
the current SSP proposal, but SPF can do without it: It's
*unnecessary* to protect domains when they have neither an
MX nor an address with an SMTP server. It's *possible* but
not *necessary* - forging such addresses makes no sense for
spammers, such addresses are "implausible", they fail in a
"call back verification".
Frank
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html