ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Last Call: <draft-ietf-dkim-rfc4871bis-12.txt> (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard

2011-06-24 18:07:40
On 6/24/11 2:43 PM, Steve Atkins wrote:
On Jun 24, 2011, at 10:33 AM, Douglas Otis wrote:

Complaints from John, Dave, and Barry and others is likely and
understandably out of fatigue.  They just want the process to be over.
We are now hearing there is a vital protocol layering principle at stake
which even precludes DKIM from making these checks!  Really?
While people are tired of you, fatigue is not the issue.

Rather it's that you either don't appear to accept the fact that very few 
people agree with you, rather you continue to bring up exactly the same 
issues repeatedly, even though you know you're not going to convince anyone 
by that repetition, as they've explained to you in detail, repeatedly why 
your concerns are unfounded. That ends up consuming many peoples time to no 
good result.

Your current argument is of the form:

     Doug: X is bad, and could theoretically lead to end-user confusion in 
one particular obscure replay scenario, given a carefully chosen set of 
assumptions about MUA user interface design.

     World: Yes, X is bad, but it's out of scope for the DKIM protocol, as 
it's nothing to do with DKIM, rather it's a violation of 5322.

     World: Spam filters and MTAs should certainly consider it, though.

     World: Heck, DKIM *implementations* probably should, even though it's 
not part of the DKIM protocol - other than "DKIM applies to email, and data 
streams with X are not email".

     Doug: If it's not in the DKIM protocol, then "we" are telling the entire 
world that they MUST NOT pay attention to X anywhere in their mail handling 
process...

     World: Uhm... what? No, we're not. That's just rid....

     Doug: .... and that makes DKIM worthless!

     World: Uhm... what? No, that's not what we said.

Repeat, ad- nauseam and beyond.
Steve and Dave,

Allow me to bring up a few new (albeit related) issues then.

ADSP (RFC5617) depends upon DKIM's output.  ADSP failed to consider a 
pre-pended header threat.  When present, this unchecked threat means the 
Author Address is undefined.  Those trusting ADSP results are placed at 
risk due to a lack of assurance pre-pended header fields were excluded.

Message Header Field for Indicating Message Authentication Status 
(RFC5451) also depends upon DKIM's output.  This specification also 
failed to consider a pre-pended header threat.  When present, this 
specification lacks signaling to indicate whether signed singleton 
header field replicates were excluded and of course the header.from is 
undefined.  Those trusting an Authentication-Results header field are 
placed at risk due to the lack of assurances that pre-pended header 
fields were excluded.

Does this avoid the "out-of-scope" claim being repeated ad-nauseam?

-Doug







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