John Levine wrote:
> Since you have to read through the whole body anyway, I don't see much
> advantage to a two-stage hash and sign strategy.
I agree with this point. What's important to me, though, is that we be
able to tell the difference between a failed signature (because the body
was changed) and a bogus signature (something signed with the wrong key,
or something made to look like a sig that's not).
Why do I care? It may be a matter of the degree of risk I'm willing to
take, and the information is useful. If I know that mybigcustomer.com
signs all of its mail (because of its SSP), then I know that mail "from"
mybigcustomer.com with no sig... is spoofed. That's easy. If I get
mail from mybigcustomer.com with a sig that validates, I know it's good.
That's easy too.
If I get mail from mybigcustomer.com with a sig, or something that looks
like one, and it fails validation, I need to decide what to do. There
could be three reasons (maybe more, but let's say three):
1. It's valid mail that was sent through some forwarder that breaks the
sig... but the changes are inconsequential.
2. It's an attack, where a spammer took a valid mybigcustomer.com sig
and stuck spam onto it.
3. It's someone trying to game the system, by just sticking a bad "sig"
on something... but it's spoofed.
If I can rule (3) out because I can tell that the sig is a good one, but
the message no longer matches it, then I can decide that perhaps
mybigcustomer.com is important enough that I want it whitelisted anyway,
and take the risk. This seems to me to be useful information. Do
others agree? Or do we think that spammers would just use it to their
advantage too much for it to be useful to us?
The other thing this does is make it easier to debug things. And make no
mistake - debuggin this stuff can be a huge pain. Having already spent way too
much time debugging this sort of code (starting with the TIS PEM
implementation), I strongly support having the hash input available in addition
to the resulting signature.
Ned
_______________________________________________
ietf-dkim mailing list
http://dkim.org