User:David MacQuigg/Sandbox/Email authentication: Difference between revisions
imported>David MacQuigg No edit summary |
imported>David MacQuigg No edit summary |
||
| Line 1: | Line 1: | ||
COPIED to PUBLIC VERSION 10/16/09 | |||
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 22: | Line 24: | ||
------ DNS ------- | ------ DNS ------- | ||
With IP-based methods, the sender publishes in DNS the IP addresses authorized to transmit | 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. | 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. | 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:53, 16 October 2009
COPIED to PUBLIC VERSION 10/16/09
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.