DKIM Third-Party Authorization Label

A third party authorization label (TPA-Label) is a DNS-based prefix for DKIM ADSP records that allow domains in the From header to authorize acceptable third-party signatures. This scheme allows autonomously and unilaterally authorizations for a range of third-party domains using scalable, individual DNS transactions. The extended scope of DKIM signing practice assertions supplant more difficult to administer transparent authorization schemes. Alternatives for facilitating third-party authorizations currently necessitate coordination between two or more domains to synchronously set up selector/key DNS records, DNS zone delegations, and/or a regular exchange of public/private keys.

Checking TPA-Label Resource Records for signing practices may infrequently occur when a message is not compliant with a restrictive ADSP polices where an Author Domain Signature is either missing or invalid. When a third-party signature is found, TPA-Label Resource Record transactions offer an efficient means for Author Domains to authorize specific third-party signing domains. Recipients are afforded a method to determine whether authorization exists in situations where other modes of authorization are impractical. TPA-Label Resource Records permit Author Domain a means to selectively influence message handling, for messages otherwise lacking valid Author Domain signatures.

Requirements Language

Status of this Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction
2. Language and Terminology
    2.1. Terms Imported from other DKIM Specifications:
    2.2. Terms Defined by this Specification:
        2.2.1. Third Party Domain
        2.2.2. Third Party Signature
        2.2.3. Third Party Signer
        2.2.4. TPA-Label Listed Domain
        2.2.5. Author's Domain Acceptable Third-Party Signature
3. Combinatorial ADSP "dkim=" Values.
    3.1. tpa-sig
    3.2. tpa-path
4. TPA-Label Resource Record Authorization Considerations
5. Evaluating the Third-party Signing Domain
    5.1. Third Party Authentication
        5.1.1. Third Party Authentication - Web Email Provider with Subscriber Pingbacks
        5.1.2. Third Party Authentication - Closed Mailing List Example
        5.1.3. Third Party Authentication - Open Mailing List Example
        5.1.4. Third Party Authentication Example - Sender Header Field
        5.1.5. Services Lacking DKIM Signatures
6. DNS Representation
7. TPA-Label and Tag Syntax Definitions
8. TPA-Label Generation
9. TPA-Label TXT Resource Record Structure
    9.1. TPA-Label Resource Record Scope Syntax
        9.1.1. TPA-Label Listed Domain Authorization
        9.1.2. Header Dependent Authorizations
        9.1.3. MailFrom Parameter
        9.1.4. SMTP Host domains
10. Authorized Signing Domain
11. TPA-Label Resource Record Query Transactions
12. TPA-Label Resource Record Compliance Assessment
13. IANA Considerations
    13.1. Author Domain Signing Practices (ADSP) Parameters
    13.2. Email Authentication Method Registry
    13.3. Email Authentication Result Names Registry
    13.4. Third Party Authorizations Labels Registry
    13.5. Third Party Authorizations Scope Registry
14. Security Considerations
    14.1. Benefits to Recipients
    14.2. Risks to Recipients
    14.3. Benefits to Author Domains
    14.4. Risks to Author Domains
    14.5. Benefits to Third Party Signers
    14.6. Risks caused by Third Party Signers
    14.7. SHA-1 Collisions
    14.8. DNS Limits
15. Acknowledgements
16. References
    16.1. Normative References
    16.2. Informative References
Appendix A. DNS Example of TPA-Label Resource Record placement
Appendix B. C code for label generation
§ Authors' Addresses

1. Introduction

Sharing a number of details between the domain owner, and one or more providers of email and DNS represents a transparent method for DKIM authorization. Since there are many ways in which such authorizations could be accomplished, it is unlikely standardized formats will be developed to exchange necessary, and at times, sensitive information. In addition, when there is a security breach and authorization is transparent, the wrong party might be held accountable for content they may have never seen nor logged. The TPA-Label Resource Record scheme is a simple authorization method that keeps visible which administrative entity signed a message and whether an Author Domain authorized the signature. The authorization record may also impose additional header requirements.

Tens of thousands of domains of various financial institutions are frequently being phished. Phishing creates a nuisance for those who aren't expecting these messages, and a threat for those who then interact with them. Whenever institutions employ DKIM and utilize various third-party services, the integrity of their Author Domain Signature might be affected. Some assert less stringent Author Domain Signing Policies on sub-domains to accommodate the affect of third-party services, as suggested by [I‑D.ietf‑dkim‑mailinglists] (Kucherawy, M., “DKIM And Mailing Lists,” June 2010.) section 4.1, that recommends the use of sub-domains to assert less restrictive ADSP policies.

Ensuring third-party inclusion of Sender or List-ID headers enhanced sorting strategies to further improve protections. Users who sort messages based upon email domains are less susceptible to look-alike phish attempts when acceptance is based upon valid Author Domain Signatures. However, when sub-domains assert less stringent policies, these messages might be combined with those having more stringent policies when sorting is based upon the parent domain. Consistently using the same domain avoids confusion that might be exploited.

ADSP represents an open registry offering domain specific guidance for DKIM acceptance criteria, when determining whether messages should be delivered, refused or discarded. However, appropriate actions are unclear whenever third-party services are involved. For example, it is not clear whether ADSP "dkim=all" assertions include third-party services that could damage Author-Domain signatures. Although ADSP warns of a potential for disruption, specific handling recommendations are limited to "dkim=discardable". Although administrative domains asserting all of their outbound messages are signed offer significant forensic value, the handling for messages lacking an Author Domain Signature with a "dkim=all" remain unclear.

2. Language and Terminology

2.1. Terms Imported from other DKIM Specifications:

2.2. Terms Defined by this Specification:

2.2.1. Third Party Domain

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 as a Author Domain Signature.

2.2.3. Third Party Signer

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-Signature header field.

2.2.4. TPA-Label Listed Domain

TPA-Label Listed Domain, TPA-LLD, is a domain TXT resource record that can be referenced with a TPA-Label within an Author Domain. When a "tpa" tag exists within the TXT resource record located at the TPA-Label, the referenced domain must be within a listed domain. When this tag does not exist, the referenced domain is presumed listed. The "scope" tag provides the TPA-LLD authorization which may stipulate additional headers or other email elements before being authorized to act on behalf of the Author Domain publishing the TPA-Label Resource Record.

2.2.5. Author's Domain Acceptable Third-Party Signature

An "Author's Domain Acceptable Third-Party Signature" is a Valid 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 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 the TPA-LLD. Following [RFC5321] (Klensin, J., “Simple Mail Transfer Protocol,” October 2008.), domain name comparisons, as well as TPA-Labels, are case insensitive.

3. Combinatorial ADSP "dkim=" Values.

3.1. tpa-sig

The ADSP dkim= value "tpa-sig" indicates that TPA-Labels will offer a comprehensive list of authorized third-party services that must add DKIM signatures. When this value is "dkim=all tpa-sig" and the DKIM signature has been authorized by a TPA-Label Resource Record with the scope of 'F', 'S', or 'L', then such signatures are in compliance with the Author Domain's asserted Signing Policies. However when 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

The ADSP dkim= value "tpa-path" indicates that TPA-Labels will offer a comprehensive list of authorized third-party services. When this value is "dkim=all tpa-path" and the DKIM signature has been authorized by a TPA-Label Resource Record with the scope of 'F', 'S', 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 DKIM signatures, the confirmed path of the message determined by either the client host name (EHLO/HELO) or the return path (Mail From). The permitted path element's domain is authorized by a TPA-Label Resource Record with the scope of 'H' or 'M' respectively. Such messages are then in compliance with the Author Domain's asserted Signing Policies. The leaf of the host name (left most label) may need to be omitted when checking for TPA-Label Resource Record authorization. When no scope is included in conjunction with 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 is not listed with an 'F', 'S', or 'L' scope, or TPA-Label Resource Record with the scope of 'H' or 'M' where the path elements of the path can not be confirmed or is not listed, the Author Domain recommends these messages be refused.

4. TPA-Label Resource Record Authorization Considerations

When an Author Domain is not within the DKIM signing domain, the TPA-LLD scheme can extend ADSP signing practice compliance. The TPA-LLD scheme with an 'F', 'S', or 'L' scope permits a contained Third Party Signature to be treated as a Author Domain Signature. This allows Author Domains a means to extend restrictive policy compliance. The TPA-LLD scheme for offering valid signatures only requires that DNS publications be made by the Author Domain, even when signing domains and the Author Domain differ. This approach avoids the need to exchange DKIM key related information.

Extended authorization will not ensure all possible spoofing is prevented. However, by permitting broader use of restrictive policies, this should generally reduce the level of spoofing. Authorized third party messages should not receive annotations that indicate the message contains authenticated identities. When the TPA-LLD scope include 'S' or 'L', the messages should contain the headers Sender and List-ID headers respectively with domains that are within the TPA-LLD.

The TPA-LLD scheme plays the role of only providing acceptable signatures or services which might be suitable for non-critical messages, with the goal of improving delivery acceptance, such as those from specific mailing-lists. Before TPA-LLD authorization is deployed, the Author Domain should be assured by the domains being authorized that appropriate measures are in place to authenticate those submitting messages.

5. Evaluating the Third-party Signing Domain

An Author Domain deploying a TPA-Label Resource Record for a Third Party Signer does so on a trust basis. Reasons for deploying TPA-Label Resource Records might be to allow deployment of more stringent ADSP records while also utilizing third-party services.

When an authorized Third Party Signer does not employ DKIM authentication with ADSP or does not include Authentication-Results headers, this could allow authorizations to be exploited.

5.1. Third Party Authentication

The Author Domain SHOULD ensure the Authorization Scope of the TPA-Label Resource Record is authenticated. There are a number of ways email can be authenticated, and different authentication mechanisms validate different parts of the email. The following are examples of how authorization might work:

5.1.1. Third Party Authentication - Web Email Provider with Subscriber Pingbacks

The Author Domain "example.com" wants to deploy a TPA-Label Resource Record to permit their traveling agents the use of "webmail.example.net" services. This email provider has a closed user policy and adds DKIM signatures to messages on behalf of the "webmail.example.net" domain.

The closed user policy of "webmail.example.net" permits subscribers to post messages with Author Domains that are not "webmail.example.net" in the From header fields only when control of the Author Address has been validated by a response to an encoded "pingback" email. The "webmail.example.net" service also establishes accounts to authenticate all users sending messages through their service. Therefore, the referenced TPA-Label Resource Record can include an 'F' scope value to authorize Author Domain messages signed by this Third-Party Signer.

5.1.2. Third Party Authentication - Closed Mailing List Example

The Author Domain wants to deploy a TPA-Label Resource Record for a mailing list with a closed posting policy that redistributes email in a way that breaks Author Domain Signatures, but that adds a DKIM signature on behalf of their domain and includes an Authentication-Results header field for posted messages. The closed posting policy is enforced by requiring subscribers to validate their control of their Author Address by responding to encoded "pingback" email sent to this address.

Because the list management always verifies control of the Author Address, is configured to include Authentication-Results headers, includes a List-ID header, the referenced TPA-Label Resource Record can include an 'L' scope value to permit Author Domain messages containing an authorized List-ID domain to be signed by this Third-Party Signer.

5.1.3. Third Party Authentication - Open Mailing List Example

The Author Domain wants to deploy a TPA-Label Resource Record for a mailing list with an open posting policy that redistributes email in a way that breaks Author Domain Signatures, but that adds a DKIM signature on behalf of their domain and includes an Authentication-Results header field for posted messages. The open posting policy will refuse messages lacking Author Domain Signatures for domains that have deployed an ADSP signing practice of "dkim=all" or "dkim=discardable".

Because the list management always refuses to post an Author Address lacking a Author Domain Signature when the domain has deployed an ADSP record with an "dkim=all" or "dkim=discardable", and is configured to include Authentication-Results headers, includes a List-ID header, the referenced TPA-Label Resource Record can include an 'L' scope value to permit Author Domain messages containing an authorized List-ID domain to be signed by this Third-Party Signer.

5.1.4. Third Party Authentication Example - Sender Header Field

Author Domain "example.com" wishes to temporarily employ the service agency "temp.example.org" to handle overflow secretarial support. The agency "temp.example.org" sends email on behalf of the executive staff of "example.com" and adds the Sender header field of "secretary@example.org" in the email. Since "temp.example.org" only allows its own staff to email through its server that adds "temp.example.org" DKIM signatures, a TPA-LLD can include the "temp.example.org" domain with 'S' scope to specifically authorize messages containing the Sender header field to help ensure these messages are not detected as phishing attempts.

5.1.5. Services Lacking DKIM Signatures

5.1.5.1. Abuse and DSN Reporting

The 'H' and 'L' scopes available within the TPA-LLD records allow the Author Domain to be associated with SMTP Clients publicly transmitting messages and/or the Mail return path when these domains differ and DKIM is not employed by the third-party service. In this case, appropriate DSN or abuse reporting to the Author Domain is better assured as a result. The correspondence between SMTP Client 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 or confirm DSN destinations.

5.1.5.2. Third Party Authentication Example - SMTP Host

Author Domain "example.com" makes use of invite services. This service does not utilize DKIM with the host name given by the EHLO command as "invite.example.net". The Author Domain can authorize the domain "invite.example.net" or "example.net" with the scope of 'H' to improve acceptance of DKIM signed messages that are on behalf of "example.com" from this outbound server.

5.1.5.3. Third Party Authentication Example - Return Path

Author Domain "example.com" makes use of tell-a-friend services. This service does not utilize DKIM with their own return path as "customer@taf.example.net" in the SMTP exchange. The Author Domain can authorize the domain "taf.example.net" with the scope of 'M' to improve acceptance of DKIM signed messages that are on behalf of "example.com" from this outbound server.

5.1.5.4. Use of Path Authorization

Those using the "tpa-path" value should not authorize domains requiring more than a few DNS transactions to confirm the domain. Those implementing this ADSP extension should also limit the number of DNS transactions that might be attempted, or this could negatively 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.

6. DNS Representation

An Author Domain may wish to delegate the listing of third-party services to a different administrative domain. Ideally, this would be accomplished by delegating the _tpa._domainkey.<Author-Domain> zone to the administrative entity handling publication of TPA-Label Resource Records. This delegation could also be done unilaterally with a DNAME resource record published at _tpa._domainkey.<Author-Domain>.

Character-strings contained within the TXT resource record are concatenated into forming a single string. A character-string is a single length octet followed by that number of characters treated as binary information. As an example, a TPA-Label Resource Record may be located at these domains:

7. TPA-Label and Tag Syntax Definitions

8. TPA-Label Generation

The TPA-Label is created from the hash value returned by the "sha1" function of the signing-domain expressed in lower case ASCII. The hash is then converted to a base32 character set, with the resulting label prefixed with an underscore. Any terminating period is not included with the signing-domain, as indicated by the ABNF definition.

9. TPA-Label TXT Resource Record Structure

9.1. TPA-Label Resource Record Scope Syntax

scope= Authorization Scope List (Optional). This tag defines a list of scoping assertions for various email-address locations within the message. Only recognized scope values offer any form of DKIM authorization.

9.1.1. TPA-Label Listed Domain Authorization

9.1.1.1. From (Author) Header Field

Tag	Function
scope=	Authorization Scope List (as-list)
tpa=	Authorized Domains List (ad-list)

Scope Values	Field or Parameter
F	From (Author) Header
L	List-ID
S	Sender Header
M	MailFrom
H	SMTP Host

The "F" scope asserts that messages carrying the Author Domain within the From header field are authorized to be signed by the TPA-LLD.

9.1.2. Header Dependent Authorizations

9.1.2.1. List-ID Header Field

9.1.2.2. Sender Header Field

The "S" scope asserts that authorization is valid only when the domain within the Sender header is within the TPA-LLD.

9.1.2.3. Combined 'L' or 'S' Scopes

When combined, the scopes 'L', 'S' require that either a List-ID identifier of the List-ID header field or the Sender header must contain a domain within the TPA-LLD for the authorization to be valid.

9.1.3. MailFrom Parameter

9.1.4. SMTP Host domains

10. Authorized Signing Domain

tpa= Authorized Signing Domain list. (optional) This tag when present, MUST repeat all or portions of the domain encoded within the TPA-Label Resource Record. This option ensures the proper handling of possible hash collisions. When a domain is prefixed with the "*." 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 no value, it should be assumed to compare with the domain used to generate the TPA-Label.

11. TPA-Label Resource Record Query Transactions

The discovery of TPA-Label resource records need not be subsequent to the discovery of the ADSP record specified by [RFC5617] (Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” August 2009.). However, when no ADSP record is discovered, the verifier MAY assume that no TPA-Label Resource Records have been published below this location. Otherwise, when there is a Third Party Signature without any Author Domain Signature, then the discovery of TPA-Label Resource Records should be attempted. The discovery of a TPA-Label Resource Record may be attempted for List-ID domains as well.

12. TPA-Label Resource Record Compliance Assessment

Signing practice compliance assessment of Third Party Signatures is a discretionary operation performed by the verifier. Where a verifier decides to assess compliance with signing practices asserted by the Author Domain for Third Party Signatures with "dkim=all tpa-sig", all of the following conditions MUST be met for the result to be considered a pass.

For Third Party Signatures with "dkim=all tpa-path", alternatives to a DKIM signature when no authorized Third Party Signatures has been found are as follows:

When the TPA-Label TXT Resource Record can not be retrieved with a DNS "NOERROR" with zero or more than one TXT records, the result of the TPA-Label Resource Record compliance assessment is "permerror".

When the TPA-Label TXT Resource Record can not be retrieved with a DNS "NXDOMAIN",the result of the TPA-Label Resource Record compliance assessment is "nxdomain".

When one or more valid Third-Party Signatures are present in the message, or when "dkim=all tpa-path" has been asserted, then:

13. IANA Considerations

13.1. Author Domain Signing Practices (ADSP) Parameters

Note to RFC EDITOR: This is currently located at: http://www.iana.org/assignments/adsp-parameters/adsp-parameters.xhtml

13.2. Email Authentication Method Registry

Note to RFC EDITOR: This is currently located at: http://www.iana.org/assignments/email-auth/email-auth.xhtml#email-auth-methods

13.3. Email Authentication Result Names Registry

Note to RFC EDITOR: This is currently located at: http://www.iana.org/assignments/email-auth/email-auth.xhtml#email-auth-result-names

13.4. Third Party Authorizations Labels Registry

13.5. Third Party Authorizations Scope Registry

14. Security Considerations

14.1. Benefits to Recipients

The verifier, after finding an Author's Domain Acceptable Third-Party Signature in a message, has a significantly greater confidence in the Third-Party authorization than when the no TPA-Label Resource Record could be retrieved. This enhanced confidence may, at the recipients' discretion, cause a message to be delivered to recipient without further domain compliance assessment.

14.2. Risks to Recipients

Type	Reference
tpa-sig	[THIS DOCUMENT]
tpa-path	[THIS DOCUMENT]

The decisions that a recipient makes with regard to message filtering based on TPA-Label Resource Records is likely to depend on the system integrity of the Third Party with respect to Authentication (see Section 5.1 (Third Party Authentication)) and the provided scope labels. When the scope is not authenticated by the Third Party or a domain is not confirmed, there is a risk of accepting a potentially spoofed message.

With this specification, third party signatures have some verifiable value. When implementing the compliance assessment of third party signatures and TPA-Label Resource Records, implementers need to consider the possibility that a Bad Actor will send the recipient a message with a large number of valid DKIM Signatures. Verifying all of these may consume a large amount of processing resources and it may be worth checking the existence of a TPA-Label Resource Record first. Section 11 (TPA-Label Resource Record Query Transactions) describes a quick check to see if TPA-Label Resource Records may exist. Additionally validating DKIM signatures and obtaining related resource records might be limited to known trustworthy domains.

14.3. Benefits to Author Domains

TPA-Label resource records can replace domain delegations, selector/key record mirroring, or key exchanges. Significant amounts of detail is associated with selector/key records. These details include user limitations, suitable services, key resource record's Time-To-Live, revocation and update procedures, and how the DKIM Signature header field's 'i=' semantics are to be applied. In addition, to better secure services that might depend upon DKIM keys, rather than delegating DKIM keys, the TPA-LLD scheme allows Author Domains an ability to limit the scope of their authorizations, without being mistaken for having authenticated the entity submitting the message.

TPA-Label Resource Records convey which third-party domains are authoritative. However, third-party domains are unable to utilize DKIM signature's 'i=' semantics to directly assert which identifiers on whose behalf a signature was added. As such, no third-party domain should be authorized unless it is trusted to ensure the Alleged Author of an email undergoes some form authentication that offers acceptable protections for the Author Domain. Such authentication might be to ensure submitting entities have demonstrated receipt of "pingback" messages sent to the Author Address contained within the messages being signed, for example.

Author Domains benefit by deploying TPA-Label Resource Records in that a recipient who assesses signing practice compliance using the TPA-LLD scheme is less likely to drop messages from their domain. In addition, the authorized third party domains are less likely to need reputations for recipients to validate the signature and assess the message for compliance with signing practices.

Scope labels provide a fine grained control that allows the Author Domain to control message attributes even from the authorized third parties.

Signing domains having good reputations referenced by a TPA-LLD might therefore provide a means to safely extend limited compliance assessment resources to otherwise unknown Author Domains or SMTP Clients.

14.4. Risks to Author Domains

As indicated in Section 5 (Evaluating the Third-party Signing Domain), there is ultimately a trust of the third 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 compliance assessment mechanisms deployed need to carefully match the scope of the TPA records.

By authorizing some mailing lists with TPA-Label Resource Records, there could be a loss of confidentiality in respect to mailing list domain participation by the Author Domain. This might then help Bad Actors deduce which subscription related email the Author Domain might receive. Because of the hashing function in generating the TPA-label, anyone wishing to find out the authorized domains has to probe each TPA-label based on the exact signing domain.

14.5. Benefits to Third Party Signers

Third Party Signers benefit by having the autonomy to deploy and change DKIM signing without consultation with Author Domains. This is particularly useful for mailing lists.

14.6. Risks caused by Third Party Signers

Third Party Signers as mentioned before need to authenticate in some way messages from Author Domains. This authentication provides a safety mechanism for the Author Domain and the recipient. The Third Party may not be aware of the value of the authentication and change this without understanding the negative impact this may have on the author and recipient domains. The Third Party also may stop DKIM signing messages, also causing a detriment to both author and recipient.

14.7. SHA-1 Collisions

The use of the SHA-1 hash algorithm does not represent a security concern. The hash simply ensures a deterministic domain-name size is achieved. Unexpected collisions can be detected and handled by using the extended TPA-Label Resource Record "tpa=" option. The use of TPA-Label Resource Records without the TPA-Label "tpa=" options does present an opportunity for an adversary to attempt to find a hash collision. Message spoofing outside the realm of DKIM protection is still likely to be easier to achieve than finding hash collisions. There is minimal risk of TPA-Labels colliding. Listing 3 x 10^45 domains will has less than a 0.1 percent risk of any two domain labels colliding.

14.8. DNS Limits

Use of the TPA-Label Resource Records, rather than simply listing the authorized domain, ensures the DNS record size is independent of the Third Party Domain. The typical domain name size has been steadily increasing. This increase has been caused by domain names that encode international character sets, and perhaps soon an increase will be spurred by an expanse of TLDs having larger labels.

15. Acknowledgements

16. References

16.1. Normative References

16.2. Informative References

Appendix A. DNS Example of TPA-Label Resource Record placement

Appendix B. C code for label generation

/*
 * TPA-Label generation utility
 * Copyright (C) 2010 The IETF Trust & and the persons identified as
 * the document authors.  All rights reserved.
 * Redistributions of source code must retain the above copyright
 * notice and the following disclaimer.
 *
 * This document is subject to the rights, licenses and restrictions
 * contained in BCP 78, and except as set forth therein, the authors
 * retain all their rights.
 * This document and the information contained herein are provided on an
 * "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 * OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 * THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 * OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 * THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 * WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 */

#include <stdio.h>
#include <sys/types.h>
#include <stddef.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <ctype.h>
#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <openssl/sha.h>

#define TPA_LABEL_VERSION   102
#define MAX_DOMAIN_NAME     256
#define MAX_FILE_NAME       1024

static char base32[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567";
static char sign_on[] =
{"%s v%d.%02d Copyright (C) (2009)  The IETF Trust & Douglas Otis\n"};
char err_cmd[] =\
 "ERR: Command error with [%s]\n";
char use_txt[]=\
 "Usage: tpa-label [-i domain_input_file] [-o label_output_file][-v]\n";
char help_txt[]=\
"The options are as follows:\n"\
"-i  domain name input. Defaults to stdin. Removes trailing '.'\n"\
"-o  TPA-Label output.  Defaults to stdout.\n"\
"-v  Specifies Verbose Mode.\n\n";

static void usage(void);
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */

static void
usage(void)
{
    (void) fprintf(stderr, "\n%s%s", use_txt, help_txt);
    exit(1);
}
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - */

int
main (int argc, char * argv[])
{
    int  ret_val, in_mode, out_mode, verbose, done, i, j, k;
    char ch;
    unsigned int len;
    unsigned long long b_5;
    char in_fn[MAX_FILE_NAME], out_fn[MAX_FILE_NAME];
    unsigned char in_buf[MAX_DOMAIN_NAME + 2];
    unsigned char sha_res[20], tpa_label[33];
    FILE *in_file, *out_file;

    ret_val = in_mode = out_mode = verbose = done = 0;
    len = 0;

    while ((ch = getopt(argc, argv, "i:o:v")) != -1)
    {
        switch (ch)
        {
            case 'i':
                in_mode = 1;          /* input from file */
                (void) strncpy(in_fn, optarg, sizeof(in_fn));
                in_fn[sizeof(in_fn) - 1] = '\0';
                break;
            case 'o':
                 out_mode = 1;         /* out to file */
                 (void) strncpy(out_fn, optarg, sizeof(out_fn));
                 out_fn[sizeof(out_fn) - 1] = '\0';
                 break;
            case 'v':
                 verbose = 1;
                 break;
            case '?':
            default:
                (void) usage();
                break;
        }
    };

    if (in_mode)
    {
        if ((in_file = fopen(in_fn, "r")) == NULL)
        {
            (void) fprintf(stderr,
                           "ERR: Error opening [%s] input file.\n",
                           in_fn);
            exit(2);
        }
    }
    else
    {
        in_file = stdin;
    }

    if (out_mode)
    {
        if ((out_file = fopen(out_fn, "w")) == NULL)
        {
            (void) fprintf(stderr,
                           "ERR: Error opening [%s] output file.\n",
                           out_fn);
            exit(3);
        }
    }
    else
    {
        out_file = stdout;
    }

    if (out_mode && verbose)
    {
        (void) printf(sign_on, "tpa-label utility",
                      TPA_LABEL_VERSION / 100,
                      TPA_LABEL_VERSION % 100);
    }

    for (i = 0; i < MAX_DOMAIN_NAME && !done; i++)
    {
        if ((ch = fgetc(in_file)) == EOF)
        {
            ch = 0;
        }
        else  if (ch == '\n' || ch == '\r')
        {
            ch = 0;
        }

        in_buf[i] = tolower(ch);

        if (ch == 0)
        {
            len = i;         /* string length */
            done = 1;
        }
    }

    if (!done)
    {
        (void) fprintf(stderr, "ERR: Domain name too long.\n");
        exit (4);
    }

    if (len && in_buf[len - 1] == '.')    /* remove any trailing "." */
    {
        len--;
        in_buf[len] = 0;     /* replace trailing "." with 0 */
    }

    in_buf[len] = 0;         /* terminate string */

    if (len < 2)
    {
        (void)
        fprintf(stderr,
                "ERR: Domain name [%s] too short with %d length.\n",
                in_buf,
                len);
        exit (5);
    }

    SHA1(in_buf, len, sha_res);

    if (verbose)
    {
        printf("Normalized Domain = [%s] %d, SHA-1 = ", in_buf, len);

        for (i = 0; i < 20; i++)
        {
            printf("%02x", sha_res[i]);
        }
        printf("\nTPA-Label: 5 bit intervals left to right.\n");
    }

    /* process sha-1 results 4 times by 40 bits (0 to 160) */

    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) + 1] << 24;
        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) + 4];

        if (verbose)
        {
            printf(" {%010llX}->", b_5);
        }

        for (k = 35; k >= 0; k-= 5, j++)    /* convert 40 bits (5x8) */
        {
            tpa_label[j] = base32[(b_5 >> k) & 0x1F];

            if (verbose)
            {
                 printf(" %02X:%c",
                        (unsigned int)(b_5 >> k) & 0x1F,
                        tpa_label[j]);
            }
        }
        if (verbose)
        {
            printf ("\n");
        }
    }
    if (verbose)
    {
        printf("\n");
    }

    tpa_label[j] = 0;   /* terminate label string */
    fprintf(out_file, "_%s", tpa_label);
    printf("\n");

    /* close */
    if (out_mode)
    {
        if (fclose (out_file) != 0)
        {
            (void) fprintf(stderr,
                           "ERR: Unable to close %s output file.\n",
                           out_fn);
            ret_val = 6;
        }
    }
    if (in_mode)
    {
        if (fclose (in_file) != 0)
        {
            (void) fprintf(stderr,
                           "ERR: Unable to close %s input file.\n",
                           in_fn);
             ret_val = 7;
        }
    }
    return (ret_val);
}

Method	Defined	ptype	property	value
tpa-lld	[THIS DOCUMENT]	header	d	value of signature "d" tag. The dkim method results from [RFC5451] (Kucherawy, M., “Message Header Field for Indicating Message Authentication Status,” April 2009.) should also be included in a Authenticated Results header field
			scope	value of scope (Third Party Authorizations Scope Registry) tag. (When 'scope' contains 'H', the iprev (Kucherawy, M., “Message Header Field for Indicating Message Authentication Status,” April 2009.) [RFC5451] (Section 3) method results should also be included in the Authenticated-Results header field)
			ca-scope	The scopes (Third Party Authorizations Scope Registry) with a compliance assessment as pass
			tpa	Value of tpa (Authorized Signing Domain) tag at time of compliance assessment

code	method	meaning
none	tpa-lld	No TPA-Label was published
pass	tpa-lld	section Section 12 (TPA-Label Resource Record Compliance Assessment)
tempfail	tpa-lld	section Section 12 (TPA-Label Resource Record Compliance Assessment)
permfail	tpa-lld	section Section 12 (TPA-Label Resource Record Compliance Assessment)
unknown	tpa-lld	The TPA-Label Resource Record had a tag/value of "dkim=unknown" and the Third Party Signature failed its compliance assessment.
discard	tpa-lld	The TPA-Label Resource Record had a tag/value of dkim=discard and the Third Party Signature failed its compliance assessment.
fail	tpa-lld	The TPA-Label Resource Record had a tag/value of dkim=all and the Third Party Signature failed to its compliance assessment.
nxdomain	tpa-lld	When obtaining the TPA-Label Resource Record, DNS indicated this domain does not exist.
Other value defined in the IANA ADSP Outbound Signing Practices Registry	tpa-lld	The TPA-Label Resource Record had a tag/value of dkim={other value} and the Third Party Signature failed to its compliance assessment.

tag	defined	definition
dkim	Section 9 (TPA-Label TXT Resource Record Structure)	As per IANA Registry ADSP Outbound Signing Practices
scope	Section 9.1 (TPA-Label Resource Record Scope Syntax)	Section 13.5 (Third Party Authorizations Scope Registry)
tpa-sig	Section 10 (Authorized Signing Domain)	List of authorized domains
tpa-path	Section 10 (Authorized Signing Domain)	List of authorized domains

value	defined
F	Section 9.1.1 (TPA-Label Listed Domain Authorization)
L	Section 9.1.2.1 (List-ID Header Field)
S	Section 9.1.2.2 (Sender Header Field)
M	Section 9.1.3 (MailFrom Parameter)
H	Section 9.1.4 (SMTP Host domains)

[FIPS.180-2.2002]	National Institute of Standards and Technology, “Secure Hash Standard,” FIPS PUB 180-2, August 2002.
[RFC2119]	Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[RFC2919]	Chandhok, R. and G. Wenger, “List-Id: A Structured Field and Namespace for the Identification of Mailing Lists,” RFC 2919, March 2001 (TXT).
[RFC4648]	Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” RFC 4648, October 2006 (TXT).
[RFC4871]	Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” RFC 4871, May 2007 (TXT).
[RFC5234]	Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” STD 68, RFC 5234, January 2008 (TXT).
[RFC5321]	Klensin, J., “Simple Mail Transfer Protocol,” RFC 5321, October 2008 (TXT).
[RFC5322]	Resnick, P., Ed., “Internet Message Format,” RFC 5322, October 2008 (TXT, HTML, XML).
[RFC5451]	Kucherawy, M., “Message Header Field for Indicating Message Authentication Status,” RFC 5451, April 2009 (TXT).
[RFC5617]	Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” RFC 5617, August 2009 (TXT).

[I-D.ietf-dkim-mailinglists]	Kucherawy, M., “DKIM And Mailing Lists,” draft-ietf-dkim-mailinglists-00 (work in progress), June 2010 (TXT).
[RFC1035]	Mockapetris, P., “Domain names - implementation and specification,” STD 13, RFC 1035, November 1987 (TXT).
[RFC2671]	Vixie, P., “Extension Mechanisms for DNS (EDNS0),” RFC 2671, August 1999 (TXT).
[RFC4686]	Fenton, J., “Analysis of Threats Motivating DomainKeys Identified Mail (DKIM),” RFC 4686, September 2006 (TXT).
[RFC5016]	Thomas, M., “Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol,” RFC 5016, October 2007 (TXT).
[RFC5226]	Narten, T. and H. Alvestrand, “Guidelines for Writing an IANA Considerations Section in RFCs,” BCP 26, RFC 5226, May 2008 (TXT).
[RFC5672]	Crocker, D., “RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update,” RFC 5672, August 2009 (TXT).
[RFC5863]	Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, “DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations,” RFC 5863, May 2010 (TXT).
[apwg-globalphishingsurvey-2H2009]	Anti-Phishing Working Group, “Global Phishing Survey: Trends and Domain Name Use 2H2009,” May 2009.

	Douglas Otis
	Trend Micro
	10101 N. De Anza Blvd
	Cupertino, CA 95014
	USA
Phone:	+1.408.257-1500
Email:	doug_otis@trendmicro.com

	Daniel Black
	Canberra ACT
	Australia
Email:	daniel.subs@internode.on.net

DKIM Third-Party Authorization Labeldraft-otis-dkim-tpa-label-04

Abstract