On Nov 10, 2008, at 1:36 PM, Dave CROCKER wrote:
Scott Kitterman wrote:
Doug: I know you disagree with that conclusion, but I'm not going
to argue it again.
Scott,
That's a good start, but you need to follow-through on the idea:
There is nothing productive in this thread.
If there is anyone other than Doug who believes, rather, that
it is important to pursue, please speak up and explain why and how.
Dave,
Agreed. The rebuttal to the otis-spf-dos-exploit remains flawed. It
omits any careful review of the local-part macro issue, and the 100
transactions per name needed to resolve target addresses. This
concern is wrongly compared to a chain of bogus NS records within an
evil domain. The operation of NS records represents an area that the
DNS protocol controls in ongoing refinements. SPF represents a
sizable diffusion of applications as MTA milters and MUA plugins that
are often poorly supported. These applications are well beyond the
purview and ability of the DNS protocol to control when there is a
need to mitigate its possible exploits beyond outright blocking of SPF
records.
Glossing over threat details represents very dangerous subterfuge when
SPF is being likened to just another area where DNS might be
exploited. While SPF proponents would like to think Sender-ID will
not utilize the same records, this is of course not realistic. Local-
part macros were demonstrated in the otis-spf-dos-exploit draft as a
possible means to stage progressively much higher gain attacks. The
trace of resolving a single SPF name included in the exploit document
was generated by a compliant SPF parsing library in common use at the
time. One SPF verified message induces from 500 KBs to 1 MB of
reflected DNS traffic starting out at 10x network gain, that can then
progress into gains that exceed 300 times that of the spam traffic
feeding the exploit. Techniques that were not covered can further
amplify the level of this attack vector.
Mitigating this free attack is rather simple. Obsolete the use of the
local-part macros. The issue of local-part addresses remains relevant
to the Authentication-Results header. This header includes the email
local-part as having been authenticated. Even the experimental
RFC4406 stipulates that the local-part is NOT verified by the
authorization process. The Authentication-Results header MUST NOT
include unverified data as having been "authenticated", ( in the case
of SPF and Sender-ID, as having been authorized which should be so
stated).
SPF can be made much safer by obsoleting a seldom used local-part
macro. Why not? Removing the local-part from the Authentication-
Results header for Sender-ID or SPF would ensure no one should expect
to make use this ill considered local-part macro expansion feature.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html