-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-
bounces(_at_)mipassoc(_dot_)org] On Behalf Of Murray S. Kucherawy
Sent: Monday, October 18, 2010 2:51 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Data integrity claims
-----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.
I said validation, not valid. That is in line with the 4871 text that
uses "validate" or some variation 22 times. That is, what was signed is
what was validated on the receiving/verifying side.
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.
See above. This leads me to believe that you might be amenable to
informative text rather than normative text.
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.
This is no more presumptuous than expecting that MUAs will adapt to
consume the output of DKIM as it stands now. The question is the value
equation. I'm not in a position to answer that question. Perhaps we
should try to get some of the MUA folks to join the conversation. It may
be that some of the well known ones go... "hey, never thought about this
issue and yeah, we will look into fixing it based on the wider scope".
On the other hand they might inquire if we are smoking crack (Just
trying to give the two extremes of responses).
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html