Email authentication

From Citizendium
Revision as of 20:51, 16 October 2009 by imported>David MacQuigg
Jump to navigation Jump to search
This article is a stub and thus not approved.
Main Article
Discussion
Related Articles  [?]
Bibliography  [?]
External Links  [?]
Citable Version  [?]
 
This editable Main Article is under development and subject to a disclaimer.

This article is a subtopic in a group of articles under Email system. We assume the reader understands the parent article, its terminology, and the roles of different agents in the system.

Secure communications may require any or all of:

1) authentication of the source (individual or organization identity)
2) verification of content (digital signature)
3) confidentiality of content (encryption)
4) originality (no duplicates)
5) timely delivery (no unexpected delays)
6) hidden communication (keeping an enemy unaware)

Solving the problems of bulk email abuse (spamming, phishing and other bulk mail scams) requires that we address issues 1 and 4. The others are irrelevant.

Email authentication methods fall into two categories. Methods like SPF, Sender ID, and CSV rely on the fact that certain IP addresses are firmly under the control of a sender (an individual or organization identified by its domain name). Methods like DKIM rely on a digital signature verifying the entire message and some of its headers. Both depend on the security of DNS. The assumptions are that only the domain owner has access to the DNS records under his name, and that a DNS query by the receiver will return those records unaltered.

|--- Sender's Network ---|           |--------- Recipient's Network --------|
                                /
Author ==> MSA/Transmitter --> / --> Receiver/Forwarder ~~> MDA ==> Recipient
                    /         /        /
                   /       Border     /
                  /                  /
                  ------ DNS -------                     

With IP-based methods, the sender publishes in DNS the IP addresses authorized to transmit using his domain name. With signature-based methods, the sender publishes a public key.

IP methods can be very efficient, rejecting an entire session without transferring any messages, but there must be a "chain of trust" from author to recipient. A "forwarding problem" may occur when the source IP address on the "last hop" is no longer related to the sender's domain name.

Signature methods work "end-to-end" and avoid the forwarding problem. They have a different problem, however. It is not hard for a criminal to get just one signed message through a reputable email service. That message can then be sent via a botnet to millions of recipients, and the signature is still valid. The fundamental advantage of signature methods (path independence) then becomes a fundamental vulnerability.