On Wed, 18 Aug 2004, Nate Leon wrote:
Do I understand correctly that Sender-ID only authenticates the most
recent hop? In the simple case, this is the domain where the client
lives that sent the message. But in the more complex case, there may be
forwarding hosts in the middle.
i.e. my receiving MTA will authenticate the SMTP client delivering the
message to me. Specifically, it will ask, is the IP address connecting
to me authorized to send mail for the domain listed in the Purported
Responsible Address?
You understand correctly. MARID/SenderID and any similar technology (RMX,
SPF, CSV, etc) based on concept of MTA IP authorization are alaways going
to be one-hop only authentication. And there is nothing that can be done
about that, since what is being authenticated is the ip address of the
mail server in the current email hop.
In order to do authentication of hop not directly preceding current one
in email path, you must have an identity that comes from that hop that
you can trust and verify to have been added during that hop and could
not have been added (forged) by anyone else. This basicly means it has
not be a cryptographic signature based verification. This is probably
going to be focus of MASS IETF WG. I have also some slides at
http://www.elan.net/~william/asrg/SecuringEmailPath.htm
(its reworked version of previously published presentation), that show
how in my view MARID (rather Unified SPF, as what is improperly listed in
slides as MARID is really unified SPF) fit into securing email system.
What is not clearly listed in slides, in that MARID work offers good features
for internet mail system because of its low computational overhead. I've
ran some tests on how much computational work is involved in different
authentication methods. The results are not unexpected - first its clear
that any cryptographic based signature verification (s/mime compared to
yahoo dk for example) requires about same amount of work, or more precisely
the computation work required is dependent on the size of the public key
and if RSA or Diffie-Helman is used but not really dependent on the method
of how signature is included and this computational work is even with low
384k keys is 10 times the work necessary to do most email body transformations
or 20 times or more what it takes to just extract simple one-line header from
the body. At the same time, the work necessary to actually go through email
body text (and dely necessary before you can do it), is also not 0 compared
to what happens when you re able to judge authenticity of email.
The scale of computation work that exist is probably something like:
1 : Envelope-only check during transmission (RMX, SPF Classic, CSV)
5-10 : Quick body context check (known bad and good "From: header address
from your personal list, reject based on known bad Subject phrase)
20-50 : Body context full check (spamphrase in body, boesian filters)
40-100 : Encryption based checks (S/MIME or PGP, Yahoo DK, etc)
From all this and from common sense, clearly the quicker you can decide on
validity of email and reject bad ones, the better. And in my view MARID
goal is to provide lightweight mechanism with low computational overhead
to be able to reject bad emails during SMTP transmission. Its a first step
that may not be able to reliable authenticate sender in complex path, but
at the same time 50% of emails are personal one sent person-person with
basicly only one hop and there it can work perfectly (i.e. direct path
cases from sender ISP MTA to recepient ISP MTA; sometimes sender may have
multiple servers involved in transmission and recepient too may have
filtering server, but these are "intranet" servers where no authenticaion
is necessary - its the step from two independent networks that we need to
be worried about). In such view if we create mechanism that works for 50%
of current email cases with low computation overhead and avoids necessity
to do more complex check that requires 20% more computational complexity,
then we have done a lot of good towards authenticated email (this is alike
RBL checks and email content checks - I use both with SBL and 5 other RBL
checks during email transmission and afterwards sending email through
spamassisin for more complex checks).
Now to be able to authenticate sender several hopes away is what we'll
need cryptography for. I do note that one highly publicided proposed
cryptography method - yahoo dk - does not fit well into this because by
its design (signature for entire body of email which can only be checked
if that body does not change; but headers do change by email servers,
forwarders or new ones added or additional body added to the end of email)
it can also only work reliably for direct next hop check and that that is
not what we want for cryptography to be used for when 20 times less
computational method is available (I hope MASS IETF group will see it
despite pressure of corporate interests involved and what will be
developed is something for point-point authentication where points are
expected to be MTAs that are often several hops away in email path).
Now one last thing, is that BATV proposal (which proposes encryption of
envelope mail from) is also cryptography based and that means it has a
lot highier overhead then something like RMX or SPF Classic. But it does
mean it will work reliably for multiple hopes, rather then just one hop.
My view of this is that RMX or SPF Classic mail-from mechanisms should
not be discarded (as they seem to be currently as part of MARID) but
should be used as whitelisting mechanisms to avoid necessity to do more
complex cryptographic verification - that is if RMX fails, the email
should not be rejected, but instead its BATV signature should be checked
in that case if it exists.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net