Re: [ietf-dkim] Data integrity claims

-----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:26 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Data integrity claims

-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org [mailto:ietf-dkim-

bounces(_at_)mipassoc(_dot_)org] On Behalf Of Mark Delany

Sent: Sunday, October 17, 2010 6:23 PM
To: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] Data integrity claims

By DKIM process, I would include anything cognizant of DKIM upto but
not including the MUA. Mike's secret sauce would count here, eg.


Current implementations, especially the two library ones that are
referenced most often in here, haven't the functionality to cause

header

fields to be removed, prefixed, reordered, modified, etc.  This change
would require them to be overhauled to extend their reach into what

the

MTA can do.  That expansion of scope of "DKIM process" to me requires

recycle at Proposed Standard.


Assuming that is the consensus solution to the perceived problem.

As others have said, there is nothing between DKIM and the MUA that
prevent DKIM exploitation so who is going to solve that problem if

not

us?


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.

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.

This leaves it to the MUAs to implement based on the DKIM output but it
addresses the DKIM related case.

Mike



_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html