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

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 December 29, 2007.

Copyright Notice

Copyright © The IETF Trust (2007).

Abstract

TPA-SSP (DKIM Third-Party Authorization for Sender Signing Practices) is a DNS-based label prefix mechanism to provide a means to authorize Third-Party signing domains in a scalable fashion. This mechanism eliminates complex coordination of selector/key DNS records, DNS zone delegation, or exchanges of public/private keys otherwise required to facilitate desired authorizations. Checking Sender Signing Practices occurs in common cases where an originating email-address of concern is not within a DKIM signing domain. In which case, the email-address has not been signed, or is signed by a Third-Party domain.

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.  The Signing Domain
4.  TPA-SSP Assertions
5.  Scope
    5.1.  (F)rom header field
    5.2.  (M)ailFrom parameter
    5.3.  (O)riginating header fields
6.  Authorized Signing Domain
7.  IANA Considerations
8.  Security Considerations
9.  Acknowledgements
10.  References
    10.1.  Normative References
    10.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] (Allman, E., Delany, M., and J. Fenton, “DKIM Sender Signing Practices,” June 2007.) can 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 DKIM signatures are utilized within their domain.

There are many uncertainties in respect to the actual usage of the DKIM protocol. These uncertainties exist due to:

• Intentionally vague DKIM protocol semantics
• Full adoption of DKIM is not implied
• Limited semantics for some signing domains
• Optional validity of email-addresses
• No assumed signature ordering or signing roles
• No direct association with the SMTP Client

The purpose of the TPA-SSP is to permit domains that are not at or above the email-address domain to comply with Sender Signing Practices. TPA-SSP authorized domains are to be considered equivalent to a signing domain at or above the email-address with respect to the application of Sender Signing Practices. This mechanism eliminates complex coordination of selector/key DNS records, DNS delegation, or exchange of public/private keys otherwise required to facilitate the desired authorization.

Rather than traversing domains searching for possible SSP records, the validity of non-existent SSP records can be confirmed by the presence of DNS records needed to discover SMTP servers. This implies SSP records must be coincident with all such DNS discovery records. For this reason, use of A records for discovering SMTP servers should be deprecated.

A message signed with DKIM, whether or not an SSP record can also be discovered, does not indicate whether a message is from a good or bad actor. However, DKIM signatures will allow a recipient's trust to be strengthened. Good actors establish trust. Bad actors do not.

Trust is an essential requisite before DKIM signature header field's 'i=' semantics or the TPA-SSP assertions provide valuable advisory information. This advisory information permits the safer application of message annotations ensuring trusted identities are properly recognized. TPA-SSP assertions convey which domains are authoritative and assure which identifiers might be considered valid. This information is essential for proper recognition of email-addresses 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 designate signing domains and assert signing practices may prevent Delivery Status Notifications (DSNs) from being sent when the signing domain is not authorized. Conversely, this may also ensure DSNs are not dropped when the signing domain is authorized. Application at the MailFrom represents an entirely optional strategy that may or may not prove either effective or practical. This is offered only for experimentation.

3.  The Signing Domain

Unlike IPv4 addresses, there is virtually no limit on the number of domain-names available. Registrar pricing of domain-names should remain uniform, otherwise higher fees based upon intrinsic value established by the owners could cause these owners to become extortion targets. Initial costs for domain-names are also unlikely to represent a deterrent due to high levels of fraud. While domain tasting allows registrars to avoid retracting a flood of fraudulent credit card transactions, this strategy also results in a daily churn of millions of domains being added and then withdrawn.

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. As a result, message acceptance will likely remain based primarily upon the IP address of the SMTP Client. Abuse reporting facilitated by a DKIM signature should therefore select those signing domains that correspond with the domain administering the SMTP Client publicly transmitting the message. TPA-SSP provides a simple means to retain a relationship between the SMTP Client and the DKIM signing domain.

When signing domains differ from that of the domain within the originating email-address, TPA-SSP offers a solution where only the actions of the email-address domain is required to retain email-address SSP compliance. In addition, just as a DKIM signature can assert an email-address is valid via the "i" construct, a signing domain that only signs validated email-addresses is denoted by the "strict" assertion within the TPA-SSP record. When coupled with the TPA prefix, the "strict" assertion indicates that the domain plays the role of assuring that email-addresses are valid. This assertion remains valid even when signing domains and the email-address domains differ.

Without the "strict" assertion within the TPA-SSP record, the domain is designated as providing only valid signatures in the same manner as would a DKIM signature lacking the "i" construct. While this latter role of only offering valid signatures will not ensure all possible spoofing is prevented, these messages should not receive annotations indicating such assurances either. This represents an economical alternative enabling large scale autonomous administration of email domains. Authorizing domains to play the role of only providing valid signatures may be suitable for non-critical messages, where the goal could be to only improve delivery acceptance.

Without the use of TPA-SSP, when the originating email-address domain differs from that of a provider's domain, additional steps must be taken by the third-party provider. DNS delegation, DNS selector/key record mirroring, or key exchanges are required to permit the DKIM signing domains to be at or above the email-address domain. This means the provider needs to sign with the customer's private key, or have their customer replicate the provider's public selector/key information within their DNS, or have their customers delegate a lower portion of their DNS zone to the provider. In addition, a significant amount of detail is associated with selector/key records that might be then controlled by the provider, such as 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 should be applied to indicate valid email-addresses.

The DNS delegation effort will likely involve sharing details between the email provider, the domain owner, and the DNS provider. As there are many ways in which this could be accomplished, it is also unlikely there will be consistent or standardized formats for exchanging this information. In addition, when there are any security breaches, the wrong party might be held accountable for message content never seen or logged by them. An authorization scheme clarifies who signed the message and on who's behalf.

Protections offered by DKIM are largely related to the better recognition of prior correspondents, and improved identification of initial sources when instances of abuse are reported. While TPA-SSP may allow receivers to detect and reject messages that appear non-compliant, the overall cases where this might happen is likely to represent a fairly small portion of overall messages. When the receiver seeks to protect the DKIM verification process with a preliminary message filter, even acquiring SSP records or DKIM keys may inadvertently leak valuable information benefiting abusive senders. The validation of DKIM and the obtaining of TPA-SSP resource records may consequently become limited to known trustworthy domains.

4.  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.). Sender Signing Practices records follow the tag-value syntax described in 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.). Tags used in SSP records are as follows. 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 terminating period is not included in domain-name conversions.

asterisk = %x2A ; "*"

hyphen = %x2D ; "-"

period = %x2E ; "."

colon = %x3A ; ":"

semicolon = %x3B ; ";"

equals = %x3D ; "="

ldh = ALPHA / DIGIT / hyphen ;

let-dig = ALPHA | DIGIT ;

subdomain = let-dig [*61(ldh) let-dig] ;

domain = subdomain 1*(period subdomain) ;

ANY = asterisk period ; "*."

FWS = ([*WSP CRLF] 1*WSP) ;

tag-list = tag-spec 0*( ";" tag-spec ) [ ";" ]

tag-spec = [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]

tag-name = ALPHA 0*ALNUMPUNC

tag-value = [ tval 0*( 1*(WSP / FWS) tval ) ]

; WSP and FWS prohibited at beginning and end

tval = 1*VALCHAR

VALCHAR = %x21-3A / %x3C-7E

; EXCLAMATION to TILDE except SEMICOLON

ALNUMPUNC = ALPHA / DIGIT / "_"

From = "F" ; %x46 [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.).From

Originator = "O" ; %x4F [RFC2822] (Resnick, P., “Internet Message Format,” April 2001.).Sender/Resent-Sender/Resent-From

MailFrom = "M" ; %x4D [RFC2821] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.).MAIL FROM

tpa-label = base32( sha-1( lcase(signing-domain))) ; 32 characters

The receiver obtains the TPA-SSP email-address domain practices using a DNS query for an IN class TXT resource record. The 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>.

5.  Scope

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

scope = %x46 / %x4D / %x4F ; "F","M", & "O"

scope-list = %x73 [FWS]equals[FWS] scope 0*(*FWS colon *FWS scope)

5.1.  (F)rom header field

The "F" Scope asserts that messages carrying the email-address domain within the From header field are authorized to be signed by the authorized domain.

5.2.  (M)ailFrom parameter

This "M" Scope asserts that messages carrying the email-address domain within the MAILFROM parameter are authorized to be signed by the authorized domain.

5.3.  (O)riginating header fields

The "O" 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.

6.  Authorized Signing Domain

a= 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 considered to be included in the list.

asd = [ANY] domain 0*(*FWS colon *FWS [ANY] domain)

asd-list = %x61 [FWS]equals[FWS] asd

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

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

9.  Acknowledgements

TBD.

10.  References

10.1. Normative References

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

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;"

## "isp.com" tpa-label ##
hgssd3snmi6635j5743vdjhajkmpmfif._ssp._domainkey.example.com.  IN TXT
    "a=isp.com; s=F;"

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

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

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.

Acknowledgment

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).