RFC 6541

DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures

📅 published February 2012, from ietf

RFC 6541 🎀 DomainKeys Identified Mail (DKIM) Authorized Third-Party Signatures

okay bestie, the big facts first 💌 this is RFC 6541, written by M. Kucherawy at Cloudmark, Inc. for the IETF. it's an Experimental doc dated February 2012, with ISSN 2070-1721. it doesn't list anything it obsoletes or updates, so it's giving independent main character energy 💅

Abstract

okay so this experimental spec proposes a tweak to DomainKeys Identified Mail (DKIM) 💌 that lets a domain advertise third-party signature authorizations. the idea is that a signature from someone else gets treated as equivalent to a signature added by the administrative domain of the message's author. it's giving trust transfer 🫶

Status of This Memo

this document is not an Internet Standards Track spec 🙈 it's published for examination, experimental implementation, and evaluation.

it defines an Experimental Protocol for the Internet community. it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🌸 it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the details 📚

info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc6541 ✨

Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. 🦋

this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. please actually read these, bestie, they spell out your rights and restrictions 🫶

if you extract Code Components from this document, they have to include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 💜

Table of Contents

1. Introduction ....................................................2
2. Definitions .....................................................3
   2.1. Key Words ..................................................3
   2.2. Email Architecture Terminology .............................3
3. Roles and Scope .................................................3
4. Queries and Replies .............................................4
   4.1. Hash Selection .............................................4
   4.2. Extension to DKIM ..........................................5
   4.3. ATPS Query Details .........................................5
   4.4. ATPS Reply Details .........................................7
5. Interpretation ..................................................8
6. Relationship to ADSP ............................................8
7. Experiment Process ..............................................8
8. IANA Considerations .............................................9
   8.1. ATPS Tag Registry ..........................................9
   8.2. Email Authentication Methods Registry Update ..............10
   8.3. Email Authentication Result Names Registry Update .........10
   8.4. DKIM Signature Tag Specifications Registry ................12
9. Security Considerations ........................................12
   9.1. Hash Selection ............................................12
   9.2. False Privacy .............................................12
   9.3. Transient Security Failures ...............................13
   9.4. Load on the DNS ...........................................13
10. References ....................................................13
   10.1. Normative References .....................................13
   10.2. Informative References ...................................14
Appendix A. Example Query and Reply ...............................15
Appendix B. Choice of DNS RR Type .................................15
Appendix C. Acknowledgements ......................................16

1. Introduction ✨

okay so [DKIM] defines a mechanism for transparent domain-level signing of messages. the point is to declare that a particular ADministrative Management Domain (ADMD) takes some responsibility for a message 💅

here's the tea though: DKIM deliberately makes no binding between the DNS domain of the Signer and any other identity found in the message 🙃 even so, people automatically perceive an Author Domain Signature (one where the RFC5322.From domain matches the DNS domain of the Signer) as more valuable or trustworthy than any other kind. it's giving unfair vibes but it's real 😭

to let a third party apply DKIM signatures to messages, the DKIM spec suggests delegating either subdomains or private keys to them, so the third party can add signatures that look like they came from the Author ADMD 🧚 what's missing is a protocol where an Author ADMD can announce that messages carrying specific valid DKIM signatures on its mail, added by other ADMDs, should be treated as if the Author ADMD signed them itself. this memo presents an experimental mechanism for exactly that, called Authorized Third-Party Signatures (ATPS) 🌈

ATPS upgrades DKIM by giving the Verifier multiple identifiers instead of just one. it validates the identifier in the DKIM signature, and then hands over the RFC5322.From domain for evaluation 💖

this memo also registers, per [AUTHRES], a way to tell downstream agents of the Verifier that a third-party signature verification happened 🔥

2. Definitions 🌸

2.1. Key Words

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 [KEYWORDS]. these are the official requirement words, so they keep their exact force 👑

2.2. Email Architecture Terminology

bestie, be familiar with the material and terminology in [MAIL] and [EMAIL-ARCH] before diving in 📚

3. Roles and Scope 🦋

the context of this protocol involves these roles:

  • ADministrative Management Domains (ADMDs), whose DNS domain name(s) appear in the RFC5322.From field of a [MAIL] message;
  • ATPS Signers, which apply [DKIM] signatures using their own domains, but on behalf of the message Author's ADMD; and
  • the Verifier, who implements the signature validation procedures described in [DKIM].

an ADMD implements this protocol if it wants to announce that a signature from any domain in a set of specified DNS domains is to be considered equivalent to one from the ADMD itself 🎀 for example, an ADMD might want to delegate signing authority for its DNS domain to an approved messaging service provider, without doing the work of key transfer described in Appendix B.1.1 of [DKIM] 🫶 an authorized ATPS Signer makes a claim of this relationship via new tags in the DKIM signature, and the ADMD confirms the claim by publishing a specific TXT record in its DNS 💌

a Verifier implements this protocol if it wants to make sure a message bears one or more signatures from sources authorized to sign mail on behalf of the ADMD, and to flag mail that does (or doesn't) meet that criterion for special treatment ✨ it does this by treating the Signer's authorization on behalf of the Author's ADMD as meaning the Signer's signature is equivalent to one affixed by the Author's ADMD 🧚

4. Queries and Replies 💅

this section describes in detail the queries issued, the replies received, and how they should be interpreted and applied 🔍

4.1. Hash Selection

the Author's ADMD indicates authorization of a third party to sign its mail through a DNS TXT record that contains an encoding of the third party's DNS domain name 💌 there are two supported methods: one is a plain copy of the third party's DNS domain name, and the other is an encoded version of the name. the encoding exists so any domain name can be added to the DNS at a fixed length, which means longer third-party domain names don't get shut out by the overall length limit on a DNS query 🌸

if you pick the encoding mechanism, you have to build a digest of the third party's DNS domain name 🙈 the Author ADMD MUST select a digest ("hash") method currently supported by DKIM (see Section 7.7 of [DKIM]), and that selection needs to be communicated to the ATPS Signer, because it's used when generating the third-party signatures 🔥

where the encoding mechanism isn't used, the ATPS Signer MUST use a hash name of "none" 💜

the full DNS mechanism is specified in Section 4.3 🎀

4.2. Extension to DKIM

[DKIM] signatures contain a tag=value sequence. this protocol adds two new tags, atps and atpsh ✨

when the ATPS Signer generates a DKIM signature for another ADMD, it MUST put its own domain in the signature's d tag, and include an atps tag whose value is the domain name of the ADMD on whose behalf it's signing 👑

the tag name that carries the name of the selected hash algorithm is atpsh. this tag MUST also be included, because it's required as part of the algorithm the Verifier will enact 🫶

the formal syntax, per [ABNF], is below 📐

dkim-atps-tag = %x61.74.70.73 *WSP "=" *WSP domain-name

dkim-atpsh-tag = %x61.74.70.73.68 *WSP "=" *WSP
                 ( "none" / key-h-tag-alg )

domain-name and key-h-tag-alg are defined in [DKIM]. note that according to [DKIM], internationalized domain names are encoded as A-labels, as described in Section 2.3 of [IDNA] 🌈

the registration for these tags can be found in Section 8 💖

4.3. ATPS Query Details 🔍

Okay so this is where the Verifier becomes a total detective 🕵️‍♀️ Once a [DKIM] signature with an atps tag has verified successfully, and the Verifier is happy with it under whatever local policy they run (which we are NOT getting into here or in [DKIM], bestie 🙈), the Verifier compares the domain in that tag's value with the one in the RFC5322.From field of the message. This comparison MUST be case-insensitive 💅

If they don't match, the atps tag MUST be ignored. No drama, just skip it ✨

If they DO match, the Verifier sends a DNS TXT query (the exact details are below 👇) to look for proof that the Author ADMD authorized the ATPS Signer to send mail on its behalf 🫶 If there are several DKIM signatures with valid atps tags, these queries MAY be done in any order or MAY be done in parallel. Literally whatever works best for you 🌸

If the RFC5322.From field has multiple addresses, this process SHOULD be applied whenever the atps tag's value matches any of the domains in that field. These MAY be done in any order.

Heads up: the algorithm uses hashing, but hashing is NOT a security mechanism here 🙅‍♀️ See Section 9.2 for the tea on that.

Here's how the query name gets built, step by step 🧁

  1. Pick the hash algorithm from the atpsh tag in the signature. If that algorithm isn't on the IANA list of ones valid for DKIM (see Section 7.7 of [DKIM]) and it isn't the reserved name none we talked about above, abort the query. Bye bye 👋
  2. Grab the value of the d= tag from the signature.
  3. Turn any uppercase characters in that string into lowercase. Lowercase only, bestie 💜
  4. If the selected hash algorithm is not none, do these extra steps too ✨
    • A. Feed the string you've got into the selected hash algorithm.
    • B. Turn the hash output into printable ASCII by applying base32 encoding as defined in Section 6 of [BASE32]. Base32 is the move here because its output only uses characters that are legal in DNS labels, and the DNS treats uppercase and lowercase the same, so it's a clean fit 🦋
  5. Append the string ._atps.
  6. Append the domain name found in the atps tag of the validated signature.

The query's formal syntax, written in [ABNF], looks like this 🤓

atps-query = ( 1*63BASE32 / domain-name )
             %x2e.5f.61.74.70.73.2e domain-name

BASE32 = ( ALPHA / %x32-37 )

That 63 limit on the base32 part comes from the maximum label length in Section 2.3.4 of [DNS]. Math checks out 🧠

Want to see a full example of a query getting built? Check out Appendix A 🎀

4.4. ATPS Reply Details 📬

Quick decoder ring first: in this section, NOERROR means DNS response code ("rcode") 0, and NXDOMAIN means rcode 3. See Section 4.1.1 of [DNS] if you want the full story 📖

Right now there are only three outcomes we need to care about for this spec 💅

  • An answer comes back (that's [DNS] reply code NOERROR with at least one answer) containing a valid ATPS reply. Yay, the protocol is satisfied! The Verifier can conclude the signing domain is authorized by the ADMD to sign its mail 🎉 Further queries SHOULD NOT be initiated. We're done here, bestie.
  • No answer comes back (that's [DNS] reply code NXDOMAIN, or NOERROR with no answers), OR one or more answers came back but none of them contain a valid ATPS reply. Sadly, the Signer hasn't been authorized to act as a third-party Signer for this ADMD, so the Verifier MUST continue to the next query, if there is one 😔
  • An error comes back (that's any other [DNS] reply code). Now the Verifier genuinely can't tell whether this message is on the ADMD's list of authorized third-party Signers, so it's a mess 😭 The Verifier SHOULD stop processing and defer the message for later, like asking the Mail Transfer Agent (MTA) for a temporary failure code.

If every query finishes and comes back as NXDOMAIN or NOERROR with no answers, then the Signer was NOT authorized by the ADMD. Sorry, not sorry 💀

A valid ATPS reply is a sequence of tag=value pairs, just like Section 3.2 of [DKIM] describes. These are the tags and values that are currently supported in ATPS records 🍓

d: Domain (plain-text; RECOMMENDED). This tag holds a plain-text copy of the DNS domain being authorized as an ATPS Signer. It's there to help catch collisions. For example, if the base32 encoding of this name doesn't match the base32 part of the query, or if this name just isn't the same as the one in the atps tag, a hash collision might have happened 👀 If no name hashing happened at all, using it is redundant. The ABNF goes like this:

atps-d-tag = %x64 [FWS] "=" [FWS] domain-name
           ; FWS is defined in [DKIM]

v: Version (plain-text; REQUIRED). This tag says which version of the ATPS specification the record follows. The record MUST be ignored if the value is not ATPS1. Strict about versions, I love that for us 🫶 The ABNF is:

atps-v-tag = %x76 [FWS] "=" [FWS] %x41.54.50.53.31
           ; FWS is defined in [DKIM]

5. Interpretation 🧠

For each DKIM signature that verifies (see Section 6 of [DKIM]), if the Verifier succeeds in confirming that the Author's ADMD authorized the ATPS Signer using this protocol, the Verifier SHOULD evaluate the message as though it had a valid signature from the Author's ADMD ✨ The Verifier MAY also independently evaluate the ATPS Signer when deciding what happens to the message.

Why does this work? Because the ADMD explicitly endorsed the ATPS Signer, so it's basically a VIP pass 🎟️ That means a reputation module that's built on DKIM signature verification SHOULD apply the reputation of the Author's ADMD domain instead of, or in addition to, the reputation of the ATPS Signer domain. Main character energy for the Author's domain 👑

6. Relationship to ADSP 🤝

[ADSP] defined a protocol where the owner of an Author Domain can tell message receivers that messages without a valid author signature should be treated with suspicion, or even thrown out 🗑️

A Verifier that implements both Author Domain Signing Practices (ADSP) and ATPS MUST test ATPS first. If ATPS shows a valid delegation, the Verifier MUST act, with respect to ADSP, as though the message has a valid Author Domain Signature (because that's literally what the delegation means 💖), and no ADSP test is required. Order matters, babe 🌈

7. Experiment Process 🧪

The working group that built DKIM thought a third-party mechanism like this one was controversial, both in terms of whether anyone needed it and whether it would be practical, so they decided an alternative mechanism was enough 🙃 But that wasn't based on real experience, because there's no real history on this question yet. So this experiment was dreamed up to fix that 🔬

The experimental protocol here has been built into DKIM as an extension in two software products. One of them is open source and seeing more and more use 🌱 It's in there so customers of those systems can use it if they think these third-party assertions are useful for the overall DKIM mechanism. More adoption as part of the experiment is welcome and encouraged 🫶

The implementers and the author of this memo are going to collect how people use the protocol, plus stories about how it changes the overall DKIM experience. Anyone participating is also advised to watch for and report the effects discussed in Section 9.4, especially MTA latency that might get introduced ⏱️

If the response is substantial and positive, advancing along the Standards Track might be warranted. Fingers crossed 🤞🌟

8. IANA Considerations 📋

This section lists the IANA actions that are requested 💼

8.1. ATPS Tag Registry 🏷️

IANA has created an Authorized Third-Party Signature (ATPS) Tag Registry, under the DomainKeys Identified Mail (DKIM) Parameters group. It lists the tags that are valid for use in ATPS records 🎀

New registrations or updates MUST be made following the "Specification Required" guidelines described in [IANA]. Every registry change MUST contain the following info 📝

  1. The name of the tag being registered or updated
  2. The document where the specification is created or updated
  3. The status of the tag, which is one of: "active" (tag is in current use), "deprecated" (tag is in current use but its use is discouraged), or "historic" (tag is no longer in use)

The registry's starting entries look like this 💜

    +-----+------------+--------+
    | Tag |  Reference | Status |
    +-----+------------+--------+
    |  d  |  [RFC6541] | active |
    +-----+------------+--------+
    |  v  |  [RFC6541] | active |
    +-----+------------+--------+

8.2. Email Authentication Methods Registry Update 📮

The following was added to the Email Authentication Methods registry (in the Email Authentication Parameters group) that [AUTHRES] set up, following [IANA] 🌸

  • Method: dkim-atps
  • Defined In: [RFC6541]
  • ptype: header
  • property: from
  • value: contents of the [MAIL] From: header field, with comments removed

8.3. Email Authentication Result Names Registry Update 🏆

The following result names were added to the Email Authentication Result Names registry (in the Email Authentication Parameters group) that [AUTHRES] set up, following [IANA] ✨

  • Code: none
    • Existing/New Code: existing
    • Defined In: [AUTHRES]
    • Auth Method: dkim-atps
    • Meaning: No valid DKIM signatures were found on the message bearing atps tags. 🫥
  • Code: pass
    • Existing/New Code: existing
    • Defined In: [AUTHRES]
    • Auth Method: dkim-atps
    • Meaning: An ATPS evaluation was performed, and a valid signature from an authorized third party was found on the message. 🎉
  • Code: fail
    • Existing/New Code: existing
    • Defined In: [AUTHRES]
    • Auth Method: dkim-atps
    • Meaning: Every valid DKIM signature bearing an atps tag either didn't reference a domain name found in the RFC5322.From field, or the ATPS test(s) run failed to confirm a third-party authorization. 🙅‍♀️
  • Code: temperror
    • Existing/New Code: existing
    • Defined In: [AUTHRES]
    • Auth Method: dkim-atps
    • Meaning: An ATPS evaluation couldn't be finished because of an error that's probably transient, like a temporary DNS error. Trying again later might give a final result. 🔁
  • Code: permerror
    • Existing/New Code: existing
    • Defined In: [AUTHRES]
    • Auth Method: dkim-atps
    • Meaning: An ATPS evaluation couldn't be finished because of an error that's probably NOT transient, like a permanent DNS error. Trying again later is unlikely to give a final result. 💀

8.4. DKIM Signature Tag Specifications Registry 🧾

The following were added to the DKIM Signature Tag Specifications registry (in the DomainKeys Identified Mail (DKIM) Parameters group) that [DKIM] set up, following [IANA] 🩷

  +-------+-----------+--------+
  | Type  | Reference | Status |
  +-------+-----------+--------+
  | atps  | [RFC6541] | active |
  +-------+-----------+--------+
  | atpsh | [RFC6541] | active |
  +-------+-----------+--------+

9. Security Considerations 🔐

Okay, security time, and this one's serious 😤 This section talks about the potential security issues tied to this experimental protocol. Let's get into it 🦋

9.1. Hash Selection 🔐

okay so the hash algorithm you pick (see Section 4.1) is a big deal for security 😭 weaker algorithms are more likely to collide, which means someone could in theory build a second DNS domain name that looks like it was authorized by the Author ADMD. yikes 💀

back when [DKIM] was published, SHA256 was preferred over SHA1 for exactly this reason 💅 but support for both was kept. see Section 3.3 of [DKIM] for more tea on this.

9.2. False Privacy 🙈

so here's the thing: the third-party domain name gets hashed and then encoded with base32, and some people might think that makes the relationship between the two parties private 🫣 it does NOT. the whole point of this protocol is to make those relationships discoverable, so hiding them would just make the discovery harder, unless you share a secret with the message verifiers out-of-band (which adds even more complexity 🌀). the hash and encode steps are only there to turn any third-party domain name into a fixed width for the DNS query. that's it, that's the tea 🍵

9.3. Transient Security Failures 🚨

approving a third-party Signer exposes the ADMD to the risk that the Signer gets compromised and starts signing malicious or nuisance messages on the ADMD's behalf 😱 that can totally reflect badly on the ADMD, and it could get worse as automated domain reputation systems get built and rolled out. ngl, thorough vetting and monitoring of third-party Signers by ADMDs will probably become the norm 🫶

9.4. Load on the DNS 📡

a Verifier doing DKIM, ADSP, and ATPS will now send a bunch of TXT queries to the DNS. the count is as many as one (for the ADSP query) plus the number of signatures on the message (one for each key to be verified) plus the number of signatures that validated and also carry an "atps" tag. on top of that, the MTA might send PTR and A queries when relaying or delivery starts. that's a LOT 😩 it can be super burdensome on the DNS at both ends, and if you wait for all of those parallel queries to come back, the MTA could time out ⏰

one option that hasn't been explored yet is storing the ATPS data at a specific URL tied to the Author's domain name 🌐 that would take pressure off the DNS, but the ADMD would have to run a web server (which has its own security implications 👀) and the Verifier would need to set up a TCP connection too. also, the Verifier would be well advised to cache this data so ATPS can't be abused as a denial-of-service vector 🛡️

see Section 8.5 of [DKIM] for more on DNS-related issues 💖

10. References 📚

10.1. Normative References

[ABNF]       Crocker, D., Ed., and P. Overell, "Augmented BNF for
             Syntax Specifications: ABNF", STD 68, RFC 5234,
             January 2008.

[AUTHRES]    Kucherawy, M., "Message Header Field for Indicating
             Message Authentication Status", RFC 5451, April 2009.

[BASE32]     Josefsson, S., "The Base16, Base32, and Base64 Data
             Encodings", RFC 4648, October 2006.

[DKIM]       Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy,
             Ed., "DomainKeys Identified Mail (DKIM) Signatures",
             RFC 6376, September 2011.

[DNS]        Mockapetris, P., "Domain names - implementation and
             specification", STD 13, RFC 1035, November 1987.

[EMAIL-ARCH] Crocker, D., "Internet Mail Architecture", RFC 5598,
             July 2009.

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

[MAIL]       Resnick, P., Ed., "Internet Message Format", RFC 5322,
             October 2008.

10.2. Informative References

[ADSP]       Allman, E., Fenton, J., Delany, M., and J. Levine,
             "DomainKeys Identified Mail (DKIM) Author Domain Signing
             Practices (ADSP)", RFC 5617, August 2009.

[IANA]       Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations Section in RFCs", BCP 26, RFC 5226,
             May 2008.

[IDNA]       Klensin, J., "Internationalized Domain Names for
             Applications (IDNA): Definitions and Document
             Framework", RFC 5890, August 2010.

Appendix A. Example Query and Reply 🎀

this section shows an example of using this protocol to query for a third-party authorization, and then talks through what the result means 🦋

picture this: a message whose RFC5322.From domain is "example.com" 💌 it has two valid signatures, one from "one.example.net" and one from "two.example.net". each one has an "atps" tag whose value is "example.com" and an "atpsh" tag whose value is "sha1". here's what happens step by step:

  1. a SHA1 hash of "one.example.net" is computed, then converted to printable form with base32 encoding, giving the string QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6 ✨
  2. a TXT query goes out to QSP4I4D24CRHOPDZ3O3ZIU2KSGS3X6Z6._atps.example.com 📨
  3. if a valid reply comes back, the algorithm stops with an [AUTHRES] result of "pass" 🥳 if the DNS returns an error code other than NXDOMAIN, the algorithm stops with "temperror" or "permerror", whichever fits 😬
  4. a SHA1 hash of "two.example.net" is computed, then base32 encoded, giving the string ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX 💫
  5. a TXT query goes out to ZTZGRRV3F45A4U6HLDKBF3ZCOW4V2AJX._atps.example.com 📨
  6. if a valid reply comes back, the algorithm stops with an [AUTHRES] result of "pass" 🥳 if the DNS returns an error code other than NXDOMAIN, the algorithm stops with "temperror" or "permerror", whichever fits 😬
  7. there are no valid signatures left to test, so the algorithm stops with an "unknown" result 🤷‍♀️

Appendix B. Choice of DNS RR Type 🧁

so at one point someone proposed putting this work in the DNS under a brand new Resource Record (RR) Type 👀 and honestly that could've been a totally fine move. but people also noticed that big chunks of DKIM already use an ASCII-based "tag=value" syntax, and already store key and ADSP data in the DNS using TXT resource records 📦 so to make it easy to reuse existing DKIM code, they decided to reuse the TXT message scheme. smart, bestie 🧠💅

Appendix C. Acknowledgements 🫶

the author wants to thank Dave Crocker, Frank Ellermann, Mark Martinec, and Phil Pennock for reviewing this proposal and giving constructive criticism 💖

the author also wants to thank Doug Otis and Daniel Black, whose original document this work was based on 🌸

Author's Address 💌

Murray S. Kucherawy
Cloudmark, Inc.
128 King St., 2nd Floor
San Francisco, CA  94107
US

Phone: +1 415 946 3800
EMail: msk@cloudmark.com
📦 where this page comes from