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

[Douglas Otis]

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