ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Final update to 4871bis for working group review

2011-07-12 17:26:25
On 7/12/11 12:02 PM, Charles Lindsey wrote:
Essentially, my concern is that an implementor reading this section should
be able to infer the nature of the particular attack I have described (the
one where the signer is the BadGuy himself using a throwaway domain),
including spotting how and why it worked and how to protect against it.

Having now read your paragraph in the context of the rest of the material
in that section, I think it just about passes that test, but only by the
thinnest of margins, so I will let it go.

But as a piece of technical writing that section is a total mess, talking
around the problem, and seemingly more concerned with enabling timid
implementors to pass the buck around amongst themselves that with
protecting the ultimate users.

I see Doug has written a detailed critique of it, and I fully endorse most
of what he has said.
Charles,

IMHO, the issue was never about throw-away domains. Without universal 
adoption of the recently invented and poorly considered 'h=' double 
tagging hack, any domain reputation based upon not sending spam or 
spoofing messages place all recipients of messages from ANY domain at 
risk whenever illegal header fields are ignored during DKIM validation 
regardless of ADSP like policy being applied.

The lack of universal adoption of 'h=' double tagging hack places 
senders and recipients at risk.  This risk should be seen as an assault 
against the entire DKIM protocol.  Steps needed to mitigate the risk 
represent less process and resource overhead than the poorly considered 
double tagging hack.  The double tagging hack might assist in a 
transition toward better validation enforcement, but without invalid 
header checks made during validation, the requisite protections that 
might have been afforded through ADSP like policy or through signing 
domain reputation is lost.

-Doug




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