On 10/15/10 10:58 PM, Murray S. Kucherawy wrote:
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of MH Michael
Hammer (5304)
Sent: Friday, October 15, 2010 1:52 PM
To: Bill Oxley @ Cox; dcrocker(_at_)bbiw(_dot_)net
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] detecting header mutations after signing
And this is where I angst. In all the discussions of a broken signature
being morally equivalent to unsigned, the thrust has been that it was
likely broken in transit. We failed to have the discussion of it being
intentionally broken in transit as an attempt to game the system.
The problem is: when is a broken signature an intentionally broken
signature and how do we detect that at the verifier side?
For
header mutations after signing (which are likely to be a malicious
attempt in the specific cases we have been discussing) I feel that
treating it as simply the same as unsigned is ignoring the potential
maliciousness.
-1. At the end of the day, giving a negative score to an invalidated
signature will/may affect the reputation of the owner of the domainname
or better said: it will influence the way the assessor will interpret
the authentication results provided by the verifier. Apart from the
problem of how to determine the 'nature of the invalidation'.
I think the problem is it's hard to tell using an algorithm. A human can
perhaps look at a modification and qualify it as an operational side-effect
or something deliberate intending to deceive, but it's pretty hard to codify
that kind of logic, especially without some foreknowledge about what
downstream agents are going to do with the message (which would make such an
algorithm heinously big).
I recognize what Murray and Dave have said on this point but it grates.
I think it's an unfortunate reality as well; absent a way to tell the
difference, it seems the best option is to act like there isn't any
difference.
Interestingly, I think the same logic applies to domain reputation: It's easy
to shed a bad reputation by changing domains, so in the end I expect a bad
reputation will be the same as no reputation.
+1
Like DNSBLs and IPv6: at some point it will be more effective to
whitelist known 'good' IP addresses than to blacklist the ever changing
IP addresses of the bad guys.
/rolf
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html