[ietf-dkim] Re: signature construct

[Ned Freed]

> 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