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

Re: [mail-vet-discuss] Auth-Results installed base

2008-11-03 21:41:05

On Nov 3, 2008, at 2:55 PM, Tony Hansen wrote:

+1

Lisa, I think we can move on.

Why should the IETF endorse a scheme likely to endanger recipients?

The motivation for this header is in support of a questionable Sender- 
ID or SPF path registration scheme.  Sender-ID is being sold as a  
replacement for source authentication.

Not having this border header as a substitute for DKIM validation  
ensures ISPs will provide access to unmodified messages.  To ensure  
security, verifying the DKIM signature should be done by the MUA  
making the annotation, rather than depending upon an injected third- 
party header.

Weakness related to DNS transaction identification have not  
disappeared, nor has the potential concern related to network  
amplification.  The injection of carrier grade NATs along with SPF's  
sizable query sequence of more than 100 different domains coupled with  
the highly distributed nature of email imposes a risk that increases  
with the rise of network bandwidths.  Racing headlong into the  
adoption of a bogus authentication scheme creates real risks for both  
recipients and the network.

While some large institutions may promote this scheme for self  
interests, they are also likely able to assert control over the  
entirety of their email infrastructure.  However, mechanisms are not  
in place to protect thousands of smaller institutions.  Nor is it  
likely that email standards will ever require the needed header field  
restrictions.  Deploying path registration as an authentication scheme  
places millions of users at risk, since the application of path  
registration as "authentication" is sure to be exploited by confidence  
artists.  In addition, the header scheme is being complicit in the  
deception.  It labels the email-address as the element being  
_authenticated_ rather than the IP address of the SMTP client as the  
element being _authorized_.  This scheme should not be endorsed  
because some software vendors wants to promote a new (albeit  
dangerous) scheme.  Why should the IETF feel obligated to help vendors  
promote a flawed and dangerous approach?  Does it really matter how  
many vendors hope to make money selling a flawed and dangerous product?

A vehicle with brakes that only work on level surfaces should not be  
endorsed simply because some influential companies deploy fleets that  
only travel over level roads.  Authentication annotations will be  
applied regardless of the nature of the route traveled.  For some  
companies and their recipients, there will be intervening routes that  
will prove unsafe for this scheme.  Nothing said changes that.

-Doug


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

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