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 DOSP Draft DOSP (DKIM Originator's Signing Policy) is a DNS-based mechanism for associating domain-names and asserting separate DKIM related policies for all originating header fields and parameters found in DKIM related messages. DOSP can associate an email-address with a list of signing domains, and a signing domain with a list of SMTP Clients. DOSP also provides a means to assert whether signatures are always initial provided, whether there was an effort to protect these signatures, their role related to offering assurances, such as when an identity referencing the DOSP policy is assured to be valid. 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 signing can be related to all of the various originating header fields and parameters found in DKIM related messages. DOSP better secures the use of the email-addresses and domain-names found in message header fields and parameters. 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 for the following reasons: 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 DOSP can assert that messages originating from a domain within a specific header field or parameter are all initially signed by a designated signing domain. DOSP can also assert that only complaint services are subsequently used with an intended goal of ensuring initial signatures are not damaged or removed. The assurance of using compliant services may enable more stringent message handling by a receiver. DOSP can also assert that an email-address domain is never used. This assertion provides a means for avoiding invalid DKIM signature spoofing of their domain. DOSP does not make distinctions between first-party and third-party signatures. Any designated signature is considered equivalent to a first-party signature for the purposes of policy evaluation. DOSP domain-name associations are only inclusive. The DOSP allows the originating domain to make assertions that indicate when a referencing identity is valid or when a signing domain fulfills DOSP policy requirements. This is accomplished by designating roles for various signing domains. In addition, DOSP allows signing domains to associate with the SMTP Clients. By allowing signing domains to designate their SMTP Clients, anti-replay mechanisms can be by-passed for these SMTP Clients. The goal of DOSP is to: Fully enumerate signing practices for all originating domains Facilitate associations with all other domains Simplify steps for establishing a comprehensive DKIM policy Accommodate all practical deployment strategies Provide a means to assure email-addresses and sources A message signed with DKIM, whether or not there is also a referenced policy, does not indicate when 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 prerequisite. The DKIM signature header field's 'i=' semantics or the DOSP policies regarding the validity of related identities provide valuable advisory information. This advisory information allows the safe application of message annotations for ensuring trusted identities are properly recognized. Policy assertions convey which domains are authoritative and can assure valid identifiers. This information is essential for the proper recognition of valid email-addresses of trusted identities, as well as when a message source may require added scrutiny. The goal of DOSP is to incorporate a full range of possible signing practices. The main objective of DOSP is to establish a basis for evaluating all originating domains and their related email-addresses. As should be expected, DOSP policy assertions are only assurances of the message's the initial state. Blocking messages from non-designated sources or with invalid signatures will not provide sufficient protection, and is also likely to disrupt message delivery in many cases. Senders may become frustrated with delivery problems, while recipients remain exposed to look-alike or "cousin" domain spoofs, and are easily misled when only the display-name is initially seen. For an email-address to be considered valid, it must be signed by either a matching or a designated domain. In addition, this email-address must be fully included within the DKIM Signature header field 'i=' parameter, or must be signed by a domain with a role of only signing valid email-addresses. Even when an email-address is assured to be valid by one of these mechanisms, it is not reasonable to consider all email-addresses from a domain represent equally trustworthy identities or all follow the same practices. For the purposes of annotating messages based upon a trusted domain, local-part associations permit a domain to indicate which identities are trustworthy from their perspective. The recipient must determine independently, through various out-of-band methods, which domains or identities should be considered trustworthy. When trust is based upon a domain-name rather than a specific email-address, message annotations should differ, and should be constrained to those identities asserted as trustworthy in the DOSP local-part policies.

DKIM allows a signing domain to selectively protect portions of a message from modification and to selectively vouch for the validity of an email-address when fully contained within the DKIM Signature header field's 'i=' parameter. Neither this document or prescribe specific actions for receivers to take upon completion of signature validation and policy conformance assessments. While this document allows all originating domains a means to succinctly assert domain associations and signing practices, it does not advise how messages are to be handled. The DKIM protocol is designed to protect message content from alteration and to offer a verified signing domain. However, by design, the signing domain remains unseen by the recipient. Message annotations are required before recipients benefit substantially from DKIM protections. Annotations of assured and trusted email-addresses may entail placement into various folders or the addition of distinctive markings. As with messages handling in general, this document also does not define how message annotations might be accomplished. DKIM is fully independent of the SMTP Client and the .MailFrom email-address. Being able to associate and assert policy for the .MailFrom email-address may prevent Delivery Status Notifications (DSNs) from being sent when this email-address is forged. Being able to associate SMTP Clients with the signing domain may circumvent mechanisms guarding against possible message replay abuse. These two policies represent entirely optional protection strategies that may or may not prove either effective or practical. These are offered only to allow 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 an intrinsic value established by the owner may cause them to become extortion targets. Fees could be added under a guise of being incurred due to poor email administration, for example. Initial costs for domain-names are unlikely to represent a deterrent, and it is unlikely registrars will be able to fairly withdraw domain-names due to unsolicited bulk email practices. In addition, DKIM can not directly identify the domain transmitting the message, and can not prevent abusive message replay. Abusive replay messages 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 correspond with the domain administering the SMTP Client publicly transmitting the message. When the signing domain differs from that of the domain of the originating email-address, DOSP offers a simple solution for email-address policy compliance. Just as a DKIM signature can assert an email-address is valid, a signing domain that only signs validated email-addresses can be designated as playing the role of providing valid email-addresses. This assertion remains valid even when signing domains and the email-address domains differ. A domain could also be designated as only providing a valid signature for fulfilling an assertion that all email-addresses are being signed, but that these email-addresses are not assured to be valid. While this latter role does not ensure all possible spoofing is prevented, these messages should not receive annotations indicating any assurances either. This role represents an economical alternative enabling large scale autonomous administration of domain associations. When the originating email-address domain differs from that of a provider adding DKIM signatures, DNS delegation or key exchanges are required before these domains can match. The provider would need to sign with the customer's key for messages sent using their account. DNS delegations or private key exchanges will likely involve a significant amount of detail, such as key selectors, 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 as indicating valid email-addresses. This DNS delegation effort will likely involve the sharing of these 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 for there to be consistent or standardized formats for the exchange of this information. In addition, when there are any security breaches, the domain owner might be held accountable for message content that was never seen or logged by them. Protections offered by DKIM are largely related to better recognition of prior correspondents, and improved identification of initial sources when instances of abuse are reported. While DOSP may allow the receiver to detect and reject messages that appear non-compliant, the overall cases where this might happen are likely to represent a fairly small portion of the overall messages. When the receiver seeks to protect the DKIM verification process with a preliminary message filter, even acquiring DOSP policy records or DKIM keys may inadvertently leak valuable information benefiting abusive senders. The validation of DKIM and the obtaining of DOSP 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 . The function "lcase" converts upper-case ALPHA characters to lower-case. The terminating period is not included in domain-name conversions. asterisk = %x2A ; "*" plus = %2B ; "+" hyphen = %x2D ; "-" period = %x2E ; "." colon = %x3A ; ":" semicolon = %x3B ; ";" equals = %x3D ; "=" underscore = %x5F ; "_" 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) ; VALCHAR = %x21-3A / %x3C-7E ; "!" to "~" except ";" ALNUMPUNC = ALPHA / DIGIT / underscore ; tag-value = [1*VALCHAR 0*( 1*(WSP / FWS) 1*VALCHAR)] ; tag-list = tag-spec 0*(semicolon tag-spec)[semicolon] ; tag-spec = [FWS] tag-name [FWS] equals [FWS] tag-value [FWS] ; tag-name = ALPHA 0*ALNUMPUNC ; From = "F" ; .From Originator = "O" ; .Sender/Resent-Sender/Resent-From MailFrom = "M" ; .MAIL FROM EHLO = "E" ; .EHLO LocalPart = "L" ; left-hand side of email-address sig-policy = (From / Originator / MailFrom) ; sig-label = base32( sha-1( lcase(signing-domain))) ; 32 characters lp-policy = LocalPart (From / Originator) ; lp-label = base32( sha-1(local-part)) ; 32 characters ehlo-policy = MailFrom ; ehlo-label = base32( sha-1( lcase(EHLO-domain))) ; 32 characters Tag Function v= Version f= Flags a= Designated Signing for Address d= Designated Signing for Domain l= Designated Local-Part Flag Function A All initial messages signed N Not signing O Only compliant subsequent services employed L Local-Part policies are published T Trusted Designated Local-Part V Valid Designated Local-Part The receiver obtains the DOSP 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. The content of this concatenated string contains a tag-list based upon the ABNF format defined within this section. Unrecognized tags MUST be ignored. A policy record may be located at these domains: "<sig-label>._DKIM-<sig-policy>.<email-address domain>." "<lp-label>._DKIM-<lp-policy>.<email-address domain>." "<ehlo-label>._DKIM-<ehlo-policy>.<signing domain>."

v= Version (MUST be included). This tag defines the version of this specification that applies to the signature record. It MUST have the value 0.0. Version = %x76 [FWS] equals [FWS] "0.0" INFORMATIVE NOTE: DKIM-Signature version numbers are expected to increase arithmetically as new versions of this specification are released. [INFORMATIVE NOTE: Upon publication, this version number should be changed to "1", and this note should be delete.]

f= Flags (Optional). This tag defines a list of flags that assert various aspects of the email-address domain signing policy. flag = %x41 / %x4C / %x4E / %x4F ; "A", "L", "O", "T", & "V" Flags =%x66 [FWS] equals [FWS] flag 0*(*FWS colon *FWS flag)

This "A" flag asserts that messages carrying the email-address domain within the relevant header field or parameter are all initially signed by a designated domain.

This "L" flag asserts that local-part policy is published for the corresponding message header field or parameter. For example when a policy is published at <sig-label>._DKIM-F.<email-address domain> that has the "L" flag asserted, then local-part policy can be found at <lp-label>._DKIM-LF.<email-address domain>. This flag is not valid in "ehlo-policy" records.

This "N" flag asserts that messages carrying the email-address domain within the relevant header field or parameter are not initially signed. This assertion might be suitable as a means to prevent or terminate a policy record search, and to assure that no signatures are generated by this domain as a means to prevent invalid signature spoofing.

This "O" flag asserts that messages carrying the email-address domain within the relevant header field or parameter are not subsequently used in conjunction with services that may either damage or remove the initial signature. This assertion might be suitable for domains willing to forego the use of many common services where signatures might be damaged, for example.

This "T" flag asserts that messages carrying the email-address containing a designated local-part found in the 'l=' tag local-part list are considered trustworthy by the email-address domain. This flag is not valid in "ehlo-policy" records.

This "V" flag asserts that messages carrying the email-address containing a designated local-part found in the 'l=' tag local-part list are considered to be valid by the email-address domain. This flag is not valid in "ehlo-policy" records.

a= Designated Signing for Address (Optional). This list defines domains considered to be the equivalent of the respective email-address domain for the purpose of assessing policy. These domains do not play the role of providing valid email-addresses, they only provide valid signatures. When the domain is prefixed with the "*." wildcard label, then all subdomains of this domain are also included to allow multiple "sig-labels" to share a common resource record. It is possible for a signing domain to be at a higher level than the respective email-address domain and not be designated. When the signing domain is not specifically listed within either designated signing domain lists (a= & d=), no policy related assurances are made. This list is not valid in "ehlo-policy" records. When the signing domain used to generate the "sig-label" is not found in the list, and the list is not empty, the policy should be obtained by replacing the "sig-label" with "*" instead. In practice, this step should rarely be needed. dsa = [ANY] domain 0*(*FWS colon *FWS [ANY] domain) dsa-list = %x61 [FWS] equals [FWS] dsa

d= Designated Signing for Address (Optional). This list defines domains considered to be the equivalent of the respective email-address domain for the purpose of assessing policy. In addition, these domains play the role of providing valid email-addresses. When the domain is prefixed with the "*." wildcard label, then all subdomains of this domain are also included, which allows multiple "sig-labels" to share a common resource record. It is possible for a signing domain to be at a higher level than the respective email-address domain and not be designated. When the signing domain is not specifically listed within either designated signing domain lists (a= & d=), no policy related assurances are made. This list also confirms SMTP Client domains in "ehlo-policy" records. When the EHLO or signing domain used to generate the "ehlo-label" or "sig-label" respectively is not found in the list, and the list is not empty, the policy should be obtained by replacing the "ehlo-label" or "sig-label" with "*" instead. In practice, this step should rarely be needed. dsd = [ANY] domain 0*(*FWS colon *FWS [ANY] domain) dsd-list = %x64 [FWS] equals [FWS] dsd

l= Local-Part policy published (Optional). This tag lists the designated local-part for which policy is being published. The local-part values contained within this tag confirms that the policy applies for the listed local-parts. These local-part values may be included in policies not referenced using "lp-labels". It is expected only a few email-addresses warrant special handling. When the local-part used to generate the "lp-label" is not found in the list, and the list is not empty, the policy should be obtained by replacing the "lp-label" with "*" instead. In practice, this step should rarely be needed. This list is not valid in "ehlo-policy" records. lp = local-part 0*(*FWS colon *FWS local-part) lp-list = %x6C [FWS] equals [FWS] lp

The default policy assumed is the same as when no optional fields are entered in the DOSP records. This default policy makes no assurance about whether all initial messages have been signed and does not include any additional domain associations. When a policy flags is asserted, it may be necessary to list the respective email-address domains in either the "Designated Signing for Address" (a=) or "Designated Signing for Domain" (d=) list. Listing the email-address domain in the "Designated Signing for Domain" list asserts that regardless of the DKIM signature header field's 'i=' semantics, email-address should not be considered valid. When the "Designated Signing for Domain" (d=) list applies in the case of the of .MailFrom parameter, this is indicative of a valid signature satisfying a possibly asserted "(A)ll initial messages signed" flag. It is unlikely there are benefits obtained by listing the domain in "Designated Signing for Address" (a=) list. When both the "Designated Signing for Address" (a=) and "Designated Signing for Domain" (d=) list are empty, and the "(A)ll initial messages signed" flag is asserted, this then means that no mail originates from this domain. A domain that ensures that all messages are initially signed and attempts to ensure their users employ only complaint services, may indicate this extraordinary effort is being made by asserting both the "(A)ll initial messages signed" and the "(O)nly compliant services employed" flags. This combination of flags could be helpful in overcoming phishing attempts without negatively affecting domains that assert just the "(A)ll initial messages signed" flag. Future flags may make use of the "+" symbol to indicate a logical OR of the related assertions. The current ":" flag separator can be considered to represent a logical AND of the related assertions.

This document may wish IANA to reserve the use of the "_DKIM-F", "_DKIM-LF", "_DKIM-O", "_DKIM-LO", "_DKIM-M", and "_DKIM-E" domain-name label. Note to RFC Editor: this section may be removed on publication as an RFC and no request is desired or considered practical.

This draft defines signing policies related to . There is no expectation this policy information is from an authenticated source. Network resources expended to acquire this information should be proportional to that needed to verify the signature. Strategies used by the receiver to limit possible amplifications that might occur with signature verification should also limit the impact of obtaining this information. 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 a default value.

Hector Santos, and Frank Ellermann.

#### # example.com email domain using isp.com as a signing domain # EHLO host-name mx-01.example.com. IN A 10.1.1.1 #### 2822.From policy *.DKIM-F.example.com. IN TXT "v=0.0; a=*.example.com; l=admin; f=A:T:V;" # "isp.com" sig-label hgssd3snmi6635j5743vdjhajkmpmfif.DKIM-F.example.com. IN TXT "v=0.0; a=isp.com; f=A;" #### 2821.MailFrom policy *.DKIM-M.example.com. IN TXT "v=0.0; a=*.example.com; f=A;" # "isp.com" sig-label hgssd3snmi6635j5743vdjhajkmpmfif.DKIM-M.example.com. IN TXT "v=0.0; a=isp.com; f=A;" #### 2822.Sender policy *.DKIM-O.example.com. IN TXT "v=0.0; a=*.example.com; f=A;" # "isp.com" sig-label hgssd3snmi6635j5743vdjhajkmpmfif.DKIM-O.example.com. IN TXT "v=0.0; a=isp.com; f=A;" #### 2821.EHLO policy *.DKIM-E.example.com. IN TXT "v=0.0; a=*.example.com; f=A;" # "mx-01.example.com" ehlo-label inkzgjwvtenf4zjexukzo4qknqhgwee6.DKIM-E.example.com. IN TXT "v=0.0; a=*.example.com; f=A;"