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


Secure communications via email may require:
Secure communications may require any or all of:
  1) authentication of the source (sender's identity)
  1) authentication of the source (individual or organization identity)
  2) verification of content (digital signature)
  2) verification of content (digital signature)
  3) confidentiality of content (encryption)
  3) confidentiality of content (encryption)
  4) originality (no duplicates)
  4) originality (no duplicates)
  5) timely delivery (no unexpected delays)
  5) timely delivery (no unexpected delays)
  6) secrecy (hidden communication)
  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 blacklist|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.


Solving the spam problem (spamming, phishing and other bulk mail scams)
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 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 by the receiver will return those records unaltered.
requires that we address issues 1 and 4.  The others are irrelevant.


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


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.
With IP-based methods, the sender publishes in DNS the IP addresses authorized to transmit using his domain nameWith signature-based methods, the sender publishes a public key.


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


With IP-based methods, the sender publishes in DNS the IP addresses authorized to use his domain nameWith signature-based methods, the sender publishes a public keyIP 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.
Signature methods work "end-to-end" and avoid the forwarding problemThey 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 13: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.