spf-discuss
[Top] [All Lists]

Re: Status of Email Authentication

2005-03-01 19:23:54
Thanks for your very helpful comments.

The latest article is at http://en.wikipedia.org/wiki/Email_Authentication

At 01:21 PM 2/28/2005 -0800, you wrote:

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

I had to compromise between the terminology in draft-crocker-email-arch-03, and terms which are more likely to convey the right mental picture to readers of an encyclopedia article, even at the cost of some technical precision. Hence, I used (author, sender, forwarder, receiver) instead of (originator, source, user mediator, destination). Author is inadequate to describe a non-human originator, sender as you point out can have the different meanings above, forwarder is only one type of mediator, etc. I defined these terms as I introduced them, so I hope I have enough precision to get the readers through the article.

The image I have in mind when talking to a general audience about spam on the Internet is analogous to senders and receivers of radio broadcasts. This image is helpful both for it parallels and for its distinct differences. For example, when someone suggests we need the government to regulate ISPs, I can say - not necessary, and point out the difference between the fundamental limits of the broadcast spectrum and the unlimited expansion capacity of the Internet.

> 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.

I expect spam will continue, but it will be rare on the part of the Internet using authentication and domain-rating lists. I may be an optimist, but I am expecting nearly 100% banishment of spammers to the "bad part" of the Internet. What I don't have a clear picture of is what the bad part will look like with 99% spam and nobody cares. No doubt there will be a lot of phishing, forgery, and every other conceivable scam. Some people we just can't save. I guess the Internet of the future will exist primarily to support spammers. Serious users will be just a sideline. :>)

>  SPF and SenderID authenticate just the domain name.

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

Seems like this will be too much detail for an article that is already rather long. I am thinking of adding a little more on DomainKeys, but there is already a good article on that, which I reference. http://en.wikipedia.org/wiki/DomainKeys

>  This requires more computation

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

As I understand it, the overhead is about 10% of the overall computational load. I agree, that's not much. I'll change the statement to: "This requires a little more computation, but may be advantageous in higher-security situations."

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.

I don't see the difference. Change the authorized sending IPs, and you have to update your DNS record. Change a DomainKey, and you have to update a similar DNS record.

>  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.

OK. See changes above. What I was thinking of is the extra security that DomainKeys provides for the *content* of a message. 56-bit DES is pretty tough to break. A 2048-bit DomainKey seems like massive overkill.

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.

A man-in-the-middle could fake an IP address and defeat *all* these methods. I can't see spammers going to that extreme, however.

>  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.

Are you talking about dynamic IP addresses? I would think most ISPs would designate only a few static IPs as their authorized senders. These should not be changed any more often than you would want to change a DomainKey.

>  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.

Understood. I'll have to think about how to make this distinction in the article, without confusing a general audience.

> 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.

Footnotes added.

>  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.

This sounds like a good rule to me. However, it will mean that any Relay must become a Mediator to participate in an SPF authenticated transfer. This seems to me like the major disadvantage of IP-authentication as opposed to DomainKeys.

I'm still puzzled why we need these anonymous Relays ( as opposed to authenticating Forwarders ) on the public Internet. Seems to me there should be only two classes of Forwarders, those designated by the Source, and those by the Destination. Destination Forwarders can be trusted by the Recipient. Source Forwarders should be explicitly authorized for the Source's domain. Anything else should not be in the middle.

-- Dave

*************************************************************     *
* David MacQuigg, PhD              * email:  dmq'at'gci-net.com   *  *
* IC Design Engineer               * phone:  USA 520-721-4583  *  *  *
* Analog Design Methodologies                                  *  *  *
*                                  * 9320 East Mikelyn Lane     * * *
* VRS Consulting, P.C.             * Tucson, Arizona 85710        *
*************************************************************     *



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