tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5863

 
 
 

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

Part 3 of 3, p. 31 to 51
Prev RFC Part

 


prevText      Top      Up      ToC       Page 31 
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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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      Up      ToC       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