Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5863

DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations

Pages: 51
Informational
Part 3 of 3 – Pages 31 to 51
First   Prev   None

Top   ToC   RFC5863 - Page 31   prevText

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.
Top   ToC   RFC5863 - Page 32
   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.
Top   ToC   RFC5863 - Page 33
   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.
Top   ToC   RFC5863 - Page 34
   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.
Top   ToC   RFC5863 - Page 35

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
Top   ToC   RFC5863 - Page 36
   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,
Top   ToC   RFC5863 - Page 37
   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.
Top   ToC   RFC5863 - Page 38

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
Top   ToC   RFC5863 - Page 39
      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.
Top   ToC   RFC5863 - Page 40
      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.
Top   ToC   RFC5863 - Page 41
         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.
Top   ToC   RFC5863 - Page 42

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.
Top   ToC   RFC5863 - Page 43

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.
Top   ToC   RFC5863 - Page 44
   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
Top   ToC   RFC5863 - Page 45
   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.
Top   ToC   RFC5863 - Page 46
      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.
Top   ToC   RFC5863 - Page 47

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:
Top   ToC   RFC5863 - Page 48
   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
Top   ToC   RFC5863 - Page 49
   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.
Top   ToC   RFC5863 - Page 50

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.
Top   ToC   RFC5863 - Page 51

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