RFC 5863
DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations
Pages: 51
Informational
Informational
Part 3 of 3 – Pages 31 to 51
7. Example Usage Scenarios
Signatures are created by different types of email actors, based on different criteria, such as where the actor operates in the sequence from author to recipient, whether they want different messages to be evaluated under the same reputation or a different one, and so on.
This section provides some examples of usage scenarios for DKIM deployments; the selection is not intended to be exhaustive but to illustrate a set of key deployment considerations.7.1. Author's Organization - Simple
The simplest DKIM configuration is to have some mail from a given organization (Company A) be signed with the same d= value (e.g., d=companya.example). If there is a desire to associate additional information, the AUID [RFC5672] value can become uniqueID@companya.example, or @uniqueID.companya.example. In this scenario, Company A need only generate a single signing key and publish it under their top-level domain (companya.example); the signing module would then tailor the AUID value as needed at signing time.7.2. Author's Organization - Differentiated Types of Mail
A slight variation of the one signature case is where Company A signs some of its mail, but it wants to differentiate among categories of its outbound mail by using different identifiers. For example, it might choose to distinguish marketing, billing or transactional, and individual corporate email into marketing.companya.example, billing.companya.example, and companya.example, respectively, where each category is assigned a unique subdomain and unique signing keys.7.3. Author Domain Signing Practices
7.3.1. Introduction
Some domains might decide to sign all of their outgoing mail. If all of the legitimate mail for a domain is signed, recipients can be more aggressive in their filtering of mail that uses the domain but does not have a valid signature from the domain; in such a configuration, the absence of a signature would be more significant than for the general case. It might be desirable for such domains to be able to advertise their intent to other receivers: this is the topic of Author Domain Signing Practices (ADSP). Note that ADSP is not for everyone. Sending domains that do not control all legitimate outbound mail purporting to be from their domain (i.e., with an RFC5322.From address in their domain) are likely to experience delivery problems with some percentage of that mail. Administrators evaluating ADSP for their domains needs to carefully weigh the risk of phishing attacks against the likelihood of undelivered mail.
This section covers some examples of ADSP usage. For the complete specification, see [RFC5617].7.3.2. A Few Definitions
In the ADSP specification, an address in the RFC5322.From header field of a message is defined as an "Author Address", and an "Author Domain" is defined as anything to the right of the '@' in an author address. An "Author Signature" is thus any valid signature where the value of the SDID matches an author domain in the message. It is important to note that unlike the DKIM specification, which makes no correlation between the signature domain and any message headers, the ADSP specification applies only to the author domain. In essence, under ADSP, any non-author signatures are ignored (treated as if they are not present). Signers wishing to publish an Author Domain Signing Practices (ADSP) [RFC5617] record describing their signing practices will thus want to include an author signature on their outbound mail to avoid ADSP verification failures.7.3.3. Some ADSP Examples
An organization (Company A) can specify its signing practices by publishing an ADSP record with "dkim=all" or "dkim=discardable". In order to avoid misdelivery of its mail at receivers that are validating ADSP, Company A needs to first have done an exhaustive analysis to determine all sources of outbound mail from its domain (companyA.example) and ensure that they all have valid author signatures from that domain. For example, email with an RFC5322.From address of bob@ companyA.example needs to have an author signature where the SDID value is "companyA.example" or it will fail an ADSP validation. Note that once an organization publishes an ADSP record using dkim=all or dkim=discardable, any email with an RFC5322.From address that uses the domain where the ADSP record is published that does not have a valid author signature is at risk of being misdelivered or discarded. For example, if a message with an RFC5322.From address of newsletter@companyA.example has a signature with d=marketing.companyA.example, that message will fail the ADSP check because the signature would not be considered a valid author signature.
Because the semantics of an ADSP author signature are more constrained than the semantics of a "pure" DKIM signature, it is important to make sure the nuances are well understood before deploying an ADSP record. The ADSP specification [RFC5617] provides some fairly extensive lookup examples (in Appendix A) and usage examples (in Appendix B). In particular, in order to prevent mail from being negatively impacted or even discarded at the receiver, it is essential to perform a thorough survey of outbound mail from a domain before publishing an ADSP policy of anything stronger than "unknown". This includes mail that might be sent from external sources that might not be authorized to use the domain signature, as well as mail that risks modification in transit that might invalidate an otherwise valid author signature (e.g., mailing lists, courtesy forwarders, and other paths that could add or modify headers or modify the message body).7.4. Delegated Signing
An organization might choose to outsource certain key services to an independent company. For example, Company A might outsource its benefits management, or Organization B might outsource its marketing email. If Company A wants to ensure that all of the mail sent on its behalf through the benefits providers email servers shares the Company A reputation, as discussed in Section 6.4, it can either publish keys designated for the use of the benefits provider under companyA.example (preferably under a designated subdomain of companyA.example), or it can delegate a subdomain (e.g., benefits.companyA.example) to the provider and enable the provider to generate the keys and manage the DNS for the designated subdomain. In both of these cases, mail would be physically going out of the benefit provider's mail servers with a signature of, e.g., d=benefits.companya.example. Note that the RFC5322.From address is not constrained: it could be affiliated with either the benefits company (e.g., benefits-admin@benefitprovider.example, or benefits-provider@benefits.companya.example) or the companyA domain. Note that in both of the above scenarios, as discussed in Section 3.4, security concerns dictate that the keys be generated by the organization that plans to do the signing so that there is no need to transfer the private key. In other words, the benefits provider would generate keys for both of the above scenarios.
7.5. Independent Third-Party Service Providers
Another way to manage the service provider configuration would be to have the service provider sign the outgoing mail on behalf of its client, Company A, with its own (provider) identifier. For example, an Email Service Provider (ESP A) might want to share its own mailing reputation with its clients, and might sign all outgoing mail from its clients with its own d= domain (e.g., d=espa.example). When the ESP wants to distinguish among its clients, it has two options: o Share the SDID domain and use the AUID value to distinguish among the clients, e.g., a signature on behalf of client A would have d=espa.example and i=@clienta.espa.example (or i=clienta@espa.example). o Extend the SDID domain, so there is a unique value (and subdomain) for each client, e.g., a signature on behalf of client A would have d=clienta.espa.example. Note that this scenario and the delegation scenario are not mutually exclusive. In some cases, it can be desirable to sign the same message with both the ESP and the ESP client identities.7.6. Mail Streams Based on Behavioral Assessment
An ISP (ISP A) might want to assign signatures to outbound mail from its users according to each user's past sending behavior (reputation). In other words, the ISP would segment its outbound traffic according to its own assessment of message quality, to aid recipients in differentiating among these different streams. Since the semantics of behavioral assessments are not valid AUID values, ISP A (ispa.example) can configure subdomains corresponding to the assessment categories (e.g., good.ispa.example, neutral.ispa.example, bad.ispa.example), and use these subdomains in the d= value of the signature. The signing module can also set the AUID value to have a unique user ID (distinct from the local-part of the user's email address), for example, user3456@neutral.domain.example. Using a user ID that is distinct from a given email alias is useful in environments where a single user might register multiple email aliases. Note that in this case, the AUID values are only partially stable. They are stable in the sense that a given i= value will always represent the same identity, but they are unstable in the sense that
a given user can migrate among the assessment subdomains depending on their sending behavior (i.e., the same user might have multiple AUID values over the lifetime of a single account). In this scenario, ISP A can generate as many keys as there are assessment subdomains (SDID values), so that each assessment subdomain has its own key. The signing module would then choose its signing key based on the assessment of the user whose mail was being signed, and if desired, include the user ID in the AUID of the signature. As discussed earlier, the per-user granularity of the AUID can be ignored by verifiers; so organizations choosing to use it ought not rely on its use for receiver side filtering results. However, some organizations might also find the information useful for their own purposes in processing bounces or abuse reports.7.7. Agent or Mediator Signatures
Another scenario is that of an agent, usually a re-mailer of some kind, that signs on behalf of the service or organization that it represents. Some examples of agents might be a mailing list manager, or the "forward article to a friend" service that many online publications offer. In most of these cases, the signature is asserting that the message originated with, or was relayed by, the service asserting responsibility. In general, if the service is configured in such a way that its forwarding would break existing DKIM signatures, it needs to always add its own signature.8. Usage Considerations
8.1. Non-Standard Submission and Delivery Scenarios
The robustness of DKIM's verification mechanism is based on the fact that only authorized signing modules have access to the designated private key. This has the side effect that email submission and delivery scenarios that originate or relay messages from outside the domain of the authorized signing module will not have access to that protected private key, and thus will be unable to attach the expected domain signature to those messages. Such scenarios include mailing lists, courtesy forwarders, MTAs at hotels, hotspot networks used by traveling users, and other paths that could add or modify headers, or modify the message body. For example, assume Joe works for Company A and has an email address joe@companya.example. Joe also has an ISP-1 account joe@isp1.example.com, and he uses ISP-1's multiple address feature to attach his work email address, joe@companya.example, to email from his ISP-1 account. When Joe sends email from his ISP-1 account and uses joe@companya.example as his designated RFC5322.From address,
that email cannot have a signature with d=companya.example because the ISP-1 servers have no access to Company A's private key. In ISP-1's case, it will have an ISP-1 signature, but for some other mail clients offering the same multiple address feature there might be no signature at all on the message. Another example might be the use of a forward article to a friend service. Most instances of these services today allow someone to send an article with their email address in the RFC5322.From to their designated recipient. If Joe used either of his two addresses (joe@companya.example or joe@isp1.example.com), the forwarder would be equally unable to sign with a corresponding domain. As in the mail client case, the forwarder can either sign as its own domain or put no signature on the message. A third example is the use of privately configured forwarding. Assume that Joe has another account at ISP-2, joe@isp-2.example.com, but he'd prefer to read his ISP-2 mail from his ISP-1 account. He sets up his ISP-2 account to forward all incoming mail to joe@isp1.example.com. Assume alice@companyb.example sends joe@isp-2.example.com an email. Depending on how companyb.example configured its signature, and depending on whether or not ISP-2 modifies messages that it forwards, it is possible that when Alice's message is received in Joe's ISP-1 account, the original signature will fail verification.8.2. Protection of Internal Mail
One identity is particularly amenable to easy and accurate assessment: the organization's own identity. Members of an organization tend to trust messages that purport to be from within that organization. However, Internet Mail does not provide a straightforward means of determining whether such mail is, in fact, from within the organization. DKIM can be used to remedy this exposure. If the organization signs all of its mail, then its boundary MTAs can look for mail purporting to be from the organization that does not contain a verifiable signature. Such mail can, in most cases, be presumed to be spurious. However, domain managers are advised to consider the ways that mail processing can modify messages in ways that will invalidate an existing DKIM signature: mailing lists, courtesy forwarders, and other paths that could add or modify headers or modify the message body (e.g., MTAs at hotels, hotspot networks used by traveling users, and other scenarios described in the previous section). Such breakage is particularly relevant in the presence of Author Domain Signing Practices.
8.3. Signature Granularity
Although DKIM's use of domain names is optimized for a scope of organization-level signing, it is possible to administer subdomains or otherwise adjust signatures in a way that supports per-user identification. This user-level granularity can be specified in two ways: either by sharing the signing identity and specifying an extension to the i= value that has a per-user granularity or by creating and signing with unique per-user keys. A subdomain or local part in the i= tag needs to be treated as an opaque identifier and thus need not correspond directly to a DNS subdomain or be a specific user address. The primary way to sign with per-user keys requires each user to have a distinct DNS (sub)domain, where each distinct d= value has a key published. (It is possible, although not advised, to publish the same key in more than one distinct domain.) It is technically possible to publish per-user keys within a single domain or subdomain by utilizing different selector values. This is not advised and is unlikely to be treated uniquely by Assessors: the primary purpose of selectors is to facilitate key management, and the DKIM specification recommends against using them in determining or assessing identities. In most cases, it would be impractical to sign email on a per-user granularity. Such an approach would be likely to be ignored: In most cases today, if receivers are verifying DKIM signatures, they are in general taking the simplest possible approach. In many cases, maintaining reputation information at a per-user granularity is not interesting to them, in large part because the per-user volume is too small to be useful or interesting. So even if senders take on the complexity necessary to support per-user signatures, receivers are unlikely to retain anything more than the base domain reputation. difficult to manage: Any scheme that involves maintenance of a significant number of public keys might require infrastructure enhancements or extensive administrative expertise. For domains of any size, maintaining a valid per-user keypair, knowing when keys need to be revoked or added due to user attrition or onboarding, and the overhead of having the signing engine constantly swapping keys can create significant and often unnecessary management complexity. It is also important to note
that there is no way within the scope of the DKIM specification
for a receiver to infer that a sender intends a per-user
granularity.
As mentioned before, what might make sense, however, is to use the
infrastructure that enables finer granularity in signatures to
identify segments smaller than a domain but much larger than a per-
user segmentation. For example, a university might want to segment
student, staff, and faculty mail into three distinct streams with
differing reputations. This can be done by creating separate
subdomains for the desired segments, and either specifying the
subdomains in the i= tag of the DKIM Signature or by adding
subdomains to the d= tag and assigning and signing with different
keys for each subdomain.
For those who choose to represent user-level granularity in
signatures, the performance and management considerations above
suggest that it would be more effective to do so by specifying a
local part or subdomain extension in the i= tag rather than by
extending the d= domain and publishing individual keys.
8.4. Email Infrastructure Agents
It is expected that the most common venue for a DKIM implementation
will be within the infrastructure of an organization's email service,
such as a department or a boundary MTA. What follows are some
general recommendations for the Email Infrastructure.
Outbound: An MSA (Mail Submission Agent) or an outbound MTA used
for mail submission needs to ensure that the message sent is in
compliance with the advertised email sending policy. It needs
to also be able to generate an operator alert if it determines
that the email messages do not comply with the published DKIM
sending policy.
An MSA needs to be aware that some MUAs might add their own
signatures. If the MSA needs to perform operations on a
message to make it comply with its email sending policy, if at
all possible, it needs to do so in a way that would not break
those signatures.
MUAs equipped with the ability to sign ought not to be
encouraged. In terms of security, MUAs are generally not under
the direct control of those in responsible roles within an
organization and are thus more vulnerable to attack and
compromise, which would expose private signing keys to
intruders and thus jeopardize the integrity and reputation of
the organization.
Inbound: When an organization deploys DKIM, it needs to make
sure that its email infrastructure components that do not have
primary roles in DKIM handling do not modify message in ways
that prevent subsequent verification.
An inbound MTA or an MDA can incorporate an indication of the
verification results into the message, such as using an
Authentication-Results header field [RFC5451].
Intermediaries: An email intermediary is both an inbound and
outbound MTA. Each of the requirements outlined in the
sections relating to MTAs apply. If the intermediary modifies
a message in a way that breaks the signature, the intermediary.
+ needs to deploy abuse filtering measures on the inbound
mail, and
+ probably also needs to remove all signatures that will be
broken.
In addition, the intermediary can:
+ verify the message signature prior to modification.
+ incorporate an indication of the verification results into
the message, such as using an Authentication-Results header
field [RFC5451].
+ sign the modified message including the verification results
(e.g., the Authentication-Results header field).
8.5. Mail User Agent
The DKIM specification is expected to be used primarily between
Boundary MTAs, or other infrastructure components of the originating
and receiving ADMDs. However, there is nothing in DKIM that is
specific to those venues. In particular, MUAs can also support DKIM
signing and verifying directly.
Outbound: An MUA can support signing even if mail is to be
relayed through an outbound MSA. In this case, the signature
applied by the MUA will be in addition to any signature added
by the MSA. However, the warnings in the previous section need
to be taken into consideration.
Some user software goes beyond simple user functionality and
also performs MSA and MTA functions. When this is employed for
sending directly to a receiving ADMD, the user software needs
to be considered an outbound MTA.
Inbound: An MUA can rely on a report of a DKIM signature
verification that took place at some point in the inbound MTA/
MDA path (e.g., an Authentication-Results header field), or an
MUA can perform DKIM signature verification directly. A
verifying MUA needs to allow for the case where mail has been
modified in the inbound MTA path; if a signature fails, the
message is to be treated the same as a message that does not
have a signature.
An MUA that looks for an Authentication-Results header field
needs to be configurable to choose which Authentication-Results
header fields are considered trustable. The MUA developer is
encouraged to re-read the Security Considerations of [RFC5451].
DKIM requires that all verifiers treat messages with signatures
that do not verify as if they are unsigned.
If verification in the client is to be acceptable to users, it
is essential that successful verification of a signature not
result in a less than satisfactory user experience compared to
leaving the message unsigned. The mere presence of a verified
DKIM signature cannot be used by itself by an MUA to indicate
that a message is to be treated better than a message without a
verified DKIM signature. However, the fact that a DKIM
signature was verified can be used as input into a reputation
system (i.e., a whitelist of domains and users) for
presentation of such indicators.
It is common for components of an ADMD's email infrastructure to do
violence to a message, such that a DKIM signature might be rendered
invalid. Hence, users of MUAs that support DKIM signing and/or
verifying need a basis for knowing that their associated email
infrastructure will not break a signature.
9. Security Considerations
The security considerations of the DKIM protocol are described in the
DKIM base specification [RFC4871].
10. Acknowledgements
The effort of the DKIM Working Group is gratefully acknowledged.
11. References
11.1. Normative References
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009. [RFC5585] Hansen, T., Crocker, D., and P. Hallam-Baker, "DomainKeys Identified Mail (DKIM) Service Overview", RFC 5585, July 2009. [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009. [RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update", RFC 5672, August 2009.11.2. Informative References
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4870] Delany, M., "Domain-Based Email Authentication Using Public Keys Advertised in the DNS (DomainKeys)", RFC 4870, May 2007. [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS Security (DNSSEC) Hashed Authenticated Denial of Existence", RFC 5155, March 2008.
Appendix A. Migration Strategies
There are three migration occasions worth noting in particular for DKIM: 1. Migrating from DomainKeys to DKIM. 2. Migrating from a current hash algorithm to a new standardized hash algorithm. 3. Migrating from a current signing algorithm to a new standardized signing algorithm. The case of deploying a new key selector record is described elsewhere (Section 3.5). As with any migration, the steps required will be determined by who is doing the migration and their assessment of: o the users of what they are generating, or o the providers of what they are consuming. Signers and verifiers have different considerations.A.1. Migrating from DomainKeys
DKIM replaces the earlier DomainKeys (DK) specification. Selector files are mostly compatible between the two specifications.A.1.1. Signers
A signer that currently signs with DK will go through various stages as it migrates to using DKIM, not all of which are required for all signers. The real questions that a signer needs to ask are: 1. how many receivers or what types of receivers are *only* looking at the DK signatures and not the DKIM signatures, and 2. how much does the signer care about those receivers? If no one is looking at the DK signature any more, then it's no longer necessary to sign with DK. Or if all "large players" are looking at DKIM in addition to or instead of DK, a signer can choose to stop signing with DK.
With respect to signing policies, a reasonable, initial approach is
to use DKIM signatures in the same way that DomainKeys signatures are
already being used. In particular, the same selectors and DNS key
records can be used for both, after verifying that they are
compatible as discussed below.
Each secondary step in all of the following scenarios is to be
prefaced with the gating factor "test, then when comfortable with the
previous step's results, continue".
One migration strategy is to:
o ensure that the current selector DNS key record is compatible with
both DK and DKIM
o sign messages with both DK and DKIM signatures
o when it's decided that DK signatures are no longer necessary, stop
signing with DK
Another migration strategy is to:
o add a new selector DNS key record only for DKIM signatures
o sign messages with both DK (using the old DNS key record) and DKIM
signatures (using the new DNS key record)
o when it's decided that DK signatures are no longer necessary, stop
signing with DK
o eventually remove the old DK selector DNS record
A combined migration strategy is to:
o ensure that the current selector DNS key record is compatible with
both DK and DKIM
o start signing messages with both DK and DKIM signatures
o add a new selector DNS key record for DKIM signatures
o switch the DKIM signatures to use the new selector
o when it's decided that DK signatures are no longer necessary, stop
signing with DK
o eventually remove the old DK selector DNS record
Another migration strategy is to:
o add a new selector DNS key record for DKIM signatures
o do a flash cut and replace the DK signatures with DKIM signatures
o eventually remove the old DK selector DNS record
Another migration strategy is to:
o ensure that the current selector DNS key record is compatible with
both DK and DKIM
o do a flash cut and replace the DK signatures with DKIM signatures
Note that when you have separate key records for DK and DKIM, you can
use the same public key for both.
A.1.1.1. DNS Selector Key Records
The first step in some of the above scenarios is ensuring that the
selector DNS key records are compatible for both DK and DKIM. The
format of the DNS key record was intentionally meant to be backwardly
compatible between the two systems, but not necessarily upwardly
compatible. DKIM has enhanced the DK DNS key record format by adding
several optional parameters, which DK needs to ignore. However,
there is one critical difference between DK and DKIM DNS key records.
The definitions of the "g" fields:
g= granularity of the key: In both DK and DKIM, this is an optional
field that is used to constrain which sending address(es) can
legitimately use this selector. Unfortunately, the treatment of
an empty field ("g=;") is different. DKIM allows wildcards where
DK does not. For DK, an empty field is the same as a missing
value, and is treated as allowing any sending address. For DKIM,
an empty field only matches an empty local part. In DKIM, both a
missing value and "g=*;" mean to allow any sending address.
Also, in DomainKeys, the "g" field is required to match the
address in "From:"/"Sender:", while in DKIM, it is required to
match i=. This might or might not affect transition.
If your DK DNS key record has an empty "g" field in it ("g=;"),
your best course of action is to modify the record to remove the
empty field. In that way, the DK semantics will remain the same,
and the DKIM semantics will match.
If your DNS key record does not have an empty "g" field in it
("g=;"), it's probable that the record can be left alone. But the
best course of action would still be to make sure that it has a
"v" field. When the decision is made to stop supporting
DomainKeys and to only support DKIM, it is important to verify
that the "g" field is compatible with DKIM, and typically having
"v=DKIM1;" in it. It is strongly encouraged that if use of an
empty "g" field in the DKIM selector, include the "v" field.
A.1.1.2. Removing DomainKeys Signatures
The principal use of DomainKeys is at boundary MTAs. Because no
operational transition is ever instantaneous, it is advisable to
continue performing DomainKeys signing until it is determined that
DomainKeys receive-side support is no longer used, or is sufficiently
reduced. That is, a signer needs to add a DKIM signature to a
message that also has a DomainKeys signature and keep it there until
they decide it is deemed no longer useful. The signer can do its
transitions in a straightforward manner, or more gradually. Note
that because digital signatures are not free, there is a cost to
performing both signing algorithms, so signing with both algorithms
ought not be needlessly prolonged.
The tricky part is deciding when DK signatures are no longer
necessary. The real questions are: how many DomainKeys verifiers are
there that do *not* also do DKIM verification, which of those are
important, and how can you track their usage? Most of the early
adopters of DK verification have added DKIM verification, but not all
yet. If a verifier finds a message with both DK and DKIM, it can
choose to verify both signatures, or just one or the other.
Many DNS services offer tracking statistics so it can be determined
how often a DNS record has been accessed. By using separate DNS
selector key records for your signatures, you can chart the use of
your records over time, and watch the trends. An additional
distinguishing factor to track would take into account the verifiers
that verify both the DK and DKIM signatures, and discount those from
counts of DK selector usage. When the number for DK selector access
reaches a low-enough level, that's the time to consider discontinuing
signing with DK.
Note, this level of rigor is not required. It is perfectly
reasonable for a DK signer to decide to follow the "flash cut"
scenario described above.
A.1.2. Verifiers
As a verifier, several issues need to be considered:A.1.2.1. Ought DK signature verification be performed?
At the time of writing, there is still a significant number of sites that are only producing DK signatures. Over time, it is expected that this number will go to zero, but it might take several years. So it would be prudent for the foreseeable future for a verifier to look for and verify both DKIM and DK signatures.A.1.2.2. Ought both DK and DKIM signatures be evaluated on a single message?
For a period of time, there will be sites that sign with both DK and DKIM. A verifier receiving a message that has both types of signatures can verify both signatures, or just one. One disadvantage of verifying both signatures is that signers will have a more difficult time deciding how many verifiers are still using their DK selectors. One transition strategy is to verify the DKIM signature, then only verify the DK signature if the DKIM verification fails.A.1.2.3. DNS Selector Key Records
The format of the DNS key record was intentionally meant to be backwardly compatible between DK and DKIM, but not necessarily upwardly compatible. DKIM has enhanced the DK DNS key record format by adding several optional parameters, which DK needs to ignore. However, there is one key difference between DK and DKIM DNS key records. The definitions of the g fields: g= granularity of the key: In both DK and DKIM, this is an optional field that is used to constrain which sending address(es) can legitimately use this selector. Unfortunately, the treatment of an empty field ("g=;") is different. For DK, an empty field is the same as a missing value, and is treated as allowing any sending address. For DKIM, an empty field only matches an empty local part. v= version of the selector It is advised that a DKIM selector have "v=DKIM1;" at its beginning, but it is not required. If a DKIM verifier finds a selector record that has an empty "g" field ("g=;") and it does not have a "v" field ("v=DKIM1;") at its beginning, it is faced with deciding if this record was:
1. from a DK signer that transitioned to supporting DKIM but forgot
to remove the "g" field (so that it could be used by both DK and
DKIM verifiers); or
2. from a DKIM signer that truly meant to use the empty "g" field
but forgot to put in the "v" field. It is advised that you treat
such records using the first interpretation, and treat such
records as if the signer did not have a "g" field in the record.
A.2. Migrating Hash Algorithms
[RFC4871] defines the use of two hash algorithms: SHA-1 and SHA-256.
The security of all hash algorithms is constantly under attack, and
SHA-1 has already shown weaknesses as of this writing. Migrating
from SHA-1 to SHA-256 is not an issue, because all verifiers are
already required to support SHA-256. But when it becomes necessary
to replace SHA-256 with a more secure algorithm, there will be a
migratory period. In the following, "NEWHASH" is used to represent a
new hash algorithm. Section 4.1 of [RFC4871] briefly discusses this
scenario.
A.2.1. Signers
As with migrating from DK to DKIM, migrating hash algorithms is
dependent on the signer's best guess as to the utility of continuing
to sign with the older algorithms and the expected support for the
newer algorithm by verifiers. The utility of continuing to sign with
the older algorithms is also based on how broken the existing hash
algorithms are considered and how important that is to the signers.
One strategy is to wait until it's determined that there is a large
enough base of verifiers available that support NEWHASH, and then
flash cut to the new algorithm.
Another strategy is to sign with both the old and new hash algorithms
for a period of time. This is particularly useful for testing the
new code to support the new hash algorithm, as verifiers will
continue to accept the signature for the older hash algorithm and
ought to ignore any signature that fails because the code is slightly
wrong. Once the signer has determined that the new code is correct
AND it's determined that there is a large enough base of verifiers
available that support NEWHASH, the signer can flash cut to the new
algorithm.
One advantage migrating hash algorithms has is that the selector can
be completely compatible for all hash algorithms. The key selector
has an optional "h=" field that can be used to list the hash
algorithms being used; it also is used to limit the algorithms that a
verifier will accept. If the signer is not currently using the key selector "h=" field, no change is required. If the signer is currently using the key selector "h=" field, NEWHASH will need to be added to the list, as in "h=sha256:NEWHASH;". (When the signer is no longer using SHA-256, it can be removed from the "h=" list.)A.2.2. Verifiers
When a new hash algorithm becomes standardized, it is best for a verifier to start supporting it as quickly as possible.A.3. Migrating Signing Algorithms
[RFC4871] defines the use of the RSA signing algorithm. Similar to hashes, signing algorithms are constantly under attack, and when it becomes necessary to replace RSA with a newer signing algorithm, there will be a migratory period. In the following, "NEWALG" is used to represent a new signing algorithm.A.3.1. Signers
As with the other migration issues discussed above, migrating signing algorithms is dependent on the signer's best guess as to the utility of continuing to sign with the older algorithms and the expected support for the newer algorithm by verifiers. The utility of continuing to sign with the older algorithms is also based on how broken the existing signing algorithms are considered and how important that is to the signers. As before, the two basic strategies are to 1) wait until there is sufficient base of verifiers available that support NEWALG and then do a flash cut to NEWALG, and 2) use a phased approach by signing with both the old and new algorithms before removing support for the old algorithm. It is unlikely that a new algorithm would be able to use the same public key as "rsa", so using the same selector DNS record for both algorithms' keys is ruled out. Therefore, in order to use the new algorithm, a new DNS selector record would need to be deployed in parallel with the existing DNS selector record for the existing algorithm. The new DNS selector record would specify a different "k=" value to reflect the use of NEWALG.
A.3.2. Verifiers
When a new hash algorithm becomes standardized, it is best for a verifier to start supporting it as quickly as possible.Appendix B. General Coding Criteria for Cryptographic Applications
NOTE: This section could possibly be changed into a reference to something else, such as another RFC. Correct implementation of a cryptographic algorithm is a necessary but not a sufficient condition for the coding of cryptographic applications. Coding of cryptographic libraries requires close attention to security considerations that are unique to cryptographic applications. In addition to the usual security coding considerations, such as avoiding buffer or integer overflow and underflow, implementers need to pay close attention to management of cryptographic private keys and session keys, ensuring that these are correctly initialized and disposed of. Operating system mechanisms that permit the confidentiality of private keys to be protected against other processes ought to be used when available. In particular, great care needs to be taken when releasing memory pages to the operating system to ensure that private key information is not disclosed to other processes. Certain implementations of public key algorithms such as RSA can be vulnerable to a timing analysis attack. Support for cryptographic hardware providing key management capabilities is strongly encouraged. In addition to offering performance benefits, many cryptographic hardware devices provide robust and verifiable management of private keys. Fortunately, appropriately designed and coded cryptographic libraries are available for most operating system platforms under license terms compatible with commercial, open source and free software license terms. Use of standard cryptographic libraries is strongly encouraged. These have been extensively tested, reduce development time and support a wide range of cryptographic hardware.
Authors' Addresses
Tony Hansen AT&T Laboratories 200 Laurel Ave. South Middletown, NJ 07748 USA EMail: tony+dkimov@maillennium.att.com Ellen Siegel Consultant EMail: dkim@esiegel.net Phillip Hallam-Baker Default Deny Security, Inc. EMail: phillip@hallambaker.com Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 USA EMail: dcrocker@bbiw.net