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> |
- Re: Status of Email Authentication,
David MacQuigg <=
|
|
|