mail-vet-discuss
[Top] [All Lists]

Re: [mail-vet-discuss] draft-kucherawy-sender-auth-header and last call draft-hoffman-dac-vbr-04

2008-11-10 21:11:06

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 

<Prev in Thread] Current Thread [Next in Thread>