spf-discuss
[Top] [All Lists]

Re: Email Forwarder's Protocol ( EFP )

2005-02-28 14:22:56
David,

  see that might need some discussion is the inclusion of Packet Switches in
  the same category as User Mediators (section 2.2.3).  

I've added some clarifying language, for the next version.



  at http://www.ece.arizona.edu/~edatools/etc/Email_Authentication_01.htm  ;;

use of the unqualified term "sender" is usually ambiguous, at best.  There are 
at least 4 different interpretations of that term, and each has significantly 
different semantics:

  RFC2822.From
  RFC2822.Sender
  RFC2821.MailFrom
  RFC2821.HELO/EHLO


  All are nearly 100% effective in stopping the kind of forgery now prevalent

Probably not.

Validating any of those fields is going to do remarkably little to deal with 
actual Phishing, because the social engineering techniques for phishing are 
very clever at deceiving readers, with close approximations of correct, branded 
names, and with deceptive of false content.


  SPF and SenderID authenticate just the domain name.

this paragraph needs to hammer home the different identities (fields) each 
scheme authenticates.


  This requires more computation

1) the computation overhead appears to be insignificant or, relative to overall 
mail processing costs.

2) Except in the simplest scenarios, path registration schemes, like SPF and 
Sender-ID, incur significant, long-term administrative costs, by having to keep 
the linkage between mta-level IP addresses, with user-level domain names.


  may be necessary in high-security situations

Sorry, no.  Domain Keys and Identified Internet Mail are not intended for 'high 
security'.  In fact they take advantage of the much lower security requirements 
for transit-time domain-only authentication.

These schemes do not incur any path dependencies and they are based on the 
fingerprint of the content, providing robustness against man-in-the-middle 
attacks.  Those are their major benefits.


  SPF and SenderID work by tying a temporary IP address to a relatively
  permanent and reputable domain name

Nicely written.  It the transient nature of IP addresses is a major difficulty 
with having to correlate them with user-level identities.


  Every incoming email has an IP address that cannot be forged {1}

Actually, IP Address spoofing is already a problem.  Spammers are stealling 
portions of IP Address space.

It is probably ok to continue to use IP Addresses for authentication activities 
that are not mission critical, such as transit-time testing, but it is not 
appropriate to use it for more than that.


  The methods differ in which of these names to use as the sender's domain
  name.

hmmm.  well, ok.  but this needs to go at the beginning.  i also think that 
using a single term to cover all the different semantics is confusing.  The MTA 
is one-hop sender and the author is another kind of sender.  But the 
differences between them are so large as to make the single term "sender" 
pretty meaningless.


  what cannot be faked is a domain name held by a DNS server for that section
  of the Internet {2}

Unfortunately, this is not correct.  There are well known attacks on the DNS 
possible.  Until DNSSec is in widespread use, again the information in the DNS 
must be used with limited trust.


  Is there any work yet on a standard for how Mediators should handle
  authentication of the sender ( SRS, Resent-From, ???) ?  Seems to me a

A simple rule for any intermediary is that if is breaks the authentication 
information, it is responsible for re-creating it.  With rare exception, this 
means that a Mediator must re-sign or re-register the message.



 d/
 --
 Dave Crocker
 Brandenburg InternetWorking
 +1.408.246.8253
 dcrocker  a t ...
 WE'VE MOVED to:  www.bbiw.net



 d/
 --
 Dave Crocker
 Brandenburg InternetWorking
 +1.408.246.8253
 dcrocker  a t ...
 WE'VE MOVED to:  www.bbiw.net