< draft-otis-dkim-tpa-label-04.txt   draft-otis-dkim-tpa-label-05.txt >
DKIM Working Group D. Otis DKIM Working Group D. Otis
Internet-Draft Trend Micro Internet-Draft Trend Micro
Intended status: Standards Track D. Black Intended status: Standards Track D. Black
Expires: December 23, 2010 June 21, 2010 Expires: December 29, 2010 June 27, 2010
DKIM Third-Party Authorization Label DKIM Third-Party Authorization Label
draft-otis-dkim-tpa-label-04 draft-otis-dkim-tpa-label-05
Abstract Abstract
A third party authorization label (TPA-Label) is a DNS-based prefix A third party authorization label (TPA-Label) is a DNS-based
for DKIM ADSP records that allow domains in the From header to extension for DKIM ADSP records that allow domains in the From header
authorize acceptable third-party signatures. This scheme allows to authorize acceptable third-party signatures. This approach allows
autonomously and unilaterally authorizations for a range of third- autonomous and unilateral authorizations for a range of third-party
party domains using scalable, individual DNS transactions. The domains using scalable, individual DNS transactions. The extended
extended scope of DKIM signing practice assertions supplant more scope of DKIM signing practice assertions supplants more difficult to
difficult to administer transparent authorization schemes. administer transparent authorization schemes. Alternatives for
Alternatives for facilitating third-party authorizations currently facilitating third-party authorizations currently necessitate
necessitate coordination between two or more domains to synchronously coordination between two or more domains to synchronously set up
set up selector/key DNS records, DNS zone delegations, and/or a selector/key DNS records, DNS zone delegations, and/or a regular
regular exchange of public/private keys. exchange of public/private keys.
Checking TPA-Label Resource Records for signing practices may Checking TPA-Label Resource Records for signing practices may
infrequently occur when a message is not compliant with a restrictive infrequently occur when a message is not compliant with restrictive
ADSP polices where an Author Domain Signature is either missing or ADSP policies, where an Author Domain Signature is either missing or
invalid. When a third-party signature is found, TPA-Label Resource invalid. When a third-party signature is found, TPA-Label Resource
Record transactions offer an efficient means for Author Domains to Record transactions offer an efficient means for Author Domains to
authorize specific third-party signing domains. Recipients are authorize specific third-party signing domains. Recipients are
afforded a method to determine whether authorization exists in afforded a method to determine whether authorization exists in
situations where other modes of authorization are impractical. TPA- situations where other modes of authorization are impractical. TPA-
Label Resource Records permit Author Domain a means to selectively Label Resource Records permit Author Domains a means to selectively
influence message handling, for messages otherwise lacking valid influence message handling, for messages otherwise lacking valid
Author Domain signatures. Author Domain signatures.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Status of this Memo Status of this Memo
skipping to change at page 2, line 13 skipping to change at page 2, line 13
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 23, 2010. This Internet-Draft will expire on December 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 11 skipping to change at page 3, line 11
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Language and Terminology . . . . . . . . . . . . . . . . . . . 6 2. Language and Terminology . . . . . . . . . . . . . . . . . . . 6
2.1. Terms Imported from other DKIM Specifications: . . . . . . 6 2.1. Terms Imported from other DKIM Specifications: . . . . . . 6
2.2. Terms Defined by this Specification: . . . . . . . . . . . 7 2.2. Terms Defined by this Specification: . . . . . . . . . . . 7
2.2.1. Third Party Domain . . . . . . . . . . . . . . . . . . 7 2.2.1. Third Party Signature . . . . . . . . . . . . . . . . 7
2.2.2. Third Party Signature . . . . . . . . . . . . . . . . 7 2.2.2. Third Party Signer . . . . . . . . . . . . . . . . . . 7
2.2.3. Third Party Signer . . . . . . . . . . . . . . . . . . 7 2.2.3. TPA-Label Listed Domain, TPA-LLD . . . . . . . . . . . 7
2.2.4. TPA-Label Listed Domain . . . . . . . . . . . . . . . 7 2.2.4. Author's Domain Acceptable Third-Party Signature . . . 7
2.2.5. Author's Domain Acceptable Third-Party Signature . . . 7 2.2.5. Author's Domain Acceptable Third-Party Service . . . . 8
3. Combinatorial ADSP "dkim=" Values. . . . . . . . . . . . . . . 8 3. Combinatorial ADSP "dkim=" Values. . . . . . . . . . . . . . . 8
3.1. tpa-sig . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1. tpa-sig . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. tpa-path . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. tpa-path . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. TPA-Label Resource Record Authorization Considerations . . . . 9 4. TPA-Label Resource Record Authorization Considerations . . . . 9
5. Evaluating the Third-party Signing Domain . . . . . . . . . . 9 5. Evaluating the Third-party Signing Domain or Service . . . . . 10
5.1. Third Party Authentication . . . . . . . . . . . . . . . . 9 5.1. Third Party Authentication . . . . . . . . . . . . . . . . 10
5.1.1. Third Party Authentication - Web Email Provider 5.1.1. Third Party Authentication - Web Email Provider
with Subscriber Pingbacks . . . . . . . . . . . . . . 10 with Subscriber Pingbacks . . . . . . . . . . . . . . 10
5.1.2. Third Party Authentication - Closed Mailing List 5.1.2. Third Party Authentication - Closed Mailing List
Example . . . . . . . . . . . . . . . . . . . . . . . 10 Example . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.3. Third Party Authentication - Open Mailing List 5.1.3. Third Party Authentication - Open Mailing List
Example . . . . . . . . . . . . . . . . . . . . . . . 10 Example . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.4. Third Party Authentication Example - Sender Header 5.1.4. Third Party Authentication Example - Sender Header
Field . . . . . . . . . . . . . . . . . . . . . . . . 11 Field . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1.5. Services Lacking DKIM Signatures . . . . . . . . . . . 11 5.1.5. Services Lacking DKIM Signatures . . . . . . . . . . . 12
6. DNS Representation . . . . . . . . . . . . . . . . . . . . . . 12 6. DNS Representation . . . . . . . . . . . . . . . . . . . . . . 13
7. TPA-Label and Tag Syntax Definitions . . . . . . . . . . . . . 13 7. TPA-Label and Tag Syntax Definitions . . . . . . . . . . . . . 14
8. TPA-Label Generation . . . . . . . . . . . . . . . . . . . . . 13 8. TPA-Label Generation . . . . . . . . . . . . . . . . . . . . . 15
9. TPA-Label TXT Resource Record Structure . . . . . . . . . . . 14 9. TPA-Label TXT Resource Record Structure . . . . . . . . . . . 15
9.1. TPA-Label Resource Record Scope Syntax . . . . . . . . . . 14 9.1. TPA-Label Resource Record Scope Syntax . . . . . . . . . . 16
9.1.1. TPA-Label Listed Domain Authorization . . . . . . . . 15 9.1.1. TPA-Label Listed Domain Authorization . . . . . . . . 16
9.1.2. Header Dependent Authorizations . . . . . . . . . . . 15 9.1.2. Header Dependent Authorizations . . . . . . . . . . . 16
9.1.3. MailFrom Parameter . . . . . . . . . . . . . . . . . . 15 9.1.3. MailFrom Parameter . . . . . . . . . . . . . . . . . . 16
9.1.4. SMTP Host domains . . . . . . . . . . . . . . . . . . 15 9.1.4. SMTP Host domains . . . . . . . . . . . . . . . . . . 17
10. Authorized Signing Domain . . . . . . . . . . . . . . . . . . 16 10. Authorized Signing Domain . . . . . . . . . . . . . . . . . . 17
11. TPA-Label Resource Record Query Transactions . . . . . . . . . 16 11. TPA-Label Resource Record Query Transactions . . . . . . . . . 17
12. TPA-Label Resource Record Compliance Assessment . . . . . . . 16 12. TPA-Label Resource Record Compliance Assessment . . . . . . . 17
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
13.1. Author Domain Signing Practices (ADSP) Parameters . . . . 18 13.1. Author Domain Signing Practices (ADSP) Parameters . . . . 19
13.2. Email Authentication Method Registry . . . . . . . . . . . 20 13.2. Email Authentication Method Registry . . . . . . . . . . . 19
13.3. Email Authentication Result Names Registry . . . . . . . . 22 13.3. Email Authentication Result Names Registry . . . . . . . . 21
13.4. Third Party Authorizations Labels Registry . . . . . . . . 22 13.4. Third Party Authorizations Labels Registry . . . . . . . . 21
13.5. Third Party Authorizations Scope Registry . . . . . . . . 23 13.5. Third Party Authorizations Scope Registry . . . . . . . . 22
14. Security Considerations . . . . . . . . . . . . . . . . . . . 24 14. Security Considerations . . . . . . . . . . . . . . . . . . . 23
14.1. Benefits to Recipients . . . . . . . . . . . . . . . . . . 24 14.1. Benefits to Recipients . . . . . . . . . . . . . . . . . . 23
14.2. Risks to Recipients . . . . . . . . . . . . . . . . . . . 24 14.2. Risks to Recipients . . . . . . . . . . . . . . . . . . . 23
14.3. Benefits to Author Domains . . . . . . . . . . . . . . . . 24 14.3. Benefits to Author Domains . . . . . . . . . . . . . . . . 24
14.4. Risks to Author Domains . . . . . . . . . . . . . . . . . 25 14.4. Risks to Author Domains . . . . . . . . . . . . . . . . . 24
14.5. Benefits to Third Party Signers . . . . . . . . . . . . . 26 14.5. Benefits to Third Party Signers . . . . . . . . . . . . . 25
14.6. Risks caused by Third Party Signers . . . . . . . . . . . 26 14.6. Risks caused by Third Party Signers . . . . . . . . . . . 25
14.7. SHA-1 Collisions . . . . . . . . . . . . . . . . . . . . . 26 14.7. SHA-1 Collisions . . . . . . . . . . . . . . . . . . . . . 25
14.8. DNS Limits . . . . . . . . . . . . . . . . . . . . . . . . 26 14.8. DNS Limits . . . . . . . . . . . . . . . . . . . . . . . . 26
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
16.1. Normative References . . . . . . . . . . . . . . . . . . . 28 16.1. Normative References . . . . . . . . . . . . . . . . . . . 27
16.2. Informative References . . . . . . . . . . . . . . . . . . 29 16.2. Informative References . . . . . . . . . . . . . . . . . . 28
Appendix A. DNS Example of TPA-Label Resource Record placement . 29 Appendix A. DNS Example of TPA-Label Resource Record placement . 28
Appendix B. C code for label generation . . . . . . . . . . . . . 31 Appendix B. C code for label generation . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
Sharing a number of details between the domain owner, and one or more A transparent method for DKIM authorization represents sharing a
providers of email and DNS represents a transparent method for DKIM number of details between the domain owner, and one or more providers
authorization. Since there are many ways in which such of email and DNS. Since there are many ways in which such
authorizations could be accomplished, it is unlikely standardized authorizations could be accomplished, it is unlikely standardized
formats will be developed to exchange necessary, and at times, formats will be developed to exchange necessary, and at times,
sensitive information. In addition, when there is a security breach sensitive information. In addition, when there is a security breach
and authorization is transparent, the wrong party might be held and authorization is transparent, the wrong party might be held
accountable for content they may have never seen nor logged. The accountable for content they may have never seen nor logged. The
TPA-Label Resource Record scheme is a simple authorization method TPA-Label Resource Record supports a simple authorization method that
that keeps visible which administrative entity signed a message and keeps visible which administrative entity signed a message, and
whether an Author Domain authorized the signature. The authorization whether an Author Domain authorized the signature. The authorization
record may also impose additional header requirements. record may also impose additional header requirements.
Tens of thousands of domains of various financial institutions are Tens of thousands of domains of various financial institutions are
frequently being phished. Phishing creates a nuisance for those who frequently being phished. Phishing creates a nuisance for those who
aren't expecting these messages, and a threat for those who then aren't expecting these messages, and a threat for those who then
interact with them. Whenever institutions employ DKIM and utilize interact with them. Whenever institutions employ DKIM and utilize
various third-party services, the integrity of their Author Domain various third-party services, the integrity of their Author Domain
Signature might be affected. Some assert less stringent Author Signature might be affected. Some assert less stringent Author
Domain Signing Policies on sub-domains to accommodate the affect of Domain Signing Policies on subdomains to accommodate the affect of
third-party services, as suggested by [I-D.ietf-dkim-mailinglists] third-party services, as suggested by [I-D.ietf-dkim-mailinglists]
section 4.1, that recommends the use of sub-domains to assert less section 4.1, that recommends use of subdomains to assert less
restrictive ADSP policies. restrictive ADSP policies.
Although, ADSP as currently structured does not offer a good As currently structured, ADSP does not offer an alternative to using
alternative, such a strategy increases those who will be deceived by more domains, where only some are protected by a restrictive policy.
phish. This is because people often do not understand the It lacks a simple method to retain an authentication and
significance of URI hierarchy, and become confused or insensitive to authorization acceptance condition while using third party services.
domain changes. APWG phishing trends, This limitation forces use of a strategy that increases those being
deceived by phishing attempts. This is because people often do not
understand the significance of URI hierarchy, and become confused or
insensitive to domain changes. APWG phishing trends,
[apwg-globalphishingsurvey-2H2009] page 18, indicates phishing [apwg-globalphishingsurvey-2H2009] page 18, indicates phishing
commonly uses subdomains in the URL to fool potential victims. commonly uses subdomains in a URL to fool potential victims.
Ensuring third-party inclusion of Sender or List-ID headers enhanced Deterrents that utilize some authorized originating header are
sorting strategies to further improve protections. Users who sort ineffective. These headers often remain invisible to recipients, and
messages based upon email domains are less susceptible to look-alike contain domains being exploited for periods measured in hours, in an
phish attempts when acceptance is based upon valid Author Domain avoidance of a Wack-A-Mole like response. Even long term reputations
Signatures. However, when sub-domains assert less stringent remain problematic due to the intermix of messages from compromised
policies, these messages might be combined with those having more accounts. Few recipients inspect the stack of message headers, or
stringent policies when sorting is based upon the parent domain. are able to draw useful conclusions from a profusion of unfriendly
Consistently using the same domain avoids confusion that might be information. However, many recipients deal with abuse by sorting
exploited. messages into groups based upon an assumed source found in a few
headers.
ADSP represents an open registry offering domain specific guidance Retaining authentication and authorization for the From, Sender, and
for DKIM acceptance criteria, when determining whether messages List-ID headers, and ensuring third-party inclusion of a Sender or
should be delivered, refused or discarded. However, appropriate List-ID header, enhances protections afforded from source sorting to
actions are unclear whenever third-party services are involved. For reduce susceptibility to being deceived by look-alike phishing
example, it is not clear whether ADSP "dkim=all" assertions include attempts. However, when subdomains assert less stringent policies
third-party services that could damage Author-Domain signatures. that omit authentication, these messages might be combined with those
Although ADSP warns of a potential for disruption, specific handling having more stringent policies when sorting is based upon parent
recommendations are limited to "dkim=discardable". Although domains. Consistently using the same domain avoids confusion that
administrative domains asserting all of their outbound messages are might otherwise be exploited to deceive recipients.
signed offer significant forensic value, the handling for messages
lacking an Author Domain Signature with a "dkim=all" remain unclear. ADSP represents an open registry which offers domain specific
guidance for DKIM acceptance criteria, when determining whether
messages should be delivered, refused or discarded. However,
appropriate actions become unclear whenever third-party services are
involved. For example, it is not clear whether ADSP "dkim=all"
assertions include third-party services that could potentially damage
Author-Domain signatures. Although ADSP warns of a potential for
disruption, specific handling recommendations are limited to
"dkim=discardable". Administrative domains that assert all of their
outbound messages are signed offer significant forensic value.
However, the handling for their messages lacking an Author Domain
Signature with an ADSP "dkim=all" assertion remains unclear.
This document describes how any Author Domain publishing ADSP records This document describes how any Author Domain publishing ADSP records
defined in [RFC5617], can autonomously authorize DKIM signatures defined in [RFC5617], can autonomously authorize DKIM signatures
[RFC4871] (updated by [RFC5672]) by specific third-party domains. [RFC4871] (updated by [RFC5672]) by specific domains. TPA-Label
TPA-Label listed domains offer secondary signing practices for listed domains offer secondary signing practices for additional ADSP
additional ADSP compliance options whenever no Author Domain compliance options, whenever no Author Domain Signature is present
Signature is present within the message. The intended purpose of within the message. The intended purpose of TPA-Label Resource
TPA-Label Resource Records is to improve acceptance rates of genuine Records is to improve acceptance rates of genuine messages, to
messages, to minimize domain use, to minimize success rates for minimize domain use, to minimize success rates for phishing, and to
phishing, and to minimize recipient's administrative costs. minimize a recipient's administrative costs.
TPA-Label Resource Records authorize third-party signing domains to TPA-Label Resource Records authorize third-party signing domains and
extend DKIM compliance options for signing practices defined by services to extend DKIM compliance options for signing practices
[RFC5617]. TPA-Label listed domains are to be considered equivalent defined by [RFC5617]. TPA-Label listed domains, TPA-LLD, are to be
to the authorizing Author Domain when assessing compliance with DKIM considered equivalent to the authorizing Author Domain when assessing
signing practices. The TXT resource records associated with TPA- compliance with ADSP. The TXT resource records, associated with TPA-
Label start with the 'dkim' tag as defined by [RFC5617] for signing Label, start with the 'dkim' tag as defined by [RFC5617] for signing
practices, and may contain tags specifically defined for TPA-Label practices, and may contain tags specifically defined for TPA-Label
Resource Records. Resource Records.
2. Language and Terminology 2. Language and Terminology
2.1. Terms Imported from other DKIM Specifications: 2.1. Terms Imported from other DKIM Specifications:
A "Valid Signature" is any signature on a message that correctly A "Valid Signature" is any signature on a message that correctly
verifies using the procedure described in Section 6.1 of verifies using the procedure described in Section 6.1 of
[RFC4871]. [RFC4871].
skipping to change at page 7, line 7 skipping to change at page 7, line 17
"Author Address" is defined in Section 2.3 of [RFC5617]. "Author Address" is defined in Section 2.3 of [RFC5617].
"Author Domain" is defined in section 2.4 of [RFC5617]. "Author Domain" is defined in section 2.4 of [RFC5617].
"Alleged Author" is defined in Section 2.5 of [RFC5617]. "Alleged Author" is defined in Section 2.5 of [RFC5617].
"Author Domain Signature" is defined in Section 2.7 of [RFC5617] "Author Domain Signature" is defined in Section 2.7 of [RFC5617]
2.2. Terms Defined by this Specification: 2.2. Terms Defined by this Specification:
2.2.1. Third Party Domain 2.2.1. Third Party Signature
A "Third Party Domain" is an originating domain within a message that
is not at or below the Author Domain.
2.2.2. Third Party Signature
A "Third Party Signature" is a Valid Signature that does not qualify A "Third Party Signature" is a Valid Signature that does not qualify
as a Author Domain Signature. as an Author Domain Signature.
Editor's Note: While this term is defined in Section 6.3 of Editor's Note: While this term is defined in Section 6.3 of
[RFC5863] and in Section 2 of [RFC5016], this definition is in [RFC5863] and in Section 2 of [RFC5016], this definition is in
terms of the Author Domain Signature and avoids statements about terms of the Author Domain Signature and avoids statements about
any header field dependencies. any header field dependencies.
2.2.3. Third Party Signer 2.2.2. Third Party Signer
A "Third Party Signer" is a signer that adds a valid DKIM signature A "Third Party Signer" is a signer that adds a valid DKIM signature
that references a Third Party Domain with the 'd=' tag in the DKIM- that references a domain with the 'd=' tag in the DKIM-Signature
Signature header field. header field that is not the Author Domain.
2.2.4. TPA-Label Listed Domain 2.2.3. TPA-Label Listed Domain, TPA-LLD
TPA-Label Listed Domain, TPA-LLD, is a domain TXT resource record TPA-Label Listed Domain, TPA-LLD, is a TXT resource record that can
that can be referenced with a TPA-Label within an Author Domain. be referenced with a TPA-Label within an Author Domain. When a "tpa"
When a "tpa" tag exists within the TXT resource record located at the tag exists within the TXT resource record located at the TPA-Label,
TPA-Label, the referenced domain must be within a listed domain. the referenced domain must be within a listed domain. When the "tpa"
When this tag does not exist, the referenced domain is presumed tag does not exist, the referenced domain is presumed listed. The
listed. The "scope" tag provides the TPA-LLD authorization which may "scope" tag may stipulate the existence of additional headers or
stipulate additional headers or other email elements before being which email elements are to confirm an administrative domain of a
authorized to act on behalf of the Author Domain publishing the TPA- service before being authorized to act on behalf of the Author
Label Resource Record. Domain. Following [RFC5321], domain name comparisons, as well as
TPA-Labels, are case insensitive.
2.2.5. Author's Domain Acceptable Third-Party Signature 2.2.4. Author's Domain Acceptable Third-Party Signature
An "Author's Domain Acceptable Third-Party Signature" is a Valid An "Author's Domain Acceptable Third-Party Signature" is a Valid
Signature in which the domain name of the DKIM signing entity, i.e., Signature in which the domain name of the DKIM signing entity, i.e.,
the 'd=' tag in the DKIM-Signature header field, is the domain name the 'd=' tag in the DKIM-Signature header field, is the domain name
referenced in the TPA-Label Resource Record published by the Author referenced in the TPA-Label Resource Record published by the Author
Domain with a scope of 'F', 'S', or 'L' when the List-ID is within Domain with a scope of 'F', 'S', or 'L'. For 'S' and 'L' scopes, the
the TPA-LLD. Following [RFC5321], domain name comparisons, as well respective Sender header or a List-ID identifier of the List-ID
as TPA-Labels, are case insensitive. header must exist for either scope and contain a domain within the
TPA-LLD for authorization to be valid.
2.2.5. Author's Domain Acceptable Third-Party Service
An "Author's Domain Acceptable Third-Party Service" is a service that
is able to confirm the administrative domain with either forward or
reverse DNS references from either the client host name (EHLO/HELO)
or the return path (Mail From) as determined by the presence of the
'H' and 'M' scopes respectively. For additional 'S' or 'L' scopes,
the respective Sender header or a List-ID identifier of the List-ID
header must exist for either scope and contain a domain within the
TPA-LLD for authorization to be valid.
3. Combinatorial ADSP "dkim=" Values. 3. Combinatorial ADSP "dkim=" Values.
This document defines new values listed with the ADSP "dkim" tag in This document defines two new values listed with the ADSP "dkim" tag
addition to those defined in [RFC5617] section 4.2.1. These values in addition to those defined in [RFC5617] section 4.2.1. These
can append to those currently defined. It is not recommended to use values can append to those currently defined, or used separately.
any new value in conjunction with "discardable", because when not When used separately, the value "all" is to be assumed to prefix the
understood, a message handled by an authorized third-party might new values when recognized, otherwise the value "unknown" will be
become lost. assumed. It is not recommended to use any new value in conjunction
with "discardable", because when not understood, a message that
depends upon different handling might become lost.
3.1. tpa-sig 3.1. tpa-sig
The ADSP dkim= value "tpa-sig" indicates that TPA-Labels will offer a The ADSP dkim= value "tpa-sig" indicates that TPA-Labels will offer a
comprehensive list of authorized third-party services that must add comprehensive list of Author's Domain Acceptable Third-Party
DKIM signatures. When this value is "dkim=all tpa-sig" and the DKIM Signatures that may include header requirements. When there is no
signature has been authorized by a TPA-Label Resource Record with the valid Author Domain Signature or Author's Domain Acceptable Third-
scope of 'F', 'S', or 'L', then such signatures are in compliance Party Signature, the Author Domain recommends these messages be
with the Author Domain's asserted Signing Policies. However when refused.
there is no valid Author Domain Signature and the DKIM signature is
not listed with an 'F', 'S', or 'L' scope, the Author Domain
recommends these messages be refused.
3.2. tpa-path 3.2. tpa-path
The ADSP dkim= value "tpa-path" indicates that TPA-Labels will offer The ADSP dkim= value "tpa-path" indicates that TPA-Labels will offer
a comprehensive list of authorized third-party services. When this a comprehensive list of Author's Domain Acceptable Third-Party
value is "dkim=all tpa-path" and the DKIM signature has been Signatures and Authorized Third-Party Services that may include
authorized by a TPA-Label Resource Record with the scope of 'F', 'S', header requirements.
or 'L', then such signatures are in compliance with the Author
Domain's asserted Signing Policies.
The "tpa-path" is used to accommodate third party services lacking The "tpa-path" is used to accommodate third party services lacking
DKIM signatures, the confirmed path of the message determined by DKIM signatures, the confirmed path of the message determined by
either the client host name (EHLO/HELO) or the return path (Mail either the client host name (EHLO/HELO) or the return path (Mail
From). The permitted path element's domain is authorized by a TPA- From). The permitted path element's domain is authorized by a TPA-
Label Resource Record with the scope of 'H' or 'M' respectively. Label Resource Record with the scope of 'H' or 'M' respectively.
Such messages are then in compliance with the Author Domain's Such messages are then in compliance with the Author Domain's
asserted Signing Policies. The leaf of the host name (left most asserted Signing Policies. The leaf of the host name (left most
label) may need to be omitted when checking for TPA-Label Resource label) may need to be omitted when checking for TPA-Label Resource
Record authorization. When no scope is included in conjunction with Record authorization.
a "tpa-path" policy, there is no requirement that the referenced
element's domain be confirmed.
When there is no valid Author Domain Signature and the DKIM signature When there is no valid Author Domain Signature, or Author's Domain
is not listed with an 'F', 'S', or 'L' scope, or TPA-Label Resource Acceptable Third-Party Signature, or Author's Domain Acceptable
Record with the scope of 'H' or 'M' where the path elements of the Third-Party Service, the Author Domain recommends these messages be
path can not be confirmed or is not listed, the Author Domain refused.
recommends these messages be refused.
ADSP defends domains against spoofing. Any subdomain of a domain
publishing an ADSP with the "dkim" tag value containing "tpa-sig" or
"tpa-path" not also publishing an MX resource record, should be
assumed to have published the same ADSP records there as well.
4. TPA-Label Resource Record Authorization Considerations 4. TPA-Label Resource Record Authorization Considerations
When an Author Domain is not within the DKIM signing domain, the TPA- When an Author Domain is not within the DKIM signing domain, the TPA-
LLD scheme can extend ADSP signing practice compliance. The TPA-LLD LLD scheme can extend ADSP signing practice compliance. The TPA-LLD
scheme with an 'F', 'S', or 'L' scope permits a contained Third Party scheme with an 'F', 'S', or 'L' scope permits a contained Third Party
Signature to be treated as a Author Domain Signature. This allows Signature to be treated as an Author Domain Signature. The 'H' and
Author Domains a means to extend restrictive policy compliance. The 'M' scopes permit acceptance based upon confirmation of either the
TPA-LLD scheme for offering valid signatures only requires that DNS client host name (EHLO/HELO) or the return path (Mail From)
publications be made by the Author Domain, even when signing domains respectively. For 'S' and 'L' scopes, the respective Sender header
and the Author Domain differ. This approach avoids the need to or a List-ID identifier of the List-ID header must exist for either
exchange DKIM key related information. scope and contain a domain within the TPA-LLD for authorization to be
valid. This allows Author Domains a means to extend restrictive
policy compliance. The TPA-LLD scheme for offering valid
authorization only requires DNS publications be made by the Author
Domain, even when signing domains and the Author Domain differ. This
approach avoids a need to exchange DKIM key related information.
Extended authorization will not ensure all possible spoofing is Extended authorization will not ensure all possible spoofing is
prevented. However, by permitting broader use of restrictive prevented. However, by permitting broader use of restrictive
policies, this should generally reduce the level of spoofing. policies, this should generally reduce the level of spoofing over
Authorized third party messages should not receive annotations that what might be otherwise allowed. Authorized third party messages
indicate the message contains authenticated identities. When the should not receive annotations that indicate the message contains
TPA-LLD scope include 'S' or 'L', the messages should contain the authenticated identities. The TPA-LLD scope should include the 'S'
headers Sender and List-ID headers respectively with domains that are or 'L' scope where appropriate to allow recipients a means to isolate
within the TPA-LLD. different message sources.
The TPA-LLD scheme plays the role of only providing acceptable The TPA-LLD scheme plays the role of only providing acceptable
signatures or services which might be suitable for non-critical signatures or services which might be suitable for non-critical
messages, with the goal of improving delivery acceptance, such as messages, with the goal of improving delivery acceptance, such as
those from specific mailing-lists. Before TPA-LLD authorization is those from specific mailing-lists. Before TPA-LLD authorization is
deployed, the Author Domain should be assured by the domains being deployed, the Author Domain should be assured by domains being
authorized that appropriate measures are in place to authenticate authorized that appropriate measures are in place to authenticate
those submitting messages. those who are submitting messages.
5. Evaluating the Third-party Signing Domain The "dkim=" tag within the TPA-Label Resource Record is expected to
normally contain a copy of the value asserted by the ADSP Resource
Record "dkim" tag. When the TPA-Label Resource Record "dkim" tag
value differs, and the message is compliant with the "scope" and "ad"
tag values, the TPA-Label Resource Record "dkim" tag value overrides
the ADSP Resource Record "dkim" tag value. Use of "tpa-path" should
selectively override the ADSP "tpa-sig" only where needed.
An Author Domain deploying a TPA-Label Resource Record for a Third 5. Evaluating the Third-party Signing Domain or Service
Party Signer does so on a trust basis. Reasons for deploying TPA-
Label Resource Records might be to allow deployment of more stringent An Author Domain deploying a TPA-Label Resource Record does so on a
ADSP records while also utilizing third-party services. trust basis. Reasons for deploying TPA-Label Resource Records might
be to allow deployment of more stringent ADSP records while also
utilizing third-party signatures or services.
When an authorized Third Party Signer does not employ DKIM When an authorized Third Party Signer does not employ DKIM
authentication with ADSP or does not include Authentication-Results authentication with ADSP or does not include Authentication-Results
headers, this could allow authorizations to be exploited. headers, this could allow authorizations to be exploited.
5.1. Third Party Authentication 5.1. Third Party Authentication
The Author Domain SHOULD ensure the Authorization Scope of the TPA- The Author Domain SHOULD ensure the Authorization Scope of the TPA-
Label Resource Record is authenticated. There are a number of ways Label Resource Record is authenticated. There are a number of ways
email can be authenticated, and different authentication mechanisms email can be authenticated, and different authentication mechanisms
validate different parts of the email. The following are examples of validate different parts of the email. The following are examples of
how authorization might work: how authorization might work.
5.1.1. Third Party Authentication - Web Email Provider with Subscriber 5.1.1. Third Party Authentication - Web Email Provider with Subscriber
Pingbacks Pingbacks
The Author Domain "example.com" wants to deploy a TPA-Label Resource The Author Domain "example.com" wants to deploy a TPA-Label Resource
Record to permit their traveling agents the use of Record to permit their traveling agents the use of
"webmail.example.net" services. This email provider has a closed "webmail.example.net" services. This email provider has a closed
user policy and adds DKIM signatures to messages on behalf of the user policy and adds DKIM signatures to messages on behalf of the
"webmail.example.net" domain. "webmail.example.net" domain.
The closed user policy of "webmail.example.net" permits subscribers The closed user policy of "webmail.example.net" permits subscribers
to post messages with Author Domains that are not to post messages with Author Domains that are not
"webmail.example.net" in the From header fields only when control of "webmail.example.net" in the From header fields, only when control of
the Author Address has been validated by a response to an encoded the Author Address has been validated by a response to an encoded
"pingback" email. The "webmail.example.net" service also establishes "pingback" email. The "webmail.example.net" service also establishes
accounts to authenticate all users sending messages through their accounts to authenticate all users sending messages through their
service. Therefore, the referenced TPA-Label Resource Record can service. Therefore, the referenced TPA-Label Resource Record can
include an 'F' scope value to authorize Author Domain messages signed include an 'F' scope value to authorize Author Domain messages signed
by this Third-Party Signer. by this Third-Party Signer.
5.1.2. Third Party Authentication - Closed Mailing List Example 5.1.2. Third Party Authentication - Closed Mailing List Example
The Author Domain wants to deploy a TPA-Label Resource Record for a The Author Domain wants to deploy a TPA-Label Resource Record for a
mailing list with a closed posting policy that redistributes email in mailing list with a closed posting policy that redistributes email in
a way that breaks Author Domain Signatures, but that adds a DKIM a way which breaks Author Domain Signatures, but adds a DKIM
signature on behalf of their domain and includes an Authentication- signature on behalf of the mailing list domain and includes an
Results header field for posted messages. The closed posting policy Authentication-Results header field for posted messages. The closed
is enforced by requiring subscribers to validate their control of posting policy is enforced by requiring subscribers to validate their
their Author Address by responding to encoded "pingback" email sent control of their Author Address by responding to encoded "pingback"
to this address. email sent to this address.
Because the list management always verifies control of the Author Since the mailing list management always verifies control of the
Address, is configured to include Authentication-Results headers, Author Address, and is configured to include Authentication-Results
includes a List-ID header, the referenced TPA-Label Resource Record headers, and includes a List-ID header, the referenced TPA-Label
can include an 'L' scope value to permit Author Domain messages Resource Record can include an 'L' scope value to permit Author
containing an authorized List-ID domain to be signed by this Third- Domain messages containing an authorized List-ID domain to be signed
Party Signer. by this Third-Party Signer.
5.1.3. Third Party Authentication - Open Mailing List Example 5.1.3. Third Party Authentication - Open Mailing List Example
The Author Domain wants to deploy a TPA-Label Resource Record for a The Author Domain wants to deploy a TPA-Label Resource Record for a
mailing list with an open posting policy that redistributes email in mailing list with an open posting policy that redistributes email in
a way that breaks Author Domain Signatures, but that adds a DKIM a way that breaks Author Domain Signatures, but that adds a DKIM
signature on behalf of their domain and includes an Authentication- signature on behalf of the mailing list domain and includes an
Results header field for posted messages. The open posting policy Authentication-Results header field for posted messages. The open
will refuse messages lacking Author Domain Signatures for domains posting policy will refuse messages lacking Author Domain Signatures
that have deployed an ADSP signing practice of "dkim=all" or for domains that have deployed an ADSP signing practice of "dkim=all"
"dkim=discardable". or "dkim=discardable".
Because the list management always refuses to post an Author Address Since the list management always refuses to post an Author Address
lacking a Author Domain Signature when the domain has deployed an lacking a Author Domain Signature when the domain has deployed an
ADSP record with an "dkim=all" or "dkim=discardable", and is ADSP record with an "dkim=all" or "dkim=discardable", and is
configured to include Authentication-Results headers, includes a configured to include Authentication-Results headers, and includes a
List-ID header, the referenced TPA-Label Resource Record can include List-ID header, the referenced TPA-Label Resource Record can include
an 'L' scope value to permit Author Domain messages containing an an 'L' scope value to permit Author Domain messages containing an
authorized List-ID domain to be signed by this Third-Party Signer. authorized List-ID domain to be signed by this Third-Party Signer.
5.1.4. Third Party Authentication Example - Sender Header Field 5.1.4. Third Party Authentication Example - Sender Header Field
Author Domain "example.com" wishes to temporarily employ the service Author Domain "example.com" wishes to temporarily employ the service
agency "temp.example.org" to handle overflow secretarial support. agency "temp.example.org" to handle overflow secretarial support.
The agency "temp.example.org" sends email on behalf of the executive The agency "temp.example.org" sends email on behalf of the executive
staff of "example.com" and adds the Sender header field of staff of "example.com" and adds the Sender header field of
"secretary@example.org" in the email. Since "temp.example.org" only "secretary@temp.example.org" in the email. Since "temp.example.org"
allows its own staff to email through its server that adds only allows its own staff to email through its server which adds
"temp.example.org" DKIM signatures, a TPA-LLD can include the "temp.example.org" DKIM signatures, a TPA-LLD can include the
"temp.example.org" domain with 'S' scope to specifically authorize "temp.example.org" domain with an 'S' scope to specifically authorize
messages containing the Sender header field to help ensure these messages containing the Sender header field to help ensure these
messages are not detected as phishing attempts. messages are not handled as phishing attempts.
5.1.5. Services Lacking DKIM Signatures 5.1.5. Services Lacking DKIM Signatures
5.1.5.1. Abuse and DSN Reporting 5.1.5.1. Abuse and DSN Reporting
The 'H' and 'L' scopes available within the TPA-LLD records allow the There is likely little interest for an otherwise uninvolved domain to
receive a massive number of bogus messages being returned as
feedback. Often the purpose of feedback is to discover compromised
systems or accounts actively being exploited in some manner. Unless
there is evidence that the Author Domain either handled or authorized
the handling of the message, only statistics and samples should be
reported to the associated Autonomous System, and perhaps to the
Author Domain when an interest is expressed.
The 'H' and 'M' scopes available within the TPA-LLD records allow the
Author Domain to be associated with SMTP Clients publicly Author Domain to be associated with SMTP Clients publicly
transmitting messages and/or the Mail return path when these domains transmitting messages, and/or the Mail return path when these domains
differ and DKIM is not employed by the third-party service. In this differ, and when DKIM is not employed by the third-party service. In
case, appropriate DSN or abuse reporting to the Author Domain is this case, appropriate DSN or abuse reporting to the Author Domain is
better assured as a result. The correspondence between SMTP Client better assured as a result. The correspondence between SMTP Client
hosts and Mail return path can be affirmed by the TPA-LLD scheme with hosts and Mail return path can be affirmed by the TPA-LLD scheme with
a scope of 'H' or 'M' that might be used to categorize feedback data a scope of 'H' or 'M' that might be used to categorize feedback data
or confirm DSN destinations. or confirm DSN destinations.
Services that depend only upon path authorizations, will permit other
domains to spoof the Author Domain, and yet obtain acceptance.
During such events, the Author Domain might need to retract their
authorization from the service. For this reason, "tpa-path"
authorization should only be used as a carefully monitored interim
solution.
5.1.5.2. Third Party Authentication Example - SMTP Host 5.1.5.2. Third Party Authentication Example - SMTP Host
Author Domain "example.com" makes use of invite services. This Author Domain "example.com" makes use of invite services. This
service does not utilize DKIM with the host name given by the EHLO service does not utilize DKIM, where the host name given by the EHLO
command as "invite.example.net". The Author Domain can authorize the command is "invite.example.net". The Author Domain can authorize the
domain "invite.example.net" or "example.net" with the scope of 'H' to domain "invite.example.net" or "example.net" with the scope of 'H' to
improve acceptance of DKIM signed messages that are on behalf of improve acceptance of messages that are sent on behalf of
"example.com" from this outbound server. "example.com" from this outbound server.
5.1.5.3. Third Party Authentication Example - Return Path 5.1.5.3. Third Party Authentication Example - Return Path
Author Domain "example.com" makes use of tell-a-friend services. Author Domain "example.com" makes use of tell-a-friend services.
This service does not utilize DKIM with their own return path as This service does not utilize DKIM with their own return path as
"customer@taf.example.net" in the SMTP exchange. The Author Domain "customer@taf.example.net" in the SMTP exchange. The Author Domain
can authorize the domain "taf.example.net" with the scope of 'M' to can authorize the domain "taf.example.net" with the scope of 'M' to
improve acceptance of DKIM signed messages that are on behalf of improve acceptance of messages that are on behalf of "example.com"
"example.com" from this outbound server. from this outbound server.
5.1.5.4. Use of Path Authorization 5.1.5.4. Use of Path Authorization
Those using the "tpa-path" value should not authorize domains Those using the "tpa-path" value should not authorize domains
requiring more than a few DNS transactions to confirm the domain. requiring more than a few DNS transactions to confirm a domain.
Those implementing this ADSP extension should also limit the number Those implementing this ADSP extension should also limit the number
of DNS transactions that might be attempted, or this could negatively of DNS transactions that might be attempted, or this could negatively
impact unrelated domains when evaluating path related protocols. impact unrelated domains when evaluating path related protocols.
Path protocol libraries may cause recipients to expand macros
containing email address local-parts, where a new set of DNS
transactions would be triggered whenever the local-part changes.
Editor's Note: This option was added for better coverage during Editor's Note: This option was added for better coverage during
initial use of DKIM and ADSP. Earlier efforts to employ SRV initial deployment of DKIM and ADSP. Earlier efforts to employ
records to resolve SMTP clients failed adoption. SRV records to resolve the SMTP client failed adoption.
Current experimental path protocols allow resolution of all IPv4
and IPv6 addresses for all outbound servers that handle a domain's Current experimental path protocols combine into a single set of
messages. To aggregate together this potentially large set of all IPv4 and IPv6 addresses for all outbound servers handling a
addresses, path protocols provide up to one hundred and eleven domain's messages. To aggregate this potentially large set of
resources, path protocols provide up to one hundred and eleven
separate DNS transactions. One to obtain the initial record, one separate DNS transactions. One to obtain the initial record, one
for each of ten permitted mechanisms, which may in turn require up for each of the ten permitted mechanisms, which may in turn
to ten transactions to resolve the mechanism's target list. require up to ten transactions to resolve the mechanism's target
list.
Path protocol libraries expand macros containing email address
local-parts as locations for subsequent resource records. This
allows a cached path related resource record to produce a new set
of DNS transactions whenever the local-part of a spam campaign
changes.
6. DNS Representation 6. DNS Representation
The receiver obtains domain authorizations with a DNS query for an IN The receiver obtains domain authorizations with a DNS query for an IN
class TXT TPA-Label resource record located below the location class TXT TPA-Label resource record located below the location
specified in [RFC4871] section 7.4 and the label "_tpa.". The TPA- specified in [RFC4871] section 7.4 and the label "_tpa.". The TPA-
Label itself is normally generated by processing the domain in Label itself is generated by processing the domain in question, which
question, which normally matches the DKIM signature's "d=" parameter. normally matches the DKIM signature's "d=" parameter. A TPA-Label
A TPA-Label Resource Record is published adjacent to the [RFC5617] Resource Record is published adjacent to the [RFC5617] conventional
conventional ADSP record, for example below "_tpa._domainkey.<Author- ADSP record, for example below "_tpa._domainkey.<Author-Domain>".
Domain>". The Author Domain provides authorization for other domains The Author Domain provides authorization for other domains with the
with the existence of a TPA-Label TXT resource record that when a existence of a TPA-Label TXT resource record. When a "tpa" tag value
"tpa" tag value exists, it includes the referenced domain. exists, it must include the referenced domain for authorization to be
Authorization to act on behalf of the Author Domain can be limited by valid. Authorization to act on behalf of the Author Domain can also
the "scope" tag value for specific message elements. be limited by the "scope" tag value for specific message elements.
An Author Domain may wish to delegate the listing of third-party An Author Domain may wish to delegate the listing of third-party
services to a different administrative domain. Ideally, this would services to a different administrative domain. Ideally, this would
be accomplished by delegating the _tpa._domainkey.<Author-Domain> be accomplished by delegating the _tpa._domainkey.<Author-Domain>
zone to the administrative entity handling publication of TPA-Label zone to the administrative entity handling publication of TPA-Label
Resource Records. This delegation could also be done unilaterally Resource Records. This delegation could also be done unilaterally
with a DNAME resource record published at _tpa._domainkey.<Author- with a DNAME resource record published at _tpa._domainkey.<Author-
Domain>. Domain>.
Character-strings contained within the TXT resource record are Character-strings contained within the TXT resource record are
concatenated into forming a single string. A character-string is a concatenated into forming a single string. A character-string is a
single length octet followed by that number of characters treated as single length octet followed by that number of characters treated as
binary information. As an example, a TPA-Label Resource Record may binary information.
be located at these domains:
The TPA-Label Resource Records should be located at these domains:
<tpa-label>._tpa._domainkey.<Author-Domain>. <tpa-label>._tpa._domainkey.<Author-Domain>.
7. TPA-Label and Tag Syntax Definitions 7. TPA-Label and Tag Syntax Definitions
"base32" function is defined in [RFC4648]. "base32" function is defined in [RFC4648].
"sha1" function is defined in [FIPS.180-2.2002]. "sha1" function is defined in [FIPS.180-2.2002].
"lcase" converts upper-case ALPHA characters to lower-case. "lcase" converts upper-case ALPHA characters to lower-case.
"signing-domain" is the "d=" tag value defined in Section 3.5 of "signing-domain" is the "d=" tag value defined in Section 3.5 of
[RFC4871]. [RFC4871].
Augmented BNF for Syntax Specifications: Augmented BNF for Syntax Specifications:
asterisk = %x2A ; "*" asterisk = %x2A ; "*"
dash = %x2D ; "-" dash = %x2D ; "-"
dot = %x2E ; "." dot = %x2E ; "."
underscore = %x5F ; "_" underscore = %x5F ; "_"
ANY = asterisk dot ; "*." ANY = asterisk dot ; "*."
dns-char = ALPHA / DIGIT / dash dns-char = ALPHA / DIGIT / dash
id-prefix = ALPHA / DIGIT id-prefix = ALPHA / DIGIT
label = id-prefix [*61dns-char id-prefix] label = id-prefix [*61dns-char id-prefix]
sldn = label dot label sldn = label dot label
base-char = (dns-char / underscore) base-char = (dns-char / underscore)
domain = *(label dot) sldn domain = *(label dot) sldn
tpa-label = underscore base32( sha-1( lcase(signing-domain))) tpa-label = underscore base32( sha1( lcase(signing-domain)))
8. TPA-Label Generation 8. TPA-Label Generation
The TPA-Label is created from the hash value returned by the "sha1" The TPA-Label is created from the hash value returned by the "sha1"
function of the signing-domain expressed in lower case ASCII. The function of the signing-domain expressed in lower case ASCII. The
hash is then converted to a base32 character set, with the resulting hash is then converted to a base32 character set, with the resulting
label prefixed with an underscore. Any terminating period is not label prefixed with an underscore. Any terminating period is not
included with the signing-domain, as indicated by the ABNF included with the signing-domain, as indicated by the ABNF
definition. definition.
Note: No newline character, 0x0A, is to be appended to the end of Note: No newline character, 0x0A, is to be appended to the end of
the domain name, as might occur with the command line generation the domain name, as might occur with the command line generation
of SHA1 values. Command line appended newlines can be avoided by of sha1 values. For example, these command line appended newlines
using the 'echo -n" option, for example. are avoided by using the 'echo -n" option.
9. TPA-Label TXT Resource Record Structure 9. TPA-Label TXT Resource Record Structure
Every TPA-Label TXT resource record MUST start with an outbound Every TPA-Label TXT resource record MUST start with an outbound
signing-practices tag, so the first four characters of the record are signing-practices tag, so the first four characters of the record are
lowercase "dkim", followed by optional whitespace and "=". In lowercase "dkim", followed by optional whitespace and "=". In
addition to the tags defined by [RFC5617], TPA-Label syntax addition to the tags defined by [RFC5617], TPA-Label syntax
descriptions for additional tags follow the tag-value syntax descriptions for additional tags follow the tag-value syntax
described in section 4.2.1 of [RFC5617] and section 3.2 of [RFC4871]. described in section 4.2.1 of [RFC5617] and section 3.2 of [RFC4871].
Unrecognized tags and tags with illegal values MUST be ignored. In Unrecognized tags and tags with illegal values MUST be ignored. In
skipping to change at page 14, line 42 skipping to change at page 16, line 4
+--------------+----------------------+ +--------------+----------------------+
| Scope Values | Field or Parameter | | Scope Values | Field or Parameter |
+--------------+----------------------+ +--------------+----------------------+
| F | From (Author) Header | | F | From (Author) Header |
| L | List-ID | | L | List-ID |
| S | Sender Header | | S | Sender Header |
| M | MailFrom | | M | MailFrom |
| H | SMTP Host | | H | SMTP Host |
+--------------+----------------------+ +--------------+----------------------+
TPA-Label Scope Values TPA-Label Scope Values
9.1. TPA-Label Resource Record Scope Syntax 9.1. TPA-Label Resource Record Scope Syntax
scope= Authorization Scope List (Optional). This tag defines a list scope= Authorization Scope List (Optional). This tag defines a list
of scoping assertions for various email-address locations within the of scoping assertions for various email-address locations within the
message. Only recognized scope values offer any form of DKIM message. Only recognized scope values offer any form of ADSP
authorization. authorization.
scope = "F" / "L" / "S" / "M" / "H" scope = "F" / "L" / "S" / "M" / "H"
as-list = "scope" [WSP] "=" [WSP] scope 0*([WSP] ":" [WSP] scope) as-list = "scope" [WSP] "=" [WSP] scope 0*([WSP] ":" [WSP] scope)
9.1.1. TPA-Label Listed Domain Authorization 9.1.1. TPA-Label Listed Domain Authorization
9.1.1.1. From (Author) Header Field 9.1.1.1. From (Author) Header Field
The "F" scope asserts that messages carrying the Author Domain within The "F" scope asserts that messages carrying the Author Domain within
skipping to change at page 15, line 26 skipping to change at page 16, line 34
9.1.2.1. List-ID Header Field 9.1.2.1. List-ID Header Field
The "L" scope asserts that authorization is valid only when a List-ID The "L" scope asserts that authorization is valid only when a List-ID
identifier of the List-ID header field [RFC2919] is within the TPA- identifier of the List-ID header field [RFC2919] is within the TPA-
LLD. LLD.
9.1.2.2. Sender Header Field 9.1.2.2. Sender Header Field
The "S" scope asserts that authorization is valid only when the The "S" scope asserts that authorization is valid only when the
domain within the Sender header is within the TPA-LLD. domain in the Sender header is within the TPA-LLD.
9.1.2.3. Combined 'L' or 'S' Scopes 9.1.2.3. Combined 'L' or 'S' Scopes
When combined, the scopes 'L', 'S' require that either a List-ID When combined, the scopes 'L' and 'S' require that either a List-ID
identifier of the List-ID header field or the Sender header must identifier of the List-ID header field or the Sender header must
contain a domain within the TPA-LLD for the authorization to be contain a domain within the TPA-LLD for the authorization to be
valid. valid.
9.1.3. MailFrom Parameter 9.1.3. MailFrom Parameter
This "M" scope asserts that an email-address domain that is within a The "M" scope asserts that an email-address domain, that is within a
TPA-LLD used in the [RFC5321] MAIL command is also authorized. TPA-LLD used in the [RFC5321] MAIL command is authorized.
9.1.4. SMTP Host domains 9.1.4. SMTP Host domains
The "H" scope asserts that host names given in [RFC5321] EHLO or HELO The "H" scope asserts that host names given in [RFC5321] EHLO or HELO
commands within TPA-LLD are also authorized. This scope might be commands within TPA-LLD is authorized.
used to better ensure DKIM signatures within messages from these
hosts are validated.
10. Authorized Signing Domain 10. Authorized Signing Domain
tpa= Authorized Signing Domain list. (optional) This tag when tpa= Authorized Signing Domain list. (optional) This tag, when
present, MUST repeat all or portions of the domain encoded within the present, MUST repeat all or portions of the domain encoded within the
TPA-Label Resource Record. This option ensures the proper handling TPA-Label Resource Record. This option ensures the proper handling
of possible hash collisions. When a domain is prefixed with the "*." of possible hash collisions. When a domain is prefixed with the "*."
ANY label, then all subdomains of this domain are to be considered ANY label, then all subdomains of this domain are to be considered
included within the list. When the 'tpa' tag is not present or has included within the list. When the 'tpa' tag is not present or has
no value, it should be assumed to compare with the domain used to no value, it should be assumed to compare with the domain used to
generate the TPA-Label. generate the TPA-Label.
ad = [ANY] domain ad = [ANY] domain
ad-list = "tpa" [WSP] "=" [WSP] ad 0*([WSP] ":" [WSP] ad) ad-list = "tpa" [WSP] "=" [WSP] ad 0*([WSP] ":" [WSP] ad)
11. TPA-Label Resource Record Query Transactions 11. TPA-Label Resource Record Query Transactions
The discovery of TPA-Label resource records need not be subsequent to The discovery of TPA-Label resource records need not be subsequent to
the discovery of the ADSP record specified by [RFC5617]. However, the discovery of the ADSP record specified by [RFC5617]. However,
when no ADSP record is discovered, the verifier MAY assume that no when no ADSP record is discovered or when it does not contain a
TPA-Label Resource Records have been published below this location. "dkim" tag value of either "tpa-sig" or "tpa-path", the verifier MAY
assume that no TPA-Label Resource Records have been published.
Otherwise, when there is a Third Party Signature without any Author Otherwise, when there is a Third Party Signature without any Author
Domain Signature, then the discovery of TPA-Label Resource Records Domain Signature, the discovery of TPA-Label Resource Records should
should be attempted. The discovery of a TPA-Label Resource Record be attempted.
may be attempted for List-ID domains as well.
12. TPA-Label Resource Record Compliance Assessment 12. TPA-Label Resource Record Compliance Assessment
Signing practice compliance assessment of Third Party Signatures is a The signing practice compliance assessment of Third Party Signatures
discretionary operation performed by the verifier. Where a verifier is a discretionary operation performed by the verifier. Messages
decides to assess compliance with signing practices asserted by the that have valid Author Domain Signatures are already considered to
Author Domain for Third Party Signatures with "dkim=all tpa-sig", all result in a pass. When a verifier decides to assess compliance for
of the following conditions MUST be met for the result to be Third Party Signatures with an Author Domain ADSP "dkim" tag value
"tpa-sig" or "tpa-path", then, checked in succession, one of the
following sets of conditions MUST be met for the result to be
considered a pass. considered a pass.
For Third Party Signatures, the following represents the set of "tpa-
sig" assessment conditions to be checked:
o The Third Party Signature MUST validate according to [RFC4871]. o The Third Party Signature MUST validate according to [RFC4871].
o The TPA-Label TXT Resource Record MUST exist in DNS. o A TXT Resource Record, referenced by a TPA-Label created by the
o The TPA-Label TXT Resource Record Structure MUST be valid. DKIM signature "d=" tag, MUST exist in DNS.
o Where a scope of "F" is specified, then the Author Domain MUST o The discovered TPA-Label TXT Resource Record Structure MUST be
have an Author Domain Signature or an Author's Domain Acceptable valid.
Third-Party Signature. o The domain that created the TPA-Label MUST be within the TPA-LLD.
o Where a scope of "L" is specified, then when a List-ID identifier o Where a scope of 'F', 'S', or 'L' is specified, the Author Domain
in the List-ID header field is within the TPA-LLD, then the Author MUST have an Author's Domain Acceptable Third-Party Signature.
Domain MUST have an Author Domain Signature or an Author's Domain o Where a scope of 'L' or 'S' is specified, a List-ID identifier in
Acceptable Third-Party Signature. the List-ID header field or a Sender header MUST contain a domain
within the TPA-LLD.
For Third Party Signatures with "dkim=all tpa-path", alternatives to Meeting all the conditions in this set results in a "tpa-sig" pass,
a DKIM signature when no authorized Third Party Signatures has been where subsequent checks are then skipped.
found are as follows:
o A TPA-Label MUST be referenced by the MAIL command or HELO/EHLO. For Third Party Services where the Author Domain ADSP "dkim" tag
o The TPA-Label TXT Resource Record Structure MUST be valid. value contains "tpa-path", and where the preceding assessment
o Where a scope of "H" is specified, the EHLO or HELO domain must be conditions were not met, then the following represents "tpa-path"
within the TPA-LLD. assessment conditions to be checked:
o Where a scope of "M" is specified, the MAIL command domain must be
within the TPA-LLD. One of three possible TXT Resource Records are checked in succession.
o Once the path domain has been authorized by the Author Domain, the These are referenced by an 'H' related TPA-Label created either from
validity of the domain should be confirmed using either forward or the domain given by [RFC5321] EHLO or HELO command, this domain with
reverse DNS references. (A path related protocol dataset might left-most label omitted, or by an 'M' related email-address domain
also provide confirmation, but conservative transaction limits within the [RFC5321] MAIL command.
should be imposed.)
The TXT record discovery process continues until a TPA-Label TXT
Resource Record Structure is found where:
o The discovered TPA-Label TXT Resource Record Structure is valid.
o The domain that created the TPA-Label is within the TPA-LLD.
o The domain that created the TPA-Label corresponds to the scope of
'H', 'H' or 'M' respectively.
o Where a scope of 'L' or 'S' is specified, either the domain in
List-ID given by [RFC2919] in the List-ID header is within the
TPA-LLD, or a Sender header contains a domain within the TPA-LLD
respectively.
o Once these four conditions have been met, the domain MUST be
confirmed using either forward or reverse DNS references. (A path
related protocol dataset might also provide confirmation, but
conservative transaction limits should be imposed.)
Meeting all four conditions in this set, and confirming the domain,
results in a "tpa-path" pass.
When the TPA-Label TXT Resource Record can not be retrieved due to When the TPA-Label TXT Resource Record can not be retrieved due to
some error that is likely transient in nature, as specified in some error that is likely transient in nature, as specified in
[RFC5617] Section 4.3. such as "SERVFAIL" for example, the result of [RFC5617] Section 4.3. such as "SERVFAIL" for example, the result of
the TPA-Label Resource Record compliance assessment is "temperror". the TPA-Label Resource Record compliance assessment is "temperror".
When the TPA-Label TXT Resource Record can not be retrieved with a When the TPA-Label TXT Resource Record retrieval returns a DNS
DNS "NOERROR" with zero or more than one TXT records, the result of "NOERROR", but not with a single record, the result of the TPA-Label
the TPA-Label Resource Record compliance assessment is "permerror". Resource Record compliance assessment is "permerror".
When the TPA-Label TXT Resource Record can not be retrieved with a When the TPA-Label TXT Resource Record can not be retrieved with a
DNS "NXDOMAIN",the result of the TPA-Label Resource Record compliance DNS "NXDOMAIN",the result of the TPA-Label Resource Record compliance
assessment is "nxdomain". assessment is "nxdomain".
When one or more valid Third-Party Signatures are present in the The following pass conditions are combined to provide a single pass
message, or when "dkim=all tpa-path" has been asserted, then: value.
o A "tpa-sig" pass confirms an Author Domain Acceptable Third-Party
o When a TPA-Label Resource Record referenced from the Author Domain
has a scope tag of "F", and the TPA-LLD represents the domain of
the DKIM signing entity, then the message is considered signed
with an Author Domain Acceptable Third-Party Signature.
o When a TPA-Label Resource Record referenced from the Author Domain
has a scope tag of "L", and the List-ID given by [RFC2919] in the
List-ID header is within the TPA-LLD, and the TPA-LLD represents
the domain of the DKIM signing entity, then the message is
considered signed with an Author Domain Acceptable Third-Party
Signature. Signature.
o A "tpa-path" pass confirms an Author Domain Acceptable Service.
o When a TPA-Label Resource Record referenced from the Author Domain
returns a TXT resource record that has a scope tag of "S", and the
email-address domain within the Sender header is within the TPA-
LLD, use of this header by this domain is authorized by the Author
Domain.
o When a TPA-Label Resource Record referenced from the Author Domain
returns a TXT resource record that has a scope tag of "M", and the
email-address domain within the [RFC5321] MAIL command is within
the TPA-LLD, use of this command by this domain is authorized by
the Author Domain. When the domain is confirmed, this provides a
pass with "tpa-path".
o When a TPA-Label Resource Record referenced from the Author Domain
returns a TXT resource record that has a scope tag of "H", and a
host domain given by [RFC5321] EHLO or HELO command is within the
TPA-LLD, the SMTP client is authorized by the Author Domain. When
the domain is confirmed, this provides a pass with "tpa-path".
13. IANA Considerations 13. IANA Considerations
13.1. Author Domain Signing Practices (ADSP) Parameters 13.1. Author Domain Signing Practices (ADSP) Parameters
To accommodate the extensions to ADSP Signing Practices, The IANA To accommodate the extensions to ADSP Signing Practices, the IANA
Registry "ADSP Outbound Signing Practices" defined by Section 4.2.1 Registry "ADSP Outbound Signing Practices" defined by Section 4.2.1
of [RFC5617] needs the following elements to be added: of [RFC5617] needs the following elements to be added:
Note to RFC EDITOR: This is currently located at: Note to RFC EDITOR: This is currently located at:
http://www.iana.org/assignments/adsp-parameters/adsp-parameters.xhtml http://www.iana.org/assignments/adsp-parameters/adsp-parameters.xhtml
+----------+-----------------+ +----------+-----------------+
| Type | Reference | | Type | Reference |
+----------+-----------------+ +----------+-----------------+
| tpa-sig | [THIS DOCUMENT] | | tpa-sig | [THIS DOCUMENT] |
| tpa-path | [THIS DOCUMENT] | | tpa-path | [THIS DOCUMENT] |
+----------+-----------------+ +----------+-----------------+
TPA-Label Resource Record validation Method TPA-Label Resource Record validation Method
13.2. Email Authentication Method Registry 13.2. Email Authentication Method Registry
skipping to change at page 20, line 8 skipping to change at page 19, line 47
+----------+-----------------+ +----------+-----------------+
| tpa-sig | [THIS DOCUMENT] | | tpa-sig | [THIS DOCUMENT] |
| tpa-path | [THIS DOCUMENT] | | tpa-path | [THIS DOCUMENT] |
+----------+-----------------+ +----------+-----------------+
TPA-Label Resource Record validation Method TPA-Label Resource Record validation Method
13.2. Email Authentication Method Registry 13.2. Email Authentication Method Registry
To accommodate the method derived from TPA-Label Resource Record To accommodate the method derived from TPA-Label Resource Record
processing, The IANA Registry "Email Authentication Method" defined processing, the IANA Registry "Email Authentication Method" defined
by Section 6.2 of [RFC5451] needs the following elements to be added: by Section 6.2 of [RFC5451] needs the following elements to be added:
Note to RFC EDITOR: This is currently located at: http:// Note to RFC EDITOR: This is currently located at: http://
www.iana.org/assignments/email-auth/ www.iana.org/assignments/email-auth/
email-auth.xhtml#email-auth-methods email-auth.xhtml#email-auth-methods
+---------+-----------+--------+----------+-------------------------+ +---------+-----------+--------+----------+-------------------------+
| Method | Defined | ptype | property | value | | Method | Defined | ptype | property | value |
+---------+-----------+--------+----------+-------------------------+ +---------+-----------+--------+----------+-------------------------+
| tpa-lld | [THIS | header | d | value of signature "d" | | tpa-lld | [THIS | header | d | value of signature "d" |
| | DOCUMENT] | | | tag. The dkim method | | | DOCUMENT] | | | tag. The dkim method |
| | | | | results from [RFC5451] | | | | | | results from [RFC5451] |
| | | | | should also be included | | | | | | should also be included |
| | | | | in a Authenticated | | | | | | in a Authenticated |
| | | | | Results header field | | | | | | Results header field |
| | | | scope | value of scope | | | | | scope | value of scope |
skipping to change at page 22, line 8 skipping to change at page 21, line 8
| | | | | (Section 10) tag at | | | | | | (Section 10) tag at |
| | | | | time of compliance | | | | | | time of compliance |
| | | | | assessment | | | | | | assessment |
+---------+-----------+--------+----------+-------------------------+ +---------+-----------+--------+----------+-------------------------+
TPA-Label Resource Record validation Method TPA-Label Resource Record validation Method
13.3. Email Authentication Result Names Registry 13.3. Email Authentication Result Names Registry
To accommodate the results derived from TPA-Label Resource Record To accommodate the results derived from TPA-Label Resource Record
processing, The IANA Registry "Email Authentication Method" defined processing, the IANA Registry "Email Authentication Method" defined
by Section 6.3 of [RFC5451] needs the following elements added: by Section 6.3 of [RFC5451] needs the following elements added:
Note to RFC EDITOR: This is currently located at: http:// Note to RFC EDITOR: This is currently located at: http://
www.iana.org/assignments/email-auth/ www.iana.org/assignments/email-auth/
email-auth.xhtml#email-auth-result-names email-auth.xhtml#email-auth-result-names
+--------------+---------+------------------------------------------+ +--------------+---------+------------------------------------------+
| code | method | meaning | | code | method | meaning |
+--------------+---------+------------------------------------------+ +--------------+---------+------------------------------------------+
| none | tpa-lld | No TPA-Label was published | | none | tpa-lld | No TPA-Label was published |
skipping to change at page 22, line 39 skipping to change at page 21, line 39
| | | assessment. | | | | assessment. |
| fail | tpa-lld | The TPA-Label Resource Record had a | | fail | tpa-lld | The TPA-Label Resource Record had a |
| | | tag/value of dkim=all and the Third | | | | tag/value of dkim=all and the Third |
| | | Party Signature failed to its compliance | | | | Party Signature failed to its compliance |
| | | assessment. | | | | assessment. |
| nxdomain | tpa-lld | When obtaining the TPA-Label Resource | | nxdomain | tpa-lld | When obtaining the TPA-Label Resource |
| | | Record, DNS indicated this domain does | | | | Record, DNS indicated this domain does |
| | | not exist. | | | | not exist. |
| Other value | tpa-lld | The TPA-Label Resource Record had a | | Other value | tpa-lld | The TPA-Label Resource Record had a |
| defined in | | tag/value of dkim={other value} and the | | defined in | | tag/value of dkim={other value} and the |
| the IANA | | Third Party Signature failed to its | | the IANA | | Third Party Signature failed its |
| ADSP | | compliance assessment. | | ADSP | | compliance assessment. |
| Outbound | | | | Outbound | | |
| Signing | | | | Signing | | |
| Practices | | | | Practices | | |
| Registry | | | | Registry | | |
+--------------+---------+------------------------------------------+ +--------------+---------+------------------------------------------+
TPA-Label Resource Record complaince assessment Results TPA-Label Resource Record complaince assessment Results
13.4. Third Party Authorizations Labels Registry 13.4. Third Party Authorizations Labels Registry
skipping to change at page 24, line 7 skipping to change at page 23, line 7
| L | Section 9.1.2.1 | | L | Section 9.1.2.1 |
| S | Section 9.1.2.2 | | S | Section 9.1.2.2 |
| M | Section 9.1.3 | | M | Section 9.1.3 |
| H | Section 9.1.4 | | H | Section 9.1.4 |
+-------+-----------------+ +-------+-----------------+
TPA-Label Resource Record compliance assessment Results TPA-Label Resource Record compliance assessment Results
14. Security Considerations 14. Security Considerations
This draft extends signing practices related to [RFC4871] where most This draft extends signing practices for [RFC4871] where most generic
generic DKIM Signature related security matters are discussed there. DKIM Signature related security matters are discussed. Additional
Additional considerations are also included in considerations are also included in [I-D.ietf-dkim-mailinglists].
[I-D.ietf-dkim-mailinglists]. Security considerations for the TPA- Security considerations for the TPA-LLD scheme are mostly related to
Label Resource Record scheme are mostly related to attempts on the attempts on the part of malicious senders to falsely represent
part of malicious senders to represent themselves as other senders, themselves as other senders, often in an attempt to defraud either
often in an attempt to defraud either the recipient or the alleged the recipient or the alleged originator.
originator.
Additional security considerations regarding DKIM signing practices Additional security considerations regarding DKIM signing practices
may be found in the DKIM threat analysis [RFC4686]. may be found in the DKIM threat analysis [RFC4686].
14.1. Benefits to Recipients 14.1. Benefits to Recipients
The verifier, after finding an Author's Domain Acceptable Third-Party The verifier, after finding either an Author's Domain Acceptable
Signature in a message, has a significantly greater confidence in the Third-Party Signature or Author's Domain Acceptable Third-Party
Third-Party authorization than when the no TPA-Label Resource Record Service in a message, will have significantly greater confidence in
could be retrieved. This enhanced confidence may, at the recipients' the Third-Party, than when no TPA-Label Resource Record is obtained.
discretion, cause a message to be delivered to recipient without This enhanced confidence may, at the recipients' discretion, cause a
further domain compliance assessment. message to be delivered to the recipient without further source
related assessment.
14.2. Risks to Recipients 14.2. Risks to Recipients
The decisions that a recipient makes with regard to message filtering The decisions a recipient makes in regard to message filtering based
based on TPA-Label Resource Records is likely to depend on the system on TPA-Label Resource Records are likely to depend on the system
integrity of the Third Party with respect to Authentication (see integrity of the Third Party with respect to the Authentication (see
Section 5.1) and the provided scope labels. When the scope is not Section 5.1) and the provided scope labels. When the 'H' or 'M'
authenticated by the Third Party or a domain is not confirmed, there scoped element is not authenticated by the Third Party or a domain is
is a risk of accepting a potentially spoofed message. not confirmed, there is a risk of accepting potentially spoofed
messages. When there is no out-of-band authentication confirming the
sender, Authentication-Results headers then play an important role.
Without proper Authentication-Results handling by the third-party,
there is also risk of accepting potentially spoofed messages.
With this specification, third party signatures have some verifiable With this specification, third party signatures have verifiable
value. When implementing the compliance assessment of third party value. When implementing the compliance assessment of third party
signatures and TPA-Label Resource Records, implementers need to signatures and TPA-Label Resource Records, implementers need to
consider the possibility that a Bad Actor will send the recipient a consider the possibility that a Bad Actor will send the recipient a
message with a large number of valid DKIM Signatures. Verifying all message with a large number of valid DKIM Signatures. Verifying all
of these may consume a large amount of processing resources and it of these may consume a large amount of processing resources such that
may be worth checking the existence of a TPA-Label Resource Record it may be worth checking the existence of a TPA-Label Resource Record
first. Section 11 describes a quick check to see if TPA-Label first. Section 11 describes a quick check to see if TPA-Label
Resource Records may exist. Additionally validating DKIM signatures Resource Records may exist. Additionally validating DKIM signatures
and obtaining related resource records might be limited to known and obtaining related resource records might be limited to known
trustworthy domains. trustworthy domains.
14.3. Benefits to Author Domains 14.3. Benefits to Author Domains
TPA-Label resource records can replace domain delegations, selector/ TPA-Label resource records can replace domain delegations, selector/
key record mirroring, or key exchanges. Significant amounts of key record mirroring, or key exchanges. A significant number of
detail is associated with selector/key records. These details details are associated with selector/key records. These details
include user limitations, suitable services, key resource record's include user limitations, suitable services, key resource record's
Time-To-Live, revocation and update procedures, and how the DKIM Time-To-Live, revocation and update procedures, and how the DKIM
Signature header field's 'i=' semantics are to be applied. In Signature header field's 'i=' semantics are to be applied. In
addition, to better secure services that might depend upon DKIM keys, addition, services that depend upon DKIM keys are better secured by
rather than delegating DKIM keys, the TPA-LLD scheme allows Author not delegating these DKIM keys, where instead the TPA-LLD scheme
Domains an ability to limit the scope of their authorizations, allows Author Domains an ability to limit the scope of their
without being mistaken for having authenticated the entity submitting authorizations, while also not being mistaken for having
the message. authenticated the entity submitting the message.
TPA-Label Resource Records convey which third-party domains are TPA-Label Resource Records convey which domains are authoritative
authoritative. However, third-party domains are unable to utilize even when they are not the Author Domain. However, authorized
DKIM signature's 'i=' semantics to directly assert which identifiers domains are unable to utilize the DKIM signature's 'i=' semantics to
on whose behalf a signature was added. As such, no third-party directly assert which identifiers on whose behalf a signature was
domain should be authorized unless it is trusted to ensure the added. As such, no domain should be authorized unless it is trusted
Alleged Author of an email undergoes some form authentication that to ensure the Alleged Author of an email undergoes authentication
offers acceptable protections for the Author Domain. Such that offers acceptable protections for the Author Domain. For
authentication might be to ensure submitting entities have example, such authentication might ensure submitting entities have
demonstrated receipt of "pingback" messages sent to the Author demonstrated receipt of "pingback" messages sent to the Author
Address contained within the messages being signed, for example. Address contained within the messages being signed.
Author Domains benefit by deploying TPA-Label Resource Records in By deploying TPA-Label Resource Records, Author Domains benefit when
that a recipient who assesses signing practice compliance using the recipients assess signing practice compliance by using the TPA-LLD
TPA-LLD scheme is less likely to drop messages from their domain. In scheme. These recipients will be less likely to drop the Author
addition, the authorized third party domains are less likely to need Domain's genuine messages, whenever the Author Domain attempts to
reputations for recipients to validate the signature and assess the restrict acceptance. Restricting acceptance of non-compliant
message for compliance with signing practices. messages is the basic motivation for publishing ADSP records. In
addition, recipients are more likely to validate Authorized Third
Party Domain Signatures.
Scope labels provide a fine grained control that allows the Author Broader use of restrictive ADSP policies provides a better likelihood
Domain to control message attributes even from the authorized third of being able to eliminate a greater range of non-compliant messages,
parties. in addition to improving acceptance from authorized sources. With
authorization, scope labels allow the Author Domain to control
message attributes even from the authorized third parties.
Signing domains having good reputations referenced by a TPA-LLD might Signing domains having good reputations referenced by a TPA-LLD might
therefore provide a means to safely extend limited compliance therefore provide a means to safely extend limited compliance
assessment resources to otherwise unknown Author Domains or SMTP assessment resources to otherwise unknown domains or SMTP Clients.
Clients.
14.4. Risks to Author Domains 14.4. Risks to Author Domains
As indicated in Section 5, there is ultimately a trust of the third As indicated in Section 5, there is ultimately a trust of the third
party domain to do the right thing and not generate or allow others party domain to do the right thing and not generate, or allow others
to generate messages that appear to be from the Author Domain. The to generate, messages that falsely appear to be from the Author
compliance assessment mechanisms deployed need to carefully match the Domain. The authentication methods in place for different email
scope of the TPA records. elements need to be carefully reflected in the scope of the TPA
records.
By authorizing some mailing lists with TPA-Label Resource Records, By authorizing mailing lists with TPA-Label Resource Records, this
there could be a loss of confidentiality in respect to mailing list could cause a loss of confidentiality in mailing list participation
domain participation by the Author Domain. This might then help Bad by the Author Domain. This might help Bad Actors deduce which
Actors deduce which subscription related email the Author Domain subscription related email the Author Domain may receive. Because of
might receive. Because of the hashing function in generating the the hashing function in generating the TPA-label, anyone wishing to
TPA-label, anyone wishing to find out the authorized domains has to discover which domains are being authorized, has to probe each TPA-
probe each TPA-label based on the exact signing domain. label based on the exact signing domain. In addition, service
organizations or community groups are able to share comprehensive
lists which means, even though the domain has been authorized, that
in itself does not mean the Author Domain is exchanging messages with
the authorized domain.
14.5. Benefits to Third Party Signers 14.5. Benefits to Third Party Signers
Third Party Signers benefit by having the autonomy to deploy and Third Party Signers benefit by allowing those using their service,
change DKIM signing without consultation with Author Domains. This the autonomy to authorize their service without needing to exchange
is particularly useful for mailing lists. DKIM key related details. This is particularly useful for mailing
lists.
14.6. Risks caused by Third Party Signers 14.6. Risks caused by Third Party Signers
Third Party Signers as mentioned before need to authenticate in some As mentioned before, Third Party Signers need to authenticate
way messages from Author Domains. This authentication provides a messages from Author Domains. This authentication provides a safety
safety mechanism for the Author Domain and the recipient. The Third mechanism for the Author Domain and their recipients. The Third
Party may not be aware of the value of the authentication and change Party may not be aware of the authentication value or the message
this without understanding the negative impact this may have on the elements involved and make changes without understanding the impact
author and recipient domains. The Third Party also may stop DKIM this may have upon targeted Author Domains and their recipients. For
signing messages, also causing a detriment to both author and example, the Third Party might stop DKIM signing or stop applying
recipient. Authentication-Results headers. The unexpected exposure might enable
wide spread abuse and prove detrimental for both the Author Domain
and their recipients.
14.7. SHA-1 Collisions 14.7. SHA-1 Collisions
The use of the SHA-1 hash algorithm does not represent a security The use of the SHA-1 hash algorithm does not represent a security
concern. The hash simply ensures a deterministic domain-name size is concern. The hash simply ensures a deterministic domain-name size is
achieved. Unexpected collisions can be detected and handled by using achieved. Unexpected collisions can be detected and handled by using
the extended TPA-Label Resource Record "tpa=" option. The use of the extended TPA-Label Resource Record "tpa=" option. The use of
TPA-Label Resource Records without the TPA-Label "tpa=" options does TPA-Label Resource Records without the TPA-Label "tpa=" options does
present an opportunity for an adversary to attempt to find a hash present an opportunity for an adversary to attempt to find a hash
collision. Message spoofing outside the realm of DKIM protection is collision. Message spoofing outside the realm of DKIM protection is
still likely to be easier to achieve than finding hash collisions. likely easier to achieve than finding hash collisions. There is
There is minimal risk of TPA-Labels colliding. Listing 3 x 10^45 minimal risk of TPA-Labels colliding. Listing 3 x 10^45 domains has
domains will has less than a 0.1 percent risk of any two domain less than a 0.1 percent risk of any two domain labels colliding.
labels colliding.
14.8. DNS Limits 14.8. DNS Limits
Use of the TPA-Label Resource Records, rather than simply listing the Use of the TPA-Label Resource Records, rather than simply listing the
authorized domain, ensures the DNS record size is independent of the authorized domain, ensures the DNS record size is independent of the
Third Party Domain. The typical domain name size has been steadily Third Party Domain. The typical domain name size has been steadily
increasing. This increase has been caused by domain names that increasing. This increase has been caused by domain names that
encode international character sets, and perhaps soon an increase encode international character sets. Perhaps soon there will be a
will be spurred by an expanse of TLDs having larger labels. futher increase spurred by an expanse of TLDs having larger
international labels.
Using TPA-Label Resource Records in the DNS, as described by this The maximum domain name size allowed, per [RFC1034] Section 3, is 255
scheme, leaves a residual size of 430 for the length of the author bytes (or octets). Each label has a byte for its length. Every
domain and the resource record content. DNS servers that add domain name has a right most label representing the root with a zero
additional resource records, for nameservers as an example, will length, for another byte. A scheme that concatenates a listed domain
further limit this size. Author Domains exceeding this length will with the publishing domain, separated by some conventional label,
need to rely on the recipients using TCP for DNS retrieval or reduces the maximal domain name in half, where the conventional label
extended DNS lengths [RFC2671]. Normally, DNS messages should not reduces this further.
exceed 512 bytes as per Section 2.3.4 of [RFC1035].
If "_tpa." were used as the conventional label with a simple listing
method, the maximum domain name size this supports would be 122
bytes. The suffix for TPA-Labels is "_tpa.domainkey." which consumes
16 bytes. The TPA-Label itself consumes 34 bytes. A domain that
publishes the TPA labels in their domain, would then have 205 bytes
available for their Author Domain. Since an Author's Domain
Acceptable Third-Party Service might not implement DKIM, the TPA-
Label is still able to authorize any domain name with a valid length.
As a result, the maximum allowable Author Domain is increased by 83
bytes or 68% over simple name concatenation.
Normally, DNS messages should not exceed 512 bytes as per Section
2.3.4 of [RFC1035]. Using TPA-Label Resource Records in the DNS, as
described by this document, consumes a consistent 50 bytes, in
addition to the domain name publishing the TPA-Labels. With this
being constant, a limit can be determined as a constraint to resource
record size, to ensure a response does not exceed the maximum DNS
message size. DNS servers that add additional resource records, for
nameservers as an example, will further reduce available resource
record capacity. Domains publishing TPA-Labels exceeding the DNS
message limit will need to rely on recipients using TCP for DNS
retrieval, or EDNS0 [RFC2671] for extended DNS lengths.
15. Acknowledgements 15. Acknowledgements
Frank Ellermann, and Wietse Venema. Frank Ellermann, Michael Deutschmann, Jeff MacDonald, and Wietse
Venema.
16. References 16. References
16.1. Normative References 16.1. Normative References
[FIPS.180-2.2002] [FIPS.180-2.2002]
National Institute of Standards and Technology, "Secure National Institute of Standards and Technology, "Secure
Hash Standard", FIPS PUB 180-2, August 2002, <http:// Hash Standard", FIPS PUB 180-2, August 2002, <http://
csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>. csrc.nist.gov/publications/fips/fips180-2/fips180-2.pdf>.
skipping to change at page 29, line 12 skipping to change at page 28, line 10
"DomainKeys Identified Mail (DKIM) Author Domain Signing "DomainKeys Identified Mail (DKIM) Author Domain Signing
Practices (ADSP)", RFC 5617, August 2009. Practices (ADSP)", RFC 5617, August 2009.
16.2. Informative References 16.2. Informative References
[I-D.ietf-dkim-mailinglists] [I-D.ietf-dkim-mailinglists]
Kucherawy, M., "DKIM And Mailing Lists", Kucherawy, M., "DKIM And Mailing Lists",
draft-ietf-dkim-mailinglists-00 (work in progress), draft-ietf-dkim-mailinglists-00 (work in progress),
June 2010. June 2010.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987. specification", STD 13, RFC 1035, November 1987.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999. RFC 2671, August 1999.
[RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys
Identified Mail (DKIM)", RFC 4686, September 2006. Identified Mail (DKIM)", RFC 4686, September 2006.
[RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail [RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail
skipping to change at page 35, line 11 skipping to change at page 34, line 11
if (verbose) if (verbose)
{ {
printf("Normalized Domain = [%s] %d, SHA-1 = ", in_buf, len); printf("Normalized Domain = [%s] %d, SHA-1 = ", in_buf, len);
for (i = 0; i < 20; i++) for (i = 0; i < 20; i++)
{ {
printf("%02x", sha_res[i]); printf("%02x", sha_res[i]);
} }
printf("\nTPA-Label: 5 bit intervals left to right.\n"); printf("\nTPA-Label: 5 bit intervals left to right.\n");
} }
/* process sha-1 results 4 times by 40 bits (0 to 160) */ /* process sha1 results 4 times by 40 bits (0 to 160) */
for (i = 0, j = 0; i < 4 ; i++) for (i = 0, j = 0; i < 4 ; i++)
{ {
b_5 = (unsigned long long) sha_res[(i * 5)] << 32; b_5 = (unsigned long long) sha_res[(i * 5)] << 32;
b_5 |= (unsigned long long) sha_res[(i * 5) + 1] << 24; b_5 |= (unsigned long long) sha_res[(i * 5) + 1] << 24;
b_5 |= (unsigned long long) sha_res[(i * 5) + 2] << 16; b_5 |= (unsigned long long) sha_res[(i * 5) + 2] << 16;
b_5 |= (unsigned long long) sha_res[(i * 5) + 3] << 8; b_5 |= (unsigned long long) sha_res[(i * 5) + 3] << 8;
b_5 |= (unsigned long long) sha_res[(i * 5) + 4]; b_5 |= (unsigned long long) sha_res[(i * 5) + 4];
if (verbose) if (verbose)
 End of changes. 111 change blocks. 
416 lines changed or deleted 509 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/