DomainKeys Identified Mail: Difference between revisions
imported>David MacQuigg (add intro) |
imported>David MacQuigg (Add section on Limitations) |
||
| Line 5: | Line 5: | ||
Verification does not depend on IP addresses or the path a message followed from signer to verifier. Thus DKIM avoids the [[Email authentication | forwarding problem]] seen by IP-based authentication methods. | Verification does not depend on IP addresses or the path a message followed from signer to verifier. Thus DKIM avoids the [[Email authentication | forwarding problem]] seen by IP-based authentication methods. | ||
=== Limitations === | |||
DKIM does not prevent "replay" abuse. The advantage of path independence is also a vulnerability. A single signed message may be replayed to a million different recipients, and all will see valid signatures. Without additional evidence of complicity, the signer of a DKIM message cannot be held responsible for replay abuse. | |||
DKIM signatures do not protect the message envelope, which includes the Return Address and the Recipient Addresses. Note, however, that the From: and To: headers can be protected. If you receive an email supposedly from your bank addressed to "Customer", asking for your password or other information that identifies you, that message is probably *not* from your bank. Rejection of such "phishing" emails could even be automated. Any signed message where the header addresses differ from the envelope addresses should at least be flagged as suspicious. | |||
Another limitation of DKIM is that a message must be received in its entirety to complete the verification. IP-based authentications are generally much quicker, as they don't require any data transfer or processing of individual messages. | |||
IP-based and signature-based methods should be treated as complements, not competitors. They each cover a different range of the risk spectrum. If recipients in your domain get a million ads for Viagra, you hold responsible the the domain that authorized the transmission of those messages (the last hop in a chain of relays). If you are the Treasury Secretary, and you get a message from the Bank of America saying "We agree to sell our bank for $330 billion.", but the DKIM signature fails to verify, you better make a call to confirm. | |||
=== How it works === | |||
Revision as of 11:58, 12 October 2009
DomainKeys Identified Mail (DKIM) is an email authentication method using a digital signature added to the the headers of a message. The signature provides strong assurance that there was no alteration of selected headers or the body of a message at any point after it left the signer's domain.
The signature can be verified by doing a DNS query for a public key in the signer's domain. Thus DKIM security depends on the distribution of public keys through DNS, rather than through a Public Key Infrastructure.
Verification does not depend on IP addresses or the path a message followed from signer to verifier. Thus DKIM avoids the forwarding problem seen by IP-based authentication methods.
Limitations
DKIM does not prevent "replay" abuse. The advantage of path independence is also a vulnerability. A single signed message may be replayed to a million different recipients, and all will see valid signatures. Without additional evidence of complicity, the signer of a DKIM message cannot be held responsible for replay abuse.
DKIM signatures do not protect the message envelope, which includes the Return Address and the Recipient Addresses. Note, however, that the From: and To: headers can be protected. If you receive an email supposedly from your bank addressed to "Customer", asking for your password or other information that identifies you, that message is probably *not* from your bank. Rejection of such "phishing" emails could even be automated. Any signed message where the header addresses differ from the envelope addresses should at least be flagged as suspicious.
Another limitation of DKIM is that a message must be received in its entirety to complete the verification. IP-based authentications are generally much quicker, as they don't require any data transfer or processing of individual messages.
IP-based and signature-based methods should be treated as complements, not competitors. They each cover a different range of the risk spectrum. If recipients in your domain get a million ads for Viagra, you hold responsible the the domain that authorized the transmission of those messages (the last hop in a chain of relays). If you are the Treasury Secretary, and you get a message from the Bank of America saying "We agree to sell our bank for $330 billion.", but the DKIM signature fails to verify, you better make a call to confirm.