RFC 5016

Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol

📅 published October 2007, from ietf

RFC 5016: Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol 💌

Okay bestie, let's talk about RFC 5016 🎀. It was written by M. Thomas from Cisco Systems, it's an Informational document, and it's dated October 2007 ✨. It doesn't obsolete or update any other RFCs, since its header doesn't list either. It's all about the requirements for a way for domains to publish their DKIM signing practices, so it's basically the to-do list for the protocol 🧚.

Status of This Memo ✨

This memo is here to give the Internet community some info 📚. It isn't an Internet standard of any kind, and distribution is unlimited, so share away 💅.

Abstract 🦋

DKIM gives domains a cryptographic way to say they're responsible for the messages they handle 🔐. This doc says a related mechanism will let an admin publish statements about their DKIM signing practices, and it lays out the requirements for that mechanism. It splits them up into the ones that must be satisfied (MUST) and the ones that are highly desirable (SHOULD) 💜.

Table of Contents 🌸

   1. Introduction ....................................................2
   2. Definitions and Requirements Language ...........................3
   3. SSP Problem Scenarios ...........................................4
      3.1. Problem Scenario 1: Is All Mail Signed with DKIM? ..........4
      3.2. Problem Scenario 2: Illegitimate Domain Name Use ...........5
   4. SSP Deployment Considerations ...................................6
      4.1. Deployment Consideration 1: Outsourced Signing .............6
      4.2. Deployment Consideration 2: Subdomain Coverage .............6
      4.3. Deployment Consideration 3: Resent Original Mail ...........7
      4.4. Deployment Consideration 4: Incremental Deployment
           of Signing .................................................7
      4.5. Deployment Consideration 5: Performance and Caching ........8
      4.6. Deployment Consideration 6: Human Legibility of Practices ..8
      4.7. Deployment Consideration 7: Extensibility ..................8
      4.8. Deployment Consideration 8: Security .......................8
   5. Requirements ....................................................9
      5.1. Discovery Requirements .....................................9
      5.2. SSP Transport Requirements ................................10
      5.3. Practice and Expectation Requirements .....................10
      5.4. Extensibility and Forward Compatibility Requirements ......13
   6. Requirements for SSP Security ..................................13
   7. Security Considerations ........................................13
   8. Acknowledgments ................................................13
   9. References .....................................................14
      9.1. Normative References ......................................14

1. Introduction 🌈

DKIM ([RFC4871]) is the message-level signing and verification mechanism for email 💌. A DKIM-signed message can vouch for itself, but things get fuzzy when a message doesn't have a valid first party signature (meaning one on behalf of the [RFC2822].From address). Is that normal, or is something sus? 🙈 For email this is a seriously tricky problem, because there's no expectation that a receiver already knows a sending domain's practices. This fuzziness can be used for a bid-down attack, which comes with systems like email that allow optional authentication 😭. If a receiver doesn't know any better, it should not assume that a missing valid signature is exceptional without other information. So an attacker can exploit that gap and just not sign their messages 💀. If a protocol let a domain publish its DKIM signing practices, a message verifier could factor that in whenever it gets an unsigned email 🦋.

This document defines the requirements for a mechanism that allows the publication of Sender Signing Practices (SSP) 🎀. It's organised into two main parts. First up is a Problem and Deployment Scenario section, covering the problems SSP is meant to address and the deployment issues around those base problems. Second is the Requirements section, which comes from those scenarios 📋.

2. Definitions and Requirements Language 💅

  • Domain Holder: the entity that controls the contents of the DNS subtree starting at the domain, either directly or by delegation via NS records it controls.
  • First Party Address: for DKIM, a first party address is defined to be the [RFC2822].From address in the message header; a first party address is also known as an Author address.
  • First Party Signature: a first party signature is a valid signature where the signing identity (the d= tag or the more specific identity i= tag) matches the first party address. "Matches" in this context is defined in [RFC4871].
  • Third Party Signature: a third party signature is a valid signature that does not qualify as a first party signature. Note that a DKIM third party signature is not required to correspond to a header field address such as the contents of Sender or List-Id, etc.
  • Practice: a statement according to the [RFC2822].From domain holder of externally verifiable behavior in the email messages it sends.
  • Expectation: an expectation combines with a practice to convey what the domain holder considers the likely survivability of the practice for a receiver, in particular receivers that may be more than one SMTP hop away.
  • DKIM Signing Complete: a practice where the domain holder asserts that all legitimate mail will be sent with a valid first party signature.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

3. SSP Problem Scenarios 🕵️‍♀️

The email world is super diverse, with lots of deployment considerations 🌍. This section walks through the usage scenarios where DKIM signing and verifying happen, and how a new protocol could help make the relevance of DKIM-signed mail clearer ✨.

3.1. Problem Scenario 1: Is All Mail Signed with DKIM? 📬

After auditing their outgoing mail and deploying DKIM signing for all of their legitimate outgoing mail, a domain could be said to be DKIM signing complete 🥳. That means the domain has, to the best of its ability, made sure that all legitimate mail claiming to come from that domain contains a valid DKIM signature.

In the general case, a receiver doesn't know what the practices are for a given domain 🤷‍♀️. So the receiver is at a disadvantage, because it doesn't know whether it should expect all mail from that domain to be signed. That knowledge gap leads to a trivially exploitable bid-down attack, where the attacker just sends unsigned mail. Since the receiver doesn't know the signing domain's practices, it can't treat the message any more harshly for lacking a valid signature 😤.

An information service that lets a receiver query the practices and expectations of the first party domain when no valid first party signature is found could help close this gap 🌸. A receiver could use that info to treat questionable mail with varying degrees of prejudice.

Note that, for the foreseeable future, unrestricted mail usage (for example, where users are members of mailing lists, etc.) will likely suffer occasional, non-malicious signature failures in transit 🚚. It's probably not a large percentage of total traffic, but this kind of breakage may be a significant concern for those usage patterns. This scenario covers the case where the sender can't set any expectation about whether an individual message will arrive intact.

Even without that expectation, a receiver may be able to use the knowledge that the domain's practice is to sign all mail, and bias its filters against mail that is unsigned or damaged in transit 🔍. This information should not be expected to be used in a binary yes/no fashion. Instead, it should be one data point among others in a filtering system 💖.

The following exchange illustrates problem scenario 1 🎬:

  1. Mail with a [RFC2822].From domain Alice is sent to domain Bob with a missing or broken DKIM first party signature from Alice.
  2. Domain Bob would like to know whether that is an expected state of affairs.
  3. Domain Alice provides information that it signs all outgoing mail, but places no expectation on whether it will arrive with an intact first party signature.
  4. Domain Bob could use this information to bias its filters to examine the message with some suspicion.

3.2. Problem Scenario 2: Illegitimate Domain Name Use 🚨

A class of mail typified by transactional mail from high-value domains is currently the target of phishing attacks 😱. Many phishing scams forge the [RFC2822].From address and also spoof much of the content, to trick unsuspecting users into revealing sensitive information 💀. Domain holders sending this mail would like to be able to give an enhanced guarantee that mail sent with their domain name should always arrive with proof that the domain holder consented to its transmission 👑. That means the message should contain a valid first party signature as defined above.

From a receiver's standpoint, knowing that a domain not only signs all of its mail, but also places a very high value on receiving a valid first party signature from that domain, is really helpful 💅. So a receiver knows that the sending domain signs all its mail, and that the sending domain considers mail from it particularly sensitive in some sense. It's asking the receiver to be more suspicious than it otherwise might be of a broken or missing first-party signature. A receiver with knowledge of the sender's expectations might choose to process messages that don't conform to the published practices in a special manner. Note that the ability to state an enhanced guarantee of a valid signature means senders should expect that mail traversing modifying intermediaries (for example, mailing lists, etc.) will likely be quarantined or deleted. So this scenario is narrower than problem scenario 1 🎯.

Informative Note: a receiving filter may choose to treat scenario 2 much more harshly than scenario 1; where scenario 1 looks odd, scenario 2 looks like something is very wrong 🚩.
  1. Mail with a [RFC2822].From domain Alice is sent to domain Bob with a missing or broken first party DKIM signature from domain Alice.
  2. Domain Bob would like to know whether that is an expected state of affairs.
  3. Domain Alice provides information that it signs all outgoing mail, and furthermore places an expectation that it should arrive with an intact first party signature, and that the receiver should be much more wary if it does not.
  4. Domain Bob could use this information to bias its filters such that it examines the message with great suspicion.

4. SSP Deployment Considerations 🛠️

Okay, so we've got the problems SSP is supposed to help recipients with 🎀. But there's also a bunch of scenarios that aren't really about those problems themselves. These are about the actual mechanics of implementing and deploying the information service that SSP would provide 🧁.

4.1. Deployment Consideration 1: Outsourced Signing 🫶

Okay so, lots of domains don't run their own mail infrastructure, or they hand parts of it off to third parties 📬. It's really desirable for a domain holder to be able to delegate signing to other entities so those entities can sign for the domain holder 💅. The obvious example is a small domain whose outgoing ISP needs to sign all of its mail on the domain holder's behalf ✨. Other vibes include outsourced bulk mail for marketing campaigns, plus outsourcing business stuff like insurance benefits, etc. 💼

4.2. Deployment Consideration 2: Subdomain Coverage 🌸

An SSP client does lookups on incoming mail streams so it can provide the info we talked about in the problem scenarios 🔍. The domain part of the first address of the [RFC2822].From is the basis for fetching the published info. Here's the tea: a super easy way to dodge finding the published info is to just use a subdomain of the parent domain that doesn't have any published info 🙈. This is called the subdomain attack. A domain wants to publish a policy for a DNS label it controls, but it also wants to protect every subdomain under that label 🛡️. If that isn't covered, an attacker only needs to make up a possibly fictitious subdomain that the SSP information service doesn't cover. So it would be a total win for SSP to cover not just a given domain, but all of its subdomains too 👑.

4.3. Deployment Consideration 3: Resent Original Mail 🔁

Resent mail is literally everywhere in email today 💌. For example, domain Alice sends a DKIM-signed message, and she has a published practice of signing all messages going to domain Bob's mailing list. Bob is a good net citizen 🫡, so he wants to take responsibility for his part of the message, and he DKIM signs it, maybe matching the Sender address.

Note that this is totally separate from whether Alice's signature survived Bob's mailing list 🤷‍♀️. Bob just wants to assert his part in the chain of accountability for the ultimate receivers. It would be great to encourage this, because it gives a more accurate picture of who handled the message 📸. It also has a bonus perk: remailers that break DKIM first-party signatures can potentially be assessed by the receiver, based on the receiver's opinion of the signing domains that actually survived 🦋.

4.4. Deployment Consideration 4: Incremental Deployment of Signing 🧩

Real talk, it can be hard for a domain to roll out DKIM signing well enough to publish the DKIM Signing Complete practice 😭. There's a whole user population, outsourced vendors sending on its behalf, and so on. That leaves an exploit open: high-value mail, like in Problem Scenario 2, has to be classified at the least common denominator of the published practices 💀. It would be desirable to let a domain holder publish a list of exceptions with a stricter practices statement 🔒. NB: this consideration has been deemed met by the mechanisms the base DKIM signing mechanism already provides. It's only documented here because it was an issue 🎀.

For example, bigbank.example.com might be ready to say that statements@bigbank.example.com is always signed, but the rest of the domain isn't. Another situation is when the practices for some local parts in a domain aren't the same as the practices for other local parts. Using the same example, statements@bigbank.example.com is transactional email that wants to publish really strong practices 🏦, while the rest of the user population's local parts may go through mailing lists and so on, where a less strong statement is appropriate 🌈.

Also, DKIM can already support this kind of differentiation through subdomains ✨. If you want to publish a strong practice, you just segregate those cases into different subdomains. For example, accounts.bigbank.example.com would publish constrained practices, while corporateusers.bigbank.example.com might publish more permissive practices 💅.

4.5. Deployment Consideration 5: Performance and Caching ⚡

Email is an any-any mesh of potential connections 🕸️. All that's required is publishing an MX record and an SMTP listener to receive mail. So SSP is likely to fall into two main scenarios. The first is large, well-known domains that are in constant contact with one another 🏢. In that case, caching records is essential for performance, including caching the non-existence of records (i.e., negative caching) 🧠.

The second main scenario is when a domain exchanges mail with a much smaller-volume domain 🪴. This can be perfectly normal, like with vanity domains, but unfortunately it can also be a vector for people sending mail for anti-social reasons 😤. Here we'd like the message exchange burden on the SSP querier to be low, since many lookups won't give a useful answer. It would also be a big help to have upstream caching here, so that, say, a mailing list exploder on a small domain doesn't cause an explosion of queries back at the root and authoritative server for the small domain 💥.

4.6. Deployment Consideration 6: Human Legibility of Practices 👀

SSP records will mostly be consumed by an automaton, but for the foreseeable future humans are also going to be inspecting them by hand 🤓. It would be nice to state the practices in a way that's also intuitive for those human inspectors 🎀.

4.7. Deployment Consideration 7: Extensibility 🧚

This document is only about DKIM signing practice requirements, but it would be beneficial for the protocol to be able to extend to other protocols too 🦋.

4.8. Deployment Consideration 8: Security 🔐

SSP must be able to withstand life in a hostile, open-Internet environment 😈. That includes DoS attacks, and especially DoS attacks that feed themselves through amplification inherent in the protocol 🔥. Also, a useful protocol can be built without strong source authentication from the information service, but a path to strong source authentication should be provided by the protocol or the underlying protocols 🔑.

5. Requirements 📋

This section defines the requirements for SSP ✨. Like most requirements documents, these define the minimum requirements a candidate protocol must provide. It should also be noted that SSP must fulfill all of the requirements 💯.

5.1. Discovery Requirements 🔎

Receivers need a way to get info about a sender's DKIM practices 📨. That means they need a way to discover where the info is and what it contains.

  1. The author is the first-party sender of a message, as specified in the [RFC2822].From field 💌. SSP's information is associated with the author's domain name, and it's published subordinate to that domain name 🏷️.
  2. To limit the cost of using it, any query service supplying SSP's information MUST provide a definitive response within a small, deterministic number of message exchanges under normal operational conditions ⏱️.

Informative Note: this is, for all intents and purposes, a prohibition on anything that might produce loops or result in extended delays and overhead 🙅‍♀️. Also, even though "deterministic" doesn't specify how many exchanges, the expectation is "few" 🤏.

Refs: Deployment Considerations, Sections 4.2 and 4.5.

  1. SSP's publishing mechanism MUST be defined such that it does not lead to multiple resource records of the same type for different protocols residing at the same location 🚫.

Informative note: an example is multiple resource records of the same type within a common DNS leaf 🍂. So uniquely defined leaf names or uniquely defined resource record types will ensure unambiguous referencing 🎯.

Refs: Deployment Consideration, Section 4.2.

  1. SSP retrieval SHOULD provide coverage for not only a given domain but all of its subdomains as well 🌳. It's recognized that there's some reasonable doubt about whether a widely accepted solution to this is feasible 🤔. If the working group does not achieve rough consensus on a solution, it MUST document the relevant security considerations in the protocol specification 📝.

Refs: Deployment Considerations, Sections 4.2 and 4.5.

5.2. SSP Transport Requirements 🚚

The publication and query mechanism will operate as an internet-based message exchange 🌐. There are several requirements for this lower-layer service:

  1. The exchange SHOULD have existing widespread deployment of the transport layer, especially if it rides on top of a true transport layer (e.g., TCP, UDP) 🛣️.

Refs: Deployment Considerations, Sections 4.5 and 4.7.

  1. The query/response, in terms of latency and the number of messages involved, MUST be low (less than three message exchanges, not counting retransmissions or other exceptional conditions) 🏃‍♀️💨.

Refs: Deployment Consideration, Section 4.5.

  1. If the infrastructure doesn't provide caching (à la DNS), the records retrieved MUST provide initiators the ability to maintain their own cache 🧁. The existing caching infrastructure is, however, highly desirable 💖.

Refs: Deployment Consideration, Section 4.5.

  1. Multiple geographically and topologically diverse servers MUST be supported for high availability 🌍✨.

Refs: Deployment Considerations, Sections 4.5 and 4.7.

5.3. Practice and Expectation Requirements 💅

okay so, remember how a practice is a statement from the domain holder about externally verifiable behaviour in the emails it sends? 💖 Like, a practice could say every email will carry a DKIM signature matching the [RFC2822].From address 🎀. But things can get altered between what the sender sends and what the receiver actually looks at, so an expectation teams up with the practice to say how likely the practice is to survive the trip to a receiver 🦋. Example: the practice is "a valid DKIM for the [RFC2822].From address is present when sent from the domain," and the expectation is "it'll stay present and valid for every receiver, whether they're right next door or way across the network" 😭✨.

  1. SSP MUST be able to make practices and expectation assertions about the domain part of a [RFC2822].From address in the context of DKIM. SSP will not make assertions about other addresses for DKIM at this time.

Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.

  1. SSP MUST provide a concise linkage between the [RFC2822].From and the identity in the DKIM i= tag, or its default if it's missing from the signature. Basically, SSP MUST precisely define what counts as a first party signature 🔥.

Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.

  1. SSP MUST be able to publish a practice saying the domain's signing behaviour is "DKIM Signing Complete." Translation: every message was sent with a valid first party signature 🌈.

Refs: Problem Scenario 1, Section 3.1.

  1. SSP MUST be able to publish an expectation that a verifiable first party DKIM signature should be expected when a message is received 🧚.

Refs: Problem Scenario 2, Section 3.2.

  1. Practices and expectations MUST be presented in SSP syntax using the most intuitive descriptor possible. For example, p=? would be better written as p=unknown 🙈.

Refs: Deployment Consideration, Section 4.6.

  1. Because DKIM uses DNS to store selectors, a domain holder can always delegate all or part of the _domainkey subdomain to an affiliated party of their choosing 🍓. Like, the domain holder can set an NS record for _domainkey.example.com to hand the whole namespace to an email provider. They can also split their namespace into subdomains to box in third parties even more. For example, a domain holder could delegate only _domainkey.benefits.example.com to a third party, so that party can only produce valid signatures inside benefits.example.com 👑. And last but not least, a domain holder can even use CNAME's to delegate individual leaf nodes 💜. With all of that covered, SSP need not invent a different way for affiliated parties to sign on a domain's behalf at this time 💅.

Refs: Deployment Consideration, Section 4.4.

  1. Practices and expectations MUST be presented as an information service from the signing domain, to be consumed as one added factor in the receiver's local policy 🦋. Specifically, a practice or expectation MUST NOT mandate any disposition stance on the receiver. Not your call, bestie 🙅‍♀️.

Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.

  1. There's no requirement that SSP publish practices of any or all third parties that MUST NOT sign on the domain holder's behalf 🌸. This should be considered out of scope.

INFORMATIVE NOTE: this is basically saying the protocol doesn't have to be a blacklist repository 💀.

Refs: Problem Scenarios 1 and 2, Sections 3.1 and 3.2.

  1. SSP MUST NOT be required to be invoked if a valid first party signature is found ✨.

Refs: Deployment Consideration, Section 4.2.

  1. SSP MUST NOT provide a mechanism that impugns the existence of non-first party signatures in a message 😤. A corollary of this requirement is that the protocol MUST NOT link practices of first party signers with the practices of third party signers.

INFORMATIVE NOTE: the main thrust here is that practices should only be published for things the publisher actually controls, and should not meddle in what is ultimately the receiver's local policy 🫶.

Refs: Deployment Consideration, Section 4.3.

5.4. Extensibility and Forward Compatibility Requirements 🌈

  1. SSP MUST NOT extend to any protocol other than DKIM for email at this time. SSP SHOULD be extensible for protocols other than DKIM 🧚.

Refs: Deployment Consideration, Section 4.7.

  1. SSP MUST be able to add new practices and expectations within the existing discovery/transport/practices in a backward compatible fashion 🎀.

Refs: Deployment Consideration, Section 4.7.

6. Requirements for SSP Security 🔐

  1. SSP for a high-value domain is potentially a high-value DoS target 😭, especially since the unavailability of SSP's record could make unsigned messages look less suspicious. Big yikes.
  2. SSP MUST NOT make highly leveraged amplification or make-work attacks possible 💀. In particular, the work and message exchanges involved MUST be order of a constant.

Refs: Deployment Consideration, Section 4.8.

  1. SSP MUST have the ability for a domain holder to provide SSP's data so a receiver can determine that it's authentically from the domain holder with a large degree of certainty 👑. SSP may provide means that offer less certainty in exchange for ease of deployment.

Refs: Deployment Consideration, Section 4.8.

7. Security Considerations 🚨

Okay, this part is serious, bestie. This document defines requirements for a new protocol, and the security related requirements are defined above 🔥. Since the new protocol is expected to use the DNS as a basis for the published SSP information, most if not all of the threats described in [RFC4686] will be applicable 😱. Read [RFC4686], no cap.

8. Acknowledgments 🫶

Dave Crocker and Jim Fenton gave substantial review to this document, and we're so grateful 💖. Thanks also to Vijay Gurbani and David Harrington for their helpful last call reviews 🌸.

9. References 📚

9.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2822]  Resnick, P., Ed., "Internet Message Format", RFC 2822,
           April 2001.

[RFC4686]  Fenton, J., "Analysis of Threats Motivating DomainKeys
           Identified Mail (DKIM)", RFC 4686, September 2006.

[RFC4871]  Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
           J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
           Signatures", RFC 4871, May 2007.

Author's Address 🖋️

Michael Thomas
Cisco Systems
606 Sanchez St
San Francisco, California  94114
USA

Phone: +1-408-525-5386
Fax:   +1-408-525-5386
EMail: mat@cisco.com

Copyright (C) The IETF Trust (2007).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🌷

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document, or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification, can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. 💜🦋

📦 where this page comes from