DKIM Working Group D. Otis Internet-Draft Trend Micro Intended status: Standards Track D. Black Expires: February 11, 2011 August 10, 2010 DKIM Third-Party Authorization Label draft-otis-dkim-tpa-label-06 Abstract A third party authorization label (TPA-Label) is a DNS-based extension for DKIM ADSP records that allows domains in the From header field to authorize acceptable third-party signatures. This approach allows autonomous and unilateral authorizations for third- party domains using scalable, individual DNS transactions. The extended scope of DKIM signing practice assertions introduced here supplants transparent authorization schemes that are more difficult to administer. 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 might occur infrequently when a message is not compliant with restrictive ADSP practices, 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 Domains a means to influence message handling selectively, for messages otherwise lacking valid Author Domain signatures. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 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 Otis & Black Expires February 11, 2011 [Page 1] Internet-Draft TPA-Label August 2010 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 Internet-Draft will expire on February 11, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) 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. Otis & Black Expires February 11, 2011 [Page 2] Internet-Draft TPA-Label August 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Language and Terminology . . . . . . . . . . . . . . . . . . . 6 2.1. Terms Imported from other DKIM Specifications: . . . . . . 6 2.2. Terms Defined by this Specification: . . . . . . . . . . . 7 2.2.1. Third Party Signature . . . . . . . . . . . . . . . . 7 2.2.2. Third Party Signer . . . . . . . . . . . . . . . . . . 7 2.2.3. TPA-Label Listed Domain, TPA-LLD . . . . . . . . . . . 7 2.2.4. Author's Domain Acceptable Third-Party Signature . . . 8 2.2.5. Author's Domain Acceptable Third-Party Service . . . . 8 3. Combinatorial ADSP "dkim" tag Values. . . . . . . . . . . . . 8 3.1. tpa-sig . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. tpa-path . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. TPA-Label Resource Record Authorization Considerations . . . . 9 5. Evaluating the Third-party Signing Domain or Service . . . . . 11 5.1. Third Party Authentication . . . . . . . . . . . . . . . . 11 5.1.1. Third Party Authentication - Web Email Provider with Subscriber Pingbacks . . . . . . . . . . . . . . 11 5.1.2. Third Party Authentication - Closed Mailing List Example . . . . . . . . . . . . . . . . . . . . . . . 11 5.1.3. Third Party Authentication - Open Mailing List Example . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.4. Third Party Authentication Example - Sender Header Field . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1.5. Services Lacking DKIM Signatures . . . . . . . . . . . 12 6. DNS Representation . . . . . . . . . . . . . . . . . . . . . . 14 7. TPA-Label and Tag Syntax Definitions . . . . . . . . . . . . . 14 8. TPA-Label Generation . . . . . . . . . . . . . . . . . . . . . 15 9. TPA-Label TXT Resource Record Structure . . . . . . . . . . . 16 10. TPA-Label Resource Record Definition . . . . . . . . . . . . . 17 11. Outbound Extended Signing Practice . . . . . . . . . . . . . . 17 12. TPA-Label Resource Record Scope Syntax . . . . . . . . . . . . 17 12.1. Authorized Signing Domain . . . . . . . . . . . . . . . . 18 12.2. TPA-Label Listed Domain Authorization . . . . . . . . . . 18 12.2.1. From (Author) Header Field . . . . . . . . . . . . . . 18 12.3. Header Dependent Authorizations . . . . . . . . . . . . . 18 12.3.1. List-ID Header Field . . . . . . . . . . . . . . . . . 18 12.3.2. Sender Header Field . . . . . . . . . . . . . . . . . 18 12.3.3. Combined 'L' or 'S' Scopes . . . . . . . . . . . . . . 18 12.4. SMTP Host domains . . . . . . . . . . . . . . . . . . . . 19 12.5. SMTP Host domains . . . . . . . . . . . . . . . . . . . . 19 12.6. MailFrom Parameter . . . . . . . . . . . . . . . . . . . . 19 12.7. SMTP Host domains . . . . . . . . . . . . . . . . . . . . 19 13. TPA-Label Resource Record Query Transactions . . . . . . . . . 20 14. TPA-Label Resource Record Compliance Assessment . . . . . . . 20 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 15.1. Author Domain Signing Practices (ADSP) Parameters . . . . 22 Otis & Black Expires February 11, 2011 [Page 3] Internet-Draft TPA-Label August 2010 15.2. Email Authentication Method Registry . . . . . . . . . . . 23 15.3. Email Authentication Result Names Registry . . . . . . . . 24 15.4. Third Party Authorizations Labels Registry . . . . . . . . 24 15.5. Third Party Authorizations Scope Registry . . . . . . . . 25 16. Security Considerations . . . . . . . . . . . . . . . . . . . 26 16.1. Benefits to Recipients . . . . . . . . . . . . . . . . . . 26 16.2. Risks to Recipients . . . . . . . . . . . . . . . . . . . 26 16.3. Benefits to Author Domains . . . . . . . . . . . . . . . . 27 16.4. Risks to Author Domains . . . . . . . . . . . . . . . . . 28 16.5. Benefits to Third Party Signers . . . . . . . . . . . . . 28 16.6. Risks caused by Third Party Signers . . . . . . . . . . . 28 16.7. SHA-1 Collisions . . . . . . . . . . . . . . . . . . . . . 28 16.8. DNS Limits . . . . . . . . . . . . . . . . . . . . . . . . 29 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 18.1. Normative References . . . . . . . . . . . . . . . . . . . 30 18.2. Informative References . . . . . . . . . . . . . . . . . . 31 Appendix A. DNS Example of TPA-Label Resource Record placement . 32 Appendix B. C code for label generation . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Otis & Black Expires February 11, 2011 [Page 4] Internet-Draft TPA-Label August 2010 1. Introduction A transparent method for DKIM authorization requires the sharing of a number of details between the domain owner, and one or more providers of email and DNS. Transparent authorization occurs when an Author Domain's DNS resolves a public DKIM key, with the corresponding private key being held by a third-party. With the many ways in which this might be achieved, it is unlikely that standardized formats will be developed to exchange necessary, and at times, sensitive information between various informal third-party services, such as mailing-lists. With transparent authorizations, when a security breach does occur, the wrong party might be held accountable for content it never saw nor logged. For informal authorizations, the TPA-Label Resource Record supports 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 field requirements to better ensure protective message sorting. 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 wish to utilize various informal third-party services, the integrity of their Author Domain Signatures might be affected. Some respond to this by implementing less stringent Author Domain Signing Practices on subdomains to accommodate the impact of these third-party services, as suggested by [I-D.ietf-dkim-mailinglists] Section 4.1, that recommends use of subdomains to assert less restrictive ADSP practices. As currently structured, ADSP does not offer an alternative to using more domains, where only some are protected by a restrictive practice. As such, it lacks a method to retain an authentication & authorization as an acceptance condition when using informal third party services. Loss of authentication will lead to an increase of 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 commonly uses subdomains in a URL to fool potential victims. Deterrents based upon reputation and/or path based strategies that utilize a variety of originating header fields are ineffective. These header fields often remain invisible to recipients, and contain domains being exploited for periods measured in hours, in an avoidance of any Whack-A-Mole like response. Even long term reputations are increasingly problematic due to an intermix of Otis & Black Expires February 11, 2011 [Page 5] Internet-Draft TPA-Label August 2010 messages from compromised accounts. Few recipients will inspect the stack of message header fields, or be able to draw useful conclusions from a profusion of unfriendly information. However, many recipients deal with abuse by sorting messages into groups based upon an assumed source found in a few originating header fields. ADSP represents an open registry that 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 defined in [RFC5617] can autonomously authorize DKIM signatures [RFC4871] (updated by [RFC5672]) by specific domains. This document offers secondary signing practices for additional ADSP compliance options whenever no Author Domain Signature is present within the message. The intended purpose of TPA-Label Resource Records is to improve acceptance rates of genuine messages, to minimize domain use, to minimize success rates for phishing, to improve sorting protections, and to minimize a recipient's administrative costs. TPA-Label Resource Records authorize third-party signing domains and services to extend DKIM compliance options for signing practices defined by [RFC5617]. Domains that both reference and are listed within a TPA-Label resource record are to be considered equivalent to the authorizing Author Domain when assessing compliance with ADSP. The TXT resource records, associated with TPA-Labels, start with the 'dkim' tag as defined by [RFC5617] for signing practices, and may contain tags specifically defined for TPA-Label Resource Records. 2. Language and Terminology 2.1. Terms Imported from other DKIM Specifications: A "Valid Signature" is any signature on a message that correctly verifies using the procedure described in Section 6.1 of [RFC4871]. "Author Address" is defined in Section 2.3 of [RFC5617]. Otis & Black Expires February 11, 2011 [Page 6] Internet-Draft TPA-Label August 2010 "Author Domain" is defined in Section 2.4 of [RFC5617]. "Alleged Author" is defined in Section 2.5 of [RFC5617]. "Author Domain Signature" is defined in Section 2.7 of [RFC5617] 2.2. Terms Defined by this Specification: 2.2.1. Third Party Signature A "Third Party Signature" is a Valid Signature that does not qualify as an Author Domain Signature. Editor's Note: While this term is defined in Section 6.3 of [RFC5863] and in Section 2 of [RFC5016], this definition is in terms of the Author Domain Signature and avoids statements about any header field dependencies. 2.2.2. Third Party Signer A "Third Party Signer" is a signer that adds a valid DKIM signature that references a domain with the 'd=' tag in the DKIM-Signature header field that is not the Author Domain. 2.2.3. TPA-Label Listed Domain, TPA-LLD TPA-Label Listed Domain, TPA-LLD, is a TXT resource record referenced with a TPA-Label published within an Author Domain. When a "tpa" tag exists within the TXT resource record located at the TPA-Label, the referencing domain (the domain used to generate the label) must be within the listed domain. When the "tpa" tag does not exist, the referenced domain is presumed listed. The "scope" tag may stipulate existence of additional header fields, or indicate alternate confirmation methods applied against specific email elements. Third- party domain confirmation might use a DKIM signature or confirm the authorized domain using specific methods with various path related email elements. 'F' is the default confirmation scope assumed, indicating DKIM confirms the authorized domain when no other method is specified. The 'S' and 'L' scope do not confirm the domain, but require at least one Sender or List-ID header field to hold the identity of the authorized domain respectively. The 'e', 'h', 'm', and 't' indicate specific alternative methods using message elements to confirm the authorized domain. Being compliant with TPA-LLD allows the referencing domain to informally act on behalf of the Author Domain. Following [RFC5321], domain name comparisons, as well as TPA-Labels, are case insensitive. Otis & Black Expires February 11, 2011 [Page 7] Internet-Draft TPA-Label August 2010 2.2.4. 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'. The 'F' scope indicates this third-party domain implements DKIM signing. For 'S' and 'L' scopes, the respective Sender header field or a List-ID identifier of the List-ID header field 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 confirms the administrative domain through the message element determined by the method specified by the scope of 'e', 'h', 'm', or 't'. For 'S' or 'L' scopes, the respective Sender header field or a List-ID identifier of the List-ID header field must exist for either scope and contain a domain within the TPA-LLD for authorization to be valid. 3. Combinatorial ADSP "dkim" tag Values. This document defines new values listed with the ADSP "dkim" tag in addition to those defined in [RFC5617] Section 4.2.1. These values can be appended to those currently defined or used separately. When used separately, the value "all" is to be assumed to prefix the new values when recognized, otherwise the value "unknown" will be 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 The ADSP dkim tag value "tpa-sig" indicates that TPA-Labels will offer a comprehensive list of Author's Domain Acceptable Third-Party Signatures that may also include header field requirements. When there is no valid Author Domain Signature or Author's Domain Acceptable Third-Party Signature, the Author Domain recommends these messages be refused. 3.2. tpa-path The ADSP dkim tag value "tpa-path" indicates that TPA-Labels will offer a comprehensive list of Author's Domain Acceptable Third-Party Signatures and Authorized Third-Party Services that may also include Otis & Black Expires February 11, 2011 [Page 8] Internet-Draft TPA-Label August 2010 header field requirements. The "tpa-path" allows alternative path verification methods, to accommodate third party services lacking DKIM signatures. The message element is determined by the method specified by the scope. When the path domain is confirmed by the specified method, and the message is compliant with TPA-LLD requirements, then it is also compliant with the Author Domain's asserted signing practices. The leaf of the hostname (left most label) may need to be omitted when checking for TPA-Label Resource Record authorization. When there is no valid Author Domain Signature, or Author's Domain Acceptable Third-Party Signature, or Author's Domain Acceptable Third-Party Service, the Author Domain 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 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 an Author Domain Signature. The 'e', 'h', and 't' scopes permit acceptance based upon confirmation of the client hostname (EHLO/HELO). The 'm' scope permits confirmations based upon the return path (Mail From) domain. For 'S' and 'L' scopes, a respective Sender header field or a List-ID identifier of the List-ID header field must exist for at least one of the scopes, and contain a domain within the TPA-LLD for authorization to be valid. The 'S' and 'L' scopes support message sorting. Any matching header field with a domain within the TPA-LLD allows recipients to differentiate sources, which satisfies requirements for any other 'S' or 'L' scope. The 'S' and 'L' scopes provide Author Domains a means to extend restrictive policy compliance. 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. The TPA-LLD authorization scheme only requires that DNS publications be made by the Author Domain, even when signing domains and the Author Domain differ. This Otis & Black Expires February 11, 2011 [Page 9] Internet-Draft TPA-Label August 2010 approach avoids a need to exchange DKIM key related information and better protects private key information. Before TPA-LLD authorization is deployed, the Author Domain should be assured by domains being authorized that appropriate measures are in place to authenticate those who are submitting messages. Retaining authentication & authorization for the From, Sender, and List-ID header fields, and being able to ensure third-party inclusion of a Sender or List-ID header fields, enhances protections afforded by message sorting. This protection reduces susceptibility to deceptive look-alike phishing attempts. Use of subdomains that assert less stringent practices, might inadvertently combine with those having more stringent practices when sorting is based upon parent domains. Consistently using the same domain avoids confusion that could be exploited to deceive recipients. At this time, it is not practical for large ISPs to make restrictive ADSP assertions. This would impair the utility of their service by excluding all third-party services lacking suitable source authentication. However, institutions can benefit by making restrictive ADSP assertions that better retain recipient trust in their email notifications, without forgoing use of all informal third-party services. Rather than using subdomains lacking ADSP restrictions, suitable third-party services can be authorized by using TPA-Labels instead. This approach also offers a proactive means for recipients to filter phishing attempts. TPA-Label authorization will not ensure all possible spoofing is prevented. However, by permitting broader use of restrictive practices, this should generally reduce the level of spoofing over what might be otherwise allowed. Authorized third party messages SHOULD NOT receive annotations that indicate the message contains authenticated identities. The TPA-LLD scope SHOULD include the 'S' or 'L' scope where appropriate to allow recipients a means to isolate and distinguish different message sources. The "dkim" tag within the TPA-Label Resource Record is normally expected to 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 "tpa" tag values, the TPA-Label Resource Record "dkim" tag value overrides the ADSP Resource Record "dkim" tag value. When the TPA- Label Resource Record "dkim" tag value contains "discardable", compliance with the "scope" tag values is not required to override the ADSP Resource Record. Use of "tpa-path" SHOULD selectively override the ADSP "tpa-sig" only where needed. Otis & Black Expires February 11, 2011 [Page 10] Internet-Draft TPA-Label August 2010 5. Evaluating the Third-party Signing Domain or Service An Author Domain deploying a TPA-Label Resource Record 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 signatures or services. When an authorized Third Party Signer does not employ DKIM authentication with ADSP or does not include Authentication-Results header fields [RFC5451], 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 its 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 its 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 adds a DKIM signature on behalf of the mailing list 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 Addresses by responding to encoded "pingback" email sent Otis & Black Expires February 11, 2011 [Page 11] Internet-Draft TPA-Label August 2010 to these addresses. Since the mailing list management always verifies control of the Author Address, and is configured to include Authentication-Results header fields, and includes a List-ID header field, 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 the mailing list 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". Since 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 header fields, and includes a List-ID header field, 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@temp.example.org" in the email. Since "temp.example.org" 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" domain with an 'S' scope to specifically authorize messages containing the Sender header field to help ensure these messages are not handled as phishing attempts. 5.1.5. Services Lacking DKIM Signatures 5.1.5.1. Abuse and DSN Reporting There is likely little interest for an otherwise uninvolved domain to receive a massive number of bogus messages being returned as Otis & Black Expires February 11, 2011 [Page 12] Internet-Draft TPA-Label August 2010 feedback. Often the purpose of feedback is to discover compromised systems or accounts actively being exploited in some manner. Unless the Author Domain is confirmed as having handled or authorized the handling of the message, only statistics and samples should be reported to the associated Autonomous System [RFC1930], and perhaps to the Author Domain when interest is expressed. The 'e', 'h', 'm', and 't' scope options within the TPA-LLD records allow the Author Domain to be associated through various methods with path related domains, when 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 well. 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, where the host name given by the EHLO command is "invite.example.net". The Author Domain can authorize the domain "invite.example.net" or "example.net" with the scope of 'e' to improve acceptance of messages that are sent 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 its 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 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 5 network transactions to confirm their domain. Those implementing this ADSP extension should also limit the number of DNS transactions attempted, or this could negatively impact unrelated domains when evaluating path related protocols. Methods that create subsequent transactions based upon the macro expansion of email-address local-parts should not be used. Libraries that process [RFC4408] record scripts may invoke a large number of DNS transactions from cached records, and target unrelated domains with queries modulated by recipients through macro expansion. Recipient processing of such scripts might become blocked, when found to produce significant network amplification from cached records during spam campaigns. Otis & Black Expires February 11, 2011 [Page 13] Internet-Draft TPA-Label August 2010 6. DNS Representation The receiver obtains domain authorizations with a DNS query for an IN class TXT TPA-Label resource record located below the location specified in [RFC4871] Section 7.4 and the label "_tpa.". The TPA- Label itself is generated by processing the domain in question, which normally matches the DKIM signature's "d=" parameter. A TPA-Label Resource Record is published adjacent to the [RFC5617] conventional ADSP record, for example below "_tpa._domainkey.". The Author Domain provides authorization for other domains with the existence of a TPA-Label TXT resource record. When a "tpa" tag value exists, it must include the referenced domain before authorization is valid. Authorization to informally act on behalf of the Author Domain can also be limited by the "scope" tag value for specific message elements. 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. zone to the administrative entity handling publication of TPA-Label Resource Records. This delegation could also be done unilaterally with a [RFC2672] DNAME resource record published at _tpa._domainkey.. Character-strings contained within the TXT resource record are concatenated into forming a single string. A character-string, as defined in [RFC1035] Section 3.3 for resource records, is a single length octet followed by that number of characters treated as binary information. The TPA-Label Resource Records should be located at these domains: ._tpa._domainkey.. 7. TPA-Label and Tag Syntax Definitions Augmented BNF for Syntax Specifications: asterisk = %x2A ; "*" dash = %x2D ; "-" dot = %x2E ; "." underscore = %x5F ; "_" ANY = asterisk dot ; "*." dns-char = ALPHA / DIGIT / dash id-prefix = ALPHA / DIGIT label = id-prefix [*61dns-char id-prefix] Otis & Black Expires February 11, 2011 [Page 14] Internet-Draft TPA-Label August 2010 sldn = label dot label base-char = (dns-char / underscore) domain = *(label dot) sldn tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ] tag-spec = *WSP tag-name *WSP "=" *WSP tag-value [WSP] tag-name = ALPHA 0*ALNUMPUNC / "dkim" / "scope" / "tpa" tag-value = [ tval 0*( 1*(WSP) tval ) ] ; WSP prohibited at end tval = 1*VALCHAR VALCHAR = %x21-3A / %x3C-7E ; EXCLAMATION to TILDE except SEMICOLON ALNUMPUNC = ALPHA / DIGIT / "_" 8. TPA-Label Generation The TPA-Label is generated by nesting functions as follows: "base32" function is defined in [RFC4648]. "sha1" function is defined in [FIPS.180-2.2002]. "lcase" converts upper-case ALPHA characters to lower-case. "tpa-domain" is normally the "d=" tag value defined in Section 3.5 of [RFC4871]. (underscore) base32( sha1( lcase(tpa-domain))) The TPA-Label is created from the hash value returned by the "sha1" function of the tpa-domain expressed in lower case ASCII. Any terminating period is not included with the tpa-domain, as indicated by the ABNF definition. Note: No newline character, 0x0A, is to be appended to the end of the domain name, as might occur with the command line generation of sha1 values. For example, these command line appended newlines can be avoided by using the 'echo -n" option. The label encoding process inputs the hash as a byte stream of four 40-bit data blocks where each data block outputs 8 encoded characters. Proceeding from left to right, a 40-bit input group is formed by concatenating 5 bytes. The 40-bit input is then treated as 8 concatenated 5-bit groups, each of which is translated into a single digit of the base32 alphabet. The bit stream is ordered with Otis & Black Expires February 11, 2011 [Page 15] Internet-Draft TPA-Label August 2010 the most-significant-bit first, being the high-order bit of the first byte. The entire output is then concatenated first to last, left to right, into 32 characters prefixed with an underscore. 9. TPA-Label TXT Resource Record Structure Every TPA-Label TXT resource record MUST start with an outbound signing-practices tag, so the first four characters of the record are lowercase "dkim", followed by optional whitespace and "=". In addition to the tags defined by [RFC5617], TPA-Label syntax descriptions for additional tags follow the tag-value syntax 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 the ABNF below, the WSP token is inherited from [RFC5322]. The ALPHA and DIGIT tokens are imported from [RFC5234]. The tags used in TPA-Label resource records are as follows: +-------+------------------------------------------------+ | Tag | Function | +-------+------------------------------------------------+ | dkim | Outbound Extended Signing Practices (dkim-tag) | | scope | Authorization Scope List (scope-tag) | | tpa | Authorized Domains List (tpa-tag) | +-------+------------------------------------------------+ TPA-Label Tags +-------------+-------------------------------+ | dkim values | Field or Parameter | +-------------+-------------------------------+ | tpa-sig | Third-Party Signature | | tpa-path | Third-Party Path or Signature | | all tpa-sig | Third-Party Signature | | discardable | Selective discardable | +-------------+-------------------------------+ Outbound Extended Signing Practices Values Otis & Black Expires February 11, 2011 [Page 16] Internet-Draft TPA-Label August 2010 +-----------+----------------------------+--------------------------+ | scope | Field or Parameter | Method | | values | | | +-----------+----------------------------+--------------------------+ | F | From (Author) Header Field | Match Address Domain | | L | List-ID Header Field | Match List-ID Identifier | | S | Sender Header Field | Match Address Domain | | e | SMTP Hostname | Resolve Hostname IP Addr | | h | SMTP Hostname | Pass SPF with Hostname | | m | MailFrom | Pass SPF with MailFrom | | t | SMTP Hostname | Cert of Hostname | +-----------+----------------------------+--------------------------+ TPA-Label Scope Values 10. TPA-Label Resource Record Definition Tags in the TPA-Label Resourse Record are shown below. The dkim tag MUST be present as the left most tag.Unrecognized tags MUST be ignored. TPA-Label Resource Record Definition tpalabelrr = dkim-tag [";"] 0*( 1*(WSP) tag-list) ] 11. Outbound Extended Signing Practice Outbound Signing Practice Extensions. This tag defines a list of extended outbound signing practices that combine with those for various email-address locations within the message. Only recognized scope values offer any form of ADSP authorization. "dkim" tag ; hyphenated-word is defined in [RFC4871] x-obesp = hyphenated-word ; for future extension dkim_val = ( "tpa-sig" / "tpa-path" / "all tpa-sig"/ "discardable" / x-obsp) dkim-tag = %x64.6b.69.6d *WSP "=" *WSP dkim_val 12. TPA-Label Resource Record Scope Syntax 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 ADSP authorization. Otis & Black Expires February 11, 2011 [Page 17] Internet-Draft TPA-Label August 2010 "scope" tag as_val = "F" / "L" / "S" / "e" / "h" / "m" / "t" as-list = %x73.63.6f.70.65 *WSP "=" [ as_val 0*( 1*(WSP) as_val )] 12.1. Authorized Signing Domain 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. "tpa" tag ad_val = [ANY] domain ad-list = %x74.70.61 *WSP "=" [ ad_val 0*( 1*(WSP) ad_val )] 12.2. TPA-Label Listed Domain Authorization 12.2.1. From (Author) Header Field The "F" scope asserts that messages carrying the Author Domain within the From header field are authorized to be signed by the TPA-LLD. 12.3. Header Dependent Authorizations 12.3.1. List-ID Header Field The "L" scope asserts that authorization is valid only when a List-ID identifier of the List-ID header field [RFC2919] contains a domain that is within a domain listed in the TPA-LLD "tpa" tag. The syntax of the List-Id header field is as follows: list-id-header = "List-ID:" [phrase] "<"identifier">"CRLF 12.3.2. Sender Header Field The "S" scope asserts that authorization is valid only when the domain in the Sender header field is within the TPA-LLD. 12.3.3. Combined 'L' or 'S' Scopes When combined, the scopes 'L' and 'S' require that either a List-ID Otis & Black Expires February 11, 2011 [Page 18] Internet-Draft TPA-Label August 2010 identifier of the List-ID header field or the Sender header field must contain a domain within the TPA-LLD for the authorization to be valid. 12.4. SMTP Host domains The "e" scope asserts that host names given in [RFC5321] EHLO or HELO commands within TPA-LLD is authorized when the hostname resolves the server's IP address. 12.5. SMTP Host domains The "h" scope asserts that host names given in [RFC5321] EHLO or HELO commands within TPA-LLD is authorized only when this hostname submitted to an spf [RFC4408] process returns pass. 12.6. MailFrom Parameter The "m" scope asserts that an email-address domain in the [RFC5321] MAIL command within a TPA-LLD is authorized only when this email- address submitted to an spf [RFC4408] process returns pass. 12.7. SMTP Host domains The "t" scope asserts that host names given in [RFC5321] EHLO command after [RFC3207] negotiation where the Cert DNS-ID domain is within TPA-LLD is authorized. Not to RFC Editor: Remove this comment before publishing. Currently, no general practice employs certificates to confirm the domain of the client initiating a connection. This may be needed for clients within IPv6 IP address space where tunneling, carrier grade NATs, and rapid space assignment without any practical reverse mapping reduces the effectiveness of IP address based reputations. There is an existing TLS option for SMTP and an ongoing effort to standardize automated server confirmation. It might be possible to leverage this effort to establish practices used at the client. It might also be possible to utilize the DKIM public key to verify a challenge signed by the client based upon keys located at its hostname, but this would require a change made to SMTP conversations defined in [RFC4954] Section 4. For information related to ongoing server related efforts see: [I-D.saintandre-tls-server-id-check] Otis & Black Expires February 11, 2011 [Page 19] Internet-Draft TPA-Label August 2010 13. 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]. However, when no ADSP record is discovered or when it does not contain a "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 Domain Signature, the discovery of TPA-Label Resource Records should be attempted. 14. TPA-Label Resource Record Compliance Assessment The signing practice compliance assessment of Third Party Signatures is a discretionary operation performed by the verifier. Messages that have valid Author Domain Signatures are already considered to result in a pass. When a verifier decides to assess compliance for 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. 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 A TXT Resource Record, referenced by a TPA-Label created by the DKIM signature "d=" tag, MUST exist in DNS. o The discovered TPA-Label TXT Resource Record structure MUST be valid. o The domain that created the TPA-Label MUST be within the TPA-LLD. o Where a scope of 'F', 'S', or 'L' is specified, the Author Domain MUST have an Author's Domain Acceptable Third-Party Signature. o Where a scope of 'L' or 'S' is specified, a List-ID identifier in the List-ID header field or a Sender header field MUST contain a domain within the TPA-LLD. Meeting all the conditions in this set results in a "tpa-sig" pass, where subsequent checks are then skipped. For Third Party Services where the Author Domain ADSP "dkim" tag value contains "tpa-path", and where the preceding assessment conditions were not met, then the following represents "tpa-path" assessment conditions to be checked: One of the three possible TXT Resource Records is checked in Otis & Black Expires February 11, 2011 [Page 20] Internet-Draft TPA-Label August 2010 succession. Each would be referenced by an 'h' or 'e' or 't' related domain given by [RFC5321] EHLO or HELO command, this domain with left-most label omitted, or by an 'm' related email-address domain within the [RFC5321] MAIL command. 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 with a listed scope of 'e', 'h' or 'm' or 't'. o Where a scope of 'L' or 'S' is specified, either the domain in List-ID given by [RFC2919] in the List-ID header field is within the TPA-LLD, or a Sender header field contains a domain within the TPA-LLD respectively. o Once these four conditions have been met, for 'h' or 'm' scopes the domain MUST be confirmed by submitting the domain to an spf process that then returns pass. The 'e' scope MUST be confirmed by a forward DNS reference that resolves the address of the SMTP client. The 't' scope MUST be confirm the DNS-ID in the client certificate. 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 some error that is likely transient in nature, as specified in [RFC5617] Section 4.3. such as "SERVFAIL" for example, the result of the TPA-Label Resource Record compliance assessment is "temperror". When the TPA-Label TXT Resource Record retrieval returns a DNS "NOERROR", but not with a single record, 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" response,the result of the TPA-Label Resource Record compliance assessment is "nxdomain". The following pass conditions are combined to provide a single pass value. o A "tpa-sig" pass confirms an Author Domain Acceptable Third-Party Signature. o A "tpa-path" pass confirms an Author Domain Acceptable Service. Otis & Black Expires February 11, 2011 [Page 21] Internet-Draft TPA-Label August 2010 15. IANA Considerations 15.1. Author Domain Signing Practices (ADSP) Parameters To accommodate the extensions to ADSP Signing Practices, the IANA Registry "ADSP Outbound Signing Practices" defined by Section 4.2.1 of [RFC5617] needs the following elements to be added: +----------+-----------------+ | Type | Reference | +----------+-----------------+ | tpa-sig | (this document) | | tpa-path | (this document) | +----------+-----------------+ TPA-Label Resource Record validation Method Otis & Black Expires February 11, 2011 [Page 22] Internet-Draft TPA-Label August 2010 15.2. Email Authentication Method Registry To accommodate the method derived from TPA-Label Resource Record processing, the IANA Registry "Email Authentication Method" defined by Section 6.2 of [RFC5451] needs the following elements to be added: +---------+-----------+--------+----------+-------------------------+ | Method | Defined | ptype | property | value | +---------+-----------+--------+----------+-------------------------+ | tpa-lld | (this | header | d | value of signature "d" | | | document) | field | | tag. The dkim method | | | | | | results from [RFC5451] | | | | | | should also be included | | | | | | in a Authenticated | | | | | | Results header field | | | | | scope | value of scope | | | | | | (Section 15.5) tag. | | | | | | (When 'scope' contains | | | | | | 'e', 'h' or 'm', the | | | | | | iprev [RFC5451] | | | | | | (Section 3) method | | | | | | results should also be | | | | | | included in the | | | | | | Authenticated-Results | | | | | | header field to capture | | | | | | the SMTP client IP | | | | | | address. | | | | | ca-scope | The scopes | | | | | | (Section 15.5) with a | | | | | | compliance assessment | | | | | | as pass | | | | | tpa | Value of tpa | | | | | | (Section 12.1) tag at | | | | | | time of compliance | | | | | | assessment | +---------+-----------+--------+----------+-------------------------+ TPA-Label Resource Record validation Method Otis & Black Expires February 11, 2011 [Page 23] Internet-Draft TPA-Label August 2010 15.3. Email Authentication Result Names Registry To accommodate the results derived from TPA-Label Resource Record processing, the IANA Registry "Email Authentication Method" defined by Section 6.3 of [RFC5451] needs the following elements added: +--------------+---------+------------------------------------------+ | code | method | meaning | +--------------+---------+------------------------------------------+ | none | tpa-lld | No TPA-Label was published | | pass | tpa-lld | Section 14 | | tempfail | tpa-lld | Section 14 | | permfail | tpa-lld | Section 14 | | 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 | tpa-lld | The TPA-Label Resource Record had a | | defined in | | tag/value of dkim={other value} and the | | the IANA | | Third Party Signature failed its | | ADSP | | compliance assessment. | | Outbound | | | | Signing | | | | Practices | | | | Registry | | | +--------------+---------+------------------------------------------+ TPA-Label Resource Record complaince assessment Results 15.4. Third Party Authorizations Labels Registry Names of tags that are valid in TPA-Label Resource Records with the exception of experimental tags Section 9 MUST be registered in this created IANA registry. New entries are assigned only for values that have been documented in a published RFC that has had IETF Review, per IANA CONSIDERATIONS Otis & Black Expires February 11, 2011 [Page 24] Internet-Draft TPA-Label August 2010 [RFC5226]. Each tag registered must correspond to a definition. The initial set of values for this registry is: +--------------+--------------+-------------------------------------+ | tag | defined | definition | +--------------+--------------+-------------------------------------+ | dkim | Section 9 | As per IANA Registry ADSP Outbound | | | | Signing Practices | | tpa-sig | Section 11 | DKIM auth | | tpa-path | Section 11 | DKIM or path auth | | all tpa-sig | Section 11 | Same as tpa-sig | | scope | Section 12 | Section 15.5 | | tpa | Section 12.1 | List of Authorized Domains or | | | | Identifiers | +--------------+--------------+-------------------------------------+ TPA-Label Resource Record compliance assessment Results 15.5. Third Party Authorizations Scope Registry Values that correspond to Section 12 MUST be registered in this created registry: New entries are assigned only for values that have been documented in a published RFC that has had IETF Review, per IANA CONSIDERATIONS [RFC5226]. Each value registered must correspond to a definition. The initial set of values for this registry is: +-------+----------------+ | value | defined | +-------+----------------+ | F | Section 12.2 | | L | Section 12.3.1 | | S | Section 12.3.2 | | h | Section 12.5 | | e | Section 12.4 | | m | Section 12.6 | | t | Section 12.7 | +-------+----------------+ TPA-Label Resource Record compliance assessment Results Otis & Black Expires February 11, 2011 [Page 25] Internet-Draft TPA-Label August 2010 16. Security Considerations This draft extends signing practices for [RFC4871] where most generic DKIM Signature related security matters are discussed. Additional considerations are also included in [I-D.ietf-dkim-mailinglists]. Security considerations for the TPA-LLD scheme are mostly related to attempts on the part of malicious senders to falsely represent themselves as other senders, often in an attempt to defraud either the recipient or the alleged originator. Additional security considerations regarding DKIM signing practices may be found in the DKIM threat analysis [RFC4686]. 16.1. Benefits to Recipients The verifier, after finding either an Author's Domain Acceptable Third-Party Signature or Author's Domain Acceptable Third-Party Service in a message, will have significantly greater confidence in the Third-Party, than when no TPA-Label Resource Record is obtained. This enhanced confidence may, at the recipients' discretion, cause a message to be delivered to the recipient without further source related assessment. 16.2. Risks to Recipients The decisions a recipient makes in regard to message filtering based on TPA-Label Resource Records are likely to depend on the system integrity of the Third Party with respect to the Authentication (see Section 5.1) and the provided scope labels. When the 'e', 'h', or 'm' scoped domain is not confirmed or the third-party domain does not authenticate the sender, there is a risk of accepting potentially spoofed messages. When there is no out-of-band authentication confirming the sender, Authentication-Results header fields 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 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 such that it may be worth checking the existence of a TPA-Label Resource Record first. Section 13 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. Otis & Black Expires February 11, 2011 [Page 26] Internet-Draft TPA-Label August 2010 Services that depend only upon path authorizations might permit the Author Domain to be spoofed and yet obtain acceptance. During such events, the Author Domain might need to retract its authorization from the service. For this reason, "tpa-path" authorization should only be used as a carefully monitored interim solution. 16.3. Benefits to Author Domains TPA-Label resource records can replace domain delegations, selector/ key record mirroring, or key exchanges. A significant number of details are 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, services that depend upon DKIM keys are better secured by not delegating these DKIM keys, where instead the TPA-LLD scheme allows Author Domains an ability to limit the scope of their authorizations, while also not being mistaken for having authenticated the entity submitting the message. TPA-Label Resource Records convey which domains are authoritative even when they are not the Author Domain. However, authorized domains are unable to utilize the DKIM signature's 'i=' semantics to directly assert which identifiers on whose behalf a signature was added. As such, no domain should be authorized unless it is trusted to ensure the Alleged Author of an email undergoes authentication that offers acceptable protections for the Author Domain. For example, such authentication might ensure submitting entities have demonstrated receipt of "pingback" messages sent to the Author Address contained within the messages being signed. By deploying TPA-Label Resource Records, Author Domains benefit when recipients assess signing practice compliance by using the TPA-LLD scheme. These recipients will be less likely to drop the Author Domain's genuine messages, whenever the Author Domain attempts to restrict acceptance. Restricting acceptance of non-compliant messages is the basic motivation for publishing ADSP records. In addition, recipients are more likely to validate Authorized Third Party Domain Signatures. Broader use of restrictive ADSP policies provides a better likelihood of being able to eliminate a greater range of non-compliant messages, 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 therefore provide a means to safely extend limited compliance Otis & Black Expires February 11, 2011 [Page 27] Internet-Draft TPA-Label August 2010 assessment resources to otherwise unknown domains or SMTP Clients. 16.4. Risks to Author Domains 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 to generate, messages that falsely appear to be from the Author Domain. The authentication methods in place for different email elements need to be carefully reflected in the scope of the TPA records. By authorizing mailing lists with TPA-Label Resource Records, this could cause a loss of confidentiality in mailing list participation by the Author Domain. This might help Bad Actors deduce which subscription related email the Author Domain may receive. Because of the hashing function in generating the TPA-label, anyone wishing to discover which domains are being authorized, has to probe each TPA- 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. 16.5. Benefits to Third Party Signers Third Party Signers benefit by allowing those using their service, the autonomy to authorize their service without needing to exchange DKIM key related details. This is particularly useful for mailing lists. 16.6. Risks caused by Third Party Signers As mentioned before, Third Party Signers need to authenticate messages from Author Domains. This authentication provides a safety mechanism for the Author Domain and their recipients. The Third Party may not be aware of the authentication value or the message elements involved and make changes without understanding the impact this may have upon targeted Author Domains and their recipients. For example, the Third Party might stop DKIM signing or stop applying Authentication-Results header fields. The unexpected exposure might enable wide spread abuse and prove detrimental for both the Author Domain and their recipients. 16.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 Otis & Black Expires February 11, 2011 [Page 28] Internet-Draft TPA-Label August 2010 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 likely easier to achieve than finding hash collisions. There is minimal risk of TPA-Labels colliding. Listing 3 x 10^45 domains has less than a 0.1 percent risk of any two domain labels colliding. 16.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. Perhaps soon there will be a further increase spurred by an expanse of TLDs having larger international labels. The maximum domain name size allowed, per [RFC1034] Section 3, is 255 bytes (or octets). Each label has a byte for its length. Every domain name has a right most label representing the root with a zero length, for another byte. A scheme that concatenates a listed domain with the publishing domain, separated by some conventional label, reduces the maximal domain name in half, where the conventional label reduces this further. 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 its 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. Otis & Black Expires February 11, 2011 [Page 29] Internet-Draft TPA-Label August 2010 17. Acknowledgements Jeff MacDonald, Michael Deutschmann, Frank Ellermann, Murray Kucherawy, and Wietse Venema. 18. References 18.1. Normative References [FIPS.180-2.2002] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, . [I-D.saintandre-tls-server-id-check] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security", draft-saintandre-tls-server-id-check-09 (work in progress), August 2010. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2919] Chandhok, R. and G. Wenger, "List-Id: A Structured Field and Namespace for the Identification of Mailing Lists", RFC 2919, March 2001. [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, February 2002. [RFC4408] Wong, M. and W. Schlitt, "Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1", RFC 4408, April 2006. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. Otis & Black Expires February 11, 2011 [Page 30] Internet-Draft TPA-Label August 2010 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, October 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. [RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009. [RFC5617] Allman, E., Fenton, J., Delany, M., and J. Levine, "DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)", RFC 5617, August 2009. 18.2. Informative References [I-D.ietf-dkim-mailinglists] Kucherawy, M., "DKIM And Mailing Lists", draft-ietf-dkim-mailinglists-01 (work in progress), July 2010. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1930] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", BCP 6, RFC 1930, March 1996. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2672] Crawford, M., "Non-Terminal DNS Name Redirection", RFC 2672, August 1999. [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006. [RFC4954] Siemborski, R. and A. Melnikov, "SMTP Service Extension for Authentication", RFC 4954, July 2007. [RFC5016] Thomas, M., "Requirements for a DomainKeys Identified Mail (DKIM) Signing Practices Protocol", RFC 5016, October 2007. Otis & Black Expires February 11, 2011 [Page 31] Internet-Draft TPA-Label August 2010 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5672] Crocker, D., "RFC 4871 DomainKeys Identified Mail (DKIM) Signatures -- Update", RFC 5672, August 2009. [RFC5863] Hansen, T., Siegel, E., Hallam-Baker, P., and D. Crocker, "DomainKeys Identified Mail (DKIM) Development, Deployment, and Operations", RFC 5863, May 2010. [apwg-globalphishingsurvey-2H2009] Anti-Phishing Working Group, "Global Phishing Survey: Trends and Domain Name Use 2H2009", May 2009, . Appendix A. DNS Example of TPA-Label Resource Record placement #### # Practices for Example.com email domain using example.com, isp.com, # and example.com.isp.com as signing domains. #### #### 5322.From authorization for 3P domains #### ## "isp.com" TPA-Label Resource Record ## _HTIE4SWL3L7G4TKAFAUA7UYJSS2BTEOV._tpa._domainkey.example.com. IN TXT "dkim=all tpa-sig; tpa=isp.com; scope=F;" #### 5322.Sender/List-ID authorization for 3P domains #### ## "example.com.isp.com" TPA-Label Resource Record ## _6MEHLQLKWAL5HQREXWDN2TBXAJ6VZ44B._tpa._domainkey.example.com. IN TXT "dkim=all tpa-sig; tpa=*.isp.com; scope=L S;" Otis & Black Expires February 11, 2011 [Page 32] Internet-Draft TPA-Label August 2010 Appendix B. C code for label generation The following utility can be compiled as tpa-label.c using the following: gcc -lcrypto tpa-label.c -o tpa-label /* * TPA-Label generation utility * Copyright (c) 2010 IETF Trust and the persons identified as the * document authors. All rights reserved. * * This document is subject to BCP 78 and the IETF Trust's Legal * Provisions Relating to IETF Documents * (http://trustee.ietf.org/license-info) 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. * * 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 #include #include #include #include #include #include #include #include #include #include #define TPA_LABEL_VERSION 102 #define MAX_DOMAIN_NAME 256 #define MAX_FILE_NAME 1024 static char base32[] = "ABCDEFGHIJKLMNOPQRSTUVWXYZ234567"; Otis & Black Expires February 11, 2011 [Page 33] Internet-Draft TPA-Label August 2010 static char sign_on[] = {"%s v%d.%02d Copyright (C) (2010) The IETF Trust, Otis & Black\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': Otis & Black Expires February 11, 2011 [Page 34] Internet-Draft TPA-Label August 2010 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, Otis & Black Expires February 11, 2011 [Page 35] Internet-Draft TPA-Label August 2010 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); Otis & Black Expires February 11, 2011 [Page 36] Internet-Draft TPA-Label August 2010 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 sha1 results 4 times by 40 bits (160 bits) */ 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"); Otis & Black Expires February 11, 2011 [Page 37] Internet-Draft TPA-Label August 2010 /* 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); } Authors' Addresses 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 Otis & Black Expires February 11, 2011 [Page 38]