[ietf-dkim] Last Call: <draft-ietf-dkim-rfc4871bis-12.txt> (DomainKeys Identified Mail (DKIM) Signatures) to Draft Standard
steve at wordtothewise.com
Fri Jun 24 16:46:48 PDT 2011
On Jun 24, 2011, at 4:04 PM, Douglas Otis wrote:
> On 6/24/11 2:43 PM, Steve Atkins wrote:
>> 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.
I think this is just a restatement of your previous concern, rather than a
new issue. It seems out of scope for this thread, though, as this thread
is discussing DKIM, while you're talking about an ADSP issue.
Perhaps bringing it up in it's own thread (with ADSP in the subject
line) would let people who are interested in the ADSP specific aspects
pay attention to them.
> 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.
This is just a restatement of your previous concern, it is not a new
More information about the ietf-dkim