-----Original Message-----
From: MH Michael Hammer (5304) [mailto:MHammer(_at_)ag(_dot_)com]
Sent: Monday, October 18, 2010 11:44 AM
To: Murray S. Kucherawy; ietf-dkim(_at_)mipassoc(_dot_)org
Subject: RE: [ietf-dkim] Data integrity claims
There's nothing between an MTA and an MUA that prevents this attack in the
non-DKIM case at all. Whose place is it to fix that?
I can't get my head around how that case is irrelevant here. This is not
a new problem, but somehow we're being called upon to deal with it.
The non-DKIM case makes no assertion with regard to authentication (I
exclude PGP and S/MIME from the non-DKIM case I think you refer to). If
DKIM made no assertion regarding validation of headers + the body length
hash then we would almost certainly not be having this discussion in the
first place. To the extent that DKIM makes such claims then it is a
different case and needs to be considered separately from the non-DKIM
case.
DKIM doesn't claim the value in From: was valid, only that it was unchanged.
If the MUA is DKIM-aware, then it will render the From: field covered by the
signature, even though the value that field could be completely bogus. If the
MUA is DKIM-ignorant, it renders the "first" one, for some search order.
In neither case is there an assertion of validity of the content.
I'm going to go back to the question I asked Wietse... Do we see double
headers (one signed and one unsigned one added later) in the normal
course of things in the wild? If not then rather than getting into the
MUA territory and fixing it, I say let's fix DKIM. If we only see this
type of behavior where there is potential non-good activity (I was
going to use malicious), we output a "warn" addition to a pass/fail/none. It's
not a huge check to look for the double headers and we aren't boiling
the ocean.
If we can output a "warn" bit in addition to pass/fail/none, we're also
presuming the MUAs will adapt to consume it. But then the MUAs can just as
easily adapt to show you what parts of the message were signed and which were
not, and that is in fact the more complete solution.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html