ietf-mxcomp
[Top] [All Lists]

Re: Sender-ID and last hop validation

2004-08-19 00:00:12


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


<Prev in Thread] Current Thread [Next in Thread>