What we have is a reproducible issue that can add "stuff" without breaking an
existing signature (if I am following along correctly) so that an email CAN
show up in a MUA and be heralded as a DKIM VALIDATED signature as well as
promote the added "stuff"
My opinion is to look at how to not allow a signature to validate after someone
has added "stuff" and making sure that the DKIM current validators are aware of
this exploit until a fix is proposed
thanks,
Bill
On Oct 19, 2010, at 1:25 PM, Murray S. Kucherawy wrote:
-----Original Message-----
From: John Levine [mailto:johnl(_at_)iecc(_dot_)com]
Sent: Monday, October 18, 2010 5:50 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Cc: Murray S. Kucherawy
Subject: Re: [ietf-dkim] detecting header mutations after signing
Why do we think such a sorting module can't/won't have the
intelligence to do the RFC5322 Section 3.6 checks?
Sheesh, I think I've answered this at least three times now.
Well gosh, I sure do appreciate your patience in dealing with the rest of us
fools that might not share your view or have something else to offer.
In the
absence of a DKIM signature, there is no reason to worry about doubled
headers since there is no reason to think one is "real" and the other
"fake". They're only a threat when they provide a way to make a DKIM
signed message render differently from what the signer expected.
But some agents, maybe even many of them, do via some mechanism decide that
one is the "real" one and make a filtering decision based on it. It might be
as simple as an MUA electing to render the first one it finds, for some value
of "first".
As I've also said before, either DKIM has a SHOULD about doubled
headers, or the equivalent advice goes into the folklore about what
you have to do make DKIM useful. Personally, I think the latter would
be a cruel joke on future implementors, but apparently other people
feel differently.
And just like when you said it the first time, I still don't share your view
that a Security Considerations section of a Draft Standard document can be
classified as "folklore".
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html