DKIM Third-Party Authorization for Sender Signer Practices
draft-otis-dkim-tpa-ssp-02

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

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.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 22, 2008.

Abstract

TPA-SSP (DKIM Third-Party Authorization for Sender Signing Practices) is a DNS-based label prefix mechanism for authorizing Third-Party domains. This mechanism allows a first-party domain to autonomously authorize a range of third-party domains in a scalable, individual DNS transaction. This authorization can extend the scope of DKIM-SSP policy assertions and eliminate more difficult to administer mechanisms. Alternatives for facilitating third-party authorizations currently necessitate coordination between two domains by setting up selector/key DNS records, DNS zone delegations, or the regular exchange of public/private keys.

Checking Sender Signing Practices occurs when a From header email-address is not within the domain of a valid DKIM signature. When a Third-Party signature is found, TPA-SSP offers an efficient means for the email address domain within the From header to specifically authorize other third-party signing domains. The scope of the authorization may also assert identity authentication for Sender and Resent-* headers for email-addresses within the signing domain. Identity authentication within the From header domain may be asserted by the scope of the authorization, even when signed by a Third-Party domain. In addition, the RFC2821.MailFrom domain can authorize domains for controlling DSNs.

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] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

Table of Contents

1.  Introduction
2.  Envelope Authorizations
3.  Evaluating Signing Domains
4.  Authorization Scope
5.  TPA-SSP Assertions
6.  Scope
    6.1.  From Originator Header Field
    6.2.  MailFrom Parameter
    6.3.  Other than From Originating Header Fields
    6.4.  NO-TPA
7.  Authorized Signing Domain
8.  Modification to Sender Signing Practices Check Procedures
9.  IANA Considerations
10.  Security Considerations
11.  Acknowledgements
12.  References
    12.1.  Normative References
    12.2.  Informative References
Appendix A.  Change Log
Appendix B.  DNS Example of TPA-SSP From record
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

This document describes how any email-address domain publishing SSP records defined in [I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) can also specifically autonomously authorize [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.) signing by third-party domains. Recommended or suggested actions for a DKIM receiver are not included, and are considered "out-of-scope" for this document. The receiver is assumed to better understand their environment's impact upon the performance of DKIM signatures and how results are utilized within their domain.

TPA-SSP records permit signing domains that are not at or above the From header email-address domain to comply with Sender Signing Practices. TPA-SSP authorized domains are to be considered equivalent to the authorizing domain for applying Sender Signing Practices. This mechanism eliminates a complex coordination of selector/key DNS records, DNS delegation, or exchanges of public/private keys between two domains otherwise required to facilitate desired authorizations.

Trust is an essential requisite before DKIM signature header field's 'i=' semantics or the TPA-SSP "-i" suffix scope assertions provide valuable advisory information. Advisory information regarding identity authentication enables safer message annotations that ensure trusted identities are recognized. TPA-SSP assertions also convey which third-party domains are authoritative for asserting which identifiers are to be considered to have been authenticated. This information is essential for the proper recognition of trusted identities, as well as noting when a message source may require added scrutiny.

2.  Envelope Authorizations

DKIM is fully independent of the SMTP Client and the [RFC2821] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.).MailFrom email-address. Allowing the [RFC2821] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.).MailFrom email-address to authorize signing domains and assert signing practices may prevent Delivery Status Notifications (DSNs) from being sent when the signing domain is not authorized and a "strict" TPA-SSP practice is being asserted. Conversely, this may also ensure DSNs are not dropped when the signing domain does happen to be authorized or is not precluded. The application of TPA-SSP at the MailFrom represents an entirely optional strategy which may or may not prove either effective or practical. The MailFrom scope is offered only for experimentation.

3.  Evaluating Signing Domains

Regulatory agencies are unable to control Internet abuse by curtailing access. Unlike IPv4 addresses, there is virtually no limit on the number of domain-names available. Registrar pricing of domain-names need to remain uniform. Otherwise, fees based upon the intrinsic value of a name could cause name holders to become extortion targets. High initial costs for domain-names are also unlikely to represent a deterrent, largely due to high levels of payment fraud. Driven by market forces, registrars offer free sampling of domain names (domain tasting) to create some revenue from a few purchased domains. However, this unfortunate practice also resulted in a daily churn of millions of domain names. Distributing domain name reputation to curb abuse has been made more expensive, slower, and less effective as a result.

In addition, DKIM can not directly identify the domain transmitting the message, and can not prevent abusive message replay. Abusive message replay may prove indistinguishable from bulk mailings of various types. Since abuse may not be controlled by the signing domain, message acceptance will likely remain largely dependent upon the reputation of the SMTP client's IP address. Abuse reporting facilitated by DKIM signatures should therefore first select signing domains that correspond with domains administering the SMTP Client publicly transmitting the message.

A domain evaluation process will confront many domains with unknown reputations. New domains are constantly being introduced where registrars are unable to prevent bad actors from controlling either a new or previously held domain name. When the receiver seeks to protect a DKIM verification process with a preliminary filter, acquiring SSP records or DKIM keys may inadvertently leak valuable information that benefits bad actors. Processing all DKIM signatures may also inundate a receiver's limited resources. As a result, validating DKIM signatures and obtaining TPA-SSP resource records may need to be limited to known trustworthy domains. Signatures authorized by domains with good reputations provide a means to safely extend limited verification resources.

4.  Authorization Scope

An Authorization effort without TPA-SSP will likely involve sharing details between the email provider, the domain owner, and the DNS provider. Since there are many ways in which authorizations can be accomplished, it is unlikely there will be consistent or standardized formats for exchanging the necessary information. In addition, in the case of security breaches, the wrong party might be held accountable for content never seen nor logged by them. The TPA-SSP authorization scheme clarifies who signed the message and on who's behalf, while permitting greater control by the authorizing domain.

TPA-SSP records replace domain delegation, selector/key record mirroring, or key exchanges. A significant amount 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 whether the DKIM Signature header field's 'i=' semantics are applied to indicate authenticated email-addresses. The TPA-SSP records allow authorizing domains the ability to limit the scope of the authorizations and authentications.

When a signing domain differs from that of a domain within the From header email-address, TPA-SSP records can safely extend compliance with SSP where actions of only the email-address domain are required. In addition, just as a DKIM signature can assert an email-address has been authenticated via the "i" construct, a signing domain that only signs authenticated email-addresses can be denoted by the "-i" suffix on the scope assertion within the corresponding TPA-SSP record. When obtained using the "tpa-label", a returned scope with an "-i" suffix indicates that the domain plays the role of assuring that email-addresses identities have been authenticated. This assertion remains valid even when signing domains and the From email-address domains differ.

Without the "-i" suffix on the scope assertion within the TPA-SSP record, the domain is designated as providing only acceptable signatures. The same would be true for a DKIM signature lacking the "i" parameter. While offering only valid signatures will not ensure all possible spoofing is prevented, messages signed in this manner should also not receive annotations indicating authenticated identities either.

Choosing not to implement identity authentication may represent an economical means to administer domains employing DKIM signatures. Authorizing domains to play the role of only providing acceptable signatures may be suitable for non-critical messages, where the goal might be to improve delivery acceptance.

5.  TPA-SSP Assertions

Syntax descriptions use the form described in Augmented BNF for Syntax Specifications [RFC4234] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.). The "base32" function is defined in [RFC4648] (Josefsson, S., “The Base16, Base32, and Base64 Data Encodings,” October 2006.) and the "sha-1" hash function is defined in [FIPS.180‑2.2002] (National Institute of Standards and Technology, “Secure Hash Standard,” August 2002.). The TPA-SSP records follow the tag-value syntax described in section 4.3 of [I‑D.ietf‑dkim‑ssp] (field, h., Domain, A., error, r., Allman, E., Fenton, J., Delany, M., and J. Levine, “DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP),” May 2009.) and section 3.2 of [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.). Unrecognized tags and tags with illegal values MUST be ignored. In the ABNF below, the FWS token is inherited from [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.) with the exclusion of obs-FWS. The ALPHA and DIGIT tokens are imported from [RFC4234] (Crocker, D., Ed. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.). The function "lcase" converts upper-case ALPHA characters to lower-case. The function "sha-1" returns a hash in base32 base-char set. The terminating period is not included in domain-name conversions. The tags used in TPA-SSP records are as follows:

  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]
  sldn = label dot label
  base-char = (dns-char / underscore)
  domain = *(label dot) sldn
         ; not to exceed 238 characters
         ; excluding "_ssp._domainkey."
  tpa-label = base32( sha-1( lcase(signing-domain)))
            ; 32 base-char characters

The receiver obtains the TPA-SSP email-address domain practices using a DNS query for an IN class TXT resource record. The tpa-label is created by processing the domain found within the signature's "d=" parameter (does not include the trailing period). This tpa-label is then placed below the "._ssp.domainkey.<email-address domain>" and used to access the TPA-SSP TXT records. 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. A TPA-SSP record may be located at these domains:

<tpa-label>._ssp._domainkey.<email-address domain>.

6.  Scope

scope= Authorization Scope List (Optional). This tag defines a list of scoping assertions for various email-address locations within the message.

scope = "F" / "F-i" / "O" / "O-i" / "M" / "M-i" / "NO-TPA"

as-list = "scope" [FWS] "=" [FWS] scope 0*([FWS] ":" [FWS] scope)

6.1.  From Originator Header Field

The "F" or "F-i" scope asserts that messages carrying the email-address domain within the From header field are authorized to be signed by the tpa listed domain. When the "-i" suffix is included, it can be assumed identities for the scoped header have been authenticated.

6.2.  MailFrom Parameter

This "M" or "M-i" scope asserts that messages carrying the email-address domain within the MailFrom parameter are authorized to be signed by the authorized domain. When the "-i" suffix is included, it can be assumed identities for the MailFrom have been authenticated.

6.3.  Other than From Originating Header Fields

The "O" or "O-i" scope asserts that messages carrying the email-address domain within the Sender or Resent-* header fields are authorized to be signed by the authorized domain. When the "-i" suffix is included, it can be assumed identities for the scoped header have been authenticated.

6.4.  NO-TPA

The "NO-TPA" scope asserts that domain does not publish TPA-SSP records.

7.  Authorized Signing Domain

tpa= Authorized Signing Domain list (Optional). This tag repeats all or portions of the domain encoded within the tpa-label. This option ensures 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.

ad = [ANY] domain

ad-list = "tpa" [FWS] "=" [FWS] ad 0*([FWS] ":" [FWS] ad)

8.  Modification to Sender Signing Practices Check Procedures

Section 4.4 step 9 is modified. Step 9 becomes:

When one or more valid Third-Party Signatures are present in the message, and a scope tag exists, and the scope tag does not contain "NO-TPA" within the SSP record, then:

• When the "dkim" tag is "strict" and a TPA-SSP record within the From header domain has a scope tag of "F" or "F-i", then the message is to be considered signed by an Originator Acceptable Third-Party Signature. When the scope tag within the TPA-SSP record is "F-i", the From email-address is to be considered authenticated by the Third-Party Domain.
• When the "dkim" tag is "all" and a TPA-SSP record within the From header domain has a scope tag of "O" or "O-i" and the email-address domain within the Sender, or Resent-* headers are within the signing domain, then the message is considered signed with an Originator Acceptable Third-Party Signature. When the scope tag within the TPA-SSP record is "O-i", then email-addresses within the third-party signing domain are considered to have been authenticated when included within the signature.
• When the "dkim" tag is "all" and no TPA-SSP record is found or published, and a valid Third-party signature is acceptable to the verifier, then the message is considered signed by a Verifier Acceptable Third-Party Signature.

If an acceptable valid Third-Party Signature has been determined, the message is not Suspicious and the algorithm terminates.

9.  IANA Considerations

Unless a registry is established for SSP record tags, there are no IANA requirements in this draft.

Note to RFC Editor: this section may be removed on publication as an RFC and no request is desired or registration is not considered practical.

10.  Security Considerations

This draft extends signing policies related to [RFC4871] (Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, “DomainKeys Identified Mail (DKIM) Signatures,” May 2007.). Security considerations in the Sender Signing Practices are mostly related to attempts on the part of malicious senders to represent themselves as other senders, often in an attempt to defraud either the recipient or the Alleged Originator. Additional security considerations regarding Sender Signing Practices may be found in the DKIM threat analysis [RFC4686] (Fenton, J., “Analysis of Threats Motivating DomainKeys Identified Mail (DKIM),” September 2006.).

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-SSP "tpa=" option.

11.  Acknowledgements

Frank Ellermann.

12.  References

12.1. Normative References

12.2. Informative References

Appendix A.  Change Log

Changes to 00 version:

• Removed the term policy.
• Corrected _domainkey vs _domainkeys label.
• Corrected appendix SSP a= vs d= tag.
• Added additional scopes in appendix example.

Changes to 01 version:

• Modified abstract and introduction.
• Removed The Signing Domain Section.
• Added Evaluating Signing Domains section.
• Added Authorized Scope section.
• Changed SSP-TPA "s=" tag from to "scope=".
• Expanded scope to include an identity ("-i") instead of "strict".
• Changed SSP-TPA "a=" tag from to "tpa=".
• Added Modification to Sender Signing Practices Check Procedures.

Appendix B.  DNS Example of TPA-SSP From record

####
# Policies for Example.com email domain using both example.com, isp.com,
# and example.com.isp.com as signing domains.
####

#### 2822.From authorization for TP domains ####
                                _ssp._domainkey.example.com.  IN TXT
    "dkim=strict; scope=F-i:O:M;"

## "isp.com" tpa-label ##
hgssd3snmi6635j5743vdjhajkmpmfif._ssp._domainkey.example.com.  IN TXT
    "dkim=all; tpa=isp.com; scope=F;"

#### 2822.From/Originator/MailFrom authorization for TP domains ####

## "example.com.isp.com" tpa-label ##
zzhffxwcfi7rpddqdigyhpbtaa7vwitu._ssp._domainkey.example.com.  IN TXT
    "dkim=strict; tpa=*.isp.com; scope=F-i:O:M; "

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2007).

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.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.