Trend Micro, NSSG

1737 North First Street, Suite 680 San Jose CA 95112 USA +1.408.453.6277 doug_otis@trendmicro.com

Internet Area DKIM Working Group TPA-SSP Draft 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. 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 .

This document describes how any email-address domain publishing SSP records defined in can authorize 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 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 trusted identities, as well as noting when a message source may require added scrutiny.

DKIM is fully independent of the SMTP Client and the .MailFrom email-address. Allowing the .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.

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

Syntax descriptions use the form described in Augmented BNF for Syntax Specifications . The "base32" function is defined in and the "sha-1" hash function is defined in . Sender Signing Practices records follow the tag-value syntax described in section 3.2 of . 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 with the exclusion of obs-FWS. The ALPHA and DIGIT tokens are imported from . 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 .From Originator = "O" ; %x4F .Sender/Resent-Sender/Resent-From MailFrom = "M" ; %x4D .MAIL FROM tpa-label = base32( sha-1( lcase(signing-domain))) ; 32 characters Tag Function s= Scope list a= Authorized Signing Domain list Scope Function F Applies to From Header O Applies to Originator Headers M Applies to MAILFROM 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: <tpa-label>._ssp._domainkeys.<email-address domain>.

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)

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.

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

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.

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

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.

This draft extends signing policies related to . 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 . 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.

TBD.

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