Email authentication: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>David MacQuigg
m (Agent --> agent, (plain English, not a "term of art"))
imported>David MacQuigg
No edit summary
Line 3: Line 3:
This article is a [[CZ:Related articles|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.
This article is a [[CZ:Related articles|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.


Email authentication methods fall into two categories.  Methods like SPF, SenderID, 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 most of its headers. Both depend on the security of [[Domain Name System|DNS]]. The assumption is that only the domain owner has access to the DNS records under his name.  
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)


With IP-based methods, the sender publishes in DNS the IP addresses authorized to use 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. End-to-end signature methods can be very secure, even with an un-trusted Forwarder in the middle.
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 [[Sender Policy Framework|SPF]], [[Sender ID]], and [[Certified Server Validation|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 [[Domain Name System|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.

Revision as of 19:51, 16 October 2009

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.