On Mon, Jan 19, 2004 at 12:18:14PM -0500, Keith Moore wrote:
It also depends on what is included in the hash. I believe it will be
necessary to omit some information from the hash in order to get the
hash to survive most existing mail transports. I don't think this is a
problem as long as we don't treat the originator-id tag as a digital
signature.
IMHO it is a question of what one wants to accomplish with the signature.
If it's end-to-end, aka MUA <> sMTA <> rMTA <> MUA signatures are nice
to have, but as I can trust my rMTA's Received: line about the sending MTA
it is not of much additional information.
The more interesting situation is if the message is multi hop, like with
forwards. Then we have a situation of MUA <> sMTA <> forw MTA <> rMTA <> MUA
and one has to trust "forw MTA" to add correct trace information about
sMTA. It is desirable to have some signature that allows my rMTA to
verify that the envelope sender (aka the originator address) and the
trace information provided by fMTA are correct and also to protect
against replay attacks, where a signature derived from MUA <> sMTA
is intercepted and abused by evil MTA to send spam and forge sender
addresses and trace information.
I don't think it is an easy task to find information to add to the hash.
Even if the Date field looks kinda sexy to be added it will cause all
sorts of problems, as even today a not too small amount of emails take
a week or more to reach their rMTA and there are a lot of MTAs with
wrong time out there. So the acceptance window has to be quite big and
that leaves enough time to abuse such a hash for replay attacks.
Adding the body of the email to the hash is also playing vabanque as
e.g. mailing lists add trailers to the message and break the hash.
\Maex
--
SpaceNet AG | Joseph-Dollinger-Bogen 14 | Fon: +49 (89) 32356-0
Research & Development | D-80807 Muenchen | Fax: +49 (89) 32356-299
"The security, stability and reliability of a computer system is reciprocally
proportional to the amount of vacuity between the ears of the admin"