On Fri, 2004-09-17 at 06:12 -0700, Michael Thomas wrote:
The problem here is that the draft does not explain how it
deals with the cut and paste attack. I've specifically asked
about that and have been told yet again that I'm "reading
way too much into it" -- a non answer.
A partial answer. Followed by a number of paragraphs of more detailed
consideration.
With none of the body included in a hash, a spammer can simply
cut a valid signature and append whatever spam to the body they
want. That's not good.
Agreed. Not ideal -- but not actually a showstopper either. Even with
this limitation, BATV still gives a huge benefit, instantly.
If you counter this by putting some or all of the body into
the hash, the whole process looks like the more general purpose
solution (eg, IIM). As I've said, I've tested IIM to see if it
works against the bounce reflection attack -- it does. The
big question is how to make this tradeoff against of hash
survivability through bouncers and the cut and paste attack.
What I don't see is why a completely different mechanism for
this attack is necessary.
BATV would appear to make an ideal _complement_ to other message signing
solutions.
By signing mail we seek to achieve two things -- firstly to allow the
potential recipient to reject mail which is not genuine, and secondly to
allow ourselves to reject 'bounces' to messages which we did not in fact
send.
The RFC2822 signature methods such as IIM/DK/etc allow participating
recipients to achieve the first objective, but without ubiquitous
deployment they can never achieve the second. They can achieve _limited_
success at the second objective, but there are just too many systems out
there which when generating a bounce will omit whatever signature
headers we use, and we'd always have the problem of deciding what do to
with a bounce which just lacks the appropriate header. By using the SMTP
reverse-path as our signature, we fix that problem without the potential
to throw away _legitimate_ bounces.
On whether we want to include a hash of the body (or a hash of the
RFC2822-signature header alone) in the BATV reverse-path itself: I'm
still not sure -- I'd be interested in a discussion of that idea.
Putting a hash into the BATV reverse-path does protect against the
replay attack. But stop and think about it for a second more -- putting
that hash into the BATV reverse-path helps to stop reception of the fake
only by _participating_ recipients. Non-participants aren't going to
check the contents against the hash, and are going to accept the message
anyway -- and later maybe generate a bounce anyway.
The hash in the BATV reverse-path is only going to stop _participating_
recipients from accepting the mail. I would suggest that there will be a
_huge_ correlation between those participating in a BATV scheme and
those participating in whatever RFC2822-level scheme we standardise.
Thus, those who'd be looking at the BATV hash of the message content
would be looking for the IIM/DK/whatever signature _anyway_ and would
have rejected the mail in question _anyway_ due to the lack of such.
So would we really gain anything by putting that hash there? I suppose
that depends on the correctness of my assumption about the correlation
between those who check BATV signatures, and those who check RFC2822
signatures. Since BATV signatures can trivially be checked in the MTA
and don't need complex algorithms to allow (slight) modification
in-transit, and RFC2822 signatures are necessarily more complex, perhaps
I could be wrong about that, and the simple BATV body-md5sum could be
more widely verified in practice? Answers on a postcard to...
--
dwmw2