User:David MacQuigg/Sandbox/Email authentication: Difference between revisions

From Citizendium
Jump to navigation Jump to search
imported>David MacQuigg
No edit summary
imported>David MacQuigg
No edit summary
 
(6 intermediate revisions by the same user not shown)
Line 1: Line 1:
'''Edit status:''' copied to main
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.


Line 7: Line 9:
  4) originality (no duplicates)
  4) originality (no duplicates)
  5) timely delivery (no unexpected delays)
  5) timely delivery (no unexpected delays)
  6) hidden communication (keep an enemy unaware)
  6) hidden communication (keeping an enemy unaware)


Solving the problems of bulk email abuse (spamming, phishing and other bulk mail scams)  
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.
requires that we address items 1 and 4.  The others may be important in higher security situations, but the major problems with email since 2003 have centered around massive abuse of bulk mail.  Email authentication seeks to alleviate these problems by identifying the source.  To be useful in email authentication, an identity must have three characteristics. It must be unique, verifiable, and suitable for accumulation of reputation.
 
Individual email addresses are unique, but not verifiable or suitable for accumulation of reputation.  Criminals commonly use randomly-chosen real addresses for both From: and To: in their bulk mailings.  Attempts to verify From: addresses will likely bother additional victims who had nothing to do with the original message.  As for accumulating reputation, there is not enough mail flow from individual addresses to get good statistics.  The main use of individual sender addresses is for [[whitelisting]] by individual recipients when there is a pre-existing relationship.


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 some of its headersBoth 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 will return those records unaltered.
An [[IP address]] is unique and verifiable, but difficult to use in a reputation system, because the assignment of IP addresses to specific senders is always changingAlso, like individual email addresses, the statistics on each identity are too sparseNevertheless, [[IP blacklist|IP blacklists]] are useful in efficiently blocking high-volume and persistent sources, and there are plenty of those.


                              |--------- Recipient's Network --------|
Domain names are unique and ideal for accumulation of reputation. Like a brand name, a domain name can be "owned" by an organization and protected by law.  The [[Domain Name System]] provides a hierarchy of names, allowing a choice of levels at which to accumulate reputation.  If az.us is too large, and Arizona has no central authority controlling what the counties do with their mail servers, then pima.az.us may be a better choice.  The problem with domain names is verifiability in an email.  A criminal can too easily forge the name of a reputable domain.  That is the problem email authentication methods seek to avoid.
                          /
  MSA ==> Transmitter --> / --> Receiver/Forwarder ~~> MDA ==> Recipient
                        /
                      Border


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


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.  Signature methods can work "end-to-end" without any reliance on IP addresses.  This avoids the [[forwarding problem]] suffered by some IP-based methods, in which the source IP address on the "last hop" is no longer related to the sender's domain name.
|--- 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.


Email authentication methods focus primarily on authentication, but also meet other requirements on this listA digital signature like that in the [[DomainKeys Identified Mail|DKIM]] method, can be generated only by someone having the private part of the key, so the signer is automatically authenticated. DKIM satisfies requirements 1 and 2, but nothing else.
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 serviceThat 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.

Latest revision as of 12:15, 26 October 2009

Edit status: copied to main

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 items 1 and 4. The others may be important in higher security situations, but the major problems with email since 2003 have centered around massive abuse of bulk mail. Email authentication seeks to alleviate these problems by identifying the source. To be useful in email authentication, an identity must have three characteristics. It must be unique, verifiable, and suitable for accumulation of reputation.

Individual email addresses are unique, but not verifiable or suitable for accumulation of reputation. Criminals commonly use randomly-chosen real addresses for both From: and To: in their bulk mailings. Attempts to verify From: addresses will likely bother additional victims who had nothing to do with the original message. As for accumulating reputation, there is not enough mail flow from individual addresses to get good statistics. The main use of individual sender addresses is for whitelisting by individual recipients when there is a pre-existing relationship.

An IP address is unique and verifiable, but difficult to use in a reputation system, because the assignment of IP addresses to specific senders is always changing. Also, like individual email addresses, the statistics on each identity are too sparse. Nevertheless, IP blacklists are useful in efficiently blocking high-volume and persistent sources, and there are plenty of those.

Domain names are unique and ideal for accumulation of reputation. Like a brand name, a domain name can be "owned" by an organization and protected by law. The Domain Name System provides a hierarchy of names, allowing a choice of levels at which to accumulate reputation. If az.us is too large, and Arizona has no central authority controlling what the counties do with their mail servers, then pima.az.us may be a better choice. The problem with domain names is verifiability in an email. A criminal can too easily forge the name of a reputable domain. That is the problem email authentication methods seek to avoid.

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