DKIM Working Group D. Otis Internet-Draft Trend Micro, NSSG Intended status: Standards Track June 26, 2007 Expires: December 28, 2007 DKIM Third-Party Authorization for Sender Signer Practices draft-otis-dkim-tpa-ssp-00 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 28, 2007. Copyright Notice Copyright (C) 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- Otis Expires December 28, 2007 [Page 1] Internet-Draft TPA-SSP June 2007 address has not been signed, or is signed by a Third-Party domain. Otis Expires December 28, 2007 [Page 2] Internet-Draft TPA-SSP June 2007 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]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Envelope Authorizations . . . . . . . . . . . . . . . . . . . 5 3. The Signing Domain . . . . . . . . . . . . . . . . . . . . . . 5 4. TPA-SSP Assertions . . . . . . . . . . . . . . . . . . . . . . 7 5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. (F)rom header field . . . . . . . . . . . . . . . . . . . 9 5.2. (M)ailFrom parameter . . . . . . . . . . . . . . . . . . . 9 5.3. (O)riginating header fields . . . . . . . . . . . . . . . 9 6. Authorized Signing Domain . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . . 11 Appendix A. DNS Example of TPA-SSP From policy . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Otis Expires December 28, 2007 [Page 3] Internet-Draft TPA-SSP June 2007 1. Introduction This document describes how any email-address domain publishing SSP records defined in [I-D.ietf-dkim-ssp] can authorize [RFC4871] 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: o Intentionally vague DKIM protocol semantics o Full adoption of DKIM is not implied o Limited semantics for some signing domains o Optional validity of email-addresses o No assumed signature ordering or signing roles o 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 a non-existent Policy record can be confirmed by the presence of DNS records needed to discover SMTP servers. This implies policy 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 there is also a policy that can be referenced, 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. Policy 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 Otis Expires December 28, 2007 [Page 4] Internet-Draft TPA-SSP June 2007 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].MailFrom email-address. Allowing the [RFC2821].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 that is 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 policy 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 Otis Expires December 28, 2007 [Page 5] Internet-Draft TPA-SSP June 2007 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 TPA-SSP policy records or Otis Expires December 28, 2007 [Page 6] Internet-Draft TPA-SSP June 2007 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]. The "base32" function is defined in [RFC4648] and the "sha-1" hash function is defined in [FIPS.180-2.2002]. Sender Signing Practices records follow the tag- value syntax described in section 3.2 of [RFC4871]. 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] with the exclusion of obs-FWS. The ALPHA and DIGIT tokens are imported from [RFC4234]. 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) ; Otis Expires December 28, 2007 [Page 7] Internet-Draft TPA-SSP June 2007 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].From Originator = "O" ; %x4F [RFC2822].Sender/Resent-Sender/Resent-From MailFrom = "M" ; %x4D [RFC2821].MAIL FROM tpa-label = base32( sha-1( lcase(signing-domain))) ; 32 characters +-----+--------------------------------+ | Tag | Function | +-----+--------------------------------+ | s= | Scope list | | a= | Authorized Signing Domain list | +-----+--------------------------------+ TPA-SSP Tags +-------+-------------------------------+ | Scope | Function | +-------+-------------------------------+ | F | Applies to From Header | | O | Applies to Originator Headers | | M | Applies to MAILFROM | +-------+-------------------------------+ TPA Scope The receiver obtains the TPA-SSP email-address domain policy 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 policy record may be located at these domains: ._ssp._domainkeys.. 5. Scope s= Scope List(Optional). This tag defines a list of scoping Otis Expires December 28, 2007 [Page 8] Internet-Draft TPA-SSP June 2007 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 ensure 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 Otis Expires December 28, 2007 [Page 9] Internet-Draft TPA-SSP June 2007 practical. 8. Security Considerations This draft extends signing policies related to [RFC4871]. 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]. 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. Otis Expires December 28, 2007 [Page 10] Internet-Draft TPA-SSP June 2007 9. Acknowledgements TBD. 10. References 10.1. Normative References [FIPS.180-2.2002] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-2, August 2002, . [I-D.ietf-dkim-ssp] Allman, E., Delany, M., and J. Fenton, "DKIM Sender Signing Practices", draft-ietf-dkim-ssp-00 (work in progress), June 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [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. 10.2. Informative References [RFC4686] Fenton, J., "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", RFC 4686, September 2006. Otis Expires December 28, 2007 [Page 11] Internet-Draft TPA-SSP June 2007 Appendix A. DNS Example of TPA-SSP From policy #### # Policies for Example.com email domain using both example.com, isp.com, # and example.com.isp.com as signing domains. #### #### 2822.From policy #### _ssp._domainkey.example.com. IN TXT "dkim=strict;" ## "isp.com" tpa-label ## hgssd3snmi6635j5743vdjhajkmpmfif._ssp._domainkey.example.com. IN TXT "d=isp.com; s=F;" ## "example.com.isp.com" tpa-label ## zzhffxwcfi7rpddqdigyhpbtaa7vwitu._ssp._domainkey.example.com. IN TXT "d=*.isp.com; s=F;" Author's Address Douglas Otis Trend Micro, NSSG 1737 North First Street, Suite 680 San Jose, CA 95112 USA Phone: +1.408.453.6277 Email: doug_otis@trendmicro.com Otis Expires December 28, 2007 [Page 12] Internet-Draft TPA-SSP June 2007 Full Copyright Statement Copyright (C) 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). Otis Expires December 28, 2007 [Page 13]