Authenticate Part IV - More About DKIM
This time, I'll finish the discussion on email authentication, with some additional information about DKIM, the primary cryptographic approach.
But first, let me ask you for any suggestions you may have, for future topics to be discussed in this blog. If there is something that you'd like to see covered, please leave a comment and tell me about it.
What Does DKIM Do For You?
DKIM has been called an enabling technology, because it enables evaluation of the trustworthiness of an entity. It does this by verifying the identity of the message signer.
An IP address has long been used as a means of identification. Its validity is based on the presumed accuracy of the underlying Internet infrastructure. However, domain-based reputation information is not built-in to the Internet infrastructure. So, another form of verification must be used.
DKIM accomplishes this with the Signing Domain Identifier (SDID) ... the signature ensures that the use of the domain identifier is legitimate and authorized. Once the sender is known, sender reputation can then help determine what to do with the message.
Defining the Operational Goals of DKIM
DKIM was designed with several operational goals in mind. Many of the functional details I talked about last time were a direct result of these design goals:
- The signature should be transparent to recipients who don't support DKIM - This is important, so that pre-DKIM email is fully interoperable with DKIM-supported email. This helps simplify implementation and spread adoption.
- Missing signature and verification failures will be treated the same - Again, interoperability and simplification are important ... verification failures become as transparent as pre-DKIM email.
- It should be useable between any two entities - This means that adoption on the Internet can be incremental.
- It will minimize additional needed infrastructure, by utilizing the existing DNS system - This will also encourage the adoption of DKIM.
- It should be flexible in where it can be deployed within an organization - Although flexibility typically adds complexity, not simplification, it can still stimulate the use of a new service.
DKIM has an extensible feature set. As is usual for Internet standards, there is a core set of features and functions, which all implementations must support. This is what guarantees interoperability among implementations coming from different organizations. There are also optional features ... extensions to the basic implementation, which can be supported.
With DKIM, any domain name can be used as the SDID. Additionally, the use of the signature key can be restricted to only particular types of services, such as for a single source of email. This might be used, for example, if signing authority were to be delegated to a third-party email service.
There is considerable flexibility in which headers will be signed. Using a minimal set of headers will probably have fewer issues caused by mishandling, by intermediate mail transfer agents (MTAs). Regardless, the DKIM signer needs to explicitly list the headers that are signed.
The DKIM signature applies to both the listed header fields and to the message body. A hash of the headers and a second hash of the body are computed. The signer then encodes the information cryptographically, with a private key, and places the signature information into a newly defined message header field called DKIMSignature.
Once the message has the signature, it can be verified by any agent in the path from Sender to Receiver. The recipient of the email can verify the signature by querying the DNS for the signer's domain and retrieving the public key. This allows the receiver to verify that the message signer had possession of the appropriate private key for the SDID.
If you want to learn more about DKIM, just go to the official web site: http://www.dkim.org.
One of the documents available there served as the primary reference for this blog. The title is: DomainKeys Identified Mail (DKIM) Service Overview. The document includes an appendix that discusses the current Internet email architecture and how it works.