< 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/ |